Core Web Vitals voor Magento store

In mei 2021 meldde Google dat page experience signalen vanaf nu zouden worden meegenomen in de ranking van zoekresultaten. Deze nieuwe page experience signalen combineren Core Web Vitals met al bestaande zoeksignalen, waaronder mobielvriendelijkheid, safe-browsing, HTTPS veiligheid en opdringerige interstitiële richtlijnen. Kort samengevat – Google heeft een aantal updates gereleased om zo een betere gebruikerservaring te bieden. Dit betekent dat gebruikers nu dé ideale zoekresultaten krijgen tussen SEO en UI/UX. Maar hoe werkt dit uit op website-eigenaren? Straft Google hun af met deze nieuwe eisen? Of is het gewoon een stimulus om hun websites te verbeteren en aan het eind van de dag een “betere oogst” te hebben? En wat moeten we doen, Magento web store eigenaren, aangezien zijn webprestaties al op een laag punt zaten, zelfs voor Google’s mededeling?

Wat zijn Core Web Vitals?

Core Web Vitals - 3 standaarden waarmee Google alle website eigenaren aanmoedigt om zichzelf continu te monitoren en te verbetren, om zo een betere gebruikerservaring aan te kunnen bieden. Sinds augustus 2021 zijn deze scores rankingfactoren in de zoekresultaten. Ze laten zien hoe snel pagina-inhoud laadt, hoe snel een browser kan reageren op de input van de gebruiker wanneer een webpagina laadt en hoe onstabiel de inhoudt is wanneer hij in de browser laadt.

Wat zijn Core Web Vitals? Zijn Core Web Vitals belangrijk? Wanneer treden de Core Web Vitals in werking? Hoe meet je de Core Web Vitals? Workflow om Core Web Vitals te optimaliseren Waar komen de Core Web Vitals gegevens waar Search rekening mee houdt vandaan? Hoe de Core Web Vitals te halen? Wat beïnvloedt de Core Web Vitals? 1. LCP (Large Contentful Paint 1.1. Wat is een goede Largest Contentful Paint (LCP) score? 1.2. Welk element wordt als LCP gezien op de pagina? 1.3. Wat heeft invloed op de LCP? 1.4. Hoe kan je de Largest Contentful Paint (LCP) voor Magento winkels verbeteren? 1.4.1. Trage server responstijden 1.4.2. Render-blocking JavaScript en CSS 1.4.3. Trage bron laadtijden 1.4.4. Client-side rendering 1.4.5. Maak geen gebruik van Lazy Loading voor LCP elementen 1.4.6. Lazyload afbeeldingen en iframes op native wijze 2. First Input Delay (FID) 2.1. Wat is een goede First Input Delay (FID) score? score?) 2.2. Wat beïnvloedt de FID? 2.3. Hoe de First Input Delay (FID) voor Magento winkel te verbeteren? 2.3.1. Verminder de impact van code van derden 2.3.2. Verminder JavaScript uitvoertijd 2.3.3. Minimaliseer hoofdthread-werk 3. Cumulative Layout Shift (CLS) 3.1. Wat is een goede Cumulative Layout Shift (CLS) score? 3.2. Wat beïnvloedt de CLS? 3.3. Hoe de Cumulatieve Layout Shift (CLS) voor Magento winkel te verbeteren? 3.3.1. Voeg altijd breedte- en hoogtekenmerken toe aan alle afbeelding- en video-elementen 3.3.2. Reserveer de benodigde ruimte voor embeds (Pseudo Element Tactiek) 3.3.3. Voeg nooit inhoud toe boven bestaande inhoud, behalve als reactie op een gebruikersinteractie 3.3.4. Gebruik transform animaties 3.3.5. Preload fonts, optimaliseer ze en host ze intern Samenvatting

Core Web Vitals:

• Largest Contentful Paint (LCP) - houdt laadsnelheid bij. Hoe lang moeten gebruikers wachten totdat ze betekenisvolle inhoudt op de website zien;
• First Input Delay (FID) - meet de interactiviteit (laad-reactiviteit) van een website (klik op knoppen, voeg product toe aan winkelwagen, zoek, log in, etc).
• Cumulative Layout Shift (CLS) - houdt tijd bij dat het kost voordat de gebruiker stabiele websites kan zien, die niet verspringen tijdens het laden.

Bron

In de afbeelding hieronder kan je zien hoe een pagina laadt en waar de verschillende Web Vital standaarden komen kijken:

Bron

Om de Core Web Vitals opdracht succesvol te maken, moet je “goed” scoren op alle drie de Core Web Vitals (LCP, FID, CLS) – gebaseerd op veldgegevens.

Het is belangrijk om te begrijpen dat voor de Google rank, alleen veldgegevens er toe doen ( gegevens verzameld van echte gebruikers d.m.v. de Chrome User Experience Report). Lab data standaarden worden verzameld vanuit een gecontroleerde omgeving. Het kan zelfs worden gemeten als je het project ontwikkeld op een lokale machine. En het is handig, aangezien je veranderingen tijdens de ontwikkeling kunt monitoren. Je kan apparaat en netwerkverbindingen van te voren bepalen.

100 krijgen op Lighthouse is zeker een goed teken, maar het betekent niet dat je site hetzelfde resultaat zal krijgen in de echte wereld

Er is zeker een sterk verband tussen Lighthouse scores (lab data) en Core Web Vitals gebaseerd op veldgegevens (echte gebruikers of RUM data). Maar het feit dat zoveel pagina’s met perfecte Lighthouse scores nog steeds problemen met de prestaties met echte gebruikers ervaren, is een goede indicator dat lab tools blinde vlekken hebben.

