Core Web Vitals: mått, gränsvärden och felsökning

En god nivå innebär LCP högst 2,5 sekunder, INP högst 200 millisekunder och CLS högst 0,1 vid den 75:e percentilen, bedömt separat för mobil och dator. Bedömningen gäller alltså respektive mått i rätt underlag, inte det bästa enskilda testet.

Bedömningen görs vid den 75:e percentilen, separat för mobil och dator. Källa: web.dev om Web Vitals. Gränserna är inte ett löfte om rankning eller konvertering.

Vad visar LCP?

LCP visar när det största kvalificerande innehållselementet i den synliga ytan har renderats. Det kan vara en stor bild eller ett textblock. Måttet anger inte när varje resurs på sidan är färdig. Identifiera därför vilket element som faktiskt mäts innan ni ändrar bilder eller typsnitt. Se web.dev om LCP.

Vad visar INP?

INP beskriver hur snabbt sidan ger visuell återkoppling på klick, tryck och tangentbordsinteraktioner. Det gäller responsen fram till nästa bildruta, inte hela tiden tills exempelvis ett nätverksberoende formulärärende är färdigbehandlat. En meny kan alltså reagera trögt även när sidans första innehåll laddades snabbt. Se web.dev om INP.

Vad visar CLS?

CLS beskriver oväntade förflyttningar av synligt innehåll. Måttet är ett poängvärde utan tidsenhet. Ett exempel är att text flyttas när en bild som saknar reserverat utrymme laddas in. Alla avsiktliga ändringar efter en användarhandling räknas inte automatiskt som oväntade skift. Se web.dev om CLS.

Fältdata kommer från verkliga användarupplevelser, medan labbdata kommer från ett kontrollerat test. Labbtester hjälper till att felsöka, men en enskild körning bevisar inte hur alla besökare upplever sidan.

Varför saknas ibland fältdata?

Fältdata kan saknas när en sida är ny eller har för få observationer från verkliga användare. PageSpeed Insights kan då visa data för hela webbplatsens ursprung i stället. Om även det underlaget är otillräckligt visas ingen sådan bedömning. Avsaknaden visar inte att sidan är snabb eller långsam.

Hur kontrollerar ni sidan i PageSpeed Insights?

Testa sidans fullständiga URL i PageSpeed Insights och läs mobil- och datorresultaten separat. Kontrollera därefter vilken datanivå och period som resultatet gäller:

1. Ange URL:en i PageSpeed Insights och starta analysen.
2. Kontrollera om fältdata gäller den enskilda sidan eller webbplatsens ursprung, alltså kombinationen av protokoll, värdnamn och port. Ett resultat för ursprunget är inte ett separat mätresultat för varje sida.
3. Notera mätperioden. Fältdata i PageSpeed Insights omfattar de senaste 28 dagarna och visar därför inte omedelbart effekten av en ändring.
4. Använd labbresultatet för felsökning. Lighthouse mäter inte INP i sitt vanliga sidladdningstest; Total Blocking Time (TBT) kan ge ledtrådar men är inte samma mått.
5. Spara URL, datum, enhetstyp och relevanta värden. Upprepa testet efter ändringen och följ fältdata över tid när underlag finns.

Googles beskrivning av PageSpeed Insights förklarar datanivåerna och mätperioden. Se även web.dev om vad labbverktygen kan mäta.

Är ett grönt Lighthouse-betyg samma sak som godkända Core Web Vitals?

Nej. Lighthouse ger ett laboratorieresultat, medan Core Web Vitals-bedömningen i PageSpeed Insights bygger på fältdata. Läs därför både datakällan och vilket mått som bedöms. Ett högt sammanfattande labbetyg kan finnas samtidigt som verkliga besök har svag respons. PageSpeed Insights dokumentation beskriver dessa separata delar.

Illustrativt exempel: ni rättar en stor bild och får bättre LCP i ett nytt labbtest. Det säger inget direkt om ett långsamt formulär längre ned på sidan, och det ersätter inte de tidigare besök som fortfarande ingår i fältperioden. Anteckna resultatet som ett test av den nya versionen, inte som bevis för att alla besökares upplevelse redan har förbättrats.

Utgå från vilket mått som är svagt och undersök vad som orsakar det på den aktuella sidtypen. Ett lågt sammanfattande testbetyg säger inte på egen hand vilken åtgärd som behövs.

