Core Web Vitals: Waarom op maat gemaakte code 100 scoort – en WordPress zelden boven de 60 komt

Er is een structurele reden waarom handgeschreven sites de Core Web Vitals halen terwijl bouwer-sites om elk puntje vechten: schone code sleept simpelweg niet het dode gewicht mee dat de statistieken breekt. De Core Web Vitals zijn een bevestigde Google-rankingfactor, en hier is wat de meeste ontwikkelaars niet hardop zeggen: het gekozen platform bepaalt ruwweg 80% van je basisscore nog voordat je iets optimaliseert. Custom PHP kan met minimale moeite 100 halen; WordPress blijft, zelfs volgepropt met cacheplugins, vaak steken in de range van 40–60. Ik heb beide gebouwd en geoptimaliseerd, dus dit is geen theorie. Laat me je precies tonen waarom, met echte cijfers, echte code en echte klantresultaten.

De zakelijke reden om Core Web Vitals te halen

Voordat we in de code duiken, begrijp je de impact. Google’s gegevens tonen aan:

• Sites die Core Web Vitals halen, zien 24% minder gebruikersverlating.
• Een verbetering van 0,5s in LCP kan conversies met 12–15% verhogen (Google casestudy).
• Paginabeleving is nu een doorslaggevende factor wanneer twee pagina’s een vergelijkbare relevantie hebben.

Je platformkeuze gaat niet alleen om ontwikkelaarsgemak – het is een directe motor voor omzet en rankings.

De ruwe cijfers: op maat gemaakte PHP vs WordPress (dezelfde server)

Ik heb een gecontroleerde test uitgevoerd op identieke hosting (Hostinger VPS, 2 vCPU, 2GB RAM, NVMe-opslag). Twee websites:

