Optimalisatie van Google Core Web Vitals voor Magento 2

Eerder dit jaar heeft Google bekendgemaakt de gebruiksvriendelijkheid van een pagina mee te nemen als ranking factor. Om een webpagina hoog te laten ranken in de Search Engine Ranking Pages (SERP) zal naast SEO en linkbuilding, nu ook de gebruiksvriendelijkheid van hoge kwaliteit moeten zijn. Google meet deze kwaliteit op basis van de Core Web Vitals. Dit zijn metrics die de prestaties van webpagina’s meten en hier scores aan koppelen. Deze scores visualiseren de sterke en zwakke punten van de betreffende webpagina.

Drie metrics

De Core Web Vitals bestaan uit drie metrics;

Largest Contentful Paint (LCP) gaat over de snelheid waarmee het grootste element op de pagina wordt ingeladen. Dit element kan bijvoorbeeld een grote afbeelding of video betreffen. Om een goede (groene) LCP-score toe te kennen, vindt Google dat het grootste element op de pagina binnen 2,5 seconden ingeladen moet zijn. Als niet aan deze drempel wordt voldaan, wordt een oranje (verbetering vereist) of rode (slecht) score toegekend.

First Input Delay (FID) meet de tijd tussen het inladen van de pagina en het eerste moment waarop een gebruiker een handeling kan uitvoeren. Wanneer dit in maximaal 100 milliseconden het geval is, kent Google een goede (groene) FID-score toe. Een langere wachttijd resulteert in een oranje (verbetering vereist) of rode (slechte) score.

Bij Cumulative Layout Shift (CLS) draait het om de visuele stabiliteit van de pagina. Het gaat hier, zoals de naam al doet vermoeden, om de opgetelde layout shifts van een pagina. Een layout shift houdt in dat een element (bijvoorbeeld een content block of font) met vertraging wordt ingeladen, waardoor een deel van de pagina hinderlijk verspringt. Elke layout shift heeft een negatief effect op de CLS-score. Om een goede (groene) CLS-score toegekend te krijgen, vindt Google dat de CLS maximaal 0.1 mag zijn. Bij een CLS tussen 0.1 en 0.25 kleurt de score oranje en boven de 0.25 wordt een rode (slechte) score toegekend.

Impact op user experience en ranking

De Core Web Vitals hebben niet alleen invloed op de pagina ranking in de Google zoekresultaten, de impact van deze metrics is groter. Het optimaliseren van de Core Web Vitals heeft namelijk als gevolg dat ook de gebruikerservaring (UX) wordt verbeterd. Dit kan dan vervolgens weer leiden tot bijvoorbeeld een daling van het bouncepercentage (percentage van bezoekers die de website zonder interactie verlaten, bijvoorbeeld door ergernis over lange laadtijd) of zelfs een stijging van de conversie en/of omzet.

Hoe groot deze impact daadwerkelijk is, hangt echter af van verschillende variabelen. Hieronder vallen onder meer de devices waarmee de doelgroep een website/webshop bezoekt en het type internetverbinding. Google schrijft in deze context over lab data en field data:

• Lab data is kunstmatige data gebaseerd op de simulaties van één vooraf ingesteld device met gespecificeerde locatie en internetverbinding.
• Field data wordt verzameld door de daadwerkelijke devices van de doelgroep, met echte locaties en lokale internetverbindingen.

Bij het optimaliseren van de Core Web Vitals testen developers met Google Lighthouse (meetsoftware die standaard is geïnstalleerd in Google Chrome) of Google’s online meetsoftware op https://web.dev/measure/ of https://pagespeed.web.dev/. Deze tests worden gebruikt om een goed beeld te krijgen van de relatieve verbetering tijdens het optimalisatieproces.

De resultaten zijn echter niet representatief wanneer de lab data niet is gebaseerd op dezelfde device, locatie en internetverbinding als de field data. ⁠Een lab data test kan bijvoorbeeld op een high-end device nagenoeg perfect zijn. Maar als de specifieke doelgroep gebruik maakt van mid-tier devices, zijn de scores van de field data niet verbeterd.

Google heeft aangegeven dat er bij de toekenning van Core Web Vital-scores enkel wordt gekeken naar de prestaties op basis van field data. Voor optimale scores is de kennis over de ‘situatie’ van de doelgroep (device, locatie en internetverbinding) dus alleen maar belangrijker geworden. Bij het optimaliseren van de Core Web Vitals moet field data daarom als uitgangspunt worden genomen en zal lab data moeten corresponderen met de echte situatie van de doelgroep.

Core Web Vitals onlangs geoptimaliseerd in Magento webshops

Performance en gebruiksvriendelijkheid zijn doorlopend punten van aandacht tijdens onze sprints. Door de introductie van Core Web Vitals is er de afgelopen maanden extra aandacht besteed aan het aanpakken van optimalisatiekansen voor verschillende Magento webshops:

• Probleem: Het inladen van onnodig grote afbeeldingen.
• ⁠Oplossing: Een service genaamd Imaginary installeren op de server, zodat afbeeldingen automatisch worden gecomprimeerd naar WebP- of JPEG-bestanden. Dit resulteert met 90+% minder data in een aanzienlijke reductie van de bestandsgrootte. Waar mogelijk serveren we afbeeldingen in een WebP-bestandsformaat. WebP maakt afbeeldingen gemiddeld nog 39% kleiner dan wanneer deze worden opgeslagen als JPEG. Echter, voor een enkele browser is het gebruik van WebP-bestanden nog niet mogelijk. In deze gevallen vallen we terug op JPEG-bestanden.

