Åtgärda långsam Largest Contentful Paint

Åtgärda en långsam Largest Contentful Paint (LCP)-bild i 4 steg: ändra storlek till visningsstorleken, konvertera till WebP eller AVIF, förladda den och ställ in fetchpriority till high. De två första stegen ger störst förbättring och kräver inga ändringar i koden på din sida.

På de flesta sidor är det största innehållselementet en enskild huvudbild, vilket innebär att LCP i grunden handlar om en enda fil snarare än hela din webbplats. Att åtgärda den enskilda filen ger oftast större utslag på mätvärdet än någon annan tillgänglig optimering.

Vad LCP mäter

LCP mäter hur lång tid det tar för det största synliga elementet att renderas, räknat från att sidan börjar läsas in. Google anser att 2,5 sekunder eller mindre är bra, 2,5 till 4 sekunder behöver förbättras och över 4 sekunder är dåligt.

Det uppmätta elementet är vanligtvis en bild, ibland ett rubrikblock, och det är alltid något som är synligt utan att scrolla. Elementet kan variera mellan olika enheter, eftersom en huvudbild som dominerar på en dator kan hamna längre ner på en mobilskärm.

Hitta elementet som orsakar problemet

Kör Lighthouse och läs posten för Largest Contentful Paint-elementet, som visar exakt vilket element som mäts. Att gissa slösar tid, eftersom elementet ofta inte är det man tror.

Kontrollera på både mobil och dator, eftersom layouten skiljer sig åt och därmed även resultatet. Fältdata från verkliga besökare är pålitligare än enstaka labbtester, eftersom nätverksförhållanden varierar mycket mer i verkligheten. Om de två inte stämmer överens ska du lita på fältdata och använda labbtester för diagnostik.

Åtgärda bilden i ordning efter effekt

För att förbättra LCP för en bild går du igenom dessa 6 steg i ordningsföljd.

1. Ändra storlek på bilden till den största yta den någonsin kommer att visas på, dubblerat för högupplösta skärmar.
2. Konvertera den till WebP, eller till AVIF om bilden är stor och fotografisk.
3. Komprimera till ett mål under 200 KB för en huvudbild, vilket är uppnåeligt i fullbredd på de flesta designer.
4. Lägg till width- och height-attribut så att webbläsaren reserverar utrymme och ingen layoutförskjutning uppstår.
5. Förladda bilden i sidans head så att webbläsaren börjar hämta den omedelbart.
6. Sätt fetchpriority till high på bild-elementet, vilket talar om för webbläsaren att denna fil är viktigast.

Steg 1 och 2 ger oftast den största förbättringen, och det är de två steg som inte kräver att du ändrar något i sidans källkod.

Varför ändrad storlek slår komprimering

Dimensionerna styr den största delen av filstorleken, så att ändra storlek tar bort mer vikt än någon kvalitetsinställning. Ett fotografi på 4000 pixlar som visas i 1200 pixlar innehåller 11 gånger mer pixeldata än vad sidan kan visa.

Den tredje raden visar varför du ska ändra storlek först. Enbart ändrad storlek var bättre än enbart komprimering, och kombinationen var bäst av allt. Siffrorna varierar beroende på bild och anslutning, men ordningen står sig alltid.

Förladdning och fetchpriority

Förladdning (preload) säger åt webbläsaren att hämta huvudbilden innan den har tolkat klart sidan, vilket vanligtvis sparar 200 till 500 millisekunder. Inställningen är viktig eftersom webbläsare upptäcker bilder sent i tolkningsprocessen.

Förladda endast en bild. Att förladda flera tar bort fördelen, eftersom webbläsaren då delar upp sin uppmärksamhet exakt som den annars skulle ha gjort. Att ställa in fetchpriority till high ger ett liknande resultat med mindre kod och räcker ofta i sig för en bild som redan finns i den ursprungliga HTML-koden.

Misstag som gör LCP sämre

