Traag per ongeluk vs Traag door ontwerp: Een web performance framework

Traag per ongeluk vs traag door ontwerp.

Wanneer je mij inhuurt om de Core Web Vitals op te lossen of erover te praten, zul je me op een gegeven moment horen praten over traag per ongeluk vs traag door ontwerp. Ik denk dat het een cruciaal onderscheid is om te maken en in dit artikel zal ik uitleggen hoe dit je zal helpen de Core Web Vitals te verbeteren.

Laatst beoordeeld door Arjen Karel in maart 2026

Wanneer iemand mij vraagt voor advies en om de Core Web Vitals te fixen, is er altijd iets mis. Traagheid komt altijd voort uit anti-patronen. Bijvoorbeeld een 'Lazy Loaded Largest Contentful Paint afbeelding', 'Grote, niet-geoptimaliseerde afbeeldingen', 'Sliders', 'blokkerende JavaScript' enzovoort.

Er is niet veel nodig om een anti-patroon te introduceren. Soms is het installeren van een plug-in of het even vergeten van best practices al genoeg om een anti-patroon te creëren.

Ik categoriseer deze anti-patronen graag in 'traag per ongeluk' en 'traag door ontwerp', omdat de manier waarop ik deze oplos compleet tegenovergesteld is.

Slechts 48% van de mobiele origins slaagt voor alle drie de Core Web Vitals volgens de 2025 Web Almanac. In mijn ervaring komt de meerderheid van die mislukkingen voort uit 'traag per ongeluk' problemen die in enkele uren kunnen worden opgelost.

Traag per ongeluk

Ik hou van 'traag per ongeluk' anti-patronen. Je hebt iets gedaan dat de pagina vertraagde. Je hebt een fout gemaakt. Je wist niet dat er een veel snellere manier is om dit te doen. Geen zorgen, ik kan fouten oplossen.

Het categoriseren van deze 'fouten' is dus logisch. Het geeft me een lijst met eenvoudig op te lossen verbeteringen met een hoge impact die ik naar je devteam kan sturen (of zelf kan oplossen). Er is meestal heel weinig discussie nodig. Het verbeteren van deze anti-patronen is simpelweg vanuit elk oogpunt logisch. Zodra ze zijn opgelost, zullen de Core Web Vitals verbeteren.

Hier zijn een paar voorbeelden van anti-patronen die ik dagelijks tegenkom. Wanneer ik uitleg wat en waarom, krijg ik meestal te horen: 'ohh, ik wist niet dat dit de pagina zou vertragen'.

1. Niet-lazy afbeeldingen

Het meest voorkomende anti-patroon is niet-lazy afbeeldingen. Afbeeldingen die niet lazy geladen worden, worden in de wachtrij geplaatst om te downloaden tijdens de vroege fasen van het laden van de pagina. Dit verbruikt netwerk- en CPU-bronnen. Het is niet logisch om kostbare bronnen toe te wijzen aan afbeeldingen die niet eens zichtbaar zijn, toch? Leer meer over het uitstellen van offscreen afbeeldingen.

De tegenovergestelde fout is net zo gebruikelijk: het lazy laden van de LCP afbeelding. Ongeveer 15% van de sites doet dit, en het zorgt ervoor dat de belangrijkste afbeelding op de pagina langzamer laadt in plaats van sneller.

2. Lettertypen van derden

Web-fonts zijn geweldig. Ze personaliseren en verbeteren de look and feel van de pagina. Helaas zal het gebruik van een externe provider zoals Google Fonts de lettertypen niet optimaliseren voor jouw specifieke situatie.

Lettertypen van derden vereisen een extra render-blokkerende stylesheet, een nieuwe verbinding met een webserver (terwijl je al deze razendsnelle verbinding met je eigen server hebt) en zullen waarschijnlijk meer lettertypen aan de browser toevoegen dan je daadwerkelijk gebruikt.

Het zou logischer zijn om je lettertypen zelf te hosten, ze te preloaden en een aangepaste font loading strategie toe te wijzen aan elk lettertypebestand. Dat is meteen nog een quick win!

3. Scripts van derden

Hoewel er niets mis is met scripts van derden, veroorzaken ze veel problemen door de manier waarop ze aan pagina's worden toegevoegd. Ik kom onbelangrijke scripts van derden tegen (zoals de Facebook tracking pixels, social media knoppen, beoordelingswidgets enz.) die daadwerkelijk de hele pagina blokkeren.

