kaxigt.com

Jag skriver om webben för webben

Google: Core Web Vitals LCP CLS FID

Postad: 24 april 2021 | SEO · UX Design | No Comments
Lästid: 4 minuter

Artikeln handlar om Google SEO LCP CLS FID och ranking


Från och med maj 2021 kommer Google lägga största vikten på Core Web Vitals-faktorerna när det gäller rankingen. Främst handlar det om tidsaspekten i olika konstellationer och hur du kan fixa eventuella problem som slöar siten. Core Web Vitals betyder följande:

  1. LCP – Largest contentful paint – hur snabb är sajtens laddningstid?
  2. CLS – Cumulative Layout Shift – hur fort blir sajten stabil samt hur länge håller den sig stabil?
  3. FID – First Input Delay – hur länge dröjer det innan dina besökare kan börja interagera med sajten?

Google Core Web Vitals
Nu ska vi kika närmare på vad Google LCP CLS FID kan betyda för just dig och din sajt.

LCP – Largest Contentful Paint

Vi tar din sajt. Hur snabbladdad är den egentligen?

Kanske har du mycket text? Använder du många och/eller stora bilder? Är dessa optimerade? lägger du upp Videos? Alla webbläsare har en renderingsmotor och det handlar om hur fort denna kan rendera ditt innehåll.

Det är just detta som Google först tittar på, det som är störst i viewport vare sig det är en stationär sida eller en mobilsida, oavsett om det är en bild, video eller text. Sådant här påverkas nämligen också av din servertid, din CSS, JavaScript, rendering på klientsidan.

Largest Contentful Paint kan även vara olika för varje webbplats och det skiljer sig också mellan mobil- och stationära versioner av din webbplats. Ibland kan LCP vara en bild medan det andra gånger endast är en text.

Googles gränser för att mäta hur bra LCP (laddningstid) sidan har är dessa:

  • Bra – mindre än eller lika med 2.5 sekunder
  • Behöver förbättras – mindre än eller lika med 4,0 sekunder
  • Dåligt – mer än 4,0 sekunder

Vad du kan göra:

  • Komprimera dina bilder.
  • Använder du WordPress så fixa ett bra plugin för caching.
  • Se till att du har en bra webbläsaroptimering.
  • Optimera dina koder (CSS och Javascript) så slipper dessa slöa ned sidan (render-blocking).
  • Minimera även din CSS och javascript från onödig text så blir de mer snabbladdade med en CSS Minifyer samt en Javascript Minifyer.
  • Försök att använda komprimering på servernivå med exempelvis Gzip.
  • Föranslut för viktiga resurser, sk pre-connect eller pre-load.
  • Använd ett innehållsleveransnätverk (CDN).
  • Sist men inte minst, ha ett bra webbhotell med snabba servrar, gärna nära.

CLS – Cumulative Layout Shift

Den andra frågan som Google ställer är hur snabbt är sidan stabil?

Håller layouten samma layout utan några förskjutningar i utseende eller moduler? Sidlayouten ska alltså inte göra ett oväntat layoutskifte. Det här är något att tänka på för dem som gör designer med olika former av animationer för att förhöja utseendet. Det är en stor risk för en dålig användarupplevelse.

Google mäter en eventuell kumulativ layoutförskjutning. Med kumulativ menas att något adderas, ökas, staplar eller hopar sig, exempelvis (javascript)animerade block.

Så, hur snabbt är allt stabilt?
Den främsta anledningen till att saker och ting inte är stabila är att bildstorlekar ofta inte definieras. Har sidan en bild och den är 300 pixlar bred och hög så måste det definieras. Förutom att det är god webbstandard är det även en bra praxis för just UX – användarupplevelsen.

Här listar jag gränserna för Google CLS – Cumulative Layout Shift:

  • Idealet – mindre 0.1
  • Behöver förbättras – mellan 0.1 till 0.25
  • Dåligt – mer än 0.25

Det du kan göra:

  • Ange höjd och bredd på bilderna.
  • Du behöver även ange dimensionerna på dina inbäddade element, reklambilder och iframes om du använder det.
  • Låt dina fonter förladdas – preload.
  • Fundera över om animerade block eller annat som ändrar storlek eller tar tid på sig för att inta sin plats i designen verkligen är nödvändiga.

FID – First Input Delay

Google vill veta hur interaktiv snabb sidan är.

För oss besökare är det viktigt för om du klickar på något, en knapp, länk eller en JavaScript-händelse, hur snabbt kan webbläsaren börja bearbeta det och ge ett resultat?

Det är definitivt inte bra om ingenting händer, eller när det väl händer något så går det väldigt långsamt. Sådant får gärna besökaren att lämna sidan, tyvärr.

Var då går smärtgränsen för att överhuvudtaget vänta på svar?

Jo, 3 sekunder. T R E sekunder.

Detta fenomen kan bero på javascript- eller tredjepartskoder. Hur hanterar din sajt Google LCP CLS FID?

Hur mäter Google FID?

  • Bäst – mindre än eller lika med 100 millisekunder
  • Behöver förbättras – mindre än eller lika med 300 millisekunder
  • Dåligt – mer än 300 millisekunder

Så vad du kan göra?

  • Ta bort alla överflödiga javascriptkoder.
  • Dela upp långa javascript till till mindre asynchrona.
  • Använd async eller skjut upp så att JavaScript bara körs när det behövs. Om du använder modern JS, konfigurera ES6-moduler för att ladda efter behov.
  • Idle until urgent is a code evaluation strategy conceived by Philip Walton from Google.
  • Optimera CSS-prestandan.
  • Försök att minimera hur mycket data som behöver behandlas på klientsidan. Det minskar mängden arbete som webbläsaren måste rendera för att visa sidan.
  • Prioritera att ladda bara det du tror ger användarna störst värde först.
  • Minimera dina koder och funktioner.

20 tips för att optimera din css-prestanda
Idle until urgent
Package Code idle-until-urgent


Förutom ovanstående Core Web Vitals faktorer så ingår naturligtvis nedanstående.

  • Sajten ska vara mobilvänlig (responsiv)
  • Man ska kunna surfa säkert (SSL)
  • Vilket då för in oss på att också använda HTTPS

Core Web Vitals

Mer om allt detta hittar du i guiden Börja blogga som ett proffs med SEO.

[Bildkälla: Samtliga bilder från https://www.searchenginejournal.com]