Meestal denken mensen bij websiteprestaties eerder aan een enkel nummer – Lighthouse score dan aan een verdeling van waardes (wat specifieke gebruikersbezoeken vertegenwoordigt) die continu kunnen verschillen en schommelen.

Dus neem opmerkingen als “Mijn site laadt in minder dan 1 seconde!” zijn zonder extra details maar loze beloftes.

Zijn Core Web Vitals belangrijk?

Zeker!

• Core Web Vitals hebben een impact op de positive van de site in de zoekresultaten
• Voldoen aan Core Web Vitals staat niet gelijk aan 100% prestatie, maar het is tastbaar voor gebruikers, een betere ervaring – meer conversies.

Waarom zijn Core Web Vitals zo belangrijk?

“Bij Google Search, is onze missie om gebruikers te helpen de meest relevante en kwalitatief goede sites te vinden op het web. Het doel van deze updates is om de beste ervaringen uit te lichten en er voor te zorgen dat gebruikers de informatie kunnen vinden waar ze naar zoeken.” Bron

Dus het gaat niet alleen om ranking. Als je een positie ten opzichte van je concurrenten verliest, betekent dat ook dat de concurrenten een betere ervaring voor de klant, die van jou zou kunnen zijn, zouden kunnen bieden.

Wanneer treden de Core Web Vitals in werking?

Google is begonnen met de geleidelijke invoering van Core Web Vitals als een ranking signaal halverwege juni 2021. En dit was klaar aan het eind van augustus. Dus waarschijnlijk heb je al wat veranderingen opgemerkt.

Hoe meet je de Core Web Vitals?

Er zijn een aantal tools waarmee je de Core Web Vitals kunt meten:

Veldtools

• Chrome User Experience Report
• PageSpeed Insights verzamelt data uit Lighthouse en het CrUX rapport
• Search Console (Core Web Vitals report)
• web -vitals JavaScript library, een aanpasbare bibliotheek die alle Web Vitals van echte gebruikers meet

Labtools

• Lighthouse
• Chrome DevTools
• web. dev’s measure tool
• WebPageTest is een web performance tool die je diepgaande inzichten geeft over hoe een pagina presteert onder bepaalde omstandigheden

Veld- en lab gecombineerde tool

• Web Vitals Chrome extension

Bron

Het is beter om verschillende veld- en labtools te gebruiken. Dit bijvoorbeeld omdat Lighthouse resultaten veranderen gebaseerd op de omgeving waarin het draait, de mogelijkheden van je PC en verschillende andere factoren, zoals de netwerksituatie van de servers die hosten, etc. Dus, als je de benchmarks naloopt, zorg er dan voor dat je PC niet vol staat met andere CPU zware taken.

Google ziet de Core Web Vitals standaarden als goed, als 75% van de mensen op je website een goed resultaat ervaren. Maar Lighthouse simuleert een gebruikerservaring op een middelmatige mobile met een trage 4G-verbinding en dat vertegenwoordigt misschien niet 75% van de échte gebruikers.

Workflow om Core Web Vitals te optimaliseren

https://web.dev/vitals-tools-workflow/

Meten – Optimaliseren - Monitoren

Bron

1) Meten - identify pain points,

• CrUX Dashboard om de “gezondheid” van je website te meten.
• Search Console om pagina’s die extra aandacht nodig hebben te identificeren
• PageSpeed Insights om dieper te duiken in de gebruikerservaringsdata van een specifieke pagina.

2) Optimaliseren - debug en optimaliseer pagina’s die aandacht nodig hebben,

• Lighthouse om een pagina na te trekken en verbeteringen te ontdekken.
• Web Vitals extension om de Core Web Vitals standaarden te analyseren in real-time op een pagina.
• Chrome DevTools om prestatieproblemen te debuggen en code-veranderingen te testen.

3) Monitor - continu monitoren en regressie te vermijden.

• CrUX on BigQuery, CrUX API, PSI API en web-vitals.js om een website’s échte gebruikersgegevensverzameling te automatiseren, om aangepaste dashboards mogelijk te maken en alarmsystemen te bouwen.
• Lighthouse-CI om labtests te automatiseren en regressie te vermijden.

Waar komen de Core Web Vitals gegevens waar Search rekening mee houdt vandaan?

De gegevens komen van de Chrome User Experience Report, vandaan, wat gebaseerd is op échte gebruikersbezoeken en intereacties met webpagina’s (RUM of veldgegevens). Om het helemaal duidelijk te maken: de gegevens zijn niet gebaseerd op labsimulaties van laadpagina’s of de bezoeken van niet-menselijke bezoekers zoals Googlebot.

Hoe de Core Web Vitals te halen?

De veelgemaakte fout is dat men probeert de groene 90+ score te behalen. Maar, in werkelijkheid moet je “goed” scoren om de Core Web Vitals opdracht te halen, op alle drie de Core Web Vitals—Largest Contentful Paint (LCP), First Input Delay (FID), en Cumulative Layout Shift (CLS) – van “Veldgegevens”, aangezien dat over échte gebruikers gaat. En alleen deze groene scores geven je groen licht. Google ziet de Core Web Vitals standaarden voor een website als “goed” als 75% van de website’s échte bezoekers een goed resultaat ervaren.

Neem bijvoorbeeld de startpagina van de webwinkel van onze cliënt grasscity.com, die de Core Web Vitals opdracht haalt, terwijl de score niet “groen” is.

En opnieuw, alleen scores gebaaseerd op veldgegevens doen er toe. Waarom lab- en veldgegevens kunnen verschillen lees je hier.

Wat beïnvloedt de Core Web Vitals?

