Een website versnellen met Core Web Vitals en echte gegevens

Websites worden vaak in de verkeerde volgorde versneld: iemand installeert een optimalisatieplug-in, schakelt elke optie in en zoekt daarna uit waarom het formulier niet meer werkt. De juiste volgorde is meten, een hypothese formuleren, één wijziging doorvoeren, de functionaliteit controleren en opnieuw meten.

In een oudere versie beschreef ik ook aanpakken die ik niet langer aanbeveel, zoals scripts van anderen lokaal proxy'en of algemene AMP- en PWA-implementaties. Ze leverden gedeeltelijke verbeteringen in laboratoriummetingen op, maar brachten risico's door verouderde code, mislukte updates en ingewikkelder onderhoud met zich mee. Een moderne website moet snel zijn in zijn hoofdversie.

Wat je vandaag moet meten

Voor Core Web Vitals gebruikt Google drie stabiele meetwaarden:

• LCP: het laden van de hoofdinhoud; een goede waarde is maximaal 2.5 seconden.
• INP: reactie op interacties; een goede waarde ligt onder 200 milliseconden.
• CLS: onverwachte verschuivingen in de lay-out; een goede waarde is maximaal 0.1.

De drempelwaarden gelden voor het 75e percentiel en worden samengevat in het officiële overzicht Core Web Vitals voor Google Zoeken. Resultaten van echte bezoekers in Search Console of CrUX hebben voorrang op één laboratoriummeting op mijn laptop.

Laboratoriumtools blijven belangrijk: ze tonen de waterval, de hoofdthread, ongebruikte code en concrete kandidaten voor herstel. Veldgegevens laten zien dat er een probleem is; het laboratorium helpt verklaren waarom.

Bepaal eerst de omvang van het probleem

1. Vergelijk mobiel en desktop.
2. Scheid templates: homepage, artikel, dienst, overzicht, formulier en webshop.
3. Controleer snelle en trage landen, apparaten en verkeersbronnen.
4. Vind URL-groepen met slechte veldgegevens.
5. Leg een reproduceerbare laboratoriumtrace vast voor een representatieve pagina.

Eén snelle homepage betekent niet dat de website snel is. Eén traag bezoek op een oude telefoon betekent niet dat het hele systeem moet worden herschreven.

Ingrepen met de grootste algemene impact

1. Server en HTML

Meet de tijd tot de eerste byte en splits die op in DNS, verbinding, wachttijd op de server en omleidingen. Lange wachttijden kunnen komen door hosting, de database, een pagina zonder cache, een trage API of omleidingsketens. Schakel geschikte paginacache in voor openbare inhoud en objectcache waar dat zinvol is. Sluit ingelogde gebruikers, winkelwagens en personalisatie correct uit van de cache.

2. Hoofdafbeelding

LCP is vaak de hero-afbeelding. Lever een formaat dat overeenkomt met de weergave, gebruik srcset, compressie en moderne WebP of AVIF met een verstandige fallback. Gebruik geen lazy loading voor de hoofdafbeelding; laad afbeeldingen onder de eerste viewport wel lui. Stel de breedte en hoogte van afbeeldingen in, zodat de browser ruimte reserveert en CLS laag blijft.

3. CSS en lettertypen

Verwijder ongebruikte stijlen voorzichtig en houd kritieke CSS klein. Beperk lettertypen tot de vereiste gewichten en tekensets, cache lokale bestanden lange tijd en laad alleen een lettertype vooraf dat echt vroeg nodig is. Tien lettertypen vooraf laden creëert alleen maar een extra wachtrij.

4. JavaScript en interactie

Splits grote bundels op, stel niet-kritieke code uit en laad scripts van derden alleen wanneer dat nodig is en toestemming dit toestaat. async en defer zijn geen magie; test de volgorde en afhankelijkheden van scripts. Verdeel lange taken op de hoofdthread en laat een klik niet wachten op analytics.

5. Scripts van derden

Chats, heatmaps, advertentiepixels, video's en A/B-tools voegen netwerkverzoeken en processorbelasting toe. Elk script heeft een eigenaar en een zakelijke reden nodig. Laad het niet synchroon in de header alleen omdat de installatiehandleiding dan korter is. Analytics kan worden beheerd via Google Tag Manager, maar de container zelf kan prestaties niet redden.

WordPress: minder lagen, meer controle

De WordPress-documentatie raadt aan prestaties aan te pakken via hosting, het aantal en de kwaliteit van plug-ins, afbeeldingen, cache en een CDN. Lees het overzicht van optimalisatie en de afzonderlijke uitleg over cache.

• Werk WordPress, PHP, het thema en plug-ins eerst bij op staging.
• Verwijder ongebruikte plug-ins en overlappende cache- of minificatietools.
• Profileer databasequeries en trage externe aanroepen.
• Plan databaseonderhoud, maar verwijder revisies of metadata niet blindelings.
• Test na elke optimalisatie formulieren, zoeken, inloggen en het aankoopproces.

Ik bespreek een verstandige keuze van add-ons in de beste WordPress-plug-ins.

Wat je niet moet doen

• Download analytics- of advertentiescripts van anderen niet alleen voor een score naar je server; je kunt beveiligings- en functionele updates kwijtraken.
• Stel geen cache van een jaar in voor een bestand dat verandert zonder de naam ervan te versienummeren.
• Verwijder CSS of JavaScript uit een geautomatiseerd rapport niet zonder elke template te testen.
• Beoordeel succes niet alleen op basis van Lighthouse. Google zegt expliciet dat goede Core Web Vitals op zichzelf geen hoge rankings of een geweldige gebruikerservaring garanderen.
• Versnel een website niet door inhoud of functionaliteit die de klant nodig heeft te verbergen.

Een plan voor vier weken

1. Week 1: nulmeting van veldgegevens, laboratoriummetingen en een templatelijst.
2. Week 2: server, cache, omleidingen en de grootste LCP-resources.
3. Week 3: afbeeldingen, lettertypen, CSS, JavaScript en scripts van derden.
4. Week 4: regressietest, nieuwe metingen, monitoring en documentatie.

Leg voor elke wijziging de datum, URL, meetwaarde voor en na, functionele impact en terugdraaioptie vast. Houd ook conversieratio, formulierafronding en fouten bij; een snellere pagina die minder verkoopt is geen afgeronde optimalisatie.

Begin met het controleren van de technische basis en analytics van de website in een technische audit en GA4. Als je reparaties wilt prioriteren op impact en kosten, neem dan contact met me op via contact.