Het is relatief eenvoudig en volkomen logisch om deze scripts uit te stellen en in te plannen totdat de browser het belangrijkere werk heeft gedaan. Uiteindelijk heb ik niets kritieks aan de site veranderd, deze ziet er nog steeds hetzelfde uit en laadt een stuk sneller. Ik heb alleen de volgorde veranderd waarin dingen worden uitgevoerd.

4. Achtergrondafbeeldingen

Vanuit een Core Web Vitals perspectief zijn achtergrondafbeeldingen onlogisch. Achtergrondafbeeldingen hebben geen native ondersteuning voor lazy loading, ze zijn niet responsive en je hebt weinig controle over hun timing en prioriteit.

Met een paar eenvoudige aanpassingen kunnen we deze achtergrondafbeeldingen transformeren in normale afbeeldingen die we lazy kunnen laden, responsive kunnen maken en waarvan we de prioriteit kunnen aanpassen. Dat zal de Largest Contentful Paint ongetwijfeld verbeteren.

5. Grote stylesheets

Stylesheets zijn render-blokkerend. Dat betekent dat terwijl de browser de stylesheets laadt, de pagina leeg blijft. Er zijn veel dingen die je kunt doen om dit op te lossen. Bijvoorbeeld ongebruikte stijlen verwijderen, de stylesheet opsplitsen, browser caching verbeteren of Critical CSS toevoegen.

Zodra we de stylesheets hebben verbeterd, zullen je Largest Contentful Paint en First Contentful Paint drastisch verbeteren!

Traag door ontwerp

Traag door ontwerp is het gedeelte waar je je zorgen over zou moeten maken. Je hebt structurele keuzes gemaakt die de pagina vertragen. Dit betreft meestal UX-ontwerpkeuzes of JavaScript code die het zichtbare deel van de pagina in zo'n mate aanpast dat er geen goede workarounds zijn.

Het probleem met 'traag door ontwerp' is dat het niet direct op te lossen is door kleine aanpassingen te maken. Het vereist meer planning en het herschrijven van enkele kernfuncties van de site.

Het eerste dat ik moet doen is de intentie achterhalen: Waarom heb je dit gedaan? Wat waren de overwegingen en wat wilde je precies bereiken? Om vervolgens binnen die parameters een beter alternatief te vinden!

Hier zijn enkele voorbeelden van de meest voorkomende 'traag door ontwerp' fouten.

1. Sliders

Sliders werken meestal zo: Wanneer de pagina rendert, zal een JavaScript de slider in de pagina injecteren. Zonder dit JavaScript zal de pagina er compleet anders uitzien. Dit veroorzaakt een langere Largest Contentful Paint, waarschijnlijk een Layout Shift en hoogstwaarschijnlijk problemen met de Interaction to Next Paint (INP).

Er is geen snelle oplossing. Het uitstellen van JavaScript zal de paint metrics verbeteren, maar zal de slider vertragen en een Layout Shift veroorzaken. Het slider-script kritiek maken zal de Layout Shift oplossen, maar zal de paint metrics vertragen.

De oplossing is om de pagina progressief te verbeteren. Zorg er eerst voor dat de slider rendert zonder JavaScript en verbeter daarna de pagina en transformeer de reeds aanwezige slider-afbeelding naar een volledige slider.

Het grappige is: slechts ongeveer 1% van de bezoekers klikt daadwerkelijk op een slider. In 9 van de 10 gevallen wanneer ik dit uitleg, stelt de eigenaar van de site meteen voor om de slider te verwijderen. Daarom is het belangrijk om te vragen naar de intenties en overwegingen van deze sliders. Meestal 'waren ze er gewoon'.

2. Product zoom

Product zoom werkt als volgt: zweef in een gemiddelde webshop over een productafbeelding en je kunt inzoomen op een deel van het product. 'Product zooms' hebben meestal hetzelfde probleem als sliders. Een stuk JavaScript code pakt je afbeeldingen, verbergt ze, en herschrijft ze vervolgens naar de pagina als zoombare afbeeldingen. Dit veroorzaakt een langere Largest Contentful Paint, waarschijnlijk een Layout Shift en hoogstwaarschijnlijk problemen met de Interaction to Next Paint (INP).

Het verschil met de slider is dat geen enkele product owner ooit zal zeggen: "oh, verwijder deze functionaliteit maar". Het is belangrijk en verhoogt de conversie.