Largest Contentful Paint (LCP) wordt beïnvloed door:

• Trage server response-tijd
• Render-blocking JavaScript en CSS
• Bron-laadtijden (vooral afbeeldingen en videobestanden)
• Rendering aan de kant van de cliënt

First Input Delay (FID) wordt beïnvloed door:

• Lange taken
• Lange JavaScript uitvoertijd
• Lange JavaScript bundels
• Render-blocking JavaScript

Cumulative Layout Shift (CLS) wordt beïnvloed door:

• Advertenties die de layout veranderen
• Cookie banners/notificaties
• Afbeeldingen zonder expliciete afmetingen (lengte en breedte)
• Dynamisch ingevoerde content
• Embedden en iframes zonder afmetingen
• Web fonts die FOIT/FOUT veroorzaken

1. LCP (Large Contentful Paint)

LCP - een gebruikersgerichte standaard die de waargenomen laadsnelheid meet, het punt vastlegt op de pagina-laadtijdlijn wanneer de hoofdinhoud (afbeelding, video, elementen met achtergrondafbeelding gelaad via de url() functie, tekstblokelementen) waarschijnlijk zijn geladen. De tijd wanneer de belangrijkste content op de pagina klaar is om te worden verwerkt.

1.1. Wat is een goede Largest Contentful Paint (LCP) score?

Sites moeten streven naar een LCP van 2.5 seconds of minder. 75% van een pagina moet zijn geladen, verspreid over mobiele- en desktopapparaten.

Bron

Een hoge LCP score betekent dat de gebuikers de content sneller zullen krijgen, begrijpen dat het handig is en op de website blijven. Het kan het bouncepercentage verminderen.

1.2. Welk element wordt als LCP gezien op de pagina?

Je kan Largest Contentful Paint HTML Elementen vinden door Chrome Dev Tools te gebruiken om de LCP (Performance tabblad) te identificeren.

Als je de ladened webpagina opneemt, komt het LCP element naar voren.

• Open Chrome Dev Tools in de Chrome Browser
• Selecteer het apparaatsoort of Responsive en stel de afmetingen in.
• Klik op het Performance Tabblad
• Herlaad de pagina en begin met opnemen
• Wacht totdat het opgenomen profile is geladen
• Ga op tijd met je muis over het LCP icoon om het LCP element op de pagina op te laten lichten

Website Image Analysis Tool op Cloudinary Website Speed Test detecteert het LCP element op de pagina, de tijd die hij nodig heeft om te laden en potentiële optimalisatie die kan worden geimplementeerd in dit gedeelte van de content.

Of in PageSpeed Insights, ga naar het Diagnostiek Gedeelte en zoek naar het LCP element.

1.3. Wat heeft invloed op de LCP?

• Langzame server responstijden

Het kan aan beroerde hosting liggen, maar ook een slechte server setup, lange server respons (door een lange afstand tussen gebruiker en server), uitgeschakelde caching, etc.

• Render-blocking JavaScript and CSS

Als je een eerste verzoek neerlegt om een website te laden, zal de server terugkeren met HTML. Maar om de browser te laden moet je een extra verzoek bij de server neerleggen voor andere belangrijke bestanden. Er wordt vaak in verwezen naar CSS en JavaScript files, waardoor situaties kunnen ontstaan waarbij een browser stopt met laden totdat het elk bestand heeft geüpload en geëvalueerd. Op dit moment wordt het laden van de pagina niet teruggehouden door “zware” afbeeldingen en video’s, maar door “zware” CSS en JavaScript bestanden.

• Bronnen laadtijden

Niet-gecomprimeerde afbeeldingen, video’s en tekstbestanden. Dezelfde content verzorgen voor alle apparaten en daarbij adaptieve en responsieve serving negeren

• Client-side rendering

Vaak gebruiken sites client-side JavaScript logica om pagina’s direct in de browser te laden. Deze client-side rendering vertraagt de lay-out en compositie van de grootste elementen binnen het venster.

PWA oplossingen die nu trending zijn worden het meest geladen aan de kant van de cliënt. Hun logica wordt front-end uitgevoerd, wat de LCP behoorlijk kan beïnvloeden.

PWA’s voor Magento die progressieve bibliotheken zoals Vie.js of React.js gebruiken in default configuratie kunnen je slechte prestatieresultaten laten zien. Het kan worden verbeterd door ervaren ontwikkelaars, maar onthoud weld at hier extra inspanningen bij komen kijken. En als je ervoor kiest om je Magento web store in PWA te converteren, simpelweg vanwege de verwachte hogere prestaties, denk dan nog eens.

1.4. Hoe kan je de Largest Contentful Paint (LCP) voor Magento winkels verbeteren?

Om de LCP te verbeteren, zou belangrijke content met minimale vertraging moeten worden vertoond. Daarom moet het gedeelte van de pagina data als eerst zichtbaar is snel laden.

1.4.1. Trage server responstijden

Hoe langer het een browser kost om content te ontvangen van de server, des te langer het zal duren voordat alles op het scherm is geladen.

Als de impact van de server responstijd significant is, zal je het zien in de Lighthouse audit – Verminder initiële server responstijd.

• Optimaliseer de server’s applicatielogica om pagina’s sneller te laten laden.
• Optimaliseer hoe je server aanvragen doet bij databases, of migreer naar snellere databasesystemen.
• Upgrade je server hardware om meer geheugen of CPU te hebben.
• Gebruik lokale servers, dichtbij je klanten. Als je een webstore hebt in meerdere landen – draag de site dan over naar de dichtstbijzijnde server, waar data sneller zal worden verzonden voor de meeste winkelaars.
• Сache statische bestanden met Varnish.
• Gebruik CDN voor statische bestanden.

