Core Web Vitals

De meeste artikelen over dit onderwerp eindigen bij een plugin-advies: installeer Imagify, ShortPixel of Smush en klaar. Dat werkt, maar het is niet nodig. Sinds WordPress 6.4/6.5 zit de conversie naar WebP al in de core. In dit artikel laten we zien hoe je dat native filter activeert, hoe je checkt of je server WebP ondersteunt, en hoe je je bestaande mediabibliotheek alsnog meeneemt, zonder een extra plugin te installeren.

Waarom WebP: kleinere bestanden, betere Core Web Vitals

WebP is een modern beeldformaat van Google dat dezelfde visuele kwaliteit levert bij een aanzienlijk kleiner bestand. Uit Google's eigen compressiestudie blijkt dat WebP-afbeeldingen gemiddeld 25 tot 34% kleiner zijn dan vergelijkbare JPEG's bij gelijke visuele kwaliteit (gemeten met SSIM), en gemiddeld 26% kleiner dan PNG.^[2] Voor een website vol productfoto's of blogafbeeldingen scheelt dat direct megabytes per paginabezoek.

Een aparte plugin-vergelijking zet dat verschil nog scherper neer: een minimale schema-plugin van 186KB haalt gemiddeld 132ms TTFB, terwijl Yoast (bijna 15MB, 1.604 bestanden) daar 81 keer groter voor is en All in One SEO zelfs 100 keer^[3]. AIOSEO kan bovendien tot 15 extra databasequeries per paginaload genereren, goed voor 200 tot 400ms extra TTFB op shared hosting, omdat de JSON-LD-schema bij elke request opnieuw wordt opgebouwd in plaats van gecachet^[10]. Handmatige JSON-LD via functions.php weegt daarentegen minder dan 1KB en heeft vrijwel geen meetbare invloed op de laadtijd^[2].

Plugin-bloat is een bekende oorzaak van trage WordPress-sites, zoals we eerder beschreven in 5 redenen waarom je WordPress site zo langzaam is: elke module die je uitschakelt, telt mee. Zie ook hoe plugins je Core Web Vitals beïnvloeden voor het bredere plaatje.

Wanneer is handmatig wél of niet de juiste keuze?

Handmatige JSON-LD werkt het best bij een sitestructuur die niet elke week verandert: een bedrijfssite met een vaste set paginatypes, of een blog met artikelen die allemaal dezelfde velden nodig hebben (titel, auteur, publicatiedatum). Je schrijft de code één keer, en WordPress vult de rest automatisch in per pagina.

• HTTP-header: voor content die geen HTML is, zoals PDF's, gebruik je een Link-header met dezelfde hreflang-informatie. Onmisbaar zodra je downloadbare documenten in meerdere talen aanbiedt.

Voor de meeste WordPress-sites is de HTML-methode de praktische keuze. Grote sites met veel taalvarianten en duizenden pagina's, waar elke extra head tag ook de paginagrootte en daarmee Core Web Vitals raakt, kiezen vaker voor de sitemap-methode.

Stap-voor-stap: hreflang instellen met een plugin (WPML / Polylang / TranslatePress)

De meeste WordPress-sites stellen hreflang in via een meertalige plugin. Het proces is bij alle drie de grote spelers vergelijkbaar: