Tre mål og deres grænser#
Google måler, hvordan hjemmesiden opleves, med tre mål. Vurderingen sker ved den 75. percentil, altså hvordan det går for tre ud af fire besøg [1]. Google bruger målene i sine systemer for sideoplevelse [2].
✓ Godt ! Skal forbedres ✕ Dårligt
Vis som tabel
| Mål | Godt | Skal forbedres | Dårligt |
|---|---|---|---|
| LCP | højst 2,5 s | 2,5-4 s | over 4 s |
| INP | højst 200 ms | 200-500 ms | over 500 ms |
| CLS | højst 0,1 | 0,1-0,25 | over 0,25 |
Hvor tallene kommer fra#
Tallene kommer fra Chrome UX Report: anonyme data fra rigtige Chrome-brugere, der deler statistik. Kun hjemmesider med tilstrækkeligt mange besøg er med, og Google siger ikke, hvor grænsen går [3]. Mangler der data for din hjemmeside, siger vi det. Vi gætter aldrig et tal.
Vores krav: under 0,7 sekunder#
Googles grænser er et minimum. På hjemmesider, vi bygger og driver, kræver vi mere: hovedindholdet skal vises inden for 0,7 sekunder på en computer, og serveren skal svare inden for 0,2 sekunder. På mobilen, hvor Google regner med et langsommere 4G-net, skal siden klare Googles grænse for godt med margin. Kravene gælder både det nye design og kopien af kundens nuværende hjemmeside [4] [5].
| Mål | Googles grænse for godt | Vores krav til vores hjemmesider |
|---|---|---|
| Serverens svar (TTFB) | højst 0,8 s (anbefaling) | højst 0,2 s |
| Det første indhold vises (FCP) | højst 1,8 s (anbefaling) | højst 0,8 s |
| Hovedindholdet vises (LCP), computer | højst 2,5 s | højst 0,7 s |
| Hovedindholdet vises (LCP), mobil på 4G | højst 2,5 s | højst 2,5 s, mål 1,0 s |
| Svar, når man klikker (INP) | højst 0,2 s | højst 0,1 s |
| Layoutskift (CLS) | højst 0,1 | højst 0,1, mål 0,02 |
| Lighthouse-ydeevne | 90+ regnes som godt | 90-100 |
| Lighthouse SEO og tilgængelighed | intet krav fra Google | 95-100 |
Sådan tester vi hastigheden#
- Hver hjemmeside, vi bygger eller viser som forhåndsvisning, testes med Googles PageSpeed Insights, på mobil og computer, mindst én gang om ugen og efter hver ændring. En hjemmeside, der ikke lever op til kravet, ses straks i vores drift med det, der skal rettes [6].
- Hver hjemmeside, vi analyserer, også kundens nuværende, testes på samme måde. Sælgeren ser tallet med kilde, for eksempel hvor mange sekunder det tager, før hovedindholdet vises på mobilen, sammenlignet med Googles grænse.
- Har hjemmesiden tilstrækkeligt mange besøgende, viser vi også Googles måling af rigtige besøgende (Chrome UX Report), som er det, Google selv bruger [3].
Det gør vi, for at hjemmesiden skal være hurtig#
- Siden sendes færdig fra serveren med den vigtigste stil direkte i siden, så intet skal vente på scripts.
- Hovedbilledet hentes først og i den rigtige størrelse til skærmen; billeder længere nede indlæses, når den besøgende scroller derned.
- Skrifttyperne ligger på vores egen server, og en reservestil med de samme mål sørger for, at teksten ikke hopper, når skrifttypen kommer.
- Den næste side hentes på forhånd, når den besøgende peger på et link, så den åbner med det samme.
- Baggrundsarbejde på serveren kommer altid efter de besøgendes sider.
- Vi viser Googles måling i analysen, når den findes, med dato og kilde.
Billeder#
Hvordan billeder skal navngives, beskrives og indlæses, og hvad der er myter om EXIF og GPS, står i Billeder og filnavne.
Hvor hurtig er din hjemmeside?
Den gratis analyse måler hastigheden på mobil og computer.
0 SEK · ingen tilmelding · svar på cirka et minut
Kilder på denne side
- Web Vitals: mål og grænseværdier web.dev (Google) · Officiel dokumentation
- Core Web Vitals og Google Søgning Google Search Central · Officiel dokumentation
- Chrome UX Report: metode Chrome for Developers · Officiel dokumentation
- Largest Contentful Paint (LCP) web.dev (Google) · Officiel dokumentation
- Time to First Byte (TTFB) web.dev (Google) · Officiel dokumentation
- Om PageSpeed Insights Google for Developers · Officiel dokumentation