Naar hoofdinhoud
TIEMAN.IT
Terug naar blog

WordPress website sneller maken: stappen op volgorde

Kevin Tieman6 min leestijd
  • wordpress
  • snelheid
  • core web vitals
  • seo

Meet eerst, want dan weet je wat traag is. Kijk daarna naar je hosting en caching, dan naar je afbeeldingen, dan naar plug-ins, thema en externe scripts. Dat is de volgorde van groot naar klein effect. Lukt het daarna nog niet, dan zit de rem vaak in het thema of de pagebuilder zelf.

Hoe meet je of je WordPress website echt traag is?

Begin met meten, anders repareer je het verkeerde. Er zijn twee soorten metingen. Labmetingen draaien een test op een nagebootst toestel. Veldmetingen zijn gegevens van echte bezoekers. Google kijkt naar veldmetingen, dus die tellen.

Gebruik PageSpeed Insights en het Core Web Vitals-rapport in Google Search Console. Dit zijn de drie meetwaarden die Google "goed" noemt, volgens web.dev (2026), gemeten bij het 75e percentiel van je bezoekers:

| Meetwaarde | Wat het meet | Goed als | |---|---|---| | LCP | Hoe snel het grootste stuk inhoud zichtbaar is | 2,5 seconden of minder | | INP | Hoe snel de pagina reageert op een klik of tik | 200 milliseconden of minder | | CLS | Hoeveel de layout verspringt tijdens het laden | 0,1 of minder |

Meet op je mobiel, niet alleen op je computer. Veel bezoekers komen via een telefoon, en daar is de site meestal het traagst. Wil je dit ook voor een webshop doen? Gebruik dan mijn webshop snelheidstest.

Schrijf je cijfers op voordat je iets verandert. Alleen met een beginmeting kun je zien of een ingreep echt hielp. Verander ook één ding tegelijk. Pas je tien dingen tegelijk aan en wordt de site sneller, dan weet je niet welke ingreep het deed. Wordt hij trager, dan weet je niet welke hem brak.

Wat is de eerste stap om een website sneller te maken: hosting en caching?

Dit heeft meestal het grootste effect. Als je server traag antwoordt, wacht de bezoeker al voordat er iets getoond wordt. Dat zit in de eerste stap van LCP: de tijd tot de browser de eerste byte van je pagina ontvangt.

Wat je kunt doen:

  • Zet paginacaching aan. Zonder cache bouwt WordPress elke pagina bij elk bezoek opnieuw op uit de database. Met cache krijgt de bezoeker een kant-en-klaar bestand. Dat verschil is vaak groot.
  • Kijk naar je hosting. Goedkope gedeelde hosting verdeelt één server over veel sites. Als een buurman druk is, ben jij traag. Een beter afgestelde server maakt een merkbaar verschil.
  • Gebruik een recente PHP-versie. WordPress zelf adviseert PHP 8.3 of hoger (wordpress.org, 2026). Oude versies zijn langzamer en niet meer veilig.

Check dit vóór je iets anders doet. Een perfect geoptimaliseerde pagina op een trage server blijft traag.

Hoe maak je afbeeldingen sneller zonder dat ze lelijk worden?

Afbeeldingen zijn meestal de grootste bestanden op je pagina, en vaak het LCP-element: het stuk dat Google meet. Pak ze in deze volgorde aan:

  1. Verklein ze tot de grootte die je echt toont. Een foto van 4.000 pixels breed in een vak van 800 pixels is verspilling.
  2. Gebruik moderne formaten zoals WebP of AVIF. Die zijn kleiner dan JPEG bij dezelfde kwaliteit.
  3. Laad de hoofdafbeelding bovenaan niet uitgesteld. Sinds WordPress 5.5 krijgen afbeeldingen standaard loading="lazy", wat de afbeelding pas laadt als hij in beeld komt. Recentere WordPress-versies slaan de eerste afbeelding vaak al over, maar controleer dat in de broncode van je pagina. Voor de afbeelding bovenaan wil je lazy loading juist niet, want web.dev adviseert: lazy-load je LCP-afbeelding nooit. Geef die afbeelding liever fetchpriority="high", zodat de browser hem als eerste ophaalt.
  4. Geef elke afbeelding een breedte en hoogte. Dan weet de browser hoeveel ruimte hij moet vrijhouden en verspringt de pagina niet (dat verbetert CLS).

