PageSpeed Insights uitgelegd: wat elke score betekent en hoe u die verbetert
PageSpeed Insights uitgelegd
PageSpeed Insights uitgelegd: scores, metrics en oplossingen | We.Inc
Wat elk getal in PageSpeed Insights betekent, field data vs lab data, drempels voor LCP, INP, CLS, FCP en TTFB, scoregewichten en code die rode resultaten oplost.
PageSpeed Insights toont twee rapporten. Het bovenste is field data van echte Chrome-bezoekers over de afgelopen 28 dagen, beoordeeld op het 75e percentiel. Het onderste is een Lighthouse-labtest met een score van 0 tot 100: 90 of hoger is goed, 50 tot 89 kan beter, onder 50 is slecht. Los eerst de field-metrics op.
Drempels voor field-metrics die PageSpeed Insights gebruikt
Metric
Goed
Kan beter
Slecht
LCP (Largest Contentful Paint)
2.5 s of minder
2.5 tot 4 s
meer dan 4 s
INP (Interaction to Next Paint)
200 ms of minder
200 tot 500 ms
meer dan 500 ms
CLS (Cumulative Layout Shift)
0.1 of minder
0.1 tot 0.25
meer dan 0.25
FCP (First Contentful Paint)
1.8 s of minder
1.8 tot 3 s
meer dan 3 s
TTFB (experimenteel)
0.8 s of minder
0.8 tot 1.8 s
meer dan 1.8 s
De meeste mensen staren naar de grote ronde score, maar dat getal komt van één gesimuleerd bezoek op een afgeremde telefoon. Deze gids haalt de twee helften van het rapport uit elkaar, laat u uw eigen getallen beoordelen aan de officiële drempels en koppelt elke rode metric aan de wijziging die er meestal verschil in maakt.
Test uw URL op pagespeed.web.dev en kijk eerst naar het blok met field data. Staat er dat er niet genoeg data is, dan is alleen de labtest beschikbaar.
Vul uw waarden voor LCP, INP, CLS, FCP en TTFB in de beoordelaar hieronder in om te zien in welke categorie elke waarde valt.
Open het onderdeel met oplossingen voor de slechtste metric en voer de bijbehorende codewijziging door.
Wacht op nieuwe field data. Het rapport met echte gebruikers beslaat steeds de laatste 28 dagen, dus verbeteringen verschijnen geleidelijk en niet de volgende ochtend.
De mobiele labtest draait op een geëmuleerde middenklasse-telefoon met een traag netwerk, dus een lagere mobiele score dan op desktop is normaal.
Labscores schommelen een paar punten tussen tests. Draai de test drie keer en kijk naar de middelste uitkomst voordat u concludeert dat er iets veranderd is.
De labtest kan INP niet meten, omdat niemand ergens op klikt. Total Blocking Time is de vervanger, dus een hoge TBT voorspelt meestal een slechte INP.
Tags van derden zoals chatwidgets, heatmaps en advertentiescripts kosten vaak meer dan uw eigen code. Bekijk de lijst met verzoeken van derden voordat u uw app herschrijft.
Veelgestelde vragen
Waarom verschillen mijn field data en labscore zo sterk?
Ze meten verschillende dingen. Field data is wat echte Chrome-gebruikers op hun eigen apparaten en netwerken over 28 dagen ervoeren. De labscore is één gesimuleerde laadbeurt met vaste vertraging. Een pagina kan in het lab 60 scoren en in het veld toch slagen voor Core Web Vitals, of andersom.
Telt de Lighthouse-score mee voor de rankings in Google?
Google beschrijft Core Web Vitals als metingen van de echte gebruikerservaring die aansluiten bij wat de kernrankingsystemen belonen. De Search-richtlijnen noemen de labscore van 0 tot 100 niet als rankingfactor, dus gebruik die score als diagnosemiddel om problemen te vinden.
Wat is TTFB en wat is een goede waarde?
Time to First Byte is hoe lang de browser wacht voordat de eerste byte van de HTML binnenkomt, inclusief redirects, DNS, het opzetten van de verbinding en serverwerk. PageSpeed Insights beschouwt 800 ms of minder als goed. HTML cachen aan de rand van een CDN is de meest voorkomende oplossing.
Hoe wordt de prestatiescore van Lighthouse berekend?
In Lighthouse 10 en later is het een gewogen mix van vijf labmetrics: Total Blocking Time 30 procent, LCP 25 procent, CLS 25 procent, FCP 10 procent en Speed Index 10 procent. Elke metric wordt eerst via een curve omgezet in een deelscore van 0 tot 100.
Waarom staat er dat er geen field data voor mijn site is?
Het Chrome User Experience Report publiceert alleen data voor pagina's en origins met genoeg geschikte bezoeken. Nieuwe sites of sites met weinig verkeer hebben vaak niets, dus vertrouw op de labtest plus uw eigen monitoring tot het verkeer groeit.
Lees het rapport van boven naar beneden
Het eerste blok beantwoordt of echte bezoekers een goede ervaring hadden. Het toont voor elke metric de waarde op het 75e percentiel, wat betekent dat drie van de vier bezoeken minstens zo snel waren. Het doel is slagen voor alle drie de Core Web Vitals (LCP, INP en CLS).
Het tweede blok is één Lighthouse-run. In de diagnoses en kansen ontdekt u waarom een field-metric traag is, omdat de labtrace de werkelijke bestanden, afbeeldingen en scripts noemt.
Een uitgewerkt voor en na
Neem een typische homepage van een klein bedrijf met een heroafbeelding over de volle breedte die lazy geladen wordt, een webfont zonder fallbackstrategie en drie marketingtags in de head. In dit voorbeeld begint de LCP-afbeelding pas te downloaden nadat het script klaar is, dus LCP komt in de slechte categorie terecht.
Door loading=lazy van de hero te halen, fetchpriority=high toe te voegen, de foto als AVIF of WebP op de weergegeven grootte te serveren en de tags pas te laden als de pagina interactief is, pakt u elk deel van LCP aan. Dat zijn de wijzigingen in de code hieronder; uw eigen getallen hangen af van uw pagina.
Waar elke metric meestal misgaat
LCP bestaat uit vier delen: time to first byte, vertraging voor het laden van de resource, laadduur van de resource en vertraging bij het renderen van het element. Zoek eerst het grootste deel en los dat op.
INP draait om lange JavaScript-taken die lopen wanneer iemand tikt of typt. CLS komt door dingen die na de eerste paint van grootte veranderen: afbeeldingen zonder afmetingen, late banners en fonts die naar een andere breedte wisselen.
Hoe de labscore gewogen wordt
Lighthouse 10 en later combineren vijf labmetrics. Total Blocking Time weegt het zwaarst, dus zware JavaScript schaadt de score meer dan wat dan ook.
Gewichten van de Lighthouse-prestatiescore
Labmetric
Gewicht
Bijbehorende field-metric
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Geen directe
Veelvoorkomende audits en de oplossing voor elk
Wat een rode audit u vertelt
Audit of symptoom
Waarom het rood is
Gebruikelijke oplossing
De afbeelding voor Largest Contentful Paint werd lazy geladen
De browser wacht op de layout voordat hij de hero ophaalt
Haal loading=lazy van de hero en voeg fetchpriority=high toe
Verwijder resources die het renderen blokkeren
CSS of synchrone scripts in de head vertragen de eerste paint
Zet kritieke CSS inline, stel scripts uit
Geef afbeeldingen het juiste formaat
Afbeeldingen zijn groter dan hun weergegeven grootte
Gebruik srcset en sizes, exporteer op weergavebreedte
Lever afbeeldingen in moderne formaten
JPEG of PNG waar AVIF of WebP kleiner zou zijn
Converteer en lever via picture of een image-CDN
Verminder ongebruikte JavaScript
Code meegestuurd voor functies die niet op deze pagina staan
Splits bundles per route, schrap ongebruikte libraries
Verminder de impact van code van derden
Tags blokkeren de main thread
Laad tags na interactie of als de browser niets te doen heeft
Afbeeldingselementen hebben geen expliciete breedte en hoogte
Er wordt geen ruimte gereserveerd, dus de inhoud verspringt
Stel width en height of aspect-ratio in
Zorg dat tekst zichtbaar blijft tijdens het laden van webfonts
Tekst is verborgen terwijl het font downloadt
Gebruik font-display: swap en preload het hoofdfont
De eerste serverrespons duurde lang
Trage TTFB door niet-gecachete HTML
Cache HTML aan de edge, schrap redirects
Codefragmenten met oplossingen
Heroafbeelding die als eerste laadt
Geen lazy loading op het waarschijnlijke LCP-element, een hoge fetch-prioriteit, moderne formaten en echte afmetingen zodat er niets verschuift.
Font dat geen tekst verbergt
Preload het ene fontbestand dat boven de vouw gebruikt wordt en laat tekst in een fallback zien tot het binnen is.
Tag van derden die laadt nadat de pagina tot rust komt
Voegt een marketingscript toe zodra de browser niets te doen heeft, zodat het niet concurreert met de eerste render of de eerste tik.
Reserveer ruimte voor late inhoud
Een embed of advertentieplek met een vaste beeldverhouding voorkomt dat de inhoud eronder verspringt als hij laadt.
Checklist voor snelheid
Werk deze in volgorde af
Stap
Controle
Field data: welke van LCP, INP en CLS faalt op het 75e percentiel?
LCP-element: is het een afbeelding, en wordt die lazy geladen of laat ontdekt?
TTFB: wordt de HTML gecachet, en zijn er redirects ervoor?
JavaScript: wat is de Total Blocking Time en welke scripts veroorzaken die?
Layout: hebben afbeeldingen, embeds en banners gereserveerde ruimte?
Fonts: is font-display ingesteld en wordt het hoofdbestand vooraf geladen?
Goed
Kan beter
Slecht
Beoordeel uw getallen
Vul de waarden uit uw rapport in om te zien of elke waarde goed is, beter kan of slecht is.