Er is een situatie die iedereen herkent die weleens in een pagina heeft gekeken. Je bekijkt de broncode en zoekt naar een tekst die duidelijk op het scherm staat. Hij staat er niet. Je zoekt nog een keer, en nog een keer. De tekst is er wel, alleen niet daar.
Dat is het verschil tussen de broncode en de DOM. En dat verschil verklaart een hoop.
Bij REHBO liep ik hier tegenaan. Ik verzorgde het webdesign, de vindbaarheid en de integratie van een nieuwsfeed. Die feed haalde berichten op bij een externe bron. Daarna zette hij ze op de pagina.
Prachtig voor de bezoeker, maar zoekmachines pikten die berichten niet altijd op. Ik heb de opbouw zo aangepast dat de kern al in de pagina zit. De feed vult daarna alleen aan. Nu ziet iedereen hetzelfde, ook de zoekmachine.
De DOM is de levende versie van je pagina, niet de broncode.
Wat is de DOM?
DOM staat voor Document Object Model. Het is de boomstructuur die je browser van je pagina maakt. Elk element wordt een knooppunt, met takken eronder.
Je hebt een body, daarin een header, daarin een menu, daarin links. Zo krijgt elk onderdeel een plek in een hierarchie.
Waarom die boom nodig is
Omdat je er dan bij kunt. Zonder structuur is je pagina een lap tekst. Met structuur kan JavaScript zeggen: pak het derde menu-item en verberg het.
Ook CSS gebruikt die boom. Een regel over links in je footer werkt alleen omdat de browser weet wat waar zit.
Het verschil met HTML
Dit is het punt waar het bij de meeste mensen misgaat. HTML is wat de server verstuurt. De DOM is wat de browser ervan maakt en daarna bijhoudt.
Die twee zijn bij het laden gelijk. Daarna kan de DOM veranderen zonder dat de HTML meebeweegt. Klap je een menu open, dan verandert de DOM. De broncode blijft precies hetzelfde.
Hoe je het bekijkt
Gebruik de ontwikkelaarstools van je browser. Rechtermuisknop en dan inspecteren. Wat je daar ziet is de DOM, dus de actuele situatie.
Kies je paginabron bekijken, dan zie je de HTML zoals hij binnenkwam. Twee vensters, twee waarheden. Voor foutzoeken heb je bijna altijd de eerste nodig.
Waar het misgaat
Te veel elementen aanpassen
Elke wijziging kost rekenwerk. De browser moet opnieuw bepalen hoe alles eruitziet en waar het staat. Doe je dat honderd keer achter elkaar, dan hapert je pagina.
Ik zie dit vooral bij sliders en filters die bij elke muisbeweging iets aanpassen. Dat kost je merkbaar pagespeed.
Inhoud die pas later verschijnt
dynamische inhoud is prima, mits de kern al in de pagina zit. Bouw je een hele productlijst pas na het laden op? Dan neem je een risico met je vindbaarheid.
Hulpsoftware die achterloopt
Verandert er iets in de DOM, dan moet een screenreader dat te horen krijgen. Anders verschijnt er een melding die niemand opmerkt. Daar is ARIA voor bedoeld.
Waar ik op let bij een oplevering
Staat de belangrijkste inhoud al in de verzonden pagina?
Blijft de site bruikbaar als een script niet laadt?
Worden dynamische meldingen aangekondigd voor hulpsoftware?
Is de paginaopbouw logisch als je de opmaak wegdenkt?
In de praktijk
In WordPress komt het meeste gedrag uit plugins. Een slecht gebouwde slider bouwt bij elk bezoek tientallen elementen op. Dat is precies waarom ik het aantal uitbreidingen laag houd.
Ik controleer dit tijdens onderhoud met de ontwikkelaarstools erbij. Verspringt de pagina zichtbaar na het laden? Dan is er te veel achteraf gebeurd.
Wat je zelf kunt controleren
Zet je scripts een keer uit in je browser en herlaad de pagina. Blijft je tekst leesbaar en je menu bruikbaar? Dan staat de kern goed in de verzonden pagina.
Valt de halve site weg, dan leunt hij te zwaar op wat er achteraf gebeurt. Dat is een risico voor je vindbaarheid en voor bezoekers met een trage verbinding.
Meer vragen over DOM
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat is de DOM?
Wat is het verschil tussen HTML en de DOM?
Waarom zie ik in de broncode iets anders dan op mijn scherm?
Hoe bekijk je de DOM van een pagina?
Waarom vertraagt te veel DOM-manipulatie je website?
Ziet Google inhoud die met JavaScript wordt toegevoegd?
Wat is de DOM?
HTML is wat de server verstuurt. De DOM is wat de browser ervan maakt en daarna bijhoudt. Dat verschil verklaart veel verwarring.
Bij het laden zijn die twee gelijk. Daarna kan de DOM veranderen zonder dat de HTML meebeweegt. Klap je een menu open, dan verandert de DOM. De broncode blijft precies hetzelfde.
Daarom kun je in de broncode zoeken naar een tekst die duidelijk op je scherm staat, en hem niet vinden. Hij is er wel, alleen niet daar.
Voor foutzoeken is dit essentieel om te weten. Kijk je in de verkeerde weergave, dan zoek je naar iets dat er nooit zal staan.
Het raakt ook je vindbaarheid. Een zoekmachine leest eerst de verstuurde HTML. Wat pas later wordt toegevoegd, wordt niet altijd meegenomen.
Doe die test eens bij je eigen site. Zoek in de broncode naar een tekst die duidelijk op je scherm staat. Vind je hem niet, dan weet je dat er iets achteraf wordt toegevoegd.
Wat is het verschil tussen HTML en de DOM?
DOM staat voor Document Object Model. Het is de boomstructuur die je browser van je pagina maakt. Elk element wordt een knooppunt, met takken eronder.
Je hebt een body, daarin een header, daarin een menu, daarin links. Zo krijgt elk onderdeel een vaste plek in een hierarchie.
Die structuur is nodig omdat je er dan bij kunt. Zonder structuur is je pagina een lap tekst zonder houvast. Met structuur kan een script zeggen: pak het derde menu-item en verberg het.
Ook je opmaak gebruikt die boom. Een regel over links in je footer werkt alleen omdat de browser weet wat waar zit.
De DOM is dus geen bestand dat ergens staat. Het is een levend model in het geheugen van je browser, dat verandert zodra er iets gebeurt op de pagina. Meer over de basis lees je bij HTML.
Je hoeft hier geen programmeur voor te zijn. Het helpt al enorm als je weet dat de pagina op je scherm iets anders is dan de code die verstuurd werd. Dat verklaart de meeste verwarring.
Hoe bekijk je de DOM van een pagina?
Met de ontwikkelaarstools van je browser, en die heb je al. Je hoeft niets te installeren.
Klik met de rechtermuisknop ergens op de pagina en kies inspecteren. Er opent een venster met de structuur van je pagina. Wat je daar ziet is de DOM, dus de actuele situatie.
Kies je in plaats daarvan paginabron bekijken, dan zie je de HTML zoals hij binnenkwam. Twee vensters, twee waarheden.
De eerste gebruik je bij het zoeken naar een fout in je opmaak. Je klikt op een element en ziet welke regels erop worden toegepast en welke winnen.
De tweede gebruik je als je wilt weten wat een zoekmachine binnenkrijgt. Staat je belangrijkste tekst daar niet in, dan is dat een aandachtspunt. Meer over die verschillen tussen browsers lees je bij browser.
Wees niet bang om te klikken in die tools. Je verandert er niets mee op de echte site. Alles wat je aanpast is weg zodra je de pagina ververst.
Waarom vertraagt te veel DOM-manipulatie je website?
Omdat elke wijziging rekenwerk kost. De browser moet opnieuw bepalen hoe alles eruitziet en waar het komt te staan.
Bij een enkele wijziging merk je daar niets van. Doe je het honderd keer achter elkaar, dan hapert je pagina zichtbaar. Op een oudere telefoon merk je dat het eerst.
Ik zie dit vooral bij sliders en filters die bij elke muisbeweging iets aanpassen. Ook meldingen en pop-ups die zichzelf opnieuw opbouwen zijn een bekende oorzaak.
Een tweede effect is verspringen. De pagina laadt, en daarna schuift alles nog een keer omdat er iets wordt toegevoegd. Dat is irritant en het telt mee in je beoordeling.
Daarom houd ik het aantal uitbreidingen bewust laag. Elke plugin voegt scripts toe die iets met de pagina willen doen. Meer daarover lees je bij pagespeed.
Let vooral op oudere telefoons in je statistieken. Wat op jouw laptop soepel loopt, kan daar merkbaar haperen. Die groep haakt af zonder dat je ooit een melding krijgt.
Ziet Google inhoud die met JavaScript wordt toegevoegd?
Tegenwoordig meestal wel, maar niet altijd en niet meteen. Daar zit het risico.
Google haalt eerst de verstuurde HTML op. Daarna zet hij de pagina in een wachtrij om ook de scripts uit te voeren. Die tweede ronde kan even duren en gaat niet altijd goed.
Andere zoekmachines en veel AI-assistenten doen die tweede ronde helemaal niet. Die zien alleen wat er direct wordt verstuurd.
Mijn regel is daarom simpel. De kern van je inhoud staat in de verzonden pagina. Scripts mogen aanvullen, verrijken en verfraaien, maar niet dragen.
Bij een nieuwsfeed betekent dat: de berichten staan er al, de filters worden erna toegevoegd. Test het door je scripts uit te zetten in je browser. Blijft je pagina begrijpelijk, dan zit het goed.
Test dit opnieuw na elke grote wijziging aan je site. Een nieuwe plugin kan zomaar inhoud gaan verplaatsen naar de tweede ronde. Dat merk je pas weken later in je posities.
Verspringt jouw pagina na het laden, of mist Google inhoud die wel op je scherm staat? Stuur me de link via het formulier hieronder. Ik kijk wat er direct wordt verstuurd en wat er pas daarna bij komt. Dan weet je of het een probleem is of alleen onhandig oogt. Vermeld je plaats, dan weet ik meteen waar je zit.
Waar kan ik je mee helpen?
Ook bekend als: Document Object Model, documentboom, paginastructuur
