Core Web Vitals — de drie prestatie-indicatoren van Google — hebben een reputatie gekregen als iets voor grote bedrijven met eigen servers en devops-teams. Maar de vraag die we regelmatig krijgen is simpelweg: kan ik een goede score halen op shared hosting? Het antwoord is ja. Maar je moet wel weten wat de server beïnvloedt en wat niet — want voor twee van de drie metrics maakt het helemaal niet uit waar je site gehost wordt.

Wat zijn de drie metrics?

LCP (Largest Contentful Paint) meet hoe snel het grootste zichtbare element op de pagina geladen is — meestal een grote afbeelding of koptekst. Google wil dit onder de 2,5 seconden. Dit is de metric waarbij de server het meeste verschil maakt.

INP (Interaction to Next Paint) meet hoe snel de pagina reageert op een klik of tap. Doel: onder de 200 milliseconden. Dit wordt vrijwel volledig bepaald door JavaScript op de pagina — de server heeft hier nauwelijks invloed op.

CLS (Cumulative Layout Shift) meet hoe stabiel de pagina is tijdens het laden — springt er een knop weg net als je erop wil klikken? Doel: onder de 0,1. Ook hier heeft de server geen invloed op. CLS is een puur frontend-probleem.

Kort samengevat: de hostingomgeving is primair van invloed op LCP. INP en CLS los je op in je thema, plugins en afbeeldingen — ongeacht of je op shared hosting of een dedicated server zit.

LCP verbeteren: hier maakt de server het verschil

De grootste oorzaak van een hoge LCP op WordPress is een trage Time to First Byte (TTFB): de server die lang doet over het genereren van de eerste byte HTML. Met de Nginx FastCGI cache die bij Lionserve standaard actief is, wordt een gecachete pagina direct teruggestuurd zonder dat PHP of MySQL wordt aangesproken. TTFB daalt daarmee van soms 300–800ms naar tientallen milliseconden voor gecachete pagina’s.

Naast caching helpt het om de LCP-afbeelding eerder te laden via een preload-hint in de <head>:

<link rel="preload" as="image" href="/pad/naar/hero-afbeelding.webp">

WP Rocket en vergelijkbare plugins kunnen dit automatisch detecteren en instellen. En gebruik WebP — gemiddeld 25–35% kleiner dan JPEG, zonder zichtbaar kwaliteitsverlies.

INP verbeteren: dit is een frontendprobleem

Een hoge INP komt bijna altijd van zware JavaScript die de hoofdthread blokkeert — page builders, sliders, chatwidgets, teveel externe scripts die tegelijk laden. De oplossing zit in het uitstellen van scripts (defer of async), het verwijderen van wat je toch niet gebruikt, en een lichtgewicht thema dat weinig JavaScript meebrengt. De server kan daar niets aan doen.

CLS verbeteren: geef alles vaste afmetingen

Layout shifts ontstaan doordat de browser ruimte moet reserveren voor elementen waarvan hij de grootte nog niet weet. De oplossing is zo simpel als het klinkt: geef elke <img> altijd een expliciete width en height mee. Laad kritieke webfonts via preload met font-display: swap. En zorg dat cookiemeldingen en banners geen bestaande content wegduwen.

Hoe meet je je score?

Twee tools die we zelf gebruiken: PageSpeed Insights voor directe lab- en velddata per metric, en het Core Web Vitals-rapport in Google Search Console voor echte gebruikersdata van jouw bezoekers. Meet altijd op een gecachete pagina — de eerste ongecachete laadtijd is niet wat de meeste bezoekers ervaren.