Core Web Vitals voor PHP-sites: hoe LCP, INP en CLS te repareren

Core Web Vitals voor PHP-sites is geen front-end-only onderwerp. Een langzame PHP-pagina kan een seconde besteden aan het produceren van HTML, en geen enkele vorm van beeldoptimalisatie kan dat herstellen. Tegelijkertijd helpt een zeer snelle server niet als een hero-afbeelding van 1,5 MB de grootste verf blokkeert. Hier ziet u hoe we beide partijen benaderen op onze eigen PHP-sites (integrono.com draait PHP-FPM achter nginx en Cloudflare) en op klantprojecten.

Wat Core Web Vitals meet

• LCP ( Largest Contentful Paint): wanneer het grootste zichtbare element (meestal een heldenafbeelding of een kopblok) wordt weergegeven. Goed is 2,5 seconden of minder.
• INP ( Interaction to Next Paint): hoe snel de pagina visueel reageert na klikken, tikken en toetsaanslagen, gedurende het hele bezoek. Goed is 200 ms of minder.
• CLS ( Cumulative Layout Shift): hoeveel inhoud verspringt tijdens het laden. Goed is 0,1 of minder.

Google evalueert ze op basis van veldgegevens van echte Chrome-gebruikers, op het 75e percentiel, afzonderlijk voor mobiel en desktop. Dat betekent dat één langzaam sjabloon of één langzaam land de hele groep in de steek kan laten. Labtools zoals Lighthouse zijn bedoeld voor foutopsporing, niet voor de eindscore.

Stap 1. Meet op de juiste manier

1. Open het Core Web Vitals-rapport in Google Search Console om te zien welke URL-groepen falen en op welke statistiek.
2. Controleer PageSpeed Insights voor één URL uit elke falende groep. Het bovenste blok "veldgegevens" is wat telt; het Lighthouse blok hieronder is een laboratoriumtest die uitlegt waarom.
3. Gebruik het prestatiepaneel in Chrome DevTools met 4x CPU-vertraging en 'Slow 4G' om een typische mobiele ervaring te reproduceren.
4. Voor voortdurende monitoring kunt u gegevens van echte gebruikers verzamelen met de web-vitals JavaScript-bibliotheek en deze naar uw analyses sturen.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Stap 2. Herstel eerst de serverresponstijd ( TTFB).

LCP omvat de tijd voordat de eerste byte arriveert. Als het genereren van uw HTML 800 ms duurt, heeft u al een derde van het budget uitgegeven. Op PHP-sites zijn de gebruikelijke hefbomen:

• Schakel OPcache in en zorg ervoor dat deze groot genoeg is om alle scripts te bevatten. Zonder dit compileert PHP de bestanden bij elk verzoek opnieuw.
• PHP-FPM afstemmen. Te weinig medewerkers staan in de wachtrij voor aanvragen, te veel geheugenverlies. Bekijk de PHP-FPM statuspagina voor "luisterwachtrij" en "max. aantal kinderen bereikt".
• Cache hele pagina's voor anonieme bezoekers (nginx fastcgi_cache, een Laravel antwoordcache of Cloudflare cacheregels) en cachefragmenten of queryresultaten met Redis.
• Repareer langzame zoekopdrachten. Schakel het langzame querylogboek in, zoek naar N+1-patronen en voeg indexen toe. Een pagina die 120 zoekopdrachten uitvoert, is traag, ongeacht de PHP-versie.
• Houd PHP actueel. Nieuwere PHP-versies zijn sneller en gebruiken minder geheugen.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Stel pm.max_children in vanuit het echte geheugen: deel het geheugen dat u aan PHP kunt geven door de gemiddelde grootte van een werkproces (controleer dit met ps). Vergeet niet om met validate_timestamps=0 PHP-FPM na elke implementatie opnieuw te laden, anders blijft oude code in het geheugen achter.

Schakel op webserverniveau HTTP/2 of HTTP/3, Brotli of gzip en langlevende caching-headers in voor statische bestanden:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Gebruik bestandsnamen met versiebeheer of een ?v=-query op basis van de wijzigingstijd van het bestand, zodat "onveranderlijk" nooit verouderde assets bedient.

Stap 3. Bevestig het LCP-element

Zoek het LCP element in PageSpeed Insights of het DevTools Performance-paneel. Op de meeste inhoudspagina's is het een heldenafbeelding. Dan:

• Laad het niet lui. loading="lazy" op het LCP-beeld vertraagt dit. Gebruik in plaats daarvan fetchpriority="high".
• Serveer de juiste maat. Een afbeelding van 2400 px voor een slot van 900 px verspilt bytes. Gebruik srcset en sizes.
• Gebruik WebP of AVIF. Typische besparingen bedragen 30 tot 60 procent ten opzichte van JPEG bij vergelijkbare kwaliteit.
• Vermijd kettingen. Een afbeelding die via een CSS-achtergrond is ingesteld of door JavaScript is geïnjecteerd, wordt laat ontdekt. Zet het in de HTML als <img>.
• Externe bronnen waarvan het LCP afhankelijk is , vooraf verbinden of zelf hosten (lettertypen, image-CDN).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Dit is het patroon dat in het artikel op deze blog wordt gebruikt: twee WebP formaten, expliciete afmetingen en hoge ophaalprioriteit voor de held.

Stap 4. Lay-outverschuivingen verwijderen ( CLS)

• Stel altijd width en height (of aspect-ratio in CSS) in op afbeeldingen, video's en iframes, zodat de browser de ruimte reserveert.
• Reserveer ruimte voor banners, cookiemeldingen en advertenties. Plaats ze in een container met een vaste minimumhoogte in plaats van de inhoud na het laden naar beneden te duwen.
• Lettertypen: gebruik font-display: swap of optional, laad het hoofdlettertypebestand vooraf en maak er een subset van. Kies een reservelettertype met vergelijkbare statistieken.
• Plaats geen inhoud boven bestaande inhoud, tenzij de gebruiker deze heeft geactiveerd.
• Animeer met transform en opacity, niet met eigenschappen die de lay-out veranderen (top, height).

Stap 5. INP verbeteren: minder JavaScript op de hoofdthread

INP is de nieuwste statistiek en degene die PHP-ontwikkelaars verwaarlozen, omdat de server hier geen directe invloed op heeft. De oorzaken liggen in de browser: lange taken uit grote bundels, zware scripts van derden (analytics, chatwidgets, tagmanagers) en handlers die teveel werk synchroon doen.

• Controleer scripts van derden. Verwijder wat niemand gebruikt, laad de rest met defer of na de eerste interactie.
• Lange taken splitsen. Verdeel het werk in stukjes met requestIdleCallback, setTimeout of de Scheduler API; verplaats zware berekeningen naar een Web Worker.
• Houd de DOM klein. Duizenden knooppunten zorgen ervoor dat elke update traag is.
• Vermijd geforceerde synchrone lay-outs in lussen (afwisselend lezen en schrijven van lay-outeigenschappen).
• Toon onmiddellijke feedback (een ingedrukte status of spinner) voordat u langzaam begint te werken.

Stap 6. Bewaak het in uw implementatieproces

De prestaties gaan stilletjes achteruit: een nieuwe tag, een zwaardere held, een extra zoekopdracht op de startpagina. Voeg Lighthouse CI of een geplande PageSpeed API-controle toe voor uw vijf belangrijkste sjablonen, stel budgetten in ( LCP, totale JS-grootte, afbeeldingsgewicht) en waarschuwt wanneer deze worden overschreden. Vergelijk TTFB voor en na elke release; als het springt, is de oorzaak bijna altijd een query of een cache die niet langer wordt gevonden.

Een realistische werkvolgorde

1. Meet veldgegevens en identificeer falende URL-groepen.
2. Schakel OPcache in, bekijk PHP-FPM-instellingen en voeg caching op volledige pagina toe voor anoniem verkeer.
3. Hero-afbeeldingen repareren: formaat, grootte, prioriteit, afmetingen.
4. Reserveer ruimte voor alles wat te laat laadt.
5. JavaScript verminderen en uitstellen; verwijder ongebruikte derden.
6. Meet na 28 dagen opnieuw, omdat veldgegevens een voortschrijdend venster zijn.

Verwacht geleidelijk verbeteringen in Search Console: het rapport gebruikt grofweg de gegevens van de afgelopen 28 dagen, dus een oplossing die vandaag is verzonden, is pas na ongeveer een maand volledig zichtbaar.

Hoe wij kunnen helpen

We doen prestatiewerk aan PHP- en Laravel-projecten als onderdeel van een technische SEO-opdracht en als eenmalige afstemming: caching, queries, afbeeldingen en front-end-fixes die in code worden verzonden. Als u wilt weten welke van de bovenstaande wijzigingen op uw site de moeite waard zijn, boek dan een consultatie of een serveranalyse. Voor de bredere checklist rond crawlen en indexeren, lees onze technische SEO-auditchecklist.