Er is geen one-size-fits-all oplossing ie de laadtijd zal vergroten. Neem bijvoorbeeld het verband van bezoekers vanuit verschillende landen aan de site en de plek van de fysieke server(s). Je kan de site overdragen aan een server, waar data veel sneller naar een meerderheid van de sitegebruikers/gebruiker CDN voor statische bestanden zal worden verzonden. Je kan proberen om statische bestanden te cachen met Varnish als sitebezoekers voornamelijk uit één gebied komen.

Maar hoe dan ook, de hosting configuratie is cruciaal voor de Magento 2 prestaties. Ena ls je niet weet hoe je het zelf moet configureren of geen tijd en middelen hebt om servers te ondersteunen en onderhouden, neem het risico dan niet – kies een hosting oplossing die al is geoptimaliseerd en verbeterd voor Magento zoals Hypernode, Cloudways Magento Hosting of MageMojo.

1.4.2. Render-blocking JavaScript en CSS

Render-blocking bronnen zoals JavaScript of CSS veroorzaken significante vertragingen bij het laden van de pagina en beïnvloedt de prestaties. Dit soort prestatieproblemen wordt aangegeven in Lighthouse – “Elimineer render-blocking bronnen”.

Om de tijd te verminderen die het een browser kost om JavaScript code (het laden van de pagina) uit te voeren en te reageren op gebruikersinteracties, moet je de hoeveelheid JavaScript op de pagina verminderen. Dit kan je doen door:

• JavaScript te bundelen
• JS bestanden naar de onderkant van de <body> te verplaatsen
• Niet-essentiele JavaScripts verwijderen
• Inline scripts naar een extern JS bestand verplaatsen

JavaScript bundelen - een techniek waarbij meerdere bestanden worden gecombineerd of gebundeld om het aantal server requests die nodig zijn om een pagina te laden te verminderen. Magento 2 heeft een ingebouwen JavaScript bundelaar, maar het is zo ineffectief dat je een aanbeveling zal zien om de ingebouwen Magento 2 bundelaar waar naar wordt verwezen in Lighthouse rapporten niet te gebruiken. Het probleem is dat het het aantal requests niet vermindert, maar een enorm JavaScript bestand maakt met alle potentieel nodige JavaScript op elke pagina die de web store prestaties zal verslechteren.

Er zijn een hoop alternatieve oplossingen voor de standaard Magento 2 bundelaar. Bijvoorbeeld Magepack - Magento 2 geavenceerde JavaScript bundelaar.

Magepack Top highlights

• Tot wel 91 punten mobile score in Google Lighthouse.
• Tot wel 98% vermindering in JavaScript bestand requests (van 177 naar maar 3).
• Tot wel 44% vermindering in overgedragen JavaScript grootte.
• Tot wel 75% vermindering in totale laadtijd.
• Werkt met Magento’s JavaScript minificatie en fusering toegestaan.
• Gebruikt aangepaste oplossing (geïnspireerd door Baler) in plaats van RequireJS optimalisator, wat veel flexibeler en sneller is, kleinere bundels maakt en niet wordt geremd door missende bestanden.

In Eltrino gebruiken we vaak Magepack voor JavaScript bundelen en de resultaten mogen er weten. Maar in alle eerlijkheid, Magepack zelf zal de prestaties niet onwijs boosten naar de vermelde 91 punten mobile score in Google Lighthouse. Er komen erg veel verbeteringen op verschillende gebieden bij kijken om dit te bereiken.

Er is ook een goede “ultieme gids” voor Magento 2 JavaScript Bundelen van Willem Wigman. Deze gids bevat integer_net Bundling tutorial en voorbeelden uit het echte leven.

Uitgesteld niet-essentiële JavaScript laden - Gebruikt async of defer voor niet-essentiële scripts voor above-the-fold content. Laad tegelijkertijd async en voer het script uit wanneer het klaar is. Laad tegelijkertijd defer en voer het script later uit, net voor domContentLoaded, in de volgordeverwijzingen.

Verplaats niet-essentiële JavaScripts naar de onderkant van de <body>. JavaScript-bestanden worden in de regel bovenaan de pagina geplaatst. Dat zorgt ervoor dat de browser het renderen uitstelt totdat al die zware js-bestanden zijn geladen. Als we alleen essentiële scripts bovenaan laten staan en alle andere onderaan verplaatsen, kan de browser het laden van pagina’s efficiënter verwerken.

Uitgestelde niet-essentiële CSS

CSS-bestanden zijn ook bronnen die het renderen blokkeren: ze moeten worden geladen en verwerkt voordat de browser de pagina weergeeft. Evenals bij JS-bestanden, hoef je alleen essentiële bestanden te uploaden die de browser nodig heeft om de zichtbare inhoud weer te geven (titel, ondertitel en accordeonknoppen). Optimaliseer je CSS zodat de browser essentiële stijlen onmiddellijk begint te verwerken nadat de pagina is geladen, terwijl niet- essentiële CSS wordt uitgesteld tot later.

Schakel het “CSS Critical Path” op Magento Admin Panel in om alle niet- essentiële CSS-bestanden die asynchroon worden geladen, uit te stellen.

Minify en Merge CSS

U kunt CSS verkleinen en samenvoegen via Magento Admin Panel: Beheerderspaneel 🡪 Winkels 🡪 Configuratie 🡪 Geavanceerd 🡪 Ontwikkelaar 🡪 CSS-instellingen 🡪 CSS samenvoegen en CSS verkleinen 🡪 Config opslaan.

