Dubbele JavaScriptbibliotheken vinden op je website

Een pagina krijgt scripts uit meerdere bronnen: het thema, extensies, tagbeheer en embeds van derden. Elk van die bronnen kan een eigen exemplaar of een andere versie van dezelfde bibliotheek meebrengen. De browser haalt dan in principe beide bestanden afzonderlijk op, tenzij er een build- of cachemechanisme tussen zit.

De kost zit op twee plaatsen. Ten eerste netwerk: extra bytes die opgehaald moeten worden. Ten tweede verwerking: de browser moet extra JavaScript parsen en uitvoeren. De cursus Learn Performance van web.dev behandelt resourcelading, het kritieke renderpad en het opsplitsen van JavaScript; het gaat daar uitdrukkelijk om welke resources de eerste weergave vertragen. Hoe zwaar een duplicaat bij jou weegt, hangt af van de grootte, de pagina en de gebruiker en vraagt dus een eigen meting.

Let op het onderscheid tussen een exact duplicaat (hetzelfde bestand, twee keer geladen) en een functioneel duplicaat (twee verschillende bestanden of versies met dezelfde taak). Het eerste is eenvoudig vast te stellen, het tweede vraagt inhoudelijke beoordeling.

1. Kies een beperkt aantal representatieve pagina's: de startpagina, een inhoudspagina, een formulier- of afrekenpagina en de zwaarste sjabloon.
2. Open de ontwikkelaarstools van je browser, ga naar het netwerkpaneel, filter op scripts en laad de pagina met een lege cache opnieuw.
3. Exporteer of noteer per script: volledige URL, bestandsnaam, grootte en het domein waaruit het komt.
4. Zoek dezelfde bestandsnaam of bibliotheeknaam die meerdere keren voorkomt, ook met verschillende versienummers of paden.
5. Open per verdacht script de bron en zoek de bibliotheeknaam of versiecommentaar bovenaan, om functionele duplicaten te herkennen.
6. Noteer per duplicaat wie het laadt. Gebruik de initiator-informatie van je browsertools als die beschikbaar is, en controleer anders thema, extensies en tagbeheer.
7. Herhaal de meting met toestemmingsbanner geaccepteerd en geweigerd, omdat sommige scripts pas na toestemming laden.

Waar de exacte paneelnamen staan, verschilt per browser en versie; controleer dat in jouw browser.

Een duplicaat zonder eigenaar blijft terugkomen. Maak een eenvoudige tabel met één rij per script en deze kolommen:

• Script: bestandsnaam, URL en versie.
• Laadt via: thema, extensie, tagbeheer of handmatige code.
• Eigenaar: persoon of leverancier die de wijziging mag doorvoeren.
• Doel: welke functie het script ondersteunt (menu, slider, formulier, meting).
• Pagina's: waar het geladen wordt.
• Status: behouden, onderzoeken of kandidaat voor verwijdering.

De kolom 'Doel' is de belangrijkste. Als niemand kan zeggen waarvoor een script dient, is het geen vrijgave voor verwijdering maar een reden om eerst uit te zoeken wat het doet. Scripts van derden vragen meestal een gesprek met de leverancier in plaats van een eigen ingreep.

De MDN-pagina over webperformance beschrijft laden en kritieke weergave als onderdeel van wat de gebruiker ervaart. Gebruik die denkwijze bij elke rij: verwijder alleen wat je kunt verantwoorden én terugdraaien.

Voer één wijziging per keer door op een testomgeving; test formulieren en afrekenen alleen daar, met een herkenbare testactie die je achteraf kunt opzoeken en verwijderen, omdat een foutmelding of time-out kan optreden nadat de gegevens al zijn opgeslagen. Doorloop daarna dezelfde checklist op je representatieve pagina's:

• Console van de browser: verschijnen er nieuwe foutmeldingen die vóór de wijziging niet bestonden?
• Navigatiemenu, zoekveld, slider en uitklappers: werken ze met muis én toetsenbord?
• Alle formulieren: verzenden, validatiemeldingen en bevestiging.
• Winkelwagen en afrekenen, indien aanwezig, tot en met een testbestelling.
• Cookiebanner en toestemmingskeuzes.
• Metingen en tags: komen je gebeurtenissen nog aan?
• Mobiel en desktop, in minstens twee browsers.

Toegankelijkheid hoort bij de regressiecontrole. De tutorials van W3C WAI bieden richtlijnen voor toegankelijke componenten; een verwijderd script kan ervoor zorgen dat bijvoorbeeld een uitklapmenu niet langer met het toetsenbord bedienbaar is. Test dus niet alleen met de muis. Deze controle bewijst geen volledige WCAG-conformiteit.

Meet daarna opnieuw met dezelfde methode als vóór de wijziging en vergelijk de lijst van opgehaalde scripts. Of dat ook zichtbaar sneller is, moet uit jouw eigen vergelijking blijken.

Een verzonnen voorbeeld, enkel ter illustratie van de werkwijze. Stel dat het netwerkpaneel op een contactpagina dezelfde bibliotheek tweemaal toont: één keer uit een themamap en één keer uit een extensiemap, met een verschillend versienummer in de commentaarregel bovenaan.

De inventaris krijgt twee rijen. Rij 1: thema-exemplaar, eigenaar webbouwer, doel menu en slider, status behouden. Rij 2: extensie-exemplaar, eigenaar beheerder van de website, doel onbekend, status onderzoeken. De beheerder zoekt eerst uit of het contactformulier van de extensie afhangt van dat exemplaar. Pas daarna wordt voorgesteld de extensie het script niet meer op pagina's zonder formulier te laten laden. De overdrachtsnota bevat: wat gewijzigd werd, op welke pagina's getest werd, welke checklist doorlopen werd, hoe de wijziging teruggedraaid wordt en wie ze goedkeurde. Er worden hier bewust geen aantallen of tijdwinsten genoemd; die moet je zelf meten.

Wil je weten welke publieke signalen je website uitstraalt rond snelheid, bekijk ze dan via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige technische implementatie of het exacte scriptgebruik per pagina.