De oplossing is hetzelfde als de fix voor de slider. Het zoom script zou de originele afbeeldingen niet moeten verbergen, maar de functionaliteit van de productafbeelding moeten uitbreiden. Helaas is de zoom functionaliteit meestal niet eenvoudig op te lossen en vereist het wat werk om het precies goed te krijgen.

3. Inline jQuery / inline JavaScript dependencies

Inline jQuery is een probleem dat begon als een 'traag per ongeluk', maar na verloop van tijd erger werd. Ongeveer 50% van de sites die ik bekijk kampt met dit probleem. Volgens W3Techs draait jQuery nog steeds op ongeveer 70% van alle websites, dus dit zal niet snel verdwijnen. Omdat inline scripts afhankelijk zijn van een eerder script (meestal jQuery), kun je jQuery niet meer uitstellen (defer). Dit zal alle paint metrics vertragen.

De oplossing is simpel: Verplaats deze scripts gewoon naar een extern script. Nu kun je zowel jQuery als het aangepaste script uitstellen.

Waarom heb ik dit dan in de categorie 'traag door ontwerp' geplaatst? Wanneer ik vraag naar intentie en overweging, krijg ik meestal te horen: 'oh, dat weet ik niet'. En dat is het echte probleem. Er is een gebrek aan kennis over hoe JavaScript werkt. Ik kan er vrij zeker van zijn dat deze fout in de toekomst zal worden herhaald. Dit betekent dat de oplossing niet hetzelfde is als de technische fix. Ik zal het devteam moeten onderwijzen over JavaScript afhankelijkheden en timing.

4. Grote (hero) afbeeldingen

Een ander 'traag door ontwerp' probleem is grote afbeeldingen. Sommige sites moeten gewoon 'indruk maken op het publiek' met veel afbeeldingen op volledige grootte. Stel je voor dat je posters verkoopt. Dan wil je waarschijnlijk grote afbeeldingen van hoge kwaliteit aan je bezoekers tonen. Deze afbeeldingen, ongeacht hoeveel je ze optimaliseert, zullen altijd meer tijd nodig hebben om te downloaden dan kleinere afbeeldingen.

Op dit punt (ervan uitgaande dat de afbeeldingen allemaal zijn geoptimaliseerd) is het enige dat ik kan doen kijken of er wat speelruimte is. Hebben we echt 4K-afbeeldingen nodig of volstaat Full-HD ook? Bekijk hoe je trage hero afbeeldingen oplost voor praktische technieken.

5. Interactieve kaarten

Een ander probleem dat ik vaak tegenkom, zijn interactieve kaarten. Wanneer een pagina een interactieve kaart heeft, is de volledige intentie van deze pagina om de bezoeker te laten interacteren met de kaart. Uiteraard zal het wat tijd kosten om die kaart te laden.

Hier kunnen we niet omheen. We zullen wat traagheid moeten accepteren. Maar er zijn wel dingen die we kunnen doen. We kunnen ervoor zorgen dat de kaarten geladen worden met de hoogste prioriteit. Meestal zijn deze pagina's niet geoptimaliseerd voor vroege JavaScript executie. In dit geval was dat de verkeerde keuze. We hebben het script nodig om zo vroeg mogelijk te downloaden en uit te voeren! Ik heb een complete gids geschreven over hoe je Google Maps kunt insluiten zonder verlies van PageSpeed.

6. Trage API's

Traag door ontwerp problemen die voortkomen uit trage API's zijn meestal te vinden in SPA-sites zoals React, Next.js of Angular. Trage API's veroorzaken doorgaans grote Layout Shifts omdat componenten te laat renderen na gebruikersinteractie. Dit soort problemen vereisen meestal een multi-team aanpak.

Het kan nuttig zijn om onderscheid te maken tussen traag per ongeluk en traag door ontwerp als het gaat om de Core Web Vitals. Traag per ongeluk is meestal eenvoudig opgelost, terwijl traag door ontwerp een veel grondigere multi-dimensionale aanpak vereist. Zodra je de 'traag per ongeluk' problemen hebt gecategoriseerd en opgelost, kun je Real User Monitoring instellen om de impact bij te houden. Field data vertelt je of jouw oplossingen daadwerkelijk de user experience voor echte bezoekers hebben verbeterd. De 'traag door ontwerp' problemen zullen dan duidelijk opvallen in je data, omdat dat is wat er nog over is.