Wat zijn de Core Web Vitals?

De Core Web Vitals zijn een drietal statistieken waarop Google de prestaties van een website of webshop beoordeeld. Dat zijn:

  • Snelheid
  • Interactiviteit
  • Visuele stabiliteit

Snelheid - LCP

LCP (Largest Contentful Paint) is de eerste meting van de Core Web Vitals die gebruikt wordt voor de snelheid van een webpagina. Kort samengevat: hoe lang het duurt voordat de grootste afbeelding of tekstblok, dat zichtbaar is zonder naar beneden te hoeven scrollen, volledig zichtbaar is.

Interactiviteit - FID

FID (First Input Delay), de tweede meting van de Core Web Vitals, is de vertraging tussen de eerste interactie vanuit de bezoeker en wanneer de website daadwerkelijk reageert, bijvoorbeeld bij het drukken op de knop voor het openklappen van navigatiemenu's.

Visuele stabiliteit - CLS

CLS (Cumulative Layout Shift), de derde meting van de Core Web Vitals, is een optelsom van alle verschuivingen die plaatsvinden op een webpagina. Heeft u wel eens meegemaakt dat er plots een advertentie tevoorschijn komt, alles naar onderen verschuift, nét voordat u ergens op wilt klikken? U bent niet de enige die daar last van heeft.

Niet alleen advertenties zorgen hiervoor.. Afbeeldingen die pas na het laden ruimte innemen, stukken tekst waarvan de lettertype veranderd zodra het lettertype is geladen – waardoor de letters een andere grote aannemen, CSS-bestanden die veel te laat toegepast worden en het design op de schop gooien, zorgen allemaal voor verschuivingen in het design - niet goed voor de Core Web Vitals.

Inzicht in voortgang Core Web Vitals

Wij leggen u in het kort uit hoe u inzicht kunt krijgen in hoe uw website of webshop er voor bestaat wat betreft de Core Web Vitals. Aangezien het zichzelf niet automatisch oplost door het te blijven testen, verdoen wij uw tijd niet en focussen wij ons op oplossingen.

Met behulp van PageSpeed Insights, krijgt u inzicht in meer dan de drie statistieken waar de Core Web Vitals zich op richt. U zult zien dat bij de labgegevens de tweede statistiek ontbreekt. Deze statistiek komt alleen naar voren uit gegevens van echte bezoekers.

De Core Web Vitals kunt u herkennen aan de blauwe icoontjes achter de naam van de statistiek. In hoeverre uw website voldoet aan de Core Web Vitals wordt aangegeven met drie kleuren en drie vormen (voor kleurenblinden, heeft Google al over nagedacht):

  • Rode driehoek - Slecht
    • LCP > 4s
    • FID > 300ms
    • CLS > 0,25
  • Oranje vierkant - Matig
    • LCP <= 4s
    • FID <= 300ms
    • CLS <= 0,25
  • Groene cirkel - Goed
    • LCP < 2,5s
    • FID < 100ms
    • CLS < 0,1

Laaghangend fruit voor Core Web Vitals

Vanwege eventuele nieuwkomers op het gebied van het optimaliseren voor de Core Web Vitals, hebben wij besloten om te beginnen met de oplossingen die gemakkelijker zijn om te implementeren. Heeft u al eerder artikelen gelezen over het optimaliseren voor de Google Core Web Vitals? Scan dit hoofdstuk dan even snel, kijk of er nog iets voor u is blijven hangen en scrol/swipe vervolgens verder naar de unieke oplossingen die wij in dit artikel weggeven om u op weg te helpen met de Core Web Vitals optimalisatie.

Lazy-loading afbeeldingen en iframes

