Hoe je webhosting je Core Web Vitals beïnvloedt

Core Web Vitals zijn de prestatiestatistieken waarmee Google meet hoe snel en stabiel een pagina aanvoelt voor echte bezoekers. Ze tellen mee voor je positie in Google, dus een trage site kost je bezoekers en zichtbaarheid. De basis voor een goede score ligt bij de reactiesnelheid van je server, nog voordat de browser iets kan tonen. In dit artikel lees je wat Core Web Vitals zijn, waarom een snelle Time To First Byte (TTFB) de basis is voor die scores en welke rol je hosting daarin speelt.

Wat zijn Core Web Vitals?

Core Web Vitals zijn drie metingen van hoe bezoekers je site ervaren. Google laat ze sinds 2021 meetellen voor je positie in de zoekresultaten. Ze worden gemeten bij echte bezoekers en samengevat op het 75e percentiel: pas als 75 procent van je bezoekers binnen de norm valt, telt een statistiek als “goed”. De drie metingen zijn:

• Largest Contentful Paint (LCP) meet hoe snel het grootste element in beeld geladen is, vaak een grote afbeelding bovenaan of een groot tekstblok. Goed is 2,5 seconden of sneller.
• Interaction to Next Paint (INP) meet hoe snel de pagina reageert op interactie, zoals een klik of een toetsaanslag, over de hele sessie. Goed is 200 milliseconden of sneller.
• Cumulative Layout Shift (CLS) meet hoeveel de lay-out verspringt tijdens het laden. Goed is een score van 0,1 of lager.

INP is sinds maart 2024 de officiële opvolger van First Input Delay (FID). Waar FID alleen de vertraging van de eerste interactie mat, kijkt INP naar de reactiesnelheid gedurende het hele bezoek. Daardoor geeft INP een strenger en eerlijker beeld van hoe snel je site reageert.

TTFB is de basis voor je Core Web Vitals

Time To First Byte is de tijd tussen het moment dat de browser een pagina opvraagt en het moment dat de eerste byte van het antwoord binnenkomt. TTFB is zelf geen Core Web Vital, maar wel de basis ervoor. De reden is simpel: de browser kan pas beginnen met het tekenen van je pagina nadat die eerste byte er is. Elke milliseconde die je server nodig heeft om te reageren, telt dus rechtstreeks door in zowel First Contentful Paint als je LCP.

Een voorbeeld: stel dat je LCP-norm 2,5 seconden is en je server doet er 1,5 seconde over voordat de eerste byte vertrekt, dan hou je nog maar één seconde over om de afbeelding te laden, het CSS toe te passen en alles in beeld te tekenen. Hoe goed je je afbeeldingen en code ook optimaliseert, je begint met een achterstand die je op de pagina zelf niet meer goedmaakt. Een trage TTFB maakt een goede LCP in de praktijk vrijwel onmogelijk.

Wat bepaalt je TTFB?

TTFB is geen losse waarde, maar de optelsom van een aantal stappen die in volgorde gebeuren voordat de eerste byte vertrekt. Bij elke stap kan tijd verloren gaan:

1. DNS-resolutie: de browser vertaalt jouw-website.nl naar het IP-adres van de server. Dit gebeurt nog voordat er een verbinding is, dus snelle DNS-resolutie verkort de tijd vóór de server überhaupt kan antwoorden.
2. Verbinding en TLS: de browser zet een TCP-verbinding op en maakt de versleutelde HTTPS-verbinding. De afstand tot de server, oftewel de latency, bepaalt hoe snel dat heen en weer gaat.
3. Serververwerking: de webserver verwerkt het verzoek. Bij een dynamische site als WordPress betekent dat PHP-code uitvoeren en database-queries draaien om de HTML op te bouwen. Dit is in de praktijk vaak het grootste deel van de TTFB, en tegelijk het deel waar je hosting de meeste invloed op heeft.

De eerste twee stappen zijn meestal een kwestie van milliseconden. Het is die derde stap, de serververwerking, die een trage site echt traag maakt. Daar speelt je hosting de grootste rol.

Hoe je hosting je TTFB bepaalt

Je hostingomgeving bepaalt hoe snel de server een verzoek kan verwerken en beantwoorden. Een paar concrete factoren wegen daarin het zwaarst.

Full-page caching

Hiermee win je verreweg de meeste tijd op je TTFB. Zonder caching bouwt WordPress bij elk bezoek de pagina opnieuw op: PHP draait, de database wordt bevraagd, en pas daarna vertrekt de HTML. Met full-page caching wordt die HTML één keer opgebouwd en als kant-en-klaar bestand bewaard. De volgende bezoeker krijgt dat bestand direct geserveerd, zonder PHP of database. Het verschil in reactietijd is groot: je slaat het zwaarste deel van de verwerking volledig over.