Inline critical CSS

CSS kan renderblokkerend zijn, maar je wilt geen productpagina zonder stylies laten zien aan je webwinkelbezoekers. Magento kan een extern CSS-bestand invoegen voordat HTML door de browser wordt weergegeven. Je kunt dus kritieke inline voor de pagina die CSS weergeeft zonder extern verzoek en de browser kan beginnen met het invullen van de pagina

1.4.3. Trage bron laadtijden

Voor veel websites, zijn afbeeldingen het grootste element in het blikveld als de pagina klaar is met laden. Optimaliseer ze.

Optimaliseer je afbeeldingen en video’s

Afbeeldingen zijn ~42% van de Largest Contentful Paint elementen op websites.

• Kies het juiste afbeeldingsformat

Gebruik moderne afbeeldingformats: WebP en SVG.

Er zijn zat modules voor Magento die afbeeldingen naar WebP kunnen converteren: Magento 2 module voor WebP door Yireo,

Magento 2 WebP Images Extension door Magefun,

Magento 2 WebP Images door LandOfCoder

Om de compatibiliteit van het format te controleren met verschillende browsers, Can I use

• Cloudinary Website Speed Test heeft een handige Website Afbeelding Analyseer Tool. Het biedt gedetailleerde optimalisatie-inzichten over hoe wijzigingen in afbeeldingsgrootte, formaat, kwaliteit en coderingsparameters de prestaties kunnen verbeteren. Je kunt huidige afbeeldingen op de website analyseren, opties voor afbeeldingsformat vergelijken met bestandsgrootte en % met de huidige, het voorbeeld bekijken, de compatibiliteit van het format met verschillende browsers controleren en zelfs geconverteerde bestanden downloaden.

• Comprimeer Afbeeldingen

ImageOptim Optimage Alternatively TinyPNG TinyJPG

• Comprimeer Magento media
• Gebruik Imagemin om afbeeldingen te comprimeren
• Vervang geanimeerde GIFs met video voor snellere pagina-laadtijden
• Responsieve afbeeldingen tonen
• Afbeeldingen met de juiste afmetingen tonen
• Gebruik WebP afbeeldingen
• Gebruik afbeelding CDN’s om afbeeldingen te optimaliseren

Optimaliseer je fonts

Het optimaliseren van het font-bestandsproces wordt subsetting genoemd. De meeste fonts bevatten ondersteuning voor allerlei talen en tekensets die je website misschien niet eens gebruikt. Dus om fonts te optimaliseren, moet je jouw fonts onderverdelen in specifieke tekensets. Hulpmiddelen voor subsetting: Font Squirrel, Glyphhanger.

Eén variabel fontbestand is lichter dan verschillende fonts.

Host fonts op je server. Het zal beter presteren om dingen in hetzelfde domein te hebben.

Pre-laad belangrijke bronnen

Door het vooraf laden van essentiële middelen zoals fonts, above-the-fold afbeeldingen of video’s en kritieke CSS of JavaScript in te schakelen, kan de browser het zichtbare deel van de pagina onmiddellijk en zonder vertraging laden en weergeven.

Gebruik om prioriteiten te stellen en de LCP op de pagina op te halen

1.4.4. Client-side rendering

Client-side rendering laadt webpagina’s in de browser met behulp van JavaScript. Zo werken PWA’s. Ze maken gebruik van client-side JavaScript-logica en progressieve bibliotheken zoals Vue.js of React.js voor Magento. Maar het heeft een aanzienlijke invloed op LCP, aangezien de browser eerst alle kritieke JavaScript moet laden voordat het renderen kan worden voltooid.

Als je al PWA gebruikt, kan server-side rendering ook een optie zijn. Het gelijktijdig gebruiken van SSR en CSR wordt een gangbare praktijk, aangezien het voor sommige PWA’s onmogelijk is om één benadering positief te kiezen. Vue.js en React hebben bibliotheken voor SSR.

1.4.5. Maak geen gebruik van Lazy Loading voor LCP elementen

Lazy Loading lijkt misschien een wondermiddel, en het is een typische truc om de waargenomen prestaties te verbeteren. Maar als je het toepast op LCP-elementen, kan dat je LCP-score verpesten. Lazy Loading stelt het downloaden van een bron uit totdat deze nodig is, waardoor gegevens worden bespaard en netwerkconflicten voor kritieke onderdelen worden verminderd, het vervangt afbeeldingen buiten het kijkveld door tijdelijke aanduidingen. Dus wanneer sitebezoekers beginnen te scrollen, wordt de media zichtbaar op hun schermen.

Lazy Loading is een verbazingwekkend effectief hulpmiddel voor het verminderen van onnodige afbeeldingsbytes, het verbetert de waargenomen prestaties aanzienlijk. Maar vermijd Lazy

Loading above-the-fold, het zal het laden van LCP-elementen uitstellen en als gevolg daarvan de LCP-score verlagen. Lazy Loading werkt perfect voor elementen die niet zichtbaar zijn terwijl de pagina wordt weergegeven, maar essentiële bronnen above-the-fold moeten worden geladen met het standaard -element, zodat ze zo snel mogelijk worden weergegeven.

1.4.6. Lazyload images and iframes natively

Als je lazy loading gebruikt voor afbeeldingen en iframes, doe dit dan native, aangezien lazy loading JS-bibliotheken van derden de hoofdthread overweldigen.

2. First Input Delay (FID)

First Input Delay (FID) meet hoe snel de gebruiker kan beginnen met interactie met de website-elementen. FID meet de tijd vanaf de eerste gebruikersinteractie met de webpagina (klik op de knop, tik op het menu, selecteer productoptie, enz.) tot het moment waarop de browser op die interactie kan reageren.