Als u gebruik maakt van WordPress en het systeem up-to-date heeft gehouden, dan heeft WordPress dit al voor u ingeschakeld. Gebruikt u een ander systeem? Dan kunt u afbeeldingen en inline frames lazy-loaden door loading="lazy" toe te voegen aan de <img>-tags en <iframe>-tags. Dit is een attribuut dat in 2019 is toegevoegd om lazy-loading via de webbrowser te laten lopen in plaats van via JavaScript. Momenteel (maart 2021) wordt native lazy-loading, zoals dat heet, goed ondersteund door de moderne webbrowsers. Safari en Safari op iOS hebben deze functionaliteit helaas niet standaard aan staan; de gebruiker dient deze functie zelf in te schakelen. Op Safari is lazy-loading via JavaScript dus alsnog vereist. Wij hopen dat Safari deze functionaliteit binnenkort standaard aanzet, zodat JavaScript-oplossingen niet meer nodig zijn. Dat maakt de Core Web Vitals optimalisatie iets gemakkelijker.

WebP-afbeeldingen voor snelle download

WebP is een encodering voor afbeeldingen dat gemiddeld 39% kleiner is dan JPEG-afbeeldingen en 45% kleiner dan PNG. Pagina's met veel zware afbeeldingen zullen niet aan de Core Web Vitals voldoen wanneer bezoekers een lage downloadsnelheid hebben.

Gebruikt u WordPress? Dan kunt u gebruik maken van WebP Express. Om deze plug-in te gebruiken, plaatst u in de backend van WordPress uw muis op Instellingen en klikt u op de link WebP Express. Scroll vervolgens naar sectie Alter HTML

Neem de instellingen over in Figuur 1 die gaan over sectie Alter HTML.

Alter HTML instellingen WebP Express

Figuur 1. Alter HTML instellingen voor plug-in WebP Express

Met deze instellingen gereed, zorgt de plug-in ervoor dat de browser WebP-afbeeldingen toont in plaats van JPEG of PNG. Als de webbrowser deze niet ondersteunt, dan gebruikt die de normale versie: JPEG of PNG. U zou er zelfs voor kunnen kiezen om Replace image URLs aan te vinken, aangezien alle moderne webbrowsers WebP ondersteunen.

Microsoft Internet Explorer ondersteund geen WebP, maar gelukkig gebruikt bijna niemand deze webbrowsers meer. Wanneer uw doelgroep nog wél gebruik maakt van Internet Explorer, raad ik het u aan om de instellingen in Figuur 1 over te nemen en Dynamically load picturefill.js on older browsers aan te vinken, aangezien <picture> niet wordt ondersteund door IE.

U kunt de afbeeldingen converteren met de knop Bulk Convert.

Het optimaliseren van afbeeldingen is een grote stap in de goede richting voor uw Core Web Vitals optimalisatie.

JavaScript-bestanden verkleinen

Hoewel dit alleen de grootte van de JavaScript-bestanden verminderd, kunnen websites met veel JavaScript een winst mee behalen. Bezoekers met een minder snelle internetverbinding zullen hierdoor minder lang hoeven te wachten. Stap voor stap dichter bij het voldoen aan de Core Web Vitals, omdat er veel optimalisaties nodig zijn waarvan geen enkele op zichzelf doorslaggevend is.

Indien u nog geen WordPress plug-in gebruikt voor snelheid optimalisatie, dan raad ik de plug-in LiteSpeed Cache aan. Als u LiteSpeed Cache heeft geïnstalleerd, ga dan in de backend van WordPress en plaats uw muis op LiteSpeed Cache en klik vervolgens op de link Pagina optimalisatie. Klik nu op tabblad [2] JS instellingen en vink Verklein JS aan. Controleer of alles nog werkt!

JavaScript-bestanden bundelen

Zoals hierboven besproken, u kunt de WordPress plug-in LiteSpeed Cache gebruiken om allerlei optimalisaties uit te voeren. Ga in de backend van WordPress, plaats uw muis op LiteSpeed Cache en klik op de link Pagina optimalisatie. Klik weer op tabblad [2] JS instellingen en vink Bundel JS aan. Controleer weer of alles naar behoren werkt. Het is absoluut niet de bedoeling dat de functionaliteit van uw website of webshop gelimiteerd moet worden om te kunnen voldoen aan de Core Web Vitals.

JavaScript-bestanden pushen