• Site A: Op maat gemaakte PHP/HTML, geen framework, minimale CSS/JS, handmatig geoptimaliseerd.
• Site B: Verse WordPress 6.7 + Astra-thema + 5 essentiële plugins (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

De 847KB aan JavaScript is de boosdoener. WordPress laadt jQuery, de blokeditor, pluginscripts en thema-assets – zelfs als je ze niet gebruikt. Google’s Lighthouse meet alles, en elke kilobyte draagt bij aan LCP en INP.

Core Web Vitals uitgelegd (drempelwaarden 2026)

Google heeft bevestigd dat paginabeleving een rankingsignaal is op zowel mobiel als desktop. In 2026 zijn de drempelwaarden:

• LCP (Largest Contentful Paint) – meet laadsnelheid. Goed: onder 2,5s.
• INP (Interaction to Next Paint) – meet responsiviteit. Goed: onder 200ms (verving FID in 2024).
• CLS (Cumulative Layout Shift) – meet visuele stabiliteit. Goed: onder 0,1.
• TTFB (Time To First Byte) – serverrespons. Goed: onder 600ms (onofficieel, maar Google gebruikt het).

Een site die niet aan deze statistieken voldoet, wordt onder snellere concurrenten gedrukt – zelfs als die meer backlinks heeft.

Hoe op maat gemaakte PHP een perfecte 100 bereikt (echte code + randtechnieken)

Dit is precies wat ik bij elke maatwerkbuild doe om een Lighthouse-score van 100 te garanderen.

1. Laad kritieke assets vooraf

Vertel de browser wat het belangrijkste is voordat deze zelfs HTML parseert.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Plaats CSS boven de vouw inline (halveer FCP)

Extraheer alleen de stijlen die nodig zijn voor het zichtbare gebied. Gebruik het Chrome Coverage-tabblad om ongebruikte CSS te vinden.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Lever responsieve afbeeldingen met srcset en WebP

De meeste sites leveren desktopformaat afbeeldingen aan mobiel – een enorme LCP-boete. Gebruik `srcset` om afbeeldingen van de juiste grootte te leveren.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Optimaliseer serverrespons (TTFB)

Ik gebruik PHP‑FPM met ingeschakelde OPcache, GZIP-compressie en database-indexering. Geen WordPress `wp_query`-overhead betekent dat queries in 5–15ms retourneren, niet 150ms. Extra aanpassingen:

• Schakel Keep‑Alive en HTTP/2 in.
• Gebruik een CDN (Cloudflare of Bunny.net) om statische assets te cachen.
• Verplaats de database naar een aparte server of gebruik Redis voor objectcaching indien nodig.

5. Elimineer layoutverschuivingen (CLS = 0,01)

Elke afbeelding, video en advertentieplaats krijgt expliciete `width`- en `height`-attributen. Reserveer ruimte voor lettertypen met `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Stel niet-kritieke JavaScript uit

Gebruik `defer` of `async` op alle externe scripts en verplaats analyses om te laden na gebruikersinteractie.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Gebruik `loading="lazy"` voor afbeeldingen onder de vouw

Afbeeldingen die niet in eerste instantie zichtbaar zijn, moeten lui worden geladen. Dit bespaart bandbreedte en versnelt LCP.

Waarom WordPress deze cijfers niet gemakkelijk kan evenaren

• Elke plugin voegt zijn eigen CSS/JS toe, vaak zonder `async` of `defer`. Zelfs “geoptimaliseerde” plugins voegen overhead toe.
• De blokeditor laadt meer dan 500KB aan JavaScript, zelfs als je maar een eenvoudige pagina gebruikt. Dat is een halve megabyte aan ongebruikte code.
• Caching-plugins helpen, maar ze kunnen de onderliggende bloat niet verwijderen – ze cachen alleen de al gezwollen output.
• Thema’s van derden bundelen hele frameworks (Bootstrap, Tailwind) – 90% ongebruikte CSS die nog steeds rendering blokkeert.

Zelfs als je tijdelijk een 90 haalt op Lighthouse, kan een plugin-update of een nieuw thema het ’s nachts naar 45 laten kelderen. Met op maat gemaakte PHP is je prestatie deterministisch – het verandert niet tenzij jij het verandert.

Twee echte klanttransformaties

Casestudy 1: WooCommerce-sieradenwinkel → Op maat gemaakte PHP

Een sieradenwinkel had een WooCommerce-site met een score van 43 op Lighthouse (mobiel). Ze hadden 12 actieve plugins, een opgeblazen thema en laadtijden van 4,2s. Na migratie naar een op maat gemaakte PHP-winkel met Stripe Checkout:

• Lighthouse-score: 43 → 98.
• Mobiele laadtijd: 4,2s → 0,9s.
• Conversiepercentage: 1,8% → 3,4% (+89%).
• Gemiddelde orderwaarde steeg met 22% (snellere checkout stimuleerde upsells).

Casestudy 2: Vastgoedsite met meer dan 500 pagina’s

Een vastgoedagentschap had een WordPress-site met paginalaadtijden van 3,5 seconden en een CLS van 0,28 (slecht). We hebben de front‑end herbouwd als een op maat gemaakte PHP-site met een lichtgewicht template, inline kritische CSS en vooraf geladen hero-afbeeldingen.

• LCP: 3,1s → 0,9s.
• CLS: 0,28 → 0,02.
• Het bouncepercentage daalde van 58% naar 37%.
• Contactformulierinzendingen namen met 41% toe binnen 60 dagen.

De verborgen kosten van pagina-builders: Wix, Squarespace, Shopify

Het is niet alleen WordPress. Alle drag‑and‑drop-platforms hebben last van slechte standaardinstellingen:

• Wix/Squarespace: Inline-stijlen overal, enorme DOM-grootte en geen controle over kritische CSS. Gemiddelde Lighthouse mobiele score: 30–50.
• Shopify: Beter dan Wix, maar thema’s laden zware JavaScript en externe lettertypen. Gemiddelde score: 60–75.
• Webflow: Kan worden geoptimaliseerd, maar vereist deskundige kennis en levert nog steeds opgeblazen code vergeleken met handgeschreven PHP.

Alleen op maat gemaakte PHP geeft je volledige controle over elke byte die de browser bereikt.

Hoe te beginnen (zelfs als je geen ontwikkelaar bent)

Je hoeft niet alles vanaf nul te schrijven. Ik bouw elke website handmatig, zodat je een 100% op maat gemaakte codebase krijgt. Het resultaat: een Lighthouse-score die je kunt screenshoten en gebruiken als vertrouwenssignaal. Je kunt ook beginnen met een statische sitegenerator (Hugo, Eleventy) en later PHP toevoegen voor dynamische functies.

Actieplan: haal vandaag nog een 100 voor je site

1. Test je huidige site op PageSpeed Insights (mobiel). Noteer je LCP, INP, CLS.
2. Los eenvoudige problemen op: comprimeer afbeeldingen, schakel caching in, verwijder ongebruikte plugins.
3. Als je onder de 70 zit, overweeg dan een platformmigratie. De ROI van een op maat gemaakte PHP-site verdient zich vaak in 6–12 maanden terug door hogere conversies en lagere hostingkosten.
4. Of huur mij in. Ik bouw een op maat gemaakte PHP-site voor je die 100 scoort – gegarandeerd.

Laatste samenvatting: platformkeuze is 80% van de strijd

Je kunt elke site optimaliseren, maar beginnen met op maat gemaakte PHP geeft je een enorme voorsprong. WordPress vereist een constante strijd tegen zijn eigen architectuur. Wix en Squarespace sluiten je op in trage sjablonen. Op maat gemaakte PHP geeft je volledige controle. De cijfers spreken voor zich.

Als je een website wilt die van nature 96–100 scoort op Lighthouse en pagina-builders overtreft, laten we dan praten.

Alle testgegevens zijn verzameld op Hostinger VPS (2 vCPU, 2GB RAM) met Lighthouse 12.0 (mobiele simulatie). Jouw resultaten kunnen variëren op basis van inhoud en hosting.