Afbeeldingen en lettertypen sneller laden: wat echt telt voor je website

Een website laadt sneller als je op elke afbeelding width en height zet, kleinere bestanden aanbiedt met srcset en moderne formaten als WebP of AVIF, alleen afbeeldingen buiten beeld uitgesteld laadt en bewust kiest hoe lettertypen worden getoond. Dat zijn geen trucjes maar bouwregels uit de documentatie van Google (web.dev) en MDN. Ze raken twee meetwaarden die Google Core Web Vitals noemt: hoe snel het grootste element zichtbaar is, en hoeveel de pagina tijdens het laden verspringt. Hieronder zie je per onderdeel wat de bronnen zeggen en wat je zelf kunt doen.

Welke meetwaarden raken afbeeldingen en lettertypen?

Afbeeldingen en lettertypen raken twee meetwaarden. LCP meet de rendertijd van het grootste element in beeld, en per 11 oktober 2026 noemt Google een LCP van 2,5 seconden of minder goed. CLS meet hoeveel de pagina verspringt, en 0,1 of lager is goed. Web.dev noemt afbeeldingen of video's zonder afmetingen en fonts die anders renderen dan het terugvallettertype als typische oorzaken, dus precies de onderwerpen van dit artikel. Wat de drempels betekenen en hoe Google ze beoordeelt, staat in de uitleg over Core Web Vitals. Voor beide meetwaarden geven de bronnen concrete maatregelen, die je in je templates kunt vastleggen.

Hoe zorg je dat afbeeldingen de juiste grootte hebben?

Begin met de grootte van het bestand. Een telefoon heeft geen afbeelding nodig die gemaakt is voor een groot beeldscherm, maar zonder aanpassing krijgt hij die toch binnen. Web.dev beschrijft de oplossing in de leerstof over responsive images: voeg meerdere versies van dezelfde afbeelding toe in verschillende formaten en gebruik het srcset-attribuut om de browser te vertellen dat die formaten bestaan en wanneer ze te gebruiken zijn. Kleine schermen laden dan geen onnodig grote bestanden. Dat scheelt data, en dat is prettig voor bezoekers op een mobiele verbinding.

In de praktijk hoef je dit niet voor elke afbeelding met de hand te doen. Een CMS of een framework kan de varianten genereren bij het uploaden of bij de eerste aanvraag en de srcset-regel zelf in de pagina zetten. Vraag bij een offerte of dat het geval is, en controleer het daarna in de broncode van een pagina. Zie je op elke afbeelding één bestand van volledige breedte, dan wordt het voordeel niet benut. Bij een WordPress-site in onderhoud kun je dit samen met de thema-instellingen nalopen.

Welk formaat en welke laadstrategie kies je?

Dan het bestandsformaat. Web.dev schrijft dat WebP en AVIF doorgaans betere compressie bieden dan oudere formaten en waar mogelijk gebruikt moeten worden. Je kunt ze met JPEG of PNG als terugval aanbieden voor browsers die het nieuwe formaat niet ondersteunen. Ter uitleg: betere compressie betekent een kleiner bestand. Hoeveel kleiner, hangt af van de afbeelding en van de instellingen, en een vast percentage beloven we daarom niet. Test een paar eigen foto's: exporteer ze in beide formaten en vergelijk de bestandsgrootte en de kwaliteit zelf.

Het attribuut loading helpt bij afbeeldingen die niet direct in beeld hoeven te zijn. Volgens web.dev kun je daarmee het laden van afbeeldingen buiten beeld volledig uitstellen. Een lange productpagina met foto's onderaan hoeft die foto's niet te laden voordat iemand scrolt. Maar er is een belangrijke waarschuwing van dezelfde bron: lazy-load geen afbeeldingen die waarschijnlijk bij het laden al in beeld zijn, zeker geen LCP-afbeelding. Wie de grote afbeelding bovenaan uitstelt, loopt het risico dat juist het belangrijkste beeld later verschijnt. Gebruik lazy loading dus voor alles onder de vouw en niet voor de hero.

Hoe voorkom je dat de pagina verspringt?

Nu het verspringen. MDN legt uit dat width en height op een img-element de browser in staat stellen de beeldverhouding te berekenen voordat de afbeelding geladen is, zodat ruimte gereserveerd wordt. Web.dev beveelt aan om altijd width- en height-attributen op afbeeldingen en video's te zetten, of ruimte te reserveren met de CSS-eigenschap aspect-ratio. Zonder die waarden weet de browser niet hoe hoog het vak wordt, en duwt de afbeelding de tekst eronder omlaag zodra ze binnenkomt. Dat is precies het verspringen dat CLS meet en dat bezoekers storend vinden.