Via de LiteSpeed Cache plug-in voor WordPress kunt u bij de Pagina optimalisatie klikken op tabblad [2] JS instellingen en de optie JS HTTP/2 Push aanvinken. Deze optie kunt u alleen gebruiken als uw website HTTPS gebruikt met een geldig SSL certificaat.

Hoewel niet verbonden met de Core Web Vitals, is HTTPS een must-have om te kunnen scoren in de zoekmachine als webshop.

CSS-bestanden verkleinen

Hetzelfde geld voor het verkleinen van CSS-bestanden. In de WordPress plug-in LiteSpeed Cache klikt u op Pagina optimalisatie en vinkt u de optie Verklein CSS aan. Controleer weer of alles werkt. Aan het einde van uw Core Web Vitals optimalisatie is het de bedoeling dat alles het nog doet.. sterker nog, het moet nog beter en sneller gaan doen!

CSS-bestanden bundelen

Op dezelfde pagina vinkt u de optie Bundel CSS aan en controleert u weer of uw website er nog goed uit ziet en goed werkt.

CSS-bestanden pushen

Op dezelfde pagina vinkt u de optie CSS HTTP/2 Push aan. Dit werkt alleen als uw website gebruik maakt van HTTPS met een geldig SSL certificaat. Controleer wel of dit bijdraagt aan de snelheid van uw website.

HTML verkleinen

Via de WordPress plug-in LiteSpeed Cache kunt u via Pagina optimalisatie klikken op tabblad [3] Optimalisatie en vervolgens de optie Verklein HTML aanvinken. Controleer goed of uw website er nog goed uit ziet en of er geen JavaScript errors zijn.

Unieke oplossingen

Om te kunnen voldoen aan de Core Web Vitals is er wel echt wat meer nodig dan al het laaghangend fruit dat op elke blogpost wordt herhaald. Het vraagt om hulp van iemand die ervaring heeft met het maken van websites, maar dan moet diegene ook nog weten hoe een website te optimaliseren voor snelheid en een betere gebruikerservaring. Dat is nou net waar de Core Web Vitals om draait.

Aantal verzoeken beperken

Voordat bestanden gedownload kunnen worden, dient er een verzoek gestuurd te worden vanuit het apparaat van de bezoeker naar de server van een website. Hoe lang het duurt tot het apparaat kan beginnen met het downloaden van een bestand vanuit de server, wordt de TTFB (Time To First Byte) genoemd. Stel dat dit 50 milliseconden per verzoek is en dat er 45 bestanden gedownload moeten worden om een webpagina compleet te maken, dan kost dit in theorie al ruim 2 seconden aan wachttijd. In de praktijk worden er meerdere verzoeken tegelijkertijd verzonden, waardoor dit minder tijd kost. Toch heeft het een behoorlijke invloed op de laadtijd en daarmee een directe invloed op of uw website of webshop gaat slagen voor de Core Web Vitals of niet.

Stel, de browser vraagt de server van een website om een bestand dat aangeeft welke kleur de letters moeten zijn op de website, hoe groot, wat de regelafstand is, etc. Het duurt 50 milliseconden tot de browser een antwoord krijgt en het bestand kan downloaden.

Vervolgens duurt het downloaden van het bestand ook nog 50 milliseconden. Tot nu toe is er niets ergs aan de hand.. Tot de browser er achter komt dat het CSS-bestand het lettertype op de webpagina wilt veranderen en daar vervolgens een tweetal lettertype-bestanden voor nodig heeft, waarvan de ene bedoeld is voor dikgedrukte tekst en de andere voor normale tekst.

Dit is niet efficiënt, omdat voor deze lettertype-bestanden nogmaals twee verzoeken gedaan moeten worden. Het had handiger geweest als de twee lettertype-bestanden al verwerkt waren in het CSS-bestand, omdat de browser er anders na 100 milliseconden achter komt dat er opnieuw gewacht moet worden op twee aparte verzoeken. Deze verzoeken voor de lettertype-bestanden hadden ook van te voren gemaakt kunnen worden, zodat op deze twee bestanden gewacht kon worden tegelijkertijd met het CSS-bestand.

