Core Web Vitals förklarat för företagare

LCP: när huvudinnehållet syns

LCP är måttet folk intuitivt menar med hastighet. En besökare kommer från Google på en telefon, och ett ögonblick är skärmen tom eller visar en logotyp. LCP är ögonblicket när den stora saken dyker upp: hjältebilden på en startsida, produktfotot på en produktsida, rubriken på en artikel. Det som fördröjer den är nästan alltid en av tre saker: långsamt serversvar, en överdimensionerad bild, eller skript och typsnitt som webbläsaren måste ladda ner innan den får rita. Vår guide om varför en hemsida är långsam visar hur du ser vilken av de tre du har.

INP: hur snabbt sidan svarar

INP mäter glappet mellan användarens handling och att skärmen ändras som svar. Tryck på en menyknapp och inget händer på en halv sekund; öppna en storleksväljare och den hackar. Det är dålig INP, och orsaken är att webbläsaren är upptagen med att köra JavaScript när trycket kommer. Typiska syndare är tunga chattwidgetar, analys- och marknadsföringstaggar, cookiebanners med stora skript och sidbyggare som skickar med långt mer kod än sidan använder. INP ersatte det äldre måttet First Input Delay eftersom det tittar på varje interaktion under besöket, inte bara den första.

CLS: därför hoppar saker runt

CLS är måttet bakom webbens mest irriterande upplevelse: du ska trycka på en knapp och sidan flyttar sig, så du trycker på en annons eller fel länk i stället. Det händer när webbläsaren ritar innehåll innan den vet hur mycket plats något behöver. Bilder utan angivna mått, typsnitt som byts in sent och ändrar radhöjder, banners som skjuts in högst upp efter laddning, och inbäddningar som ändrar storlek knuffar alla runt innehållet. CLS är oftast det billigaste av de tre att åtgärda, eftersom det mest handlar om att ange storlekar och reservera plats snarare än att skriva om något.

• Ge varje bild och video uttrycklig bredd och höjd så att webbläsaren reserverar platsen innan filen anländer.
• Reservera plats för cookiebanners, notisfält och annonser i stället för att skjuta in dem ovanför befintligt innehåll.
• Ladda webbtypsnitt på ett sätt som undviker synligt byte, eller använd ett systemtypsnitt för brödtext.
• Undvik innehåll som dyker upp ovanför det besökaren redan läser, som sent laddade bildkaruseller.

Fältdata och labbtester

Det finns två sorters siffror och de är ofta oense. Labbtester, som en körning i PageSpeed Insights eller Lighthouse, laddar sidan en gång på en simulerad enhet och uppkoppling. Fältdata kommer från Chrome User Experience Report, insamlad från riktiga besökare de senaste 28 dagarna, och det är den Google faktiskt använder för rankning. En sajt kan få bra betyg i labbet och dåligt i fält om de riktiga besökarna sitter på äldre telefoner och mobilnät, vilket i Sverige är vanligt utanför storstäderna. Bedöm alltid utifrån fältdatan i Search Console; använd labbtester bara för att förstå varför fältsiffran ser ut som den gör.

Vilket mått du ska börja med

Öppna Search Console, välj mobil och se vilka sidgrupper som är markerade som dåliga. Åtgärda i den här ordningen: först det mått som är dåligt på sidtypen med mest söktrafik, oftast startsidan eller tjänstesidorna; sedan LCP överallt där det är dåligt, eftersom det drabbar varje besökare från första sekunden; sedan INP, som mest drabbar besökare som interagerar, alltså era mest värdefulla; sedan CLS. Kontrollera igen efter 28 dagar, eftersom fältdatan behöver så lång tid för att spegla en ändring. En prestanda- och SEO-optimering följer exakt den här ordningen, och aktuellt pris finns på vår prissida.

När ni inte behöver det här: visar alla tre måtten bra på mobil i Search Console flyttar mer hastighetsarbete inte era placeringar, och pengarna gör mer nytta i innehåll eller konvertering. Har sajten för få besökare för att Google ska rapportera fältdata alls, åtgärda det uppenbara ett labbtest visar och gå vidare. Är du osäker på hur rapporten ska läsas, boka ett kort samtal och dela skärmen.

Vanliga frågor