Noll layoutförskjutning på 456 sidor

Utmaningen

Den animerade hero-sektionen som används i kunskapsbanken och på integrationssidorna laddades utan reserverat utrymme. I mobilen var den noll pixlar hög fram till första scrollningen, sedan hoppade allt under den; på dator registrerades det som en layoutförskjutning på 0,126, över Googles gräns på 0,1 för ett bra värde. Besökarna såg bakgrunder poppa upp och sektioner i fel bredd.

Lösningen

• Mätte innan något ändrades: Lighthouse i mobilprofil, tre körningar per variant, jämförda bara mellan körningar under liknande belastning — samma sida svängde mellan 230 ms och 5,3 s blockeringstid utan att något på sajten ändrats
• Åtgärdade hero-animationen vid källan: utrymmet reserveras innan animationen laddas, och en stillbild syns från första renderingen. En ändring, applicerad på 456 sidor, kontrollerad mot hela sitemapen i stället för ett urval — det första urvalet hade missat just de sidor där felet satt
• Flyttade in webbtypsnittet i temat, vilket tog bort två externa domäner från den kritiska vägen, och stoppade att samma typsnittsfil laddades ner två gånger
• Tog bort en ändring som Lighthouse räknade som en förbättring: den förstörde scrollpositionen efter en omladdning eller ett hopp, något som inget poäng mäter. Bara ett beteendetest fångade det
• SEO på fyra språk: hreflang med x-default i varje mall, brödsmulor som följer sidans språk och korrigerad strukturerad data för abonnemangspriser
• Allt i iWebs egen portal, efter deras konventioner och modulregler, under deras namn

Resultatet

Hero-sektionen laddas med noll layoutförskjutning på var och en av de 456 sidor som använder den, mätt i mobil och på dator på fyra språk. Varje siffra här kommer från en mätning — även den som fick oss att ta bort en ändring.