Het van te voren downloaden van een bestand wordt preloading genoemd. Dit bespreken wij verderop in dit artikel, aangezien dat soms nodig is om verschuivingen te voorkomen. Verschuivingen veroorzaken hoge CLS, de derde statistiek van de Core Web Vitals.

Data-URI voor kleine favicons

Een favicon is een miniatuur van uw logo dat als icoontje gebruikt wordt in de tabbladen in uw webbrowser. Zie Figuur 2. Deze wordt ook getoond in de mobiele zoekresultaten. Aangezien favicons vaak maar 1KB groot zijn, is het efficiënter om deze direct in het HTML-document te plaatsen. Dan hoeft er geen extra verzoek gedaan te worden voor een bestand van 1KB in grootte. Wanneer een bestand veel groter is, bijvoorbeeld 200KB, dan is het verstandig deze via een apart verzoek in te laden. Bestanden, die via een URL worden gedownload, kunnen namelijk gecached worden door de webbrowser. Dat betekent dat het bestand opgeslagen wordt en deze niet opnieuw gedownload hoeft te worden wanneer de bezoeker een andere pagina opent waar dat bestand ook wordt gebruikt.

De favicon is iets wat over het hoofd gezien wordt, het is ook maar een icoontje. Toch vraagt het een om extra verzoek. Het aantal verzoeken beperken is wat de bedoeling is. Elk extra verzoek, hoe klein die ook is, is een stap verder van de Core Web Vitals vandaan.

Favicon in een tabblad

Figuur 2. Favicon in een tabblad

Wij hebben op deze website een data-URI gebruikt voor de 32x32-favicon, aangezien die grootte het meest wordt gebruikt. De grotere favicons worden via een apart verzoek geladen, aangezien deze minder vaak worden gebruikt en een groter bestand hebben.

U kunt met behulp van de Image to Data URI converter een data-URI genereren die u kunt gebruiken voor uw kleinste favicon. Zie Figuur 3 voor een voorbeeld van hoe een data-URI gebruikt kan worden voor een favicon.

Favicon data-URI voor Core Web Vitals optimalisatie

Figuur 3. Voorbeeld van een data-URI voor een favicon

Data-URI voor woff2 lettertypes

Terugkomend op het voorbeeld van het CSS-bestand waaruit twee aparte verzoeken voor lettertype-bestanden ontstaan, is het mogelijk om een lettertype-bestand te verwerken in het CSS-bestand, zodat hiervoor geen apart verzoek gedaan hoeft te worden.

Het is daarbij wel verstandig dat u zeker weet dat dit lettertype-bestand gebruikt gaat worden, aangezien het CSS-bestand natuurlijk groter wordt wanneer u het lettertype-bestand er in verwerkt. Op deze website maken wij gebruik van icoontjes die verwerkt zitten in een lettertype-bestand. Dat bestand was erg klein en werd opgeroepen via een CSS-bestand, dus hebben wij dit lettertype-bestand verwerkt in het CSS-bestand zelf, zodat daarvoor geen apart verzoek gemaakt hoeft te worden. Zie Figuur 4.

woff2 data-URI voor Core Web Vitals optimalisatie

Figuur 4. Data-URI van een woff2 lettertype-bestand

U kunt zelf een data-URI genereren voor woff2-bestanden via de data: URI Generator. Zorg er daarbij wel voor dat u de optie Explicitly specify mime type selecteerd en in het veld naast Enter Mime Type de waarde font/woff2 invoert. Zie Figuur 5.

Klik vervolgens op knop Generate Data URI, klik vervolgens op de data-URI die verschijnt en kopieer het (CTRL + C). U kunt nu in het CSS-bestand de URL van het woff2 lettertype-bestand vervangen door de data-URI (CTRL + V).

Let er wel op dat u de juiste URL vervangt, zoek naar de URL die vóór format('woff2') staat tussen url(' en ').

Mime Type van data-URI voor Core Web Vitals

Figuur 5. Mime Type van het bestand specificeren waarvoor de data-URI dient

Asynchroon decoderen van afbeeldingen

