Je website sneller maken

Je maakt je website sneller door eerst te meten waar de vertraging precies zit met een snelheidstest en daarna de grootste boosdoeners aan te pakken, meestal afbeeldingen, lettertypen en overbodige scripts.

De valkuil is beginnen met aanpassen voor je weet wat het probleem is. Dat kost tijd en levert vaak weinig op. Meet eerst, kies dan gericht wat je aanpakt.

Eerst meten, dan pas aanpassen

1. Draai een test in PageSpeed Insights. Vul je URL in en bekijk zowel de labdata (een eenmalige test) als de velddata (echte metingen van bezoekers over de afgelopen weken).
2. Vertrouw op de velddata als bewijs van een probleem. De labscore kan slecht zijn terwijl bezoekers in de praktijk een snelle ervaring hebben en andersom.
3. Noteer de drie Core Web Vitals apart. Laadtijd van het grootste element (LCP), reactiesnelheid op interactie (INP) en visuele stabiliteit (CLS). Meer uitleg staat bij Core Web Vitals uitgelegd.
4. Bepaal welke vital het zwakst scoort. Elke vital heeft een andere oorzaak en dus een andere oplossing, dus meng de aanpak niet.

De grootste boosdoeners aanpakken

1. Comprimeer en verklein afbeeldingen. Grote productfoto’s of headerbeelden zijn vaak de belangrijkste oorzaak van een trage LCP. Gebruik een modern formaat en laad afbeeldingen pas als ze in beeld komen.
2. Beperk het aantal lettertypen en laad ze efficiënt. Elk extra lettertype is een extra verzoek aan de server voor de pagina volledig toont wat er staat.
3. Verwijder scripts die je niet meer gebruikt. Oude trackingscripts, ongebruikte plugins en dubbele widgets vertragen elke pagina waarop ze staan, ook als niemand ze meer nodig heeft.
4. Stel caching in op serverniveau. Een goed ingestelde cache zorgt dat terugkerende bezoekers de pagina sneller zien zonder dat alles opnieuw wordt opgebouwd.
5. Test na elke aanpassing opnieuw. Zo weet je welke wijziging daadwerkelijk verschil maakte, in plaats van tien dingen tegelijk te veranderen en te gissen wat werkte.

Prioriteren op basis van impact

1. Begin bij de pagina’s met het meeste verkeer. Een snelheidswinst op je meest bezochte pagina’s levert meer op dan dezelfde winst op een pagina die bijna niemand ziet.
2. Herhaal de meting na een paar weken. Velddata heeft tijd nodig om zich te vernieuwen, dus een test van vlak na de wijziging toont nog grotendeels de oude situatie.

Google gebruikt sinds maart 2024 reactiesnelheid op interactie (INP) als officiële Core Web Vital, met tweehonderd milliseconden als grens tussen goed en verbeterpunt. Dat verving de oudere meting van eerste reactietijd (FID), die alleen de allereerste interactie mat en niet het hele bezoek.

Veelgemaakte fouten bij snelheidsverbetering

• Alles tegelijk veranderen. Een nieuwe hostingpartij, een nieuw thema en tien plugins tegelijk uitschakelen levert misschien winst op, maar je weet niet meer wat de oorzaak van die winst was.
• Alleen op de labscore sturen. Een labtest draait onder gecontroleerde omstandigheden en zegt niet automatisch iets over wat je echte bezoekers ervaren. Neem de velddata altijd als leidend bewijs.
• Snelheidswinst boeken die niemand voelt. Een verbetering op een pagina met nauwelijks bezoekers levert weinig praktisch resultaat op, ook al staat het netjes in het rapport.
• Vergeten opnieuw te testen na een sitewijziging. Een nieuwe plugin of een aangepast thema kan zonder dat je het merkt een eerder opgeloste vertraging weer terugbrengen.

Een voorbeeld uit de praktijk

Een site met een zware header-afbeelding op de homepage kan alleen al door die ene afbeelding te comprimeren en later te laten laden, een merkbaar verschil zien in de laadtijd van het grootste element. Vaak zit het grootste knelpunt niet verspreid over tientallen kleine dingen, maar in twee of drie zware elementen die onevenredig veel gewicht toevoegen.

Wat je aan een developer overlaat

Niet elke verbetering hoef je zelf uit te voeren. Comprimeren van afbeeldingen en het opschonen van ongebruikte plugins kun je vaak zelf, maar aanpassingen aan hoe de server reageert, hoe scripts worden geladen of hoe caching op serverniveau werkt, vragen meestal om iemand met technische kennis van je specifieke platform. Leg in dat geval de resultaten van je meting voor, inclusief welke Core Web Vital het zwakst scoort, zodat de developer gericht kan werken in plaats van een algemene doorlichting te moeten doen.

Werk je met een bureau of freelancer, vraag dan altijd om een nieuwe meting na afronding. Een aanpassing die op papier klopt, moet zich ook terugzien in de velddata voor je hem als opgelost beschouwt.

Wil je naast snelheid ook de rest van de techniek van je site controleren, kijk dan naar hoe je een technische SEO-audit doet. Twijfel je waar je site nu staat, doe dan de gratis AI-zichtbaarheidscheck.

Heb je hier zelf de uren niet voor, dan is dat wat wij doen bij SEO en GEO uitbesteden.