FID heeft een cruciale impact op de eerste gebruikersexpressie op je webwinkel.

2.1. Wat is een goede First Input Delay (FID) score?

Sites moeten streven naar een First Input Delay van 100 milliseconden of minder.

Bron

Voor het gemiddelde mobiele apparaat met een langzame 3G-verbinding kan het 6 seconden duren om 200 kB aan JavaScript-overdracht te ontleden. Dus als je een framework voor een client-side JavaScript gebruikt, kan het een uitdaging zijn om de interactiviteitsbaseline van 5 seconden te halen.

2.2. Wat beïnvloedt de FID?

Als gebruikers hebben we allemaal die frustrerende ervaring wel eens gehad waarbij je een website op je mobiel opende, probeerde op de knop te tikken en er niet gebeurde. Deze vertraging treedt op omdat de hoofdthread van de browser bezig is met iets anders, dus het vertraagt het reageren op de gebruiker totdat de prioriteitstaak is voltooid. In de regel gebeurt dit omdat de browser een groot JavaScript-bestand, grote JS-bundels of andere renderblokkerende middelen aan het analyseren en uitvoeren is.

2.3. Hoe de First Input Delay (FID) voor Magento winkel te verbeteren?

FID is een veldmetriek en kan niet worden gesimuleerd in een laboratoriumomgeving. Een echte gebruikersinteractie is vereist om de responsvertraging te meten.

2.3.1. Verminder de impact van code van derden

Analyseservices, A/B-tests, allerlei embeds van derden (feed voor sociale media, YouTube-video’s, kaarten, enz.), advertentienetwerken, chatservices, marketingservices, gepersonaliseerde productaanbevelingen - moeten meestal een script van een derde partij toevoegen aan je HTML. En al deze scripts van derden kunnen de laadprestaties van je pagina’s aanzienlijk beïnvloeden. Het is dus essentieel om trage scripts van derden te identificeren, hun waarde voor je bedrijfslogica te analyseren, alleen echt waardevolle scripts te houden en deze correct te implementeren.

Veel populaire embeds bevatten meer dan 100 KB JavaScript, soms zelfs tot 2 MB. Het schaadt zeker de prestaties van de website. Meer dan 50% van de gebruikers verlaat een website als het langer dan 3 seconden duurt om te laden. Dus onnodige code van derden kan je bedrijf meer schaden dan de voordelen die je kunt halen uit het gebruik ervan.

Om de impact van embeds te verminderen, maar hun functionaliteit te behouden:

- Scriptvolgorde (de belangrijkste inhoud van de eerste partij wordt eerst geladen, terwijl de ingesloten inhoud van derden na de belangrijkste inhoud wordt weergegeven)

- Lazy-loading (stel het downloaden van ingesloten inhoud uit totdat het echt nodig is). Lazy-loading van de YouTube-embed kan ongeveer 500 KB besparen bij het laden van de eerste pagina.

- Lazysizes-bibliotheek (lazysizes is een snelle, SEO-vriendelijke lazy loader voor zowel afbeeldingen als iframes)

- Vervang embeds met façades (statische elementen die lijken op de daadwerkelijke embedded derden). Lite-youtube-embed is een aanbevolen façade voor de YouTube-speler, die eruitziet als de echte speler, maar 224 keer sneller is. Façades zijn geschikt voor: chat-widgets, zoekbibliotheken, reCaptcha, formuliervalidatie, social share buttons, one-click betaalknoppen (bijvoorbeeld PayPal)

2.3.2. Verminder JavaScript uitvoertijd

• Verstuur alleen de code die je gebruikers nodig hebben door codesplitsing te implementeren. Verminder JavaScript-payloads met codesplitsing.
• Ongebruikte code verwijderen.
• Verminder netwerk reizen door je code in de cache te plaatsen met het PRPL-patroon

2.3.3. Minimaliseer hoofdthread-werk

Om je code in een webpagina om te zetten, moet de browser deze weergeven. De hoofdthread van dat proces bedient de meeste code: het ontleedt de HTML en bouwt de DOM, ontleedt de CSS en past de gespecificeerde stijlen toe, en ontleedt, evalueert en voert JavaScript uit.

De hoofdthread verwerkt ook gebruikersevents. Wanneer de hoofdthread bezig is met iets anders, kan je webpagina niet reageren op gebruikersinteracties, dit veroorzaakt vertraging, met als resultaat dat de FID-tijd toeneemt.

Optimaliseer JavaScript van derden - services van derden op je webwinkelpagina spelen een essentiële rol voor je bedrijf, door de website te voorzien van nieuwe functies, analyses, een gepersonaliseerde gebruikerservaring voor je klanten, enz. Maar als ze allemaal worden uitgevoerd wanneer de gebruiker de pagina opent, houdt het de hoofdthread lang bezig. Als gevolg hiervan kunnen gebruikers een tijdje geen interactie hebben met de website-elementen. En we hebben allemaal maar één thread per tabblad om het werk te doen van het weergeven van onze sites en het uitvoeren van ons JavaScript.

De oplossing is om prioriteit te geven aan het laden van webelementen, zodat alleen essentiële elementen van derden above-the-fold worden geplaatst. FID meet het reactievermogen van een pagina tijdens het laden, waarbij de nadruk ligt op input events van discrete acties zoals klikken, tikken en toetsaanslagen, maar niet op scrollen of zoomen. De belangrijkste taak is dus om alle elementen above-the-fold bruikbaar te maken, terwijl andere on-demand kunnen worden geladen.

Gebruik webworkers

