Tre mål og grensene deres#
Google måler hvordan nettstedet oppleves med tre mål. Vurderingen gjøres ved 75. persentil, altså hvordan det går for tre av fire besøk [1]. Google bruker målene i systemene sine for sideopplevelse [2].
✓ God ! Bør forbedres ✕ Dårlig
Vis som tabell
| Mål | God | Bør forbedres | Dårlig |
|---|---|---|---|
| LCP | høyst 2,5 s | 2,5-4 s | over 4 s |
| INP | høyst 200 ms | 200-500 ms | over 500 ms |
| CLS | høyst 0,1 | 0,1-0,25 | over 0,25 |
Hvor tallene kommer fra#
Tallene kommer fra Chrome UX Report: anonyme data fra ekte Chrome-brukere som deler statistikk. Bare nettsteder med nok besøk er med, og Google sier ikke hvor terskelen går [3]. Hvis data mangler for nettstedet ditt, sier vi det. Vi gjetter aldri et tall.
Vårt krav: under 0,7 sekunder#
Googles grenser er et minstenivå. På nettsteder vi bygger og drifter, krever vi mer: hovedinnholdet må vises innen 0,7 sekunder på en datamaskin, og serveren må svare innen 0,2 sekunder. På mobil, der Google forutsetter et tregere 4G-nett, må siden klare Googles grense for god med margin. Kravene gjelder både det nye designet og kopien av kundens nåværende nettsted [4] [5].
| Mål | Googles grense for god | Vårt krav til våre nettsteder |
|---|---|---|
| Serverens svar (TTFB) | høyst 0,8 s (anbefaling) | høyst 0,2 s |
| Det første innholdet vises (FCP) | høyst 1,8 s (anbefaling) | høyst 0,8 s |
| Hovedinnholdet vises (LCP), datamaskin | høyst 2,5 s | høyst 0,7 s |
| Hovedinnholdet vises (LCP), mobil på 4G | høyst 2,5 s | høyst 2,5 s, mål 1,0 s |
| Respons når du klikker (INP) | høyst 0,2 s | høyst 0,1 s |
| Layoutforskyvning (CLS) | høyst 0,1 | høyst 0,1, mål 0,02 |
| Lighthouse-ytelse | 90+ regnes som god | 90-100 |
| Lighthouse SEO og tilgjengelighet | ikke noe krav fra Google | 95-100 |
Slik tester vi hastigheten#
- Hvert nettsted vi bygger eller forhåndsviser, testes med Googles PageSpeed Insights, på mobil og datamaskin, minst én gang i uken og etter hver endring. Et nettsted som ikke klarer kravet, vises med en gang i driften vår, med hva som må rettes [6].
- Hvert nettsted vi analyserer, også kundens nåværende, testes på samme måte. Selgeren ser tallet med kilde, for eksempel hvor mange sekunder det tar før hovedinnholdet vises på mobil, sammenlignet med Googles grense.
- Hvis nettstedet har nok besøkende, viser vi også Googles måling av ekte besøkende (Chrome UX Report), som er det Google selv bruker [3].
Dette gjør vi for at nettstedet skal være raskt#
- Siden sendes ferdig fra serveren, med den viktigste stilen direkte i siden, så ingenting må vente på skript.
- Hovedbildet hentes først og i riktig størrelse for skjermen; bilder lenger ned lastes når den besøkende ruller dit.
- Skriftene ligger på vår egen server, og en reservestil med de samme målene hindrer teksten i å hoppe når skriften kommer.
- Neste side hentes på forhånd når den besøkende peker på en lenke, så den åpnes med en gang.
- Bakgrunnsarbeid på serveren kommer alltid etter de besøkendes sider.
- Vi viser Googles måling i analysen når den finnes, med dato og kilde.
Bilder#
Hvordan bilder bør navngis, beskrives og lastes, og hva mytene om EXIF og GPS er, står i Bilder og filnavn.
Hvor raskt er nettstedet ditt?
Den gratis analysen måler hastigheten på mobil og datamaskin.
0 SEK · ingen registrering · svar på omtrent ett minutt
Kilder på denne siden
- Web Vitals: måleverdier og terskler web.dev (Google) · Offisiell dokumentasjon
- Core Web Vitals og Google Søk Google Search Central · Offisiell dokumentasjon
- Chrome UX Report: metode Chrome for Developers · Offisiell dokumentasjon
- Largest Contentful Paint (LCP) web.dev (Google) · Offisiell dokumentasjon
- Time to First Byte (TTFB) web.dev (Google) · Offisiell dokumentasjon
- Om PageSpeed Insights Google for Developers · Offisiell dokumentasjon