Vergeet de inhoud rond de afbeeldingen niet. Een template met vaste afmetingen helpt niet als een redacteur later een foto in een andere verhouding uploadt of een video insluit zonder afmetingen. Zorg dat de invoegvelden in je CMS altijd breedte en hoogte meenemen en dat embeds in een vak met een vaste verhouding staan. Dit is ook een afspraak voor het onderhoud: nieuwe pagina's moeten dezelfde regels volgen als de oorspronkelijke, anders sluipt het probleem er langzaam weer in zonder dat iemand het merkt.

Wat doe je met lettertypen en font-display?

Lettertypen vragen om een andere afweging. Web.dev schrijft dat font-display bepaalt hoe de browser tekst rendert zolang het webfont nog niet geladen is, en dat het LCP, FCP en layoutstabiliteit kan beïnvloeden. Er zijn vijf mogelijke waarden. Welke waarde bij jouw site past, hangt af van het lettertype, het terugvallettertype en de ontwerpkeuzes, en dat is iets om te testen en niet blind over te nemen. De bron noemt geen vaste winnaar, dus doen wij dat hier ook niet. Stel de waarde wel bewust in, in plaats van de standaard te laten staan.

Zoals gezegd noemt web.dev fonts die anders renderen dan het terugvallettertype als oorzaak van layoutverschuiving. Wanneer het webfont binnenkomt, kan de tekst een andere breedte hebben dan het tijdelijke lettertype, waardoor regels anders afbreken en de pagina beweegt. Ons advies: kies een terugvallettertype dat qua afmetingen dicht bij je webfont zit, zodat er minder verschuift. Houd daarnaast het aantal lettertypen en gewichten klein: elk extra bestand moet worden opgehaald. Dit zijn ontwerpadviezen en geen cijfers uit een bron, maar ze volgen uit de logica van het ophalen.

Hoe test je of het werkt en wat levert het op?

Hoe weet je of het werkt? Web.dev schrijft dat Core Web Vitals door alle site-eigenaren gemeten horen te worden. Voor INP noemt web.dev als meetpunt het 75e percentiel van paginaladingen die in het veld zijn gemeten, dus bij echte bezoekers. Ons advies: vertrouw niet alleen op een eenmalige test op je eigen laptop. Gebruik testtools om oorzaken te vinden, en kijk daarna naar de veldgegevens om te zien of de verbetering bij echte bezoekers aankomt. Houd er rekening mee dat Google zegt dat de metrics die Core Web Vitals vormen kunnen veranderen, dus de getallen in dit artikel zijn een stand van zaken per 11 oktober 2026.

Wat levert dit op voor je positie in Google? Per 11 oktober 2026 raadt Google Search Central site-eigenaren sterk aan goede Core Web Vitals te halen, voor succes in Google Zoek en voor een goede gebruikerservaring. Een garantie voor een positie geeft Google daarbij niet. Google zegt ook dat je niet op een of twee aspecten van pagina-ervaring moet focussen, maar op de algehele ervaring. Snellere afbeeldingen zijn daarom vooral goed voor je bezoeker. Dat een bezoeker minder lang wacht en minder verspringende tekst ziet, is op zichzelf al reden genoeg om het te doen.

Een praktische volgorde voor je eigen site. Controleer eerst de hero-afbeelding: geen lazy loading, wel width en height. Zet daarna op alle andere afbeeldingen width en height, en laat ze lazy laden zodra ze onder de vouw staan. Zorg dat er varianten in meerdere formaten bestaan en bied WebP of AVIF aan met een terugval. Stel font-display bewust in en test de pagina op een trage verbinding. Wil je dit niet zelf uitzoeken, dan kijkt Digitaalnu mee bij hosting en het onderhoud van je site.

Meer lezen? In Website laten maken: wat zijn de kosten in 2026 staat waar je bij een nieuwe site op let, en het artikel over HTTPS en mobile-first indexeren behandelt de mobiele kant van hetzelfde verhaal. Bouw je een webshop, dan zijn productafbeeldingen een zwaar onderdeel van een pagina, en loont het om de regels uit dit artikel vanaf het begin in het ontwerp vast te leggen.

Laatst bijgewerkt op 11 oktober 2026