De zwaarst belaste hoofdthread is een belangrijk knelpunt voor de prestaties. Om dat op te lossen, kunnen we in sommige gevallen webworkers gebruiken die parallel lopen met de hoofdthread. Webworkers worden uitgevoerd in een aparte JavaScript-omgeving en hebben invloed op de hoofdthread. Maar houd er rekening mee dat webworkers geen wondermiddel zijn. In tegenstelling tot PWA hebben webworkers geen toegang tot de DOM en veel API’s zoals WebUSB, WebRTC of Web Audio, dus je kunt geen onderdelen van je app die afhankelijk zijn van dergelijke toegang in een worker plaatsen. Hierdoor kunnen webworkers op dit moment alleen AJAX-oproepen afhandelen.

Draag het laden van de JavaScript code over

Je hebt bijvoorbeeld een beoordelingswidget op je productpagina die wordt geleverd door een systeem van derden. Het kan zelf zwaar zijn, dus alleen al het opnemen ervan op de pagina kan op sommige apparaten een interactievertraging van vele seconden veroorzaken.

De truc is om deze beoordelingen te verbergen via de knop “Productbeoordeling bekijken”.

Als we het laden van de beoordelingsfunctie helemaal uitstellen, of door te wachten tot de gebruiker erop klikt, of het later laadt, ging het laden van de eerste pagina een stuk soepeler. De tijd voor interactie is korter en met bijna geen kosten voor de waargenomen visuele ervaring.

Als je zelf JavaScript schrijft, weet je waarschijnlijk hoe je het kunt optimaliseren.

3. Cumulative Layout Shift (CLS)

Cumulatieve Lay-out Shift (CLS) meet de visuele stabiliteit van zichtbare inhoud op de pagina. Het kwantificeert onverwachte lay-outverschuivingen, vervelende inhoudsbewegingen die de gebruikerservaring afleiden.

CLS is een maatstaf voor de grootste uitbarsting van lay-outverschuivingsscores voor elke onverwachte lay-outverschuiving die optreedt gedurende de gehele levensduur van een pagina, ook wanneer gebruikers naar beneden scrollen.

Lay-outverschuivingen vinden alleen plaats bij bestaande elementen die hun startpositie wijzigen. Als een nieuw element wordt toegevoegd aan de DOM of een bestaand element wordt vergroot/verkleind - telt dit niet als een lay-outverschuiving. Om iets een ​​lay-outverschuiving te kunnen noemen, zou dit ertoe moeten leiden dat andere zichtbare elementen hun startpositie wijzigen.

Alleen onverwachte lay-outverschuivingen zijn slecht. Als het een verwachte reactie is op gebruikersinteractie (klikken op een link, op een knop drukken, in een zoekvak typen, enz.) en het gebeurt binnen 500 milliseconden na gebruikersinvoer, telt dit niet mee voor de CLS-berekening.

Je hebt bijvoorbeeld een knop “Meer laden”. Als de nieuwe inhoud binnen 500 ms vanaf de gebruikersinteractie wordt toegevoegd (klik op de knop “Meer laden”), wordt er geen CLS gegenereerd.

3.1. Wat is een goede Cumulative Layout Shift (CLS) score?

Een goede Cumulatieve Layout Shift (CLS)-score is 0,1 of minder. Een score boven 0,25 kan een negatieve invloed hebben op de ranking, een duidelijk teken dat gebruikers een slechte ervaring op de pagina hebben.

Bron

3.2. Wat beïnvloedt de CLS?

CLS veroorzaakt door:

• Afbeeldingen zonder afmetingen
• Advertenties, embeds, iFrames zonder afmetingen
• Webfonts die FOIT/FOUT veroorzaken
• CSS laden voor zichtbare inhoud

Inhoudsverschuivingen vinden in de regel plaats omdat elementen asynchroon worden geladen of DOM-elementen dynamisch worden toegevoegd aan de pagina boven bestaande inhoud.

In de regel wordt CLS gegenereerd door een afbeelding of video met onbekende afmetingen, een font dat te lang duurt om te renderen, of een widget, ingesloten, iframe, adv-blok van derden dat met vertraging kan verschijnen (vanwege zware js-code ) of niet de juiste maatvoering heeft.

3.3. Hoe de Cumulatieve Layout Shift (CLS) voor Magento winkel te verbeteren?

Het lastige van CLS is dat er tijdens de ontwikkeling geen verschuivingen optreden omdat afbeeldingen en andere inhoud al in de browser van de ontwikkelaar zijn opgeslagen. Evenals API kan dit lokaal veel sneller worden uitgevoerd dan in productie. Vertragingen zijn dus niet merkbaar voor ontwikkelaars. Tegelijkertijd kunnen echte gebruikers de tegenovergestelde ervaring hebben.

Het is dus cruciaal om de CLS standaarden voor échte gebruikers te monitoren.. En als je geen 28 dagen kan wachten om in een CrUX rapport te zien of de geïmplementeerde updates de échte gebruikerservaring beïnvloeden, kan je maar beter de web -vitals JavaScript bibliotheek, toevoegen, een aanpasbare bibliotheek die CLS meet, samen met andere Core Web Vitals met de gegevens van échte gebruikers.

3.3.1. Voeg altijd breedte- en hoogtekenmerken toe aan alle afbeelding- en video-elementen

Expliciete elementenafmetingen helpen de browser om de juiste hoeveelheid ruimte in het document toe te wijzen terwijl de afbeelding wordt geladen. Dus wanneer het element is geladen, zal het geen andere elementen op de pagina duwen. Je kan ook het unsized-media feature beleid gebruiken om dit gedrag in browsers, die een feature beleid ondersteunen, te forceren.