Wanneer een afbeelding wordt gedownload, kan deze nog niet direct op het beeld getoond worden. Het afbeeldingsbestand dient eerst omgezet te worden in pixels en kan daarna door de webbrowser getekend worden. Het omzetten van een afbeeldingsbestand naar pixels heet het decoderen van afbeeldingen. Het omzetten van pixels naar een afbeeldingsbestand heet encoderen.

De tijd dat het kost om een afbeelding te decoderen hangt af van de grootte van het bestand, de kracht van de processor (CPU), het werkgeheugen (RAM) van het apparaat en de codering van de afbeelding (JPEG, PNG, WebP, AVIF). Om een beeld te scheppen van over hoeveel tijd wij het hebben: op een snelle PC duurde het bij ons 24 milliseconden om een JPEG-afbeelding te decoderen van 119KB (2480x1651). Op mobiele apparaten zou dit wat langer duren en bij mobiele apparaten met een minder snelle CPU en minder werkgeheugen zou dit op kunnen lopen tot 100 milliseconden of meer. Hoe groot een afbeelding is heeft dus niet alleen invloed op hoe lang het downloaden duurt, maar ook hoe lang het duurt voordat zo'n afbeelding door de browser getekend kan worden.

Standaard blokkeert het decoderen van een afbeelding het proces van het tekenen van andere inhoud op de pagina, maar het is mogelijk om het decoderen van afbeeldingen asynchroon te laten verlopen met behulp van een HTML-attribuut genaamd decoding.

De standaardwaarde voor dit attribuut is auto. In dat geval bepaald de webbrowser zelf wat de beste strategie is voor het decoderen van de afbeelding. De waarde sync geeft aan dat het decoderen synchroon loopt met de andere content dat door de webbrowser getekend moet worden. Met de waarde async kunt u dus afbeeldingen asynchroon laten decoderen en vertraagd dit de rest niet.

Wikipedia wilt niet dat het decoderen van afbeeldingen voor vertraging zorgt voor het tonen van de rest van de inhoud. Zij maken daarom gebruik van deze techniek, zodat bij hun de inhoud meer prioriteit krijgt dan de afbeeldingen. Zie Figuur 6.

async decoding met Wikipedia.org als voorbeeld

Figuur 6. Gebruik van asynchroon decoderen door Wikipedia.org

JavaScript polyfills uitschakelen

JavaScript-polyfills maken functies beschikbaar voor verouderde webbrowsers zoals Microsoft Internet Explorer. De reden waarom u kunt overwegen om polyfills uit te schakelen, is voor de snelheid van uw website en om weer een stuk dichter bij het voldoen aan de Core Web Vitals te komen. Waarschijnlijk lijkt het verschil in laadtijd klein, maar niet als u alle optimalisaties bij elkaar opteld.

Internet Explorer heeft wereldwijd nog maar een aandeel van 0,81% (februari 2021). U zou er dus voor kunnen kiezen om de polyfill uit te schakelen, mocht uw doelgroep geen gebruik maken van Internet Explorer. Internet Explorer zal nog wel meer in gebruik zijn bij de oudere generatie, aangezien de meeste ouderen niet weten wat een webbrowser is, niet weten dat hun webbrowser is verouderd of niet weten hoe zij zelf een moderne browser als Google Chrome, Microsoft Edge of Mozilla Firefox kunnen installeren.

In principe laat u cross-browser compatibiliteit vallen voor oude webbrowsers voor een betere ervaring op moderne webbrowsers. Meegaan met de tijd is een belangrijk deel van het optimaliseren van websites en webshops, omdat er steeds efficiëntere coderingen worden ontwikkeld voor afbeeldingen, video's en lettertypes die gebruikt kunnen worden door moderne webbrowsers.

Gebruikt u toevallig WordPress? Overweeg dan om de polyfill van Babel uit te schakelen. Voordat u dit doet, is het handig om eerst te kijken of uw website of webshop deze polyfill wel heeft ingeschakeld. Als u gebruik maakt van een WordPress plug-in voor snelheid, schakelt u deze voor de controle even uit zodat de JavaScript-bestanden niet gebundeld of hernoemd kunnen worden.

