121 Core Web Vitals metingen: mijn beste hypotheses faalden
CSS samenvoegen verslechterde TBT van 76 naar 372 ms. AJAX uitstellen van 64 naar 265 ms. De echte boosdoener was de advertentiestack.
👁 116 keer gelezen
We optimaliseerden deze site enkele dagen lang en deden na elke wijziging een reeks Lighthouse-metingen in plaats van één enkele run. Het resultaat was vernederend: twee van onze beste hypotheses bleken schadelijk, en de echte boosdoener vonden we pas toen we stopten met vertrouwen op één enkel resultaat. 121 metingen in negen reeksen. Dit is wat eruit kwam.
Drie conclusies in één alinea
1. Eén Lighthouse-meting betekent niets - hetzelfde adres gaf ons resultaten van 60 tot 96 punten zonder enige codewijziging. 2. CSS-bestanden samenvoegen in één bestand, het advies uit elke handleiding, verslechterde TBT van 76 naar 372 ms. 3. De boosdoener van de spreiding was niet onze code, maar de advertentiestack - na het blokkeren van advertentiedomeinen stabiliseerde het resultaat op 77/77 met een FCP-spreiding van 0,7% in plaats van 22%.
Actuele lijst AI-cursussen
Overzicht dat automatisch dagelijks wordt bijgewerkt: prijzen, aantal lessen en beoordelingen rechtstreeks uit de catalogus van de verkoper. Nieuwigheden en bestsellers bovenaan.
Open overzicht →
Basisregel: meet een reeks, geen enkele run
Het klinkt banaal, maar bijna niemand doet het - en daarom zijn bijna alle “optimalisaties” op internet toeval.
We draaiden Lighthouse tien keer achter elkaar op een ongewijzigd adres. De resultaten liepen uiteen van 60 tot 96 punten. Als we iets in de code hadden gewijzigd en toevallig een run van 96 na de wijziging en 60 ervoor hadden gekregen, hadden we succes verkondigd. Als het andersom was uitgepakt, hadden we een goede verbetering teruggedraaid.
Pro tip: minimaal vijf runs per variant, vergelijk medianen en geef altijd het volledige bereik aan. Als de bereiken voor en na elkaar overlappen, heb je geen resultaat - je hebt ruis.
Hypothese 1, verworpen: CSS samenvoegen in één bestand
Klassiek advies: minder HTTP-verzoeken, dus voeg stylesheets samen. We bouwden een pakket van meerdere CSS-bestanden van het thema, controleerden de juistheid van relatieve padnamen en de volgorde van imports, en implementeerden het. Meting:
| Indicator op artikelpagina | Voor | Na samenvoegen |
|---|---|---|
| TBT (blokkering hoofdthread) | 76 ms | 372 ms |
| Tijd styleLayout | 700 ms | 1018 ms |
Waarom het niet werkte: vijf afzonderlijke stylesheets zijn vijf korte parsingtaken die de browser kan verweven met andere taken. Eén stylesheet van 69 KB is één lange taak die niet onderbroken kan worden - en lange taken zijn precies wat TBT meet. We verminderden het aantal verzoeken en verslechterden de ervaren vloeiendheid.
Pro tip: met HTTP/2 is het aantal verzoeken geen probleem meer. Bestanden samenvoegen is advies uit de tijd van HTTP/1.1 en kan tegenwoordig schade aanrichten.
Hypothese 2, verworpen: AJAX-verzoeken uitstellen
De winkelpagina stuurde bij het opstarten meerdere AJAX-verzoeken. We stelden ze uit via requestIdleCallback met een tijdslimiet van 3000 ms - een schoolboekoplossing. Meting:
- TBT winkel: 64 ms → 265 ms
- Start van verzoeken verschoof van het interval 183-1329 ms naar 383-2411 ms
Waarom het niet werkte: de tijdslimiet van 3000 ms zorgde ervoor dat de browser alle uitgestelde verzoeken in één reeks afvuurde - en dat precies in het venster waarin TBT wordt gemeten. In plaats van het werk te spreiden, verzamelden we het in één file.
Pro tip: requestIdleCallback met een korte tijdslimiet is niet “doe dit later”. Het is “doe dit later, maar zeker weten”. Zonder limiet of met een zeer lange limiet gedraagt het zich anders.
Wat wel werkte en waarom
Eén regel die 70 ms geforceerde layout-herberekening elimineerde
Een script las de positie van een element uit en wijzigde deze meteen. Dit veroorzaakt geforceerde layout-herberekening - de browser moet alles onderbreken en de geometrie van de pagina berekenen. Lighthouse wees 70-75 ms aan in één regel.
De fix is één regel:
if (window.requestAnimationFrame) requestAnimationFrame(plaats); else plaats();
Het uitlezen verplaatst naar een moment waarop de browser toch al de layout herberekent. De kosten dalen naar nul en de code doet precies hetzelfde.
Uit het kritieke pad verwijderen wat de pagina niet gebruikt
Het template-stylesheet woog 75.094 bytes en laadde op elke subpagina, ook al gebruikt het merendeel van de pagina’s geen enkele van die templates. De basisversie is 9.708 bytes - dus 87% van het gewicht was voor niets. Hetzelfde gold voor jQuery, dat werd geladen ondanks het ontbreken van enige consument.
Pro tip: voordat je gaat minificeren, controleer of het bestand überhaupt nodig is op die pagina. Verwijderen verslaat compressie elke dag.
De echte boosdoener: advertentiestack
Na het verwerpen van beide hypotheses stelden we een andere vraag: waar komt de spreiding van 60-96 punten vandaan. We blokkeerden advertentie- en toestemmingsdomeinen en herhaalden de reeks:
| Met advertenties | Zonder advertenties | |
|---|---|---|
| Prestatiescore | 60-96, bipolair | stabiel 77/77 |
| FCP-spreiding | 22% | 0,7% |
| TBT | variabel | 0 |
| Gewicht stack | 445-467 KB | |
De conclusie was genadeloos: we hadden enkele dagen code geoptimaliseerd die verantwoordelijk was voor een fractie van het probleem. De spreiding kwam van externe scripts waarop we geen invloed hebben en die we niet kunnen verwijderen omdat ze de site financieren.
Pro tip, de belangrijkste van de hele tekst: voordat je iets optimaliseert, meet hoeveel van het resultaat van jou komt en hoeveel van externe scripts. Doe een reeks met geblokkeerde domeinen van derden. Als het verschil groot is, ligt je werkelijke plafond veel lager dan je denkt - en dat kun je beter voor drie dagen werk weten dan erna.
Twee valkuilen van tools waar we op stuitten
Pingdom kan liegen over compressie
Het rapport beweerde dat de server geen antwoorden comprimeert. We controleerden rechtstreeks: de server stuurt br en zstd, en wanneer je expliciet om gzip vraagt, levert hij de hoofdpagina in 71.306 bytes in plaats van 289.394 ongecomprimeerd. De tool declareerde gewoon geen ondersteuning voor nieuwere algoritmes. Vervaltijdheaders waren ook aanwezig.
Het wissen van de hele cache kan de vormgeving verpesten
Een plugin wiste bij elke publicatie de hele cache inclusief geminificeerde CSS-bestanden. In het venster tussen verwijderen en herbouwen linkte de pagina naar een stylesheet die er niet was - en werd even weergegeven als kale HTML. Bij tientallen artikelen per dag gebeurde dit regelmatig.
Pro tip: wis na publicatie van een artikel gericht - alleen het artikel zelf, de hoofdpagina, zijn categorieën en de RSS-feed. Een nieuw artikel verandert de inhoud van het CSS-bestand niet, dus er is geen reden om het te verwijderen.
Checklist als je dit zelf wilt herhalen
- Doe tien metingen op een ongewijzigde pagina. Noteer de mediaan en het bereik. Dit is je ruis.
- Herhaal de reeks met geblokkeerde externe domeinen. Het verschil is het plafond van je mogelijkheden.
- Pas nu pas één ding tegelijk aan en meet met een reeks, niet met een enkele run.
- Als de bereiken voor en na elkaar overlappen - draai de wijziging terug. Geen bewijs is geen bewijs.
- Begin met verwijderen, niet met minificeren. Een bestand dat er niet is, is altijd het snelst.
- Zoek naar geforceerde layout-herberekeningen. Ze kunnen 70 ms waard zijn voor één regel code.
Waar deze cijfers vandaan komen
Alle waarden komen uit 121 Lighthouse-metingen in negen reeksen, uitgevoerd op deze site op 18-19 september 2026 op vier typen pagina’s: hoofdpagina, artikel, recensie en winkel. Beide verworpen hypotheses werden in productie geïmplementeerd, gemeten en teruggedraaid. Dit is geen overzicht van andermans adviezen - dit is een verslag van wat bij ons wel en niet werkte.
More on this from HELDER
benchmarks·AI-model weigert documenten te lezen: test bij drie providersContexttest toonde content_filter bij elk document boven ~2000 tokens op AWS, bij de maker en in Google. Zelfs voor tekst over planten.