Op het Advanced-pakket regel je dit zelf, bijvoorbeeld door WP Super Cache te installeren via je WordPress-beheer. Op het Businesspakket levert Chessweb een caching-plugin mee, die je zelf aanzet. Hoe dat gaat, lees je in WordPress traag: ligt het aan je hosting?

Object caching met Redis

Niet elk verzoek is te cachen als kant-en-klare pagina. Denk aan een ingelogde bezoeker of een dynamische pagina die per persoon verschilt. Voor die gevallen helpt object caching: terugkerende database-resultaten worden in het werkgeheugen bewaard in plaats van telkens opnieuw uit de database gehaald. Redis haalt die gegevens uit het geheugen, vele malen sneller dan een query op schijf. Dat verkort de verwerking op de server flink.

Op het Businesspakket is Redis Object Cache standaard beschikbaar voor WordPress-sites. Dat maakt het pakket bij uitstek geschikt voor zwaardere of dynamische sites, zoals een drukke webshop, waar veel verzoeken niet uit de pagina-cache komen.

Opcode-caching met opcache

WordPress bestaat uit PHP-bestanden die de server bij elk verzoek normaal opnieuw moet inlezen en compileren. Opcache bewaart de gecompileerde versie van die code in het geheugen, zodat de server dat werk niet telkens overdoet. Dat scheelt verwerkingstijd op elk dynamisch verzoek. Op het Businesspakket is opcache standaard beschikbaar voor WordPress-sites.

Servercapaciteit en snelle opslag

Caching helpt alleen als de server genoeg capaciteit heeft. Zit een server overvol, dan staan verzoeken in de wachtrij en loopt de TTFB op, juist op de drukke momenten waarop het ertoe doet. Voldoende rekenkracht en geheugen per site houden de reactietijd ook onder belasting stabiel. Snelle SSD- en NVMe-opslag versnelt bovendien de momenten waarop de server tóch naar schijf moet, bijvoorbeeld voor data die niet in de cache zit.

Serverlocatie en snelle DNS

De afstand tussen bezoeker en server bepaalt de latency: hoe verder weg, hoe langer elk heen-en-weertje duurt. Voor een site met vooral Nederlandse bezoekers zijn servers in Nederland gunstig, want de lijnen zijn kort. Chessweb draait zijn webhosting op servers in Nederland, wat de latency voor je Nederlandse bezoekers laag houdt.

Ook de DNS-laag telt mee. Bij anycast DNS wordt je domeinnaam beantwoord door de dichtstbijzijnde van meerdere wereldwijd verspreide servers, in plaats van door één centrale server. Dat verkort de DNS-resolutie en daarmee de tijd vóór de eerste byte. Het is geen onderdeel van de serververwerking, maar het haalt wel een stukje vertraging uit het allereerste deel van de laadtijd.

Wat je daarnaast op de site zelf optimaliseert

Een snelle TTFB is de basis. De rest van je Core Web Vitals bepaal je op de pagina zelf. De server levert de eerste byte snel aan, daarna is het aan je thema, afbeeldingen en scripts om het werk af te maken. De belangrijkste aandachtspunten per meting:

• Voor LCP: comprimeer afbeeldingen, serveer ze in een modern formaat zoals WebP, en laad de afbeelding die meteen in beeld staat als eerste. Een te zware afbeelding bovenaan is een veelvoorkomende oorzaak van een trage LCP.
• Voor CLS: geef afbeeldingen en advertenties vaste afmetingen mee, zodat de lay-out niet verspringt zodra ze inladen. Laad lettertypen zo dat tekst niet halverwege opnieuw opbouwt.
• Voor INP: beperk zware JavaScript en het aantal scripts van derden, zoals tracking en externe widgets. Die houden de browser bezig, waardoor de pagina traag reageert op klikken.

De praktische kant van die optimalisaties, toegespitst op WordPress, staat in het artikel de snelheid van je WordPress-website. Houd ook je PHP-versie actueel, want een recente PHP-versie verwerkt code merkbaar sneller dan een verouderde.

Je Core Web Vitals meten

Voor je iets verandert, is het verstandig om te meten waar je nu staat. Er zijn twee soorten metingen, en het verschil is belangrijk:

• Veldgegevens komen van echte bezoekers. Daar kijkt Google naar voor je positie in de zoekresultaten. Je vindt ze in Google Search Console onder het rapport Core Web Vitals.
• Labgegevens komen uit een testmeting onder gecontroleerde omstandigheden. Een tool als PageSpeed Insights toont beide en geeft per pagina een TTFB-waarde plus concrete verbeterpunten.

Begin bij PageSpeed Insights en let op de TTFB en de LCP. Zie je een hoge TTFB, dan ligt de winst aan de serverkant, bij caching en je pakket. Is de TTFB laag maar de LCP toch hoog, dan zit het knelpunt in je afbeeldingen of code op de pagina. Heb je Search Console nog niet gekoppeld, dan helpt het artikel Hoe stel ik Google Search Console in? je op weg.