Blog
Gemeten bij je echte bezoekers, niet in Lighthouse.
Waar de winst voor Core Web Vitals in een Drupal-site echt zit, op het 75e percentiel van je paginaweergaven.
Core Web Vitals zijn drie meetwaarden uit de browser van echte bezoekers, geen Lighthouse-score.
Google beoordeelt je site op het 75e percentiel van de paginaweergaven, dus drie kwart van je bezoekers moet binnen de drempel vallen.
Een test op je eigen glasvezellijn zegt dus niets over iemand met een drie jaar oude Android op 4G.
LCP, INP en CLS: de drie waarden en hun drempels
De drie waarden meten laadsnelheid, reactiesnelheid en visuele stabiliteit, elk met een eigen grens.
Largest Contentful Paint is het moment waarop het grootste element in beeld staat, meestal een afbeelding of een kop.
Interaction to Next Paint is de tijd tussen een interactie (klik, tik of toetsaanslag) en het eerstvolgende beeld.
Van alle interacties in een bezoek houdt Google de langste over, op enkele uitschieters na, niet het gemiddelde, dus een handvol trage klikken bepaalt je score.
Cumulative Layout Shift is de zwaarste reeks verschuivingen die de bezoeker niet zelf veroorzaakt, zoals tekst die wegspringt terwijl een lettertype inlaadt: Google telt de verschuivingen binnen een venster van maximaal vijf seconden op en rapporteert het zwaarste venster, niet alle verschuivingen van de hele pagina samen.
| Waarde | Goed | Matig | Slecht |
|---|---|---|---|
| LCP | 2,5 seconden of minder | 2,5 tot 4 seconden | meer dan 4 seconden |
| INP | 200 milliseconden of minder | 200 tot 500 milliseconden | meer dan 500 milliseconden |
| CLS | 0,1 of minder | 0,1 tot 0,25 | meer dan 0,25 |
INP verving First Input Delay op 12 maart 2024, dus een rapport dat nog FID toont meet iets dat niet meer meetelt.
Meet eerst, sleutel daarna
Velddata bepalen je beoordeling, labtools leggen alleen uit waarom.
PageSpeed Insights toont de echte metingen uit het Chrome User Experience Report over de voorbije 28 dagen en daaronder een Lighthouse-test in een gesimuleerde omgeving.
Search Console groepeert die velddata per set URL's, zodat je ziet hoeveel pagina's falen.
Een score van 100 in Lighthouse zegt op zich weinig, want labtools kunnen INP niet meten zonder echte interactie.
Hoe je lab- en velddata uit elkaar houdt en hoe je opspoort waar een trage site precies vastloopt, staat in waarom je PageSpeed-score niet je snelheid is; hieronder ga ik verder met het optimaliseren zelf.
Caching: hier zit bij Drupal de grootste winst
Bij een Drupal-site zit de grootste winst bijna altijd in de cachelagen, niet in de frontend.
Een pagina die Drupal volledig moet opbouwen kost honderden milliseconden tot enkele seconden servertijd en die tijd zit integraal in je LCP voordat de browser een afbeelding heeft gezien.
Internal Page Cache bewaart de volledige HTML voor anonieme bezoekers en levert die heel vroeg in de request af.
Die laag valt in de praktijk vaak stil door iets kleins: code die op elke pagina een sessie start of een cookie zet.
Dynamic Page Cache werkt ook voor ingelogde gebruikers en bewaart de pagina met placeholders voor wat per gebruiker verschilt.
Hij hangt volledig aan correcte cachemetadata: een blok dat max-age 0 teruggeeft op paginaniveau maakt de hele pagina oncachebaar en cachecontexten die per querystring verschillen versnipperen je cache.
BigPipe zit sinds Drupal 8.3 stabiel in core en staat sinds 8.5 standaard aan in het Standard-profiel.
Hij stuurt het paginaskelet meteen en vult de dynamische delen daarna in.
Het werk wordt er niet kleiner van, alleen anders verdeeld.
Daarboven zet ik een reverse proxy of CDN met invalidatie op cachetags, want de edge antwoordt zonder PHP.
Afbeeldingen: bijna altijd het LCP-element
Op de meeste Drupal-sites is het LCP-element een afbeelding en daar ligt de snelste winst.
Core converteert sinds Drupal 9.2 naar WebP in een image style en sinds Drupal 11.2 naar AVIF met een fallback.
Gebruik responsive image styles, zodat een telefoon geen desktopbestand binnenhaalt.
Let op een detail dat core tegen je werkt: sinds Drupal 9.1 krijgen afbeeldingen standaard loading="lazy".
Voor je hero is dat precies verkeerd, want dan stelt de browser het belangrijkste bestand uit.
Zet die op eager, geef hem een hoge fetchpriority en vul width en height in zodat de ruimte gereserveerd blijft.
Sinds Drupal 9.4 regel je dat per veld in de UI.
Eerlijk erbij: een hero van 1,8 MB naar 150 kB brengen levert meer op dan alle andere ingrepen samen en een thumbnail van 40 kB in AVIF zetten levert niets meetbaars op.
CSS en JS: aggregeren en dan pas snijden
Aggregatie hoort aan te staan, maar ze is zelden je grootste probleem.
Sinds Drupal 10.1 bouwt core de aggregaten niet meer tijdens het renderen van de pagina, maar via een eigen route wanneer het bestand wordt opgevraagd, wat honderden milliseconden van een koude request haalt.
Op Drupal 9 of ouder mis je dat. Drupal 10 bereikt end of life op 9 december 2026, dezelfde week waarin Drupal 12 uitkomt, dus een upgradetraject staat bij de meeste sites toch al op de planning.
De echte winst zit in wat je niet laadt.
Een sliderbibliotheek die globaal in de libraries.yml van je thema hangt, een contrib-module die jQuery op elke pagina meesleept, een tagmanager die drie externe scripts binnenhaalt: dat zijn de lange taken die je INP boven 200 milliseconden duwen.
Aggregeren maakt die scripts niet korter.
Lettertypen: klein probleem, vaste bron van CLS
Lettertypen zijn zelden je LCP, maar wel de meest voorspelbare oorzaak van layoutverschuiving.
Host ze in je thema in plaats van via een externe stylesheet, want dat scheelt een verbinding.
Gebruik font-display swap, preload het ene bestand dat boven de vouw nodig is en stem je fallback af met size-adjust of ascent-override.
Zonder die afstemming ruil je met swap onzichtbare tekst in voor een verschuiving.
Twee families met elk drie gewichten is meestal een gewicht te veel.
Views die te veel doen
Een view die te veel doet is de meest onderschatte oorzaak van trage Drupal-pagina's.
De klassieke combinatie: rendered entity als rijstijl op een lijst van vijftig items, waardoor je vijftig volledige entiteitsweergaven opbouwt in plaats van een paar velden.
Daarbovenop filters en relaties die joins toevoegen, node_access-joins op sites met fijnmazige rechten, een pager op honderd en render caching die uit staat.
Nuance die vaak wegvalt: staat je paginacache goed, dan betaalt alleen de eerste bezoeker na een cache-clear de rekening.
Je ziet een zware view dan in pieken in je TTFB, niet in je mediaan.
Wat niet meetbaar helpt
Een deel van wat als performancewerk verkocht wordt, verandert niets in je velddata.
Jagen op een Lighthouse-score van 100 terwijl je velddata al groen zijn, minificatie van enkele kilobytes, een extra cachemodule bovenop de drie lagen in core, of alles tegelijk preloaden zodat de verzoeken om bandbreedte concurreren.
Core Web Vitals zijn ook maar een signaal in de beoordeling van Google en de inhoud weegt zwaarder, dus een snellere pagina doe je voor je bezoeker.
Waar ik zou beginnen
- Velddata ophalen uit Search Console en vastleggen welke waarde faalt.
- TTFB scheiden van de rest: is die hoog, dan is het caching.
- De drie cachelagen in core nakijken, inclusief wat ze stilzet.
- Het LCP-element aanwijzen en dat ene bestand aanpakken.
- Views en globaal geladen scripts opschonen, geordend op impact.
- Na 28 dagen opnieuw meten, want velddata schuiven traag.
Loopt je site vast op een van de drie waarden, dan breng ik in kaart waar het ontstaat en los ik het op in de code.
Dat werk zit bij technische SEO en frontend performance, de opvolging erna bij technisch beheer en consultancy.
Stuur je site door via het contactformulier, je hebt binnen 24 uur antwoord.
Veelgestelde vragen
Hoe maak je een Drupal-website sneller?
Je maakt een Drupal-website sneller door de traagste stap te verkleinen, niet door alles een beetje te optimaliseren.
De volgorde is bijna altijd dezelfde: eerst de cachelagen, dan het LCP-element, dan de scripts die op elke pagina meekomen, dan de views.
Je werkt naar een LCP van 2,5 seconden, een INP van 200 milliseconden en een CLS van 0,1.
Welke cachelagen van Drupal moet ik aan hebben staan?
Internal Page Cache voor anonieme bezoekers, Dynamic Page Cache voor ingelogde gebruikers en BigPipe voor de dynamische delen: die drie zitten in core en horen alle drie aan te staan.
Daarboven zet ik een reverse proxy of CDN met invalidatie op cachetags, want de edge antwoordt zonder PHP.
Let vooral op wat die lagen stilzet, zoals code die op elke pagina een sessie start of een blok dat max-age 0 teruggeeft.
Moet ik lazy loading uitzetten op mijn hero-afbeelding?
Ja.
Sinds Drupal 9.1 krijgen afbeeldingen standaard loading="lazy" en op het LCP-element werkt dat tegen je: de browser stelt precies het belangrijkste bestand uit.
Zet die afbeelding op eager, geef hem een hoge fetchpriority en vul width en height in zodat de ruimte gereserveerd blijft.
Sinds Drupal 9.4 regel je dat per veld in de UI.
Hoe krijg ik mijn INP onder 200 milliseconden?
INP verbeter je door JavaScript weg te halen, niet door het te verkleinen.
De gebruikelijke oorzaken zijn een bibliotheek die globaal in de libraries.yml van je thema hangt, een contrib-module die jQuery op elke pagina meesleept en een tagmanager die externe scripts binnenhaalt.
Aggregeren maakt die scripts niet korter, dus laad ze alleen op de pagina's waar ze echt nodig zijn.
Wegen Core Web Vitals mee in de rankings van Google?
Core Web Vitals zijn een van de signalen waarmee Google pagina-ervaring beoordeelt, maar relevantie en inhoud wegen zwaarder.
Een site van rood naar groen brengen levert zelden een sprong in posities op, terwijl een LCP van vijf naar twee seconden wel merkbaar is voor wie je site gebruikt.
Behandel het dus als werk voor je bezoeker, met vindbaarheid als bijeffect.
Helpt BigPipe mijn Core Web Vitals?
BigPipe helpt vooral bij ingelogde en gepersonaliseerde pagina's en zit sinds Drupal 8.3 stabiel in core en sinds 8.5 standaard aan in het Standard-profiel.
Hij stuurt het paginaskelet meteen en vult de dynamische blokken daarna in, dus de bezoeker ziet eerder iets bruikbaars.
Voor een anonieme bezoeker die een volledig gecachte pagina krijgt verandert BigPipe vrijwel niets.
Een vraag over dit onderwerp?
Beschrijf kort je situatie, dan laat ik weten wat er speelt en wat het zou kosten. Zonder offertetraject.