• Probleem: De twee standaard manieren van JavaScript inladen in Magento 2 zorgen voor onnodig grote downloads of voor onnodig veel netwerkverzoeken: ⁠1. Alle JavaScript wordt samengevoegd, waardoor de browser minder bestanden hoeft te downloaden. De bestanden zijn alleen veel te groot, omdat deze onnodige code bevatten. Zo wordt bij het inladen van bijvoorbeeld de productdetailpagina ook al JavaScript voor de checkout ingeladen. ⁠2. Bij het inladen van pagina-onderdelen wordt per onderdeel uitgezocht welke JavaScript bestanden er nodig zijn om dit onderdeel goed te laten functioneren. De benodigde bestanden worden vervolgens één voor één worden gedownload.
• ⁠Oplossing: Het implementeren van onze eigen JavaScript Bundler. Hiermee bundelen we enkel de benodigde JavaScript om de betreffende pagina te laten werken. Dankzij deze manier van advanced bundling, hoeven er minder bestanden worden opgehaald en wordt enkel de code ingeladen die nodig is voor de specifieke pagina. JavaScript zal de main thread niet of minder lang blokkeren, waardoor de bezoeker eerder kan interacteren met de pagina.

• Probleem: JavaScript wordt gebruikt om aanpassingen op de pagina te doen aan de hand van bepaalde variabelen, zoals de breedte van het device. Zo kan JavaScript dus ongewenst de hoogte van elementen veranderen, waardoor layout shifts ontstaan.
• ⁠⁠Oplossing: De visuele rendering van elementen niet meer afhankelijk maken van JavaScript, waardoor het formaat van een element niet ongewenst wordt aangepast.

• Probleem: Doordat content blocks later worden ingeladen dan omliggende elementen, verspringen delen van de pagina en ontstaan layout shifts.
• ⁠Oplossing: Het specificeren van image heights en widths. Door het meegeven van heights en widths kan de browser een aspect-ratio berekenen en de juiste ruimte op de pagina reserveren voordat content wordt ingeladen. Voor content blocks die pas later worden ingeladen wordt dus ook een plaats op de pagina gereserveerd, wat resulteert in het niet verspringen van de overige delen van de pagina.

• Probleem: Doordat het custom font nog gedownload moet worden en pas later wordt ingeladen, verspringt (een deel van) de pagina.
• ⁠Oplossing: Als font strategy ‘display swap’ gebruiken en daarbij custom fonts preloaden. Custom fonts moeten nog steeds worden gedownload, maar door te preloaden zijn deze eerder (vaak bijna direct) beschikbaar. Tijdens het downloaden van het custom font, wordt er al een standaard font getoond om de witruimte op de pagina te vullen en de bezoeker alvast van tekstuele inhoud te voorzien. Zodra het custom font beschikbaar is, worden de fonts conform design ‘geswapped’. De effectiviteit van deze oplossing hangt logischerwijs af van het aantal custom fonts dat gedownload moet worden. 15 in te laden custom fonts zullen zorgen voor een slechtere CLS-score dan wanneer dit er 5 of minder zijn.

• Probleem: Icon libraries worden volledig ingeladen, waar er slechts enkele icons van de 250 icons gebruikt worden.
• Oplossing: Een custom icon font maken en daarin alleen de benodigde icons toevoegen, waardoor de bestandsgrootte van de in te laden icon library aanzienlijk reduceert. Een tweede optie is het inladen van de benodigde icons in SVG-formaat en de elementen op de pagina’s vervangen door deze SVG-afbeeldingen.

• Probleem: JavaScript wordt ingeladen en uitgevoerd voor onderdelen van een pagina waarmee de bezoeker niet direct interacteert, zoals de search engine, chat widgets en Trustpilot.
• Oplossing: JavaScript voor de search engine, chat widgets en Trustpilot pas inladen wanneer de bezoeker hiermee interacteert. Hierdoor is er minder blocking time (de tijd dat de bezoeker op de interactie met de pagina wacht en dus ‘geblokkeerd’ is) en kan de bezoeker sneller interacteren met de pagina. Daarnaast wordt de main thread van de CPU op deze manier niet volgezet door JavaScript. Een volle main thread zou zorgen voor een slechtere FID-score.

Optimalisatie van Core Web Vitals is een continu proces

Het optimaliseren van gebruiksvriendelijkheid en performance zullen ook in de toekomst veel aandacht blijven krijgen binnen onze sprints. Google wordt namelijk steeds strikter in het beoordelen en zal de Web Vitals-knoppen blijven aandraaien. Het is een continu proces waarin de prestaties van webshops aan steeds hogere kwaliteitseisen moeten voldoen.

Het is onduidelijk of elke applicatie in de toekomst zal kunnen blijven voldoen aan deze nieuwe eisen. Google lijkt met het strikter beoordelen van de Core Web Vitals traag ladende websites steeds meer te straffen. Hierdoor ontstaat er bij steeds meer websites ruimte voor optimalisaties op het gebied van gebruiksvriendelijkheid en performance. Bij Reach Digital hebben we veel goede ideeën hoe we kunnen inspelen op de ontwikkelingen rondom de stijgende kwaliteitseisen. We komen graag met je in contact om samen te kijken hoe we ook jouw webshop kunnen klaarstomen voor de toekomst van e-commerce.