Website sneller maken en Core Web Vitals verbeteren

Het zijn drie indicatoren waarmee Google meet hoe snel en stabiel een site werkt bij echte Chrome-gebruikers: LCP (hoe snel de hoofdcontent verschijnt), INP (hoe snel de site op een klik reageert) en CLS (of de layout niet verspringt tijdens het laden). De resultaten zie je in Search Console en PageSpeed Insights. Ze maken deel uit van de signalen die Google meeweegt, maar zijn niet de enige.

De prijs noem ik na een snelheidsaudit, als vaste scope op papier en niet als urenteller. Die hangt af van het platform, het aantal templates (homepage, categorie, product, bericht), het aantal plugins en scripts en of het probleem in de code of op de server zit. De meeste verbeteringen voer ik binnen een paar weken door, en de eerste, goedkoopste wijzigingen komen meestal als eerste op je site.

Het helpt, maar eerlijk: snelheid is een van de vele rankingsignalen en geen magische hefboom. Core Web Vitals zijn een bevestigd onderdeel van de page-experience-signalen van Google, dus een site die ze niet haalt, concurreert met een handicap. Snelheid herstellen haalt die handicap weg en verbetert de efficiëntie van het crawlen, maar haalt op zichzelf geen betere content in. Daarom zie ik het als één discipline naast technische SEO, en ik zeg je vooraf als je grotere probleem ergens anders ligt.

WordPress zelf is zelden het probleem. Meestal is het opgebouwde gewicht eromheen het probleem: thema's van pagebuilders, een dozijn plugins die eigen scripts laden, niet-geoptimaliseerde afbeeldingen en trage databasequery's. De meeste WordPress- en WooCommerce-sites die ik zie, hebben veel marge zonder van platform te wisselen. Is een thema of een stapel plugins echt niet te redden, dan zeg ik dat en laat ik ter vergelijking zien wat een herbouw zou kosten. Jij beslist op echte cijfers.

In de meeste gevallen is het optimaliseren van de bestaande site de juiste eerste stap: het is goedkoper, sneller en de metingen laten precies zien hoe ver het kan reiken. Een herbouw is alleen zinvol als de bottleneck het fundament zelf is: een thema dat elke optimalisatie tegenwerkt, of een stack waar je uit bent gegroeid. De audit beantwoordt die vraag met data voordat je je aan een van beide routes verbindt, en ik heb geen motief om je naar een groter project te duwen.

Elke opdracht begint met gedocumenteerde nulmetingen: labdata uit Lighthouse en veldgegevens uit het Chrome UX Report (CrUX) van Google, plus tests op echte apparaten en verbindingen, niet alleen in een desktopsimulator. Na elke ronde verbeteringen meet ik dezelfde pagina's op dezelfde manier en lever ik een rapport voor/na. Als een verbetering de cijfers niet laat bewegen, zie je dat ook. CrUX-data omvat de laatste 28 dagen, dus het volledige effect van wijzigingen zie je daarin met vertraging, en bij weinig verkeer kan het helemaal ontbreken; dat vermeld ik dan in het rapport.

Dat is een reëel risico bij agressieve caching en het verplaatsen van scripts, daarom werk ik voorzichtig: wijzigingen controleer ik eerst op een kopie van de site, ik voer ze stapsgewijs door en verifieer ze op je kernprocessen (formulieren, checkout, tracking) vóór en na elke stap. Alles is gedocumenteerd en terug te draaien. Al het werk is van jou en niets gaat naar productie zonder dezelfde tests te doorstaan die de browser van een echte klant zou uitvoeren.

Nee. Het resultaat hangt ook af van zaken buiten de code: hosting, externe scripts die je niet wilt verwijderen en de apparaten van je klanten. Ik beloof een gedocumenteerde meting vóór de wijzigingen, verbeteringen op volgorde van invloed op het resultaat en dezelfde meting erna. Is een doel zonder herbouw niet haalbaar, dan zeg ik dat vóór de offerte.