Trackingtags vertragen de eerste interactie

MDN beschrijft in het overzicht over webprestaties (https://developer.mozilla.org/en-US/docs/Web/Performance) prestaties als zowel objectieve meting als ervaren snelheid, inclusief hoe snel een site interactief en responsief wordt. De bron noemt richtwaarden zoals 50 ms voor inactiviteit en 50 tot 200 ms voor het reageren op gebruikersinvoer, en benadrukt dat er geen harde regels bestaan voor wat traag is.

Voor deze proef gebruik je 50 ms als eigen werkdrempel voor een lange taak, afgeleid van die richtwaarde. Het is een afspraak voor je onderzoek, geen vastgestelde norm. Definieer ook wat jouw eerste interactie is: bijvoorbeeld een tik op het menu of een klik op de knop voor een aanvraag. Meet dat moment, niet alleen het laden van de pagina.

Een tag kan zich anders gedragen naargelang de keuze in je toestemmingsbanner. Test daarom elke toestand afzonderlijk. Wat er wettelijk in elke toestand mag gebeuren, valt buiten dit artikel. Je legt alleen vast wat technisch gebeurt.

Leg ook vast hoe de banner zelf laadt, want ook die kan een taak zijn die de eerste interactie raakt.

1. Kies één paginatype met veel verkeer en één met veel conversies.
2. Gebruik één apparaat en één browserprofiel zonder extensies, en noteer de verbinding die je instelt of gebruikt.
3. Begin elke run met een leeg browserprofiel of gewiste opslag, zodat de toestemmingstoestand echt overeenkomt met je tabelrij.
4. Neem de pagina op met het prestatiepaneel van de ontwikkeltools van je browser. De exacte naam en indeling verschilt per browser en versie, dus controleer dat in jouw browser.
5. Doe op het afgesproken moment je eerste interactie en noteer of de reactie zichtbaar vertraagd is. Gebruik een testomgeving of een interactie die geen echte aanvraag verstuurt, vul geen persoonsgegevens in en filter testverkeer uit je rapportages, want een geregistreerde klik of conversie-event bewijst geen echte aanvraag.
6. Zoek in de opname taken boven je werkdrempel en noteer van welk script ze komen.
7. Bekijk daarnaast de resourcetimings per domein, waarmee je volgens MDN timings van alle opgevraagde bestanden ziet, en zet de tag-bestanden in je tabel.
8. Herhaal elke toestand meerdere keren en vergelijk de spreiding, niet één enkele run.

De cursus Learn Performance van web.dev (https://web.dev/learn/performance) behandelt onder meer het kritieke renderpad, renderblokkerende en parserblokkerende bronnen en het opsplitsen van JavaScript omdat sommige scripts niet nodig zijn voor de eerste lading. Gebruik die begrippen om je bevindingen te ordenen.

• Tagbestand laadt vroeg en blokkeert rendering of parser: onderzoek de manier waarop het script is ingeladen en het moment waarop het start.
• Bestand laadt traag maar blokkeert niets: het probleem zit mogelijk bij de netwerktijd, niet bij je eerste interactie.
• Lange taak na het laden, vlak vóór of tijdens je interactie: het script bezet de hoofdthread. Kijk wat de tag op dat moment uitvoert.
• Lange taak enkel na toestemming: de toestemmingstoestand heeft invloed. Test het moment van activeren apart.

Een tag die in de opname naast een lange taak staat, is nog niet bewezen oorzaak. Verwijder of verplaats hem in een testomgeving en herhaal de run om te zien of het verschil blijft.

Spreek vooraf af wie een tag mag aanpassen. Een tag heeft vaak een zakelijke reden, dus beslis samen met de eigenaar van de campagne of de rapportage.

1. Heeft de tag geen eigenaar en geen gebruikt rapport, dan is verwijderen een optie.
2. Is de tag nodig maar start ze vroeger dan nodig, dan test je een latere trigger.
3. Vraagt een tag zwaar werk bij de eerste lading, dan onderzoek je of ze later of via een lichtere weg kan starten.
4. Blijft ze zwaar en nodig, dan leg je de kost vast en bewaak je ze in latere runs.

Fictief scenario. Invoer: een offertepagina met een weergave van de toestemmingsbanner en drie tags, kortweg tag A, B en C. Je test de vier toestanden met telkens vijf runs op dezelfde mobiele verbinding. Verwachte technische controles: per run de tijd van de eerste klik op de aanvraagknop, de taken boven 50 ms met hun script, en de activatiemomenten van A, B en C na de toestemmingsklik. Er is hier geen uitkomst verzonnen. Je vult de tabel met je eigen waarnemingen.

Herhaal na een tagwijziging dezelfde runs in dezelfde toestanden en vergelijk met je eerdere tabel. Controleer daarnaast of de tag nog doet waarvoor ze bedoeld was, via de foutopsporing of testmodus van het betrokken platform, en of de toestemmingskeuze nog steeds het gewenste gedrag bepaalt. Een snellere pagina met een stuk meting dat niet meer werkt, is geen winst.

Controleer tot slot of de interactieve onderdelen nog toegankelijk werken. De tutorials van W3C (https://www.w3.org/WAI/tutorials/) geven best practices voor toegankelijke inhoud en tonen per pagina de gebruikte WCAG-criteria. Test na een wijziging bijvoorbeeld of menu en formulier nog met toetsenbord te bedienen zijn.

Wil je weten welke publieke signalen je website toont rond snelheid en meting? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst niet hoe je tags intern geladen worden of wat er na toestemming gebeurt.