Magento bevat breedte- en hoogtekenmerken op productafbeeldingen. Maar vergeet niet om voor alle andere afbeeldingen expliciete afmetingen op te geven.

3.3.2. Reserveer de benodigde ruimte voor embeds (Pseudo Element Tactiek)

Reserveer de benodigde ruimte voor elementen die later zullen worden geladen, met iets zoals CSS aspect ratio boxes om de browser de correct hoeveelheid ruimte in het document toe te bedelen. Bereken de benodigde ruimte en reserveer deze bijvoorbeeld door de minimale hoogte van de wrapper in te stellen waar het element (menu, banner, carrousel, etc.) later getoond moet worden.

3.3.3. Voeg nooit inhoud toe boven bestaande inhoud, behalve als reactie op een gebruikersinteractie

Dit zorgt ervoor dat er met eventuele lay-outverschuivingen rekening wordt gehouden. Als je iets boven het bestaande element moet toevoegen, overweeg dan om position: absoluut of vast te gebruiken.

3.3.4. Gebruik transform animaties

Geef de voorkeur aan transform animaties tot animaties van eigenschappen die lay-outwijzigingen veroorzaken.

Het veranderen van transform veroorzaakt geen geometrieveranderingen of schilderen, wat erg goed is. Dit betekent dat de bewerking waarschijnlijk kan worden uitgevoerd door de compositor-thread met behulp van de GPU.

3.3.5. Preload fonts, optimaliseer ze en host ze intern

Vaak veroorzaken extern geladen fonts lay-outverschuivingen. Verschuivingen vinden op twee manieren plaats:

• Een fallback-font wordt verwisseld met een nieuw font (“flash of unstyled text” -FOUT)
• “Onzichtbare” tekst wordt weergegeven totdat een nieuw font op de pagina wordt weergegeven (“flits van onzichtbare tekst” - FOIT)

Aangepaste fonts zijn belangrijk voor marketing. Ze maken deel uit van de merkidentiteit en zijn essentieel voor differentiatie. Aangepaste fonts hebben een andere lgrootte en spatiëring dan de standaardfonts. En het kost meer tijd om ze te laden, te verwerken en weer te geven, dus in eerste instantie wordt de inhoud weergegeven in het standaardfont en vervolgens omgezet in aangepast. Als het onjuist gebeurt, veroorzaakt het lay-outverschuivingen.

Dus hoe voorkom je dat de lay-out verschuift als gevolg van aangepaste fonts met behoud van de CLS-score?

• Preload fonts (vermijd layoutverschuivingen en stukken onzichtbare tekst (FOIT) door optionele fonts te preloaden)
• Host fonts lokaal
• Verander icoonfonts in SVG. Icoonfonts-bestanden zijn groot. Iconen worden pas weergegeven als het hele fontbestand is gedownload. Je kunt ook geen afmetingkenmerken opgeven voor het font icoon. En deze combinatie van vertraging, niet-gespecificeerde en veranderende afmeting is schadelijk voor de CLS-schaal. SVG-elementen worden sneller gedownload en bewegen niet over de pagina (als je afmetingkenmerken instelt)
• Kritische CSS gebruiken

Samenvatting

Zelfs als je aan alle Core Web Vital-vereisten voldoet, de website ongelooflijk snel uploadt en de perfecte ervaring biedt voor gebruikers, ze zien de informatie op je pagina meteen, maar die informatie is niet afgestemd op wat Google aanneemt waar ze naar op zoek zijn, zal je niet zichtbaar zijn. Het zou dus het beste zijn als je ervoor zorgt dat de webwinkel technisch perfect gestructureerd is en dat je de juiste inhoud hebt die gebruikers nodig hebben.

Een score van 100% op Lighthouse betekent niet dat je site in de echte wereld hetzelfde resultaat zal opleveren. Houdt voortdurend toezicht op en vertrouw op veldgegevens (echte gebruikerservaring).

Interpreteer gegevens met zorg met behulp van verschillende tools voor het meten en combineren van veld- en laboratoriumgegevensresultaten. De Core Web Vitals-statistieken zijn een goede indicatie van wat er op een website gebeurt, maar er is geen perfecte tool die met 100% zekerheid laat zien wat er aan de hand is. Het is dus aan te raden om je meer te concentreren op de optimalisatiemogelijkheden in het rapport.

Om te slagen voor Core Web Vitals, heb je geen prestatiescore van 100% nodig, je moet voldoen aan de vereisten voor LCP, FID, CLS. Ga niet achter een “groene” score aan, geef prioriteit aan de drie hoofdstatistieken.

Het zijn niet alleen de ontwikkelaars, maar iedereen in het team moet meewerken aan de wijzigingen die in een webwinkel worden aangebracht. En alle afdelingen moeten begrijpen hoe deze veranderingen de prestaties van de webwinkel beïnvloeden. Onthoud dat elk toegevoegd script op de pagina van invloed is op prestatiestatistieken en vooral op de Core Web Vitals.

Voeg geen nieuwe functies toe via Google Tag Manager zonder overleg met de ontwikkelaar. Alle toegevoegde scripts moeten verstandig en in de juiste volgorde worden toegevoegd. Anders zullen deze 100 verzoeken de prestaties en het bedrijf zelf schaden.

Meer over Core Web Vitals

Waarom lab- en veldgegevens kunnen verschillen

Een Magento Website Core Web Vitals diagnosticeren

Praktische Gids voor Core Web Vitals (voor handelaren) door Wilem Wigman

Optimaliseren voor Core Web Vitals

Genereer CrUX + ROI calculator door Erwin Hofman