• Lazy loading på huvudbilden. Lazy loading fördröjer exakt den fil du vill ha först. Använd det endast för innehåll längre ner på sidan.
• Ladda huvudbilden via JavaScript. En bild som läggs till via skript kan inte börja laddas ner förrän skriptet har körts.
• Använda en CSS-bakgrundsbild. Bakgrundsbilder upptäcks senare än img-element och kan inte prioriteras lika enkelt.
• Förladda flera bilder. Konkurrerande prioriteringar tar helt bort fördelen.
• Utelämna width och height. Layoutförskjutningar försämrar ett annat mätvärde samtidigt som detta förbättras.

När LCP-elementet är text

En textbaserad LCP fördröjs oftast av webbtypsnitt snarare än av själva texten. Webbläsaren har orden omedelbart men väntar på typsnittsfilen innan de ritas ut.

Ställ in font-display till swap så att texten visas med ett reservtypsnitt och växlar när webbtypsnittet har laddats. Förladda den enskilt viktigaste typsnittsfilen och beskär typsnittet till de tecken som dina sidor faktiskt använder, vilket ofta minskar ett typsnitt från 200 KB till under 30 KB. Att leverera typsnitt från din egen domän tar bort en extra anslutning till en tredje part.

Serverns svarstid sätter lägsta nivån

LCP kan inte vara snabbare än den tid det tar för din server att skicka den första byten, så en långsam server sätter ett tak för alla andra förbättringar. Säkta efter under 600 millisekunder till första byten.

Kontrollera den siffran innan du optimerar bilder, eftersom en server-svarstid på 2 sekunder gör ett LCP-mål på 2,5 sekunder omöjligt oavsett vad du gör med filerna. Cachning, ett snabbare webbhotell eller ett innehållsnätverk (CDN) löser det lagret. Bildarbetet förbättrar sedan det som återstår istället för att kämpa mot en gräns som satts någon annanstans.

Tredjepartsskript fördröjer också bilden

Analysverktyg, banderoller för samtycke, chatt-widgets och skript för annonser konkurrerar med din huvudbild om bandbredd och bearbetningstid. En perfekt optimerad bild visas fortfarande sent om 12 skript laddas före den.

Banderoller för samtycke skadar mest, eftersom många blockerar utritningen tills besökaren gör ett val. Ladda tredjepartsskript med attributen defer eller async så att de inte uppehåller sidan, och granska hur många som verkligen behövs. Att ta bort 3 oanvända spårningsskript förbättrar ofta LCP mer än ytterligare en omgång bildkomprimering.

Testa ändringen på rätt sätt

Testa i ett privat fönster med tillägg inaktiverade, och kör mätningen 3 gånger istället för att lita på ett enskilt resultat. Poängen varierar mellan körningarna med en märkbar marginal.

Verifiera att webbläsaren faktiskt tog emot den mindre filen. Öppna utvecklarverktygen, gå till fliken Nätverk, filtrera på bilder och läs om sidan. Den överförda storleken och formatet visas i listan. En sida som fortfarande levererar den gamla filen innebär oftast att ett cachelager håller kvar den tidigare versionen snarare än att optimeringen misslyckades.

Hålla LCP snabb efter åtgärden

Sätt upp en regel för huvudbilder istället för att åtgärda dem en och en, eftersom nya sidor kommer att återinföra problemet. En webbplats som åtgärdats en gång kommer att försämras inom några månader om redaktörer laddar upp direkt från en kamera.

Kom överens om en maximal bredd och en maximal filstorlek för huvudbilder, skriv ner det och tillämpa det på varje ny sida. En regel som 1920 pixlars bredd och under 200 KB är enkel att kontrollera och täcker nästan alla designer. Där flera personer publicerar väger den skriftliga regeln tyngre än tekniken, eftersom mätvärdet speglar den sämsta sidan snarare än den bästa.

Förbereda huvudbilder i ett enda steg

Bearbeta webbplatsens alla huvudbilder tillsammans, eftersom de delar samma specifikation och målstorlek. De flesta webbplatser har mellan 10 och 100 sådana bilder fördelade på landningssidor, kategorisidor och artiklar.

Ställ in bredden och KB-målet en gång, släpp in bilderna och alla filer kommer tillbaka anpassade. Upp till 500 bilder kan köras per omgång, helt i din webbläsare på din egen processor. Ingenting laddas upp, så utkast, opublicerade kampanjsidor och kundarbeten stannar kvar på din dator medan hela biblioteket förbereds.