• Vid sen visning: undersök innehållsresurs, serverrespons och blockerande resurser.
• Vid trög interaktion: undersök arbete som hindrar webbläsarens respons.
• Vid layoutförskjutning: undersök element som tillkommer eller ändrar storlek utan reserverat utrymme.

Testa relevanta sidmallar. Ett formulär eller en gemensam komponent kan påverka flera sidor samtidigt.

Illustrativt exempel: om sidans stora huvudbild är det element som visas sent, kontrollera när bildförfrågan startar, resursens storlek och om annat innehåll blockerar visningen. Att bara komprimera alla bilder kan missa ett problem med prioritering eller serverrespons. Efter rättelsen behöver samma sidtyp testas igen och bilden fortfarande fungera i den godkända layouten.

Hur undersöker ni en långsam LCP-resurs?

Dela upp väntan i serverns första svar, fördröjd resursstart, hämtning och fördröjd rendering. Om bilden börjar hämtas sent hjälper en mindre fil bara en del av problemet. Om resursen är färdig men innehållet hålls tillbaka av kod behöver renderingen undersökas. web.dev delar upp LCP i dessa fyra delar.

Spara en inspelning av sidladdningen och peka ut LCP-elementet samt den del där tiden går åt. Testa därefter en riktad förändring och kontrollera samma element igen. Dokumentera exempelvis att resursen börjar hämtas tidigare; skriv inte bara att ”bilderna optimerades”.

Hur undersöker ni trög interaktion?

Återskapa den långsamma handlingen och undersök om fördröjningen uppstår före, under eller efter dess händelsehantering. Annat JavaScript kan blockera huvudtråden innan handlingen behandlas. Även själva behandlingen och webbläsarens arbete med nästa bildruta kan ta tid. web.dev beskriver de tre delarna av interaktionsfördröjningen.

Illustrativt exempel: en filterknapp behöver ge återkoppling när besökaren trycker. Om ett stort arbete startas samtidigt kan utvecklaren pröva att minska eller dela upp det arbetet. Efter ändringen behöver både responsen och filtreringens korrekta resultat kontrolleras. Att dölja knappen eller ta bort funktionen är inte samma sak som att rätta fördröjningen.

Hur hittar ni orsaken till layoutskift?

Identifiera vad som flyttar sig och vilket innehåll som ändrar utrymmet omkring det. Bilder, inbäddat innehåll och sent tillkommande element kan behöva reserverat utrymme. Text kan också flyttas när typsnitt byts. Följ web.dev:s felsökning av CLS och kontrollera sidan även efter den första laddningen.

Illustrativt exempel: ett inbäddat formulär fyller först ingen yta och skjuter sedan ned texten när det visas. Pröva utrymmet i den befintliga layouten och testa både när formuläret laddas normalt och när det inte laddas. En tom yta som permanent döljer nästa steg är inte en färdig lösning.

Kontrollera både mätvärdena och att menyer, formulär och tillgänglighet fungerar efter en prestandaändring. Dokumentera vad ni ändrar, mät igen och kontrollera sidan som besökare.

När ni har identifierat ett återkommande problem i rätt mätunderlag behöver det kopplas till en teknisk orsak. Läs om arbetet med Core Web Vitals och hur ändringar följs upp.

Dokumentera både förbättringen och vad som inte har mätts. Ett bra labbresultat efter en ändring kan vara användbart direkt, medan fältunderlaget ännu innehåller besök från tiden före ändringen. Undvik därför att presentera ett omedelbart labbtest som en bekräftad förbättring för alla användare.

Hur hänger Core Web Vitals ihop med SEO?

Google använder Core Web Vitals i sina rankningssystem, men bra värden garanterar inte höga placeringar. Innehållet måste fortfarande svara på sökningen. Google rekommenderar en bra helhetsupplevelse i stället för att jaga ett enskilt perfekt testvärde. Se Google om Core Web Vitals och sökresultat.

Avsluta med en kort ändringslogg: berörd sidtyp, reproducerat problem, ändring, nytt test och kvarvarande osäkerhet. Om mätvärdena är bra men besökaren inte kan läsa villkor eller slutföra en förfrågan behövs även testning av mobilfunktionerna. Prestandamåtten ersätter inte den kontrollen.