Welke plug-ins, thema en scripts vertragen je site?

Elke plug-in voegt code toe. Niet elke plug-in is zwaar, maar een stapel van dertig is dat wel. Loop ze één voor één langs:

  • Verwijder wat je niet gebruikt. Uitgeschakeld is niet weg; de bestanden blijven staan. Echt verwijderen is ook veiliger.
  • Vervang zware plug-ins door lichtere of door een paar regels code als de functie klein is.
  • Let op externe scripts: chatwidgets, trackers, reviewkaders, kaarten. Elk daarvan laadt van een andere server en kan je INP laten zakken. Houd alleen wat geld oplevert.
  • Laad lettertypen zelf in plaats van van een externe dienst, en gebruik niet meer lettertypen dan nodig.

Test na elke wijziging. Soms haalt het weghalen van één plug-in meer winst dan lang finetunen.

Wanneer loop je tegen de grens van WordPress aan?

Soms is optimaliseren niet genoeg. Dat zie je aan deze signalen:

  • Je pagebuilder (de editor waarmee je pagina's sleept en neerzet) levert zoveel extra code dat zelfs een lege pagina traag is.
  • Je hebt tientallen plug-ins die elk een stuk functie dragen, en weghalen breekt iets.
  • Je thema is gebouwd om alles te kunnen, en laadt dus ook alles.
  • Je doet alle stappen hierboven en blijft onder de drempel hangen.

Dan zit het probleem in de bouwwijze, niet in de instellingen. Een site die op maat is gebouwd laadt alleen wat die pagina nodig heeft. Ik werk dagelijks aan een Magento 2-webshop met ruim 3.400 producten en 328 actieve modules. De mobiele laadtijd (LCP) stond daar in de labmeting op 14 tot 16 seconden. Bij echte bezoekers meet Google nu 2,14 seconden. Dat lukte niet met één trucje, maar met meten, stap voor stap de grootste vertraging wegnemen en opnieuw meten. Dezelfde werkwijze gebruik ik voor snelheidsoptimalisatie van andere sites.

Wil je weg van WordPress? Mijn WordPress-migratie neemt je inhoud mee naar een snelle, op maat gebouwde site. Maar ik zeg het eerlijk: veel WordPress-sites zijn met een paar goede ingrepen snel genoeg. Migreren is pas zinvol als je tegen de grens aanloopt.

Veelgestelde vragen

Wat is een goede laadtijd voor een website?

Google noemt een LCP van 2,5 seconden of minder goed, gemeten bij echte bezoekers op het 75e percentiel (web.dev, 2026). Streef daarnaast naar een INP onder 200 milliseconden en een CLS onder 0,1. Hoe sneller je daaronder zit, hoe beter.

Helpt een cache-plug-in genoeg?

Vaak helpt het veel, maar niet altijd genoeg. Cache lost een trage serverreactie op, niet een te zware pagina. Als je afbeeldingen groot zijn of je thema veel onnodige code laadt, blijft de pagina na het cachen nog zwaar.

Verbetert een snelle website mijn Google-positie?

Snelheid is een van de dingen die meetellen, maar goede inhoud blijft belangrijker. Een snelle pagina met zwakke inhoud rankt niet vanzelf. Een trage pagina met sterke inhoud verliest wel bezoekers voordat ze lezen.

Kun je mijn WordPress-site voor me versnellen?

Ja. Ik meet eerst, laat je zien wat de grootste rem is en pak die aan. Wat het kost, hangt af van je site en je hosting, dus dat stel ik vast na een eerste gesprek. Neem contact op met je adres en ik kijk mee.

Klaar om te beginnen?

Neem contact op voor een vrijblijvend gesprek over de mogelijkheden.