Snelheid is SEO: waarom Google houdt van clean code

Je site rankt niet slecht door slechte content. Hij rankt slecht door slechte code. Je kent het wel: je contentteam publiceert sterke pagina’s, je interne linking klopt, je krijgt links binnen. En toch blijft die top 3 net buiten bereik. Vaak zit het verschil niet in wát je zegt, maar in hoe snel en stabiel je pagina op het scherm verschijnt. Technical debt is dan geen puur development-probleem meer, maar SEO-debt.

Waarom snelheid tegenwoordig SEO is (zonder de magie)

Google wil resultaten tonen waar gebruikers blij van worden. Je kunt nog zo relevant zijn, als je pagina voelt als stroop of verspringt tijdens het laden, dan is de kans groter dat iemand terug klikt. Dat terugklikken is niet één op één een ranking signaal, maar het effect op gedrag en conversie is wel degelijk meetbaar.

Wat opvalt: slechts 33% van websites slaagt voor Core Web Vitals (Ahrefs, 2023). Dat betekent dat performance geen “nice to have” is waar iedereen al goed in is. Het is juist een onderscheidende factor, omdat veel sites blijven hangen in legacy CSS, component library bloat en third-party tags die langzaam zijn gegroeid.

Er is ook een duidelijke correlatie met rankings. Pagina’s op positie 1 zijn 10% vaker ‘Good’ op Core Web Vitals dan pagina’s op positie 9 (Semrush/Google, 2023). Dat is geen bewijs van causaliteit, maar het past bij het tie-breaker verhaal: als twee pagina’s inhoudelijk dicht bij elkaar zitten, helpt een betere ervaring je net over de streep.

Wat Google echt meet: LCP, INP en CLS in developer-taal

Core Web Vitals zijn drie UX-metrics die Google gebruikt om te meten hoe snel en stabiel een pagina aanvoelt. Niet in een lab-gevoel, maar gebaseerd op echte gebruikersdata (CrUX) zodra je genoeg traffic hebt.

• LCP (Largest Contentful Paint) meet hoe snel het grootste zichtbare element in de viewport verschijnt. Denk aan de hero-afbeelding op je landingpage, of de producttitel en hoofdafbeelding op PDP’s. Als je LCP slecht is, voelt je pagina “leeg” of half geladen.

• INP (Interaction to Next Paint) meet hoe responsief je pagina is op interacties. Je merkt dit als klikken op een filter, openen van een menu of typen in een zoekveld een fractie te lang duurt. Vaak is dit het gevolg van main-thread drukte door te veel JavaScript.

• CLS (Cumulative Layout Shift) gaat over layout shifts. Je kent het wel: je wilt op een knop klikken en ineens schuift alles naar beneden omdat een banner, webfont of afbeelding net te laat binnenkomt. Dit is niet alleen irritant, het kost ook conversie omdat mensen misclicks maken.

Wil je dit checken zonder te gokken? Gebruik PageSpeed Insights voor field data en Lighthouse voor lab data. Als je echt wilt weten waarom iets traag is, duik dan in Chrome DevTools Performance en Coverage.

Waar je code meestal stukloopt (en wat je vandaag kunt fixen)

Je hoeft geen complete rewrite te doen om CWV te verbeteren. Meestal zit de winst in het weghalen van ballast en het slimmer laden van wat je al hebt.

Render-blocking CSS en JavaScript

Een klassieke valkuil is dat je bundel en CSS de eerste render blokkeren. Zeker bij SPA’s zie je dat de shell snel komt, maar de echte content pas na een JS-bundel van een paar MB. Wat werkt in de praktijk: gebruik critical CSS voor above-the-fold en laad de rest asynchroon, stel JavaScript uit waar het kan, en overweeg server-side rendering of pre-rendering voor content-heavy pagina’s. Meet dit in Lighthouse en bevestig in DevTools Performance: kijk naar lange taken op de main thread en naar de timing van First Contentful Paint versus LCP.