Open een pagina op uw website of webshop, druk op F12 (Mac: Command + Option + I), druk vervolgens op CTRL + F en typ daarna wp-polyfill-js in en druk op Enter. Als er niks gevonden wordt, dan gebruikt uw website waarschijnlijk deze polyfill niet.

Mocht uw website deze polyfill wél gebruiken, dan kunt u de polyfill van Babel uitschakelen door de volgende code toe te voegen in het child-thema in bestand functions.php het volgende toe te voegen onderin het bestand:

function tw_remove_wp_polyfill() {
  wp_deregister_script('wp-polyfill');
}
add_action('wp_enqueue_scripts', 'tw_remove_wp_polyfill');

Indien u geen child-thema heeft, kunt u een child-thema genereren met behulp van plug-in Child Theme Generator. Wij raden u aan om een back-up aan te maken (database & bestanden) van uw WordPress website voordat u het child-thema activeert, aangezien de thema-opties bij sommige thema's niet goed opgeslagen worden of verloren kunnen gaan bij het gebruik van child-thema's.

Heeft u geen FTP-toegang tot uw WordPress website, maar staat er wel de link Thema editor onder Weergave in het WordPress-menu? Klik daar dan op, schakel vervolgens over naar uw child-thema (de selectie box boven de rechter zij-balk). Klik vervolgens op Themafuncties (functions.php) in de rechter zij-balk. Voeg nu de bovenstaande code toe en druk op de knop Bestand bijwerken.

Indien u wél FTP-toegang heeft, kunt u het bestand vinden door folder wp-content te openen, daarna folder themes te openen, daarna het mapje te openen waarbij -child achter de naam staat van de WordPress-thema die u op uw website gebruikt. Bewerk vervolgens het bestand genaamd functions.php. Voeg nu onderin het bestand de bovenstaande code toe en sla het PHP-bestand op.

Test voor de zekerheid wel of alles nog werkt! Open een aantal pagina's, druk bij elk op F12 (Mac: Command + Option + I), klik op tab Console en kijk of er JavaScript errors zijn. Zijn die er? Controleer dan of die errors er ook zijn als de polyfill ingeschakeld is.

Indien u voor deze controle een plug-in heeft uitgeschakeld die voor optimalisatie zorgde, vergeet deze dan niet weer in te schakelen. Dat zou natuurlijk niet handig zijn voor de voortgang van uw Core Web Vitals optimalisatie!

CSS-bestanden opsplitsen in apparaat-specifieke bestanden

Indien u zelf de CSS geschreven heeft voor uw website en dit een groot bestand is, dan is het misschien de moeite waard om alle CSS-bestanden te bundelen en vervolgens op te splitsen in drie CSS-bestanden:

  • een bestand waarin de media queries voor schermbreedtes uitgefilterd zijn;
  • een bestand waarin enkel de media queries voor schermbreedtes van mobiele apparaten (smartphones en tablets) zitten;
  • een bestand waarin enkel de media queries voor schermbreedtes van laptops en desktops zitten.

Let op: indien u gebruik maakt van HTML output caching tool, bekijk dan of het bij die tool mogelijk is om een aparte cache bij te houden voor mobiele apparaten, aangezien anders enkel het CSS-bestand voor laptops en desktops ingeladen wordt op mobiele apparaten vanwege de cached HTML output. Als dat niet mogelijk is, dan raad ik het u af om het CSS-bestand op te splitsen.

Houdt alstublieft wel een backup van het originele CSS-bestand paraat. U kunt met behulp van user-agent sniffing in PHP of welke backend-taal dan ook er achter komen of het apparaat dat uw website bezoekt gebruik maakt van een mobiele apparaat of een desktop-apparaat. Op die manier zou je enkel het CSS-bestand voor mobiele apparaten óf voor laptops en desktops in kunnen laden en daarbij het CSS-bestand die geen media queries heeft voor schermbreedten. U kunt vervolgens met JavaScript nog een controle doen of de uitkomst van de user-agent sniffing wel overeenkomt met het apparaat gedetecteerd m.b.v. JavaScript. U kunt namelijk met behulp van JavaScript controleren of het aanslaat op bepaalde media queries (die in een van de CSS-bestanden zitten).

