Tre sekunder. Det är allt du har
Tänk dig det här. En potentiell kund googlar exakt det du säljer. Din sida dyker upp. De klickar. Och sedan… väntar de. En sekund. Två sekunder. Tre sekunder. Borta. De har redan tryckt på tillbaka-knappen och valt din konkurrent istället.
Det låter dramatiskt, men siffrorna ljuger inte. Google har själva visat att sannolikheten för att en besökare lämnar sidan ökar med 32% när laddningstiden går från en till tre sekunder. Vid fem sekunder? Då har du tappat över hälften. Och det handlar inte bara om besökare – det handlar om hur Google rankar dig.
Sedan 2021, när Google rullade ut sina Core Web Vitals som rankningsfaktor, är laddningstid inte längre bara en trevlig bonus. Det är en grundpelare i modern sökmotoroptimering. Punkt.
Google mäter din sida som en besatt kontrollant
Förr räckte det med bra innehåll och rätt nyckelord. Inte längre. Google har blivit besatt av användarupplevelsen, och laddningstid är kärnan i den besattheten.
Tre mätvärden styr spelet just nu. Largest Contentful Paint (LCP) mäter hur lång tid det tar innan det största synliga elementet på sidan – ofta en hero-bild eller en stor rubrik – har renderats. Google vill se det under 2,5 sekunder. First Input Delay (FID), som nu ersatts av Interaction to Next Paint (INP), mäter hur snabbt sidan reagerar när någon klickar på något. Och Cumulative Layout Shift (CLS) mäter hur mycket saker hoppar runt på skärmen medan sidan laddar.
Du vet känslan. Du ska precis trycka på en länk, och plötsligt dyker en banner upp ovanifrån och du klickar på fel sak istället. Det där hatar Google. Och ärligt talat – det hatar vi alla.
Men vet du vad? De flesta webbplatser jag granskar missar minst ett av dessa mätvärden. Ofta alla tre. Och ägarna har ingen aning om det förrän de undrar varför trafiken sjunker.
Bilderna – den tysta banditen som stjäl dina millisekunder
Om jag fick peka ut en enda sak som dödar laddningstiden på svenska webbplatser, skulle det vara bilder. Varje gång.
Jag ser det konstant. En e-handlare som laddar upp produktbilder rakt från fotografens kamera – 4000 pixlar breda, 8 megabyte styck, i PNG-format. På en kategorisida med 40 produkter pratar vi plötsligt om hundratals megabyte data som ska tryckas genom ledningen. Det är vansinne.
Lösningen är enklare än du tror. Konvertera till WebP eller AVIF-format. En bild som väger 2 MB i JPEG kan krympa till 200 KB i WebP utan synlig kvalitetsförlust. Använd lazy loading så att bilder under folden – alltså de som inte syns direkt på skärmen – inte laddas förrän besökaren scrollar ner. Och för guds skull, ange width och height i HTML:en så att webbläsaren kan reservera rätt utrymme och undvika layouthopp.
Ett konkret exempel: jag jobbade med en restaurangsida i Göteborg som hade en bildkarusell på startsidan med sex stycken okomprimerade bilder. Totalt laddade startsidan 23 MB. Efter bildoptimering landade vi på 1,4 MB. LCP-tiden gick från 7,2 sekunder till 1,8. Rankingen för deras viktigaste sökord klättrade fyra positioner inom sex veckor.
Din server spelar större roll än du tror
Många fokuserar på frontend-optimering och glömmer helt bort vad som händer på servern. Men det spelar ingen roll hur optimerad din kod är om servern sitter och tuggar i tre sekunder innan den ens börjar skicka data.
Time to First Byte (TTFB) – tiden från att webbläsaren skickar en förfrågan tills den får tillbaka den första byten av data – bör ligga under 800 millisekunder. Helst under 200. Om du sitter på ett billigt delat webbhotell där din sida delar resurser med hundratals andra webbplatser, ja, då kan du räkna med att TTFB blir lidande.
Vad kan du göra? Uppgradera till en VPS eller dedikerad server om trafiken motiverar det. Använd ett CDN – Content Delivery Network – som Cloudflare eller Fastly. Ett CDN cachar din sida på servrar runt om i världen, så en besökare i Malmö inte behöver hämta data från en server i Texas. Skillnaden kan vara enorm.
Och om du kör WordPress – snälla, se över dina plugins. Jag har sett WordPress-installationer med 47 aktiva plugins där varje sidladdning triggar 200 databasfrågor. Det är som att be en bil köra snabbt med handbromsen i.
CSS och JavaScript – rensa, minifiera, skjut upp
Varje CSS-fil och JavaScript-fil som din sida laddar är en förfrågan som webbläsaren måste hantera. Och renderblockering – det är det riktiga problemet.
Renderblockering innebär att webbläsaren inte kan visa något på skärmen förrän den har laddat klart och tolkat vissa filer. Om du har en stor CSS-fil som importerar tre Google Fonts, en jQuery-fil, ett analysverktyg och ett chatbot-script som alla laddas i head-taggen – ja, då står besökaren och stirrar på en vit skärm medan allt det där processas.
Lösningen? Identifiera vilken CSS som faktiskt behövs för det som syns ovanför folden – så kallad critical CSS – och lägg den inline direkt i HTML:en. Resten kan laddas asynkront. JavaScript som inte behövs direkt kan märkas med defer eller async. Minifiera allt. Ta bort oanvänd kod.
Det finns verktyg som gör det här nästan automatiskt. PurgeCSS rensar bort CSS-regler som aldrig används. Terser minifierar JavaScript. Och om du använder ett modernt ramverk som Next.js eller Nuxt får du mycket av det här på köpet – men bara om du konfigurerar det rätt.
En sak till. Google Fonts. Jag älskar dem, men de kan vara en prestanda-mördare om du inte är försiktig. Ladda bara de vikter och stilar du faktiskt använder. Överväg att hosta fonterna själv istället för att hämta dem från Googles servrar – det eliminerar en extern förfrågan och ger dig mer kontroll över caching.
Caching – låt inte webbläsaren göra samma jobb två gånger
Caching är ett av de mest underskattade verktygen för snabbare laddningstider. Konceptet är enkelt: om en besökare redan har laddat din logotyp en gång, varför ska webbläsaren ladda ner den igen nästa gång?
Browser caching låter dig tala om för webbläsaren hur länge den ska spara olika typer av filer. En logotyp som aldrig ändras? Cacha den i ett år. En CSS-fil som uppdateras ibland? Kanske en vecka, med versionsnummer i filnamnet så att ändringar slår igenom direkt.
Server-side caching är minst lika viktigt. Om du kör en dynamisk sida – WordPress, WooCommerce, Magento – genereras HTML:en på nytt vid varje sidladdning. Det innebär databasfrågor, PHP-exekvering och templating varje gång. Med server-side caching sparar du den färdiga HTML-sidan och serverar den direkt. Verktyg som Varnish, Redis eller till och med enkla WordPress-plugins som WP Super Cache kan göra dramatisk skillnad.
Faktum är att jag sett sidor gå från 4 sekunders laddningstid till under en sekund bara genom att implementera ordentlig caching. Ingen kodändring. Ingen serveruppgradering. Bara smart caching.
Mät, åtgärda, mät igen – den enda metoden som fungerar
Du kan inte förbättra det du inte mäter. Börja med Google PageSpeed Insights. Det är gratis, det är direkt kopplat till hur Google bedömer din sida, och det ger konkreta rekommendationer. Kör din startsida. Kör dina viktigaste landningssidor. Kör din produktsida med flest besökare.
Men stanna inte där. PageSpeed Insights visar laboratoriedata – simulerade tester. Google Search Console visar fältdata – hur riktiga användare faktiskt upplever din sida. Det är fältdatan som påverkar din ranking. Ibland ser labbtesterna bra ut men fältdatan avslöjar problem, särskilt på mobila enheter med svagare processorer och långsammare uppkopplingar.
GTmetrix och WebPageTest ger dig djupare insikter. Vattenfallsdiagram som visar exakt vilka resurser som laddas, i vilken ordning, och hur lång tid varje del tar. Det är där du hittar de riktiga bovarna.
Och sedan – prioritera. Allt behöver inte fixas samtidigt. Börja med det som ger störst effekt. Ofta är det bildoptimering och caching. Sedan server-konfiguration. Sedan CSS och JavaScript. Jobba systematiskt. Mät efter varje förändring. Ibland gör en åtgärd saken värre på oväntade sätt – det enda sättet att veta är att mäta.
Mobilen först – för det är där dina besökare är
Över 60% av all webbtrafik i Sverige kommer från mobila enheter. Och Google indexerar din sida baserat på mobilversionen. Inte desktopversionen. Mobilversionen.
Det betyder att om din sida laddar snabbt på en stationär dator med fiber men kryper fram på en iPhone med 4G, ja, då är det mobilupplevelsen som räknas. Och mobila enheter har sämre processorer, mindre minne och ofta långsammare uppkoppling. Allt du gör för att optimera laddningstiden behöver testas med mobilanvändaren i åtanke.
Responsiva bilder med srcset-attributet är guld här. Istället för att skicka en 2000 pixlar bred bild till en telefon med 400 pixlar bred skärm, låter du webbläsaren välja rätt storlek. Det sparar data och snabbar upp renderingen markant.
Tänk också på touch-targets och interaktivitet. En knapp som tar en sekund att reagera på en telefon förstör upplevelsen – och ditt INP-värde.
Hastighet är inte allt, men det är grunden
Jag vill vara ärlig. Att ha världens snabbaste webbplats hjälper inte om innehållet är uselt, om ingen länkar till dig, eller om du riktar in dig på fel sökord. Laddningstid är en rankningsfaktor bland många. Men det är en grundförutsättning.
Tänk på det så här. Om två sidor har lika bra innehåll, lika starka backlinks och lika relevant struktur – men den ena laddar på 1,5 sekunder och den andra på 4,5 – vem tror du Google väljer? Precis.
Och bortom Google handlar det om konvertering. Amazon räknade ut att varje 100 millisekunder extra laddningstid kostade dem 1% i försäljning. Du är inte Amazon, men proportionerna gäller. Snabbare sidor konverterar bättre. Det är inte en åsikt – det är data från tusentals A/B-tester.
Så börja idag. Öppna PageSpeed Insights. Kör din sida. Titta på siffrorna. Och gör en sak – bara en enda sak – för att göra den snabbare. Komprimera bilderna. Aktivera caching. Flytta ett script till defer. Det spelar ingen roll vad du börjar med. Det som spelar roll är att du börjar.
Din ranking, dina besökare och din plånbok kommer att tacka dig.