Hastighet
Hastighet: Googles gränser och vårt krav
De tre måtten Google använder (Core Web Vitals), gränserna för bra, vårt eget krav på varje sajt vi bygger (huvudinnehållet på under 0,7 sekunder) och hur vi testar hastigheten på varje sajt.
Tre mått och deras gränser
Google mäter hur sajten upplevs med tre mått. Bedömningen görs på den 75:e percentilen, alltså hur det går för tre av fyra besök [1]. Google använder måtten i sina system för sidupplevelse [2].
✓ Bra ! Behöver förbättras ✕ Dåligt
Visa som tabell
| Mått | Bra | Behöver förbättras | Dåligt |
|---|---|---|---|
| LCP | högst 2,5 s | 2,5–4 s | över 4 s |
| INP | högst 200 ms | 200–500 ms | över 500 ms |
| CLS | högst 0,1 | 0,1–0,25 | över 0,25 |
Varifrån siffrorna kommer
Siffrorna kommer från Chrome UX Report: anonym data från riktiga Chrome-användare som delar statistik. Bara sajter med tillräckligt många besök finns med, och Google talar inte om var gränsen går [3]. Saknas data för er sajt säger vi det. Vi gissar aldrig fram en siffra.
Vårt krav: under 0,7 sekunder
Googles gränser är en miniminivå. På sajter vi bygger och driver kräver vi mer: huvudinnehållet ska synas inom 0,7 sekunder på en dator och servern ska svara inom 0,2 sekunder. I mobilen, där Google räknar med ett långsammare 4G-nät, ska sidan klara Googles gräns för bra med marginal. Kraven gäller både den nya designen och kopian av kundens nuvarande sajt [4] [5].
| Mått | Googles gräns för bra | Vårt krav på våra sajter |
|---|---|---|
| Serverns svar (TTFB) | högst 0,8 s (rekommendation) | högst 0,2 s |
| Första innehållet syns (FCP) | högst 1,8 s (rekommendation) | högst 0,8 s |
| Huvudinnehållet syns (LCP), dator | högst 2,5 s | högst 0,7 s |
| Huvudinnehållet syns (LCP), mobil på 4G | högst 2,5 s | högst 2,5 s, mål 1,0 s |
| Svar när man klickar (INP) | högst 0,2 s | högst 0,1 s |
| Layoutskift (CLS) | högst 0,1 | högst 0,1, mål 0,02 |
| Lighthouse prestanda | 90+ räknas som bra | 90–100 |
| Lighthouse SEO och tillgänglighet | inget krav från Google | 95–100 |
Så testar vi hastigheten
- Varje sajt vi bygger eller förhandsvisar testas med Googles PageSpeed Insights, i mobil och dator, minst en gång i veckan och efter varje ändring. En sajt som missar kravet syns direkt i vår drift med vad som ska åtgärdas [6].
- Varje sajt vi analyserar, också kundens nuvarande, testas på samma sätt. Säljaren ser siffran med källa, till exempel hur många sekunder det tar innan huvudinnehållet syns i mobilen jämfört med Googles gräns.
- Har sajten tillräckligt många besökare visar vi också Googles mätning av riktiga besökare (Chrome UX Report), som är det Google själv använder [3].
Det här gör vi för att sajten ska vara snabb
- Sidan skickas färdig från servern, med den viktigaste stilen direkt i sidan, så att inget behöver vänta på script.
- Huvudbilden hämtas först och i rätt storlek för skärmen; bilder längre ner laddas när besökaren scrollar dit.
- Typsnitten ligger på vår egen server, och en reservstil med samma mått gör att texten inte hoppar när typsnittet kommer.
- Nästa sida hämtas i förväg när besökaren pekar på en länk, så att den öppnas direkt.
- Bakgrundsarbete på servern går alltid efter besökarnas sidor.
- Vi visar Googles mätning i analysen när den finns, med datum och källa.
Hur snabb är er webbplats?
Den kostnadsfria analysen mäter hastigheten på mobil och dator.
0 kr · ingen registrering · svar på ungefär en minut
Källor på den här sidan
- Web Vitals: mått och gränsvärden web.dev (Google) · Officiell dokumentation
- Core Web Vitals och Google Sök Google Search Central · Officiell dokumentation
- Chrome UX Report: metod Chrome for Developers · Officiell dokumentation
- Largest Contentful Paint (LCP) web.dev (Google) · Officiell dokumentation
- Time to First Byte (TTFB) web.dev (Google) · Officiell dokumentation
- Om PageSpeed Insights Google for Developers · Officiell dokumentation
NOVAI Pulse · Kunskapsbanken uppdaterad 12 oktober 2026. Hittar du något som inte stämmer? Säg till din kontaktperson så rättar vi.