Hoe meer CSS er verwerkt en toegepast moet worden, hoe meer tijd dat kost voor de webbrowser om de webpagina te laten zien. Minder CSS draagt dus bij aan de eerste statistiek van de Core Web Vitals: Largest Contentful Paint (LCP).

Belangrijke CSS preloaden in de <head>

Wanneer het belangrijkste CSS-bestand pas na andere bestanden gedownload gaat worden, kan dit er voor zorgen dat er een periode ontstaat waarin de webbrowser de pagina alvast heeft getekend vóórdat het belangrijkste CSS-bestand gedownload is en dus nog niet toegepast had kunnen worden. Dit zorgt voor een impact op de CLS-score in de zin dat het zorgt voor grote verschuivingen.

Hoge CLS-score betekent slechte visuele stabiliteit (#3 van Core Web Vitals). Simpelweg het verplaatsen van het belangrijkste CSS-bestand naar bovenin de <head> zorgt ervoor dat uw CSS-bestand overschreven kan worden door CSS-bestanden die, door het verplaatsen van het belangrijkste CSS-bestand naar bovenin de <head>, ná het belangrijkste CSS-bestand toe worden gepast.

U kunt aangeven dat het CSS-bestand alvast gedownload kan worden, maar dat de prioriteit van het bestand alsnog afhankelijk is van de positie van het <link>-element die naar het CSS-bestand verwijst. Dit minimaliseert de kans dat de webbrowsers uw website alvast tekent voordat het belangrijkste CSS-bestand toegepast kon worden vanwege te laat downloaden. Zie Figuur 7.

Belangrijke CSS preloaden voor Core Web Vitals optimalisatie

Figuur 7. Het belangrijkste CSS-bestand preloaden in de <head>

Lazy-rendering

Lazy rendering voor Core Web Vitals

Figuur 8. Laaste sectie staat buiten beeld en wordt nog niet getekend

Wanneer u een pagina opent, maakt de browser gebruik van CSS-bestanden om de pagina op te maken. Hoe groter het bestand en hoe meer elementen beïnvloed worden door het bestand, des te meer tijd het kost om de pagina te tekenen.

De browser tekent de gehele pagina, ongeacht of u die hele pagina wel in beeld krijgt of niet. Het is mogelijk om de browser alleen het gedeelte te laten tekenen dat in uw scherm zit (met een speling van 50%), zodat de browser hier minder tijd aan kwijt is en de pagina sneller geladen kan worden.

Het is hetzelfde idee als lazy-loading bij afbeeldingen, waarbij enkel de afbeeldingen die in beeld komen te laden (uiteraard ook met een speling). Zie Figuur 8 voor een visualisatie.

Lazy-rendering toepassen is gemakkelijk, maar het brengt ook een probleem met zich mee. Als een sectie namelijk nog niet door de browser is getekend, heeft die sectie géén hoogte.

Dat zorgt er voor dat de pagina minder lang lijkt als u naar de scrollbar kijkt, omdat veel secties 0 pixels hoog zijn.

Wanneer de bezoeker dan naar beneden scrolt, komen de andere secties in de buurt, worden deze getekend en nemen ze vervolgens een hoogte aan die door de browser is berekent.

Om er voor te zorgen dat dit niet gebeurd, dient een sectie een geschatte hoogte te hebben aangegeven die wordt gebruikt zolang de sectie nog niet door de browser is getekend. Deze schatting dient wel nauwkeurig te zijn. Zie Figuur 9.

Wij zijn momenteel bezig met de ontwikkeling van een thema dat wij voor onze klanten willen gebruiken in de toekomst.

Dat thema wordt op deze website gebruikt en ontwikkeld en beschikt over alle optimalisaties die wij hier met u bespreken.

Hoogte nauwkeurig schatten bij lazy-rendering

Figuur 9. Nauwkeurigheid van lazy-rendering bij het thema van Terluin Webdesign

Met ons thema willen wij garantie bieden voor voldoening aan de Core Web Vitals, zonder dat daarvoor dure optimalisaties nodig zijn.