Een te grote DOM maakt productfilters traag

De browser bouwt van je HTML een boomstructuur, de DOM. De uitleg over webperformance van MDN stelt dat er geen vaste regels zijn voor wat traag is, maar noemt wel richtlijnen, waaronder 50 tot 200 milliseconden voor reactie op invoer. Bekijk die als oriëntatie, niet als drempel. Bij een filter verandert vaak een groot deel van de lijst: elementen worden verwijderd, toegevoegd of herberekend.

Hoe zwaar dat is, hangt af van meer dan het aantal elementen. Ook de diepte van de structuur, de stijlregels, het script dat na een klik loopt en het toestel spelen mee. Een grote DOM is dus een verdachte, geen bewezen schuldige. Je zoekt een bewijs door één variabele te veranderen en dezelfde interactie opnieuw te meten.

Begin met een meetbasis op een representatief toestel. Een snelle ontwikkelaarslaptop verbergt problemen die bezoekers met een middenklassetelefoon wel voelen.

1. Open de categoriepagina met alle producten en tel de elementen in de pagina. In de console van de ontwikkelaarstools kan dat met een korte opdracht die alle elementen van het document telt.
2. Noteer ook het aantal producten in beeld en het aantal elementen per productkaart.
3. Voer één vaste interactie uit, bijvoorbeeld een filter aanzetten dat de lijst halveert.
4. Neem de interactie op met het prestatiepaneel van je browser en noteer de duur tussen klik en volgende zichtbare update.
5. Herhaal drie keer en bewaar de afzonderlijke waarden, niet alleen het gemiddelde.

Let op welk deel van de opname de tijd verbruikt: scriptuitvoering, stijlberekening of layout. Dat bepaalt of ingrijpen op de DOM-grootte zinvol is.

Maak een testversie waarin dezelfde pagina slechts een deel van de producten toont. Dit kan met een testparameter, een stagingomgeving of een tijdelijke aanpassing in de ontwikkelaarstools. Pas geen live pagina aan zonder dat iemand de gevolgen kan terugdraaien.

1. Bepaal een vaste beperkte lijst, bijvoorbeeld de eerste groep producten die zonder scrollen en een stuk daaronder zichtbaar is.
2. Laat filterlogica, stijl en scripts ongewijzigd, zodat enkel het aantal gemonteerde elementen verschilt.
3. Voer dezelfde interactie uit op hetzelfde toestel met dezelfde netwerkinstelling.
4. Vergelijk de opnames uit de diagnose met die van de beperkte lijst.
5. Test ook de gevoelsmatige ervaring: reageert de knop meteen, springt de lijst, verdwijnt de focus?

De cursus Performance van web.dev behandelt onder meer het kritieke pad, het laden van resources en het opsplitsen van JavaScript. Gebruik die als achtergrond wanneer de proef een ander knelpunt toont dan DOM-grootte.

Kies steeds één wijziging per ronde. Doe je drie dingen tegelijk, dan weet je achteraf niet wat gewerkt heeft.

Dit voorbeeld is verzonnen en bevat alleen invoer en verwachte controles. Een categoriepagina toont 48 productkaarten. Veronderstel dat elke kaart 40 elementen heeft, dan zijn dat 1920 elementen voor de lijst, plus de rest van de pagina. Een beperkte testversie toont 12 kaarten, goed voor 480 elementen in de lijst.

Verwachte controles: tel de elementen in beide versies, voer dezelfde filterklik uit en vergelijk de opnames. Is het verschil klein, dan zoek je verder bij scripts. Is het groot, dan kies je een aanpak met minder gemonteerde producten. Hoeveel winst dat in jouw winkel oplevert, weet je pas na meting.

Controleer na de wijziging drie dingen. Meet dezelfde interactie opnieuw op hetzelfde toestel. Test met toetsenbord en schermlezer of filters, paginering of een knop om meer te laden bruikbaar blijven. De toegankelijkheidstutorials van W3C geven praktijkrichtlijnen voor veelvoorkomende onderdelen. Bekijk tot slot of alle producten nog bereikbaar zijn via gewone links. Wil je weten welke signalen je site publiek toont? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en vervangt je eigen metingen niet.