Unused dependencies en component library bloat

Je importeert één component en je bundel slurpt een halve library mee. Of je hebt drie datepickers omdat elk team ooit “even snel” iets koos. Hier helpen tree shaking en dependency hygiene, maar alleen als je build setup het goed doet. Check in DevTools Coverage hoeveel JS en CSS ongebruikt blijft op je belangrijkste templates. Als 60% van je bundle rood is, dan betaal je elke bezoeker voor code die niks doet. Zorg dat je ESM builds gebruikt waar mogelijk, vervang zware utilities door native APIs of kleinere alternatieven, en splits je design system zodat niet elke pagina de volledige set components hoeft te laden.

Lazy loading die echt iets oplevert

Lazy loading is pas winst als je het koppelt aan het echte probleem. Als je LCP-element lazy loadt, schiet je jezelf in de voet. Optimaliseer hero media juist: gebruik het juiste formaat, moderne formats, en preloading waar relevant. Lazy load afbeeldingen en modules onder de fold en combineer dit met goede placeholders en vaste dimensies om CLS te voorkomen. Let ook op third-party tags: marketing scripts zijn vaak async, maar ze claimen alsnog main-thread tijd en kunnen INP negatief beïnvloeden.

Technical debt is SEO-debt (en je voelt het later in je rankings)

Shortcuts zijn verleidelijk. Even snel die extra tag, polyfill of component dupliceren. Het probleem is dat performance-debt cumulatief is. Elke release maakt je baseline iets zwaarder, totdat je ineens in een performance-project van zes weken zit zonder productfeatures. Dit is niet alleen een dev-observatie: technical debt werd het meest genoemde risico (28%) voor technisch SEO-succes volgens het State of Technical SEO Report (2023). Als je platform traag is, wordt alles moeilijker: crawling kost meer, rendering wordt zwaarder, en je gebruikerservaring zakt net onder de grens waar je concurrent wel “Good” scoort.

Het goede nieuws is dat kleine verbeteringen aantoonbaar geld opleveren. Vodafone verbeterde LCP met 31% en zag 8% meer sales (Google/Deloitte, 2020). Een vertraging van 1 seconde kan conversie met 7% doen dalen (Portent, 2024). Gebruik deze cijfers om performance net zo meetbaar te maken als je feature output.

Zo pak je het aan zonder religie: meten, snijden, verifiëren

Wil je pragmatisch aan de slag? Werk dan in een loop: meten, hypothese, fix, opnieuw meten. Niet op gevoel, maar op data. Gebruik PageSpeed Insights voor field data (CrUX) en snelle hints per URL, Lighthouse voor reproduceerbare labmetingen, Chrome DevTools Performance om long tasks te vinden, Coverage om ongebruikte JS/CSS te kwantificeren en WebPageTest voor waterfalls en visuele progressie. Kies één template die businesskritisch is, zoals je homepage of PDP. Fix eerst LCP en CLS op die pagina. INP volgt vaak als je JS-bloat en long tasks aanpakt.

Conclusie

Core Web Vitals zijn sinds 2021 een rankingfactor (Google), maar zoals John Mueller aangeeft: verwacht geen gigantische ranking-sprongen puur door CWV. Zie het als tie-breaker én als UX-fundament. Bij vergelijkbare content wint de site die sneller rendert, sneller reageert en niet verspringt. Als je dit goed aanpakt, betaal je technical debt niet alleen terug in minder bugs en snellere development, maar koop je ook betere SEO-kansen, lagere bounce en hogere conversie. Wil je weten waar jouw grootste performance-lekken zitten en welke fixes het meeste opleveren? Krafters kan een technische performance en CWV quickscan doen op je belangrijkste templates, inclusief DevTools-analyse, concrete tickets en een meetplan zodat je impact kunt aantonen in Lighthouse en field data.