Ongebruikte CSS herkennen zonder je site te breken

De dekkingsrapporten in browserdeveloper tools tonen welke CSS-bytes bij een bepaalde sessie zijn toegepast. Dat is een momentopname van wat jij in die sessie hebt gedaan, geen bewijs dat de rest overbodig is. De web.dev-cursus beschrijft het critical rendering path als het concept dat bepaalt hoe snel de eerste weergave van een pagina verschijnt, waarbij render-blocking en parser-blocking resources een rol spelen (web.dev, Learn Performance). CSS kan dus de eerste weergave beïnvloeden, maar dat is pas een reden om te snoeien als je zeker weet wat je weghaalt.

Er zijn vier typische valkuilen:

• Regels voor toestanden die pas na interactie bestaan, zoals :hover, :focus, open menu's, modals en tabs.
• Regels voor foutstaten en lege staten, zoals validatiemeldingen, een lege winkelwagen of een 404-pagina.
• Regels voor sjablonen die je niet vaak bezoekt, zoals een blogartikel, een contactpagina of een bedankpagina.
• Regels die door een script worden toegevoegd of verwijderd, bijvoorbeeld via klassen die JavaScript zet.

Behandel een dekkingsmeting daarom als een lijst met kandidaten om te onderzoeken, niet als een lijst met regels om te verwijderen.

Maak eerst een inventaris voordat je iets meet. Eén tabel is genoeg. Zet in de rijen alle paginatypes van je site (niet alle URL's) en in de kolommen de toestanden die per type kunnen voorkomen.

1. Haal de sjablonen op uit je CMS of thema: homepage, categoriepagina, detailpagina, artikel, contact, winkelwagen, afrekenen, bedankpagina, 404.
2. Noteer per sjabloon welke componenten kunnen verschijnen: navigatie, formulier, slider, tabbladen, accordeon, banner, pop-up.
3. Noteer per component de toestanden: standaard, hover, focus, geopend, actief, fout, laden, leeg, uitgeschakeld.
4. Noteer de schermbreedtes waarvoor je CSS hebt, want media queries bevatten vaak een groot deel van de regels. Test minstens smal, middel en breed.
5. Noteer ook ingelogde en uitgelogde weergaven als je site die kent.

Het resultaat is je testmatrix. Hoe vollediger die is, hoe minder verrassingen je later hebt. Vraag collega's of de eigenaar van de site naar pagina's die zij zelden zien: een campagnepagina, een reserveringsflow of een pagina in een tweede taal.

Meet vervolgens per route in plaats van één keer globaal. Open de developer tools van je browser, start een dekkingsopname (de exacte menunaam verschilt per browser en versie, controleer dit in de tools die je gebruikt), laad de pagina en doorloop daarna actief de toestanden uit je matrix: open het menu, tab door het formulier, verstuur het leeg zodat de foutmeldingen verschijnen, klik door alle tabbladen, verklein het venster.

Exporteer of noteer per sessie welke regels ongebruikt bleven. Leg de resultaten naast elkaar en bepaal per regel of selector in hoeveel sessies hij werd gebruikt. Een regel die in geen enkele sessie voorkwam, is een kandidaat. Een regel die op slechts één route voorkwam, is zeker geen kandidaat, ook al lijkt hij op de rest van de site overbodig.

Let ook op wat je niet kunt meten: stijlen voor toestanden die je niet kunt uitlokken, zoals een serverfout of een betaalstap in een testomgeving die je niet hebt. Markeer die regels als onbekend en laat ze staan tot je meer weet. MDN beschrijft webperformance als objectieve metingen en ervaren laad- en reactietijd (MDN over webperformance). Een kapotte weergave is een eigen risico dat je bij het snoeien zelf moet afwegen tegen een mogelijk beperkte winst.

Gebruik dit overzicht per kandidaatregel. Is het antwoord in een van de eerste vier rijen ja (of onzeker), dan laat je de regel staan tot de bijbehorende controle is gedaan.

De toegankelijkheidsrij is geen detail. De WAI-tutorials van W3C richten zich op het ontwikkelen van content die toegankelijk is voor mensen met een beperking (W3C WAI-tutorials). Of een bepaalde voorziening in jouw site via CSS loopt, controleer je zelf in je code. Een regel die alleen bij toetsenbordnavigatie zichtbaar wordt, verschijnt in een muissessie nooit in je dekkingsrapport.

Verwijder nooit alles in één keer. Werk in kleine, afgebakende batches, bijvoorbeeld per component of per bestand, zodat je bij een probleem weet waar je moet zoeken.

1. Werk op een testomgeving of een aparte branch, niet in productie.
2. Maak eerst screenshots van de belangrijkste routes en toestanden uit je matrix, op minstens drie breedtes.
3. Verwijder één batch en laad dezelfde routes opnieuw. Vergelijk visueel met de screenshots.
4. Doorloop alle toestanden opnieuw: hover, focus met het toetsenbord (Tab en Shift+Tab), open en gesloten componenten, foutmeldingen, lege staten.
5. Controleer de browserconsole op fouten en kijk of er elementen zijn die onverwacht van positie of grootte veranderd zijn.
6. Test minstens in de browsers waarin je bezoekers je site het vaakst gebruiken. Je analysegegevens vertellen je welke dat zijn.
7. Rol uit en zet een terugdraaipunt klaar. Bewaar de oude stylesheet tot je site een tijd zonder meldingen draaide.

Meet na de wijziging opnieuw met dezelfde methode als ervoor, bijvoorbeeld de bestandsgrootte en het laadgedrag in de netwerktab. Neem geen verbetering aan: het effect hangt af van je site, je hosting en je bezoekers, en kan klein zijn.

Een fictief voorbeeld met invoer en verwachte controles, zonder resultaten. Een kleine webwinkel heeft één stylesheet. De dekkingsmeting op de homepage markeert een groot blok regels met de selectors .cart-empty, .form-error en .menu-open als ongebruikt.

Verwachte controles voor dit scenario:

• Zoek de drie selectors in alle sjablonen en scripts. Verschijnt .menu-open in een script dat een klasse zet, dan blijft die regel staan.
• Leeg de winkelwagen en bezoek de winkelwagenpagina: gebruikt die .cart-empty?
• Verstuur het contactformulier leeg en met een foutief e-mailadres: gebruikt dat .form-error?
• Open het mobiele menu op een smal scherm en controleer .menu-open.
• Alleen wat in alle controles ongebruikt blijft en in de code nergens voorkomt, gaat in een aparte batch naar de testomgeving. Houd er rekening mee dat klassenamen die dynamisch worden samengesteld of uit externe inhoud komen, niet altijd via zoeken te vinden zijn.

Leg voor de overdracht vast in één document: de routes en toestanden die je testte, de schermbreedtes, de browsers, de regels die je liet staan en waarom, en de batch die je verwijderde met een verwijzing naar het terugdraaipunt. Wie het later overneemt, kan dan dezelfde matrix herhalen in plaats van opnieuw te beginnen.

Wil je ook zien welke publieke signalen je website nu afgeeft rond snelheid en weergave? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en vervangt je eigen dekkingstest op echte routes niet.