Een snellere website in zeven stappen

Een snellere website vraagt meer dan een caching plugin…

Herken je het probleem? Je website ziet er uitstekend uit. Je bent er trots op. Of je hem nu zelf hebt gebouwd, je nerdy neefje het hebt laten doen, of je een professioneel bedrijf aan het werk hebt gezet, doet er even niet toe… maar de website geeft je een warm gevoel, wanneer je er naar kijkt.

Maar wanneer je door de site heen klikt, gaat alles toch wel bijzonder traag. Het zou sneller moeten zijn. Bezoekers haken halverwege af en Google PageSpeed geeft je waarschuwingen die niet altijd begrijpelijk zijn.

Welke caching plugin moet ik gebruiken?

Een vraag die ik regelmatig te horen krijg is ‘Welke caching plugin moet ik gebruiken’. En hoewel het zeker verstandig is gebruik te maken van caching mogelijkheden, is het niet zomaar mogelijk om je probleem direct met een caching plugin op te lossen. Vergelijk de caching plugin met antibiotica… er zijn veel problemen die je er mee op kan lossen, maar beslist niet alle!

Goede performance is niet het resultaat van één truc, maar van het weloverwogen doorlopen van de zeven stappen genoemd in dit blogartikel.

Nog een kanttekening bij WordPress

Ik heb in talloze blogartikelen verteld waarom WordPress een ‘zware applicatie’ is en veel van het systeem vergt. Door de jaren heen hebben de makers van WordPress niet stil gezeten. Op het momen dat ik dit schrijf is WordPress 7.0 de ‘gangbare versie’ en duurt het niet lang voordat versie 7.1 uitkomt. WordPress 6.8 introduceerde ‘speculative loading’ en verbeteringen rond onder meer de query caching (het opslaan van recente resultaten van database-vragen). voor WordPress 7.1 staat alweer een verdere verbetering van speculative loading gepland wanneer zowel object caching als page caching aanwezig zijn. Dus ook binnen WordPress zelf wordt hard gewerkt aan een core die in staat is tot betere prestaties.

1. Meet eerst wat werkelijk traag is

Een website optimaliseren zonder eerst te meten is eigenlijk hetzelfde als medicijnen nemen zonder diagnose. Je doet misschien iets wat goed klinkt, maar je weet niet of je het juiste probleem oplost.

Bij WordPress gebeurt dit vaak. Er wordt een cache-plugin geïnstalleerd, afbeeldingen worden nog een keer gecomprimeerd of er wordt een extra optimalisatie-plugin toegevoegd. Soms helpt dat, maar soms wordt de website er juist instabieler van. De echte oorzaak kan namelijk ergens anders liggen: bij de hosting, een zwaar thema, externe scripts, een trage databasequery, een te grote hero-afbeelding of JavaScript dat de pagina blokkeert.

Daarom begint snelheidsoptimalisatie altijd met meten. Niet om een mooi rapport te krijgen, maar om te begrijpen waar de vertraging werkelijk ontstaat.

PageSpeed Insights – Wat wordt er mee gemeten?

PageSpeed Insights is een gratis tool van Google waarmee je een specifieke pagina kunt analyseren. De tool geeft een aparte beoordeling voor mobiel en desktop en laat zien waar de belangrijkste verbeterpunten zitten. Google omschrijft PageSpeed Insights als een tool die de gebruikerservaring van een pagina op mobiele en desktopapparaten rapporteert en suggesties geeft voor verbetering.

Labdata en fielddata

Binnen PageSpeed Insights worden twee soorten data gemeten: Labdata en fielddata. Beide soorten van gegevens hebben ieder hun eigen nut.

Fielddata zijn de gegevens die tonen hoe echte bezoekers je website ervaren. Dit zijn natuurlijk belangrijke gegevens, want dat zijn de gegevens die laten zien hoe bezoekers je site werkelijk ervaren. Maar voor een deel zijn het ook juist de gegevens, waar je mogelijk weinig aan kan doen. Het is een optelsom van zaken waar je wel invloed op kan hebben (snelle server, gecomprimeerd aanleveren van data, snelle website) en zaken waar je geen of minder invloed op hebt (snelheid van het device, hoeveelheid geheugen, werkelijke verbindingssnelheid). Het geeft je wel een goede indicatie wat de belangrijkste bottlenecks zijn, wat je aan moet pakken om een groot deel van het snelheidsprobleem op te lossen

Labdata helpen je met het testen van paginas. Stel, je hebt met de fielddata gevonden dat een bepaalde pagina traag is en de grote boosdoener is de laadtijd van de afbeeldingen. Jij hebt alle denkbare maatregelen genomen om de pagina’s sneller, en vanuit browser cache, waar mogelijk, te laden. Het probleem met ‘fielddata’ is dat het een gemiddelde van een langere periode betreft. Het zal dagen, zo geen weken, duren voor je ook maar iets van een verandering zal zien. Binnen de labdata zie je echter deze verandering direct. En hoewel het je geen ‘vaste’ voorspelling geeft voor de toekomst, geeft het wel een indicatie of de genomen maatregelen hebben geholpen of niet.

Google Search Console: Kijken naar je gehele website

PageSpeed Insights is handig voor het testen van één pagina. Google Search Console kijkt breder naar je website als geheel. In Search Console kun je onder andere zien hoe je website presteert in Google Zoeken, welke zoekopdrachten bezoekers opleveren en of Google technische problemen ziet. Google beschrijft Search Console als een verzameling tools en rapporten om zoekverkeer en prestaties te meten en problemen op te lossen.

Voor snelheid is vooral het Core Web Vitals-rapport interessant. Dit rapport groepeert pagina’s op basis van ervaringen van echte gebruikers. Je ziet dus niet alleen dat één URL traag is, maar ook of een hele groep vergelijkbare pagina’s hetzelfde probleem heeft. Denk aan blogartikelen, productpagina’s of categoriepagina’s.

Dat is belangrijk, omdat WordPress-sites vaak met templates werken. Als één productpagina traag is door de manier waarop de template is opgebouwd, is de kans groot dat veel andere productpagina’s hetzelfde probleem hebben.

Core Web Vitals (LCP, INP en CLS) in bijna begrijpelijke taal…

Core Web Vitals zijn drie metingen waarmee Google probeert te beoordelen of een pagina prettig werkt voor bezoekers. Het Core Web Vitals-rapport in Search Console is gebaseerd op LCP, INP en CLS, gemeten met echte gebruikersdata.

LCP – Largest Contentful Paint

LCP gaat over laden. Simpel gezegd: hoe lang duurt het voordat het belangrijkste zichtbare onderdeel van de pagina geladen is? Vaak is dat de grote afbeelding bovenaan, een titelblok of een belangrijk contentvlak. Google adviseert dat LCP binnen 2,5 seconden plaatsvindt.

INP – Interaction to Next Paint

INP gaat over reageren. Hoe snel reageert de pagina wanneer een bezoeker klikt, tikt of iets invult? Een pagina kan er snel uitzien, maar alsnog traag aanvoelen als knoppen, menu’s of formulieren vertraagd reageren. Google adviseert een INP van minder dan 200 milliseconden.

CLS – Cumulative Layout Shift

CLS gaat over visuele stabiliteit. Verschuift de layout terwijl de pagina laadt? Denk aan tekst die ineens naar beneden springt omdat er later nog een afbeelding, advertentie, cookiebar of ingesloten element verschijnt. Een lage CLS-score betekent dat de pagina rustig en voorspelbaar blijft.

Samen geven deze drie metingen een beter beeld dan alleen “de pagina laadt in zoveel seconden”. Ze kijken naar laden, reageren en stabiliteit. Dat zijn precies de dingen die bezoekers merken.

Staar je niet blind op een 100/100 score!

Een perfecte PageSpeed-score klinkt aantrekkelijk, maar is niet altijd nodig en ook niet altijd realistisch. Zeker niet bij websites met WooCommerce, formulieren, marketingtools, video’s, kaarten, boekingssystemen of leeromgevingen.

Het doel is niet om een rapport mooi groen te krijgen. Het doel is een website die voor echte bezoekers snel en prettig werkt.

Soms levert het najagen van een perfecte score zelfs verkeerde keuzes op. Je kunt bijvoorbeeld scripts extreem uitstellen, waardoor de score stijgt, maar een formulier, menu of winkelwagen minder betrouwbaar werkt. Of je verwijdert visuele elementen die belangrijk zijn voor vertrouwen en conversie, alleen om een paar punten te winnen.

Een goede optimalisatie zoekt daarom balans. De website moet snel zijn, maar ook blijven doen waarvoor hij bedoeld is: informeren, verkopen, aanvragen binnenhalen, cursussen tonen of klanten ondersteunen.

En nu even een praktijk voorbeeld:

Stel: een homepage scoort op desktop prima. De eigenaar test de website op kantoor, op een snelle laptop en via een goede internetverbinding. Alles lijkt soepel te werken.

Maar in PageSpeed Insights blijkt de mobiele score tegen te vallen. De oorzaak zit niet in één groot probleem, maar in een combinatie van factoren:

• De hero-afbeelding is veel groter dan nodig
• Er worden meerdere JavaScript-bestanden geladen
• Een slider voegt extra CSS en scripts toe
• Analytics, een Facebook-pixel en een chatwidget laden direct mee
• Het belangrijkste zichtbare element verschijnt daardoor te laat

In dat geval heeft het weinig zin om zomaar een extra plugin te installeren. De juiste aanpak is eerst vaststellen welk onderdeel de grootste vertraging veroorzaakt. Misschien moet de hero-afbeelding kleiner en beter geprioriteerd worden. Misschien moeten externe scripts later laden. Misschien moet de slider verdwijnen. Misschien ligt het probleem bij de hosting of caching.

Meten voorkomt dat je gokt. En juist daardoor kun je gerichter optimaliseren.

2. Begin bij hosting en serverinstellingen

Na het meten komt de technische basis aan de beurt: de hosting. Dat klinkt misschien minder spannend dan een nieuwe optimalisatie-plugin, maar bij WordPress maakt de serveromgeving enorm veel verschil.

WordPress is namelijk geen verzameling losse HTML-pagina’s die simpelweg vanaf de server worden opgehaald. WordPress is dynamisch. Bij iedere pagina die niet uit de cache komt, moet PHP aan het werk, wordt de database aangesproken en worden thema’s, plugins, instellingen en soms externe koppelingen geladen.

Dat is precies waarom hosting zo belangrijk is. Een trage server kan niet volledig worden gerepareerd met een plugin. Een cache-plugin kan helpen, maar zodra een pagina niet uit de cache komt, bijvoorbeeld bij een winkelwagen, checkout, ledenomgeving, zoekopdracht of ingelogde gebruiker, moet de server het echte werk doen.

Goede hosting is daarom niet alleen opslagruimte. Het is de technische ondergrond waarop WordPress soepel, veilig en betrouwbaar moet kunnen draaien.

Waarom goedkope hosting altijd duur uitpakt…

Goedkope algemene hosting lijkt aantrekkelijk. Voor een paar euro per maand staat je website online, je krijgt e-mailadressen, wat opslagruimte en vaak een eenvoudig controlepaneel. Voor een kleine statische site kan dat voldoende zijn. Voor een serieuze WordPress-site ligt dat anders.

Bij goedkope hosting deel je vaak servercapaciteit met veel andere websites. Dat hoeft niet altijd een probleem te zijn, maar het betekent wel dat je afhankelijk bent van hoe druk die server is, hoeveel geheugen beschikbaar is en hoe goed de hostingpartij WordPress heeft ingericht.

Een WordPress-site heeft nu eenmaal meer nodig dan alleen schijfruimte. PHP moet snel genoeg reageren, de database moet vlot bereikbaar zijn, caching moet goed zijn ingericht en piekmomenten moeten kunnen worden opgevangen. Zeker bij WooCommerce, online leeromgevingen, boekingssites of websites met veel plugins merk je het verschil snel.

Een trage hostingomgeving kan allerlei klachten veroorzaken:

• Pagina’s laden traag, vooral op mobiel
• Het WordPress-dashboard voelt log aan
• WooCommerce-pagina’s reageren langzaam
• Updates duren lang of lopen vast
• Bezoekers merken wisselende laadtijden
• Optimalisatie-plugins leveren minder winst op dan verwacht

Het vervelende is dat deze problemen niet altijd direct als hostingprobleem worden herkend. Vaak wordt eerst gezocht naar een cache-plugin, een image optimizer of een andere technische truc. Maar als de server onvoldoende presteert, blijf je optimaliseren bovenop een zwakke basis.

PHP, database en caching als fundament

Een moderne WordPress-omgeving begint bij actuele servercomponenten. WordPress adviseert momenteel PHP 8.3 of hoger, MariaDB 10.6 of hoger of MySQL 8.0 of hoger, plus HTTPS-ondersteuning. Dat zijn geen details voor systeembeheerders, maar praktische voorwaarden voor snelheid, veiligheid en toekomstbestendigheid.

PHP is de programmeertaal waarin WordPress grotendeels is gebouwd. Iedere dynamische pagina moet door PHP worden verwerkt. Een moderne PHP-versie is meestal sneller, veiliger en beter ondersteund dan een oude versie. Draait een website nog op een verouderde PHP-versie, dan kan dat zowel performance- als beveiligingsproblemen geven.

De database is de plek waar WordPress de inhoud, instellingen, gebruikers, bestellingen, producten en veel plugin-data bewaart. Bij iedere niet-gecachete pagina worden databasegegevens opgehaald. Een goede databaseversie en goede databaseconfiguratie zijn daarom belangrijk. Vooral bij WooCommerce, LMS-systemen en grotere sites kan databaseprestatie een groot verschil maken.

HTTPS, HTTP/2 en HTTP/3

HTTPS is inmiddels de normale standaard voor websites. Het zorgt voor een versleutelde verbinding tussen bezoeker en website. Voor formulieren, webshops, inlogpagina’s en klantgegevens is dat vanzelfsprekend, maar ook voor gewone informatieve websites is HTTPS belangrijk.

Daarnaast speelt het protocol waarmee bestanden worden geladen een rol. HTTP/2 en HTTP/3 kunnen ervoor zorgen dat browsers efficiënter meerdere bestanden tegelijk ophalen. Dat is vooral relevant voor WordPress-sites, omdat een pagina vaak bestaat uit HTML, CSS, JavaScript, afbeeldingen, fonts en externe scripts.

Dit betekent niet dat HTTP/3 op zichzelf een trage website ineens snel maakt. Maar op een moderne hostingomgeving hoort ondersteuning voor actuele webstandaarden wel bij de basis.

Wanneer shared hosting genoeg is en wanneer een VPS logischer wordt

Shared hosting is niet automatisch slecht. Voor een kleinere bedrijfswebsite, een informatieve site of een startende WordPress-site kan goede managed shared hosting prima zijn. Zeker wanneer de omgeving goed geïsoleerd is, server-level caching biedt, voldoende resources heeft en actief wordt gemonitord.

Shared hosting wordt minder logisch wanneer de website zwaarder of bedrijfskritischer wordt. Denk aan situaties zoals:

• Een WooCommerce-webshop met veel producten of bestellingen
• Een online leeromgeving met ingelogde cursisten
• Veel maatwerkfunctionaliteit
• Veel bezoekerspieken
• Zware koppelingen met externe systemen
• Hogere eisen aan veiligheid, performance of beschikbaarheid
• Behoefte aan specifieke serverinstellingen

In zulke gevallen kan een VPS logischer zijn. Niet omdat een VPS automatisch sneller is, maar omdat de omgeving gerichter kan worden ingericht. Je hebt meer controle over PHP-instellingen, caching, geheugen, databaseconfiguratie, beveiliging en monitoring.

De keuze is dus niet simpelweg “shared hosting is goedkoop en VPS is goed”. De juiste vraag is: wat heeft deze website nodig om betrouwbaar en snel te functioneren?

Goede hosting is meer dan opslagruimte

Bij WordXPression wordt hosting daarom niet gezien als een los product met wat schijfruimte en dataverkeer. Goede hosting is een beheerde technische basis voor de website of webapplicatie.

Daarbij gaat het onder andere om:

• Isolatie per website, zodat problemen op de ene site niet zomaar doorwerken naar een anderemonitoring, zodat storingen en afwijkingen sneller zichtbaar worden
• Server-level caching en CDN waar dat zinvol is
• Moderne PHP- en databaseversies
• Voldoende geheugen voor WordPress, WooCommerce en plugins
• Staging, zodat grotere wijzigingen eerst getest kunnen worden
• Backups en herstelmogelijkheden
• Een omgeving die past bij het doel van de website

Dat is een wezenlijk verschil met algemene budgethosting. Daar ligt de nadruk vaak op zoveel mogelijk websites tegen een zo laag mogelijke prijs. Bij managed WordPress-hosting ligt de nadruk op stabiliteit, snelheid, veiligheid en beheerbaarheid.

Lees ook meer over het aanbod van de verschillende hostingmogelijkheden van WordXPression. Twee andere hostingpartijen die ik zeker kan aanbevelen zijn SiteGround en Hostinger.

3. Richt caching goed in

Caching is één van de bekendste manieren om een WordPress-website sneller te maken. Toch is het ook één van de meest verkeerd begrepen onderdelen van website-optimalisatie.

In eenvoudige taal betekent caching: niet alles telkens opnieuw doen als dat niet nodig is.

Een WordPress-pagina wordt normaal gesproken dynamisch opgebouwd. WordPress haalt informatie uit de database, laadt het thema, voert plugins uit, verwerkt instellingen en maakt daar uiteindelijk een HTML-pagina van die de bezoeker te zien krijgt. Dat kost tijd en servercapaciteit.

Als de inhoud van die pagina niet steeds verandert, is het zonde om dat hele proces bij iedere bezoeker opnieuw uit te voeren. Met caching wordt een eerder opgebouwde versie tijdelijk bewaard. De volgende bezoeker krijgt die opgeslagen versie te zien. Dat is meestal veel sneller.

Maar caching is geen magische oplossing voor alle performanceproblemen. Het is vooral een slimme manier om onnodig werk te voorkomen.

Wat doet een cache-plugin?

Een cache-plugin helpt WordPress om bepaalde onderdelen tijdelijk op te slaan. De bekendste vorm is page caching. Daarbij wordt een complete pagina bewaard nadat WordPress die één keer heeft opgebouwd.

Zonder page cache gebeurt er bij een bezoek ongeveer dit:

1. De bezoeker vraagt een pagina op
2. WordPress start
3. PHP verwerkt de aanvraag
4. De database wordt aangesproken
5. Thema en plugins worden geladen
6. De pagina wordt opgebouwd
7. De bezoeker krijgt het resultaat te zien.

Met page cache kan een groot deel van dit proces worden overgeslagen. De server levert dan direct een opgeslagen HTML-versie van de pagina terug. Vooral bij gewone informatiepagina’s, blogartikelen en landingspagina’s kan dit veel snelheidswinst opleveren.

Een goede cache-plugin doet vaak meer dan alleen page caching. Denk aan browser caching, optimalisatie van CSS en JavaScript, lazy loading, preloaden van cache en soms integratie met een CDN. Toch moet je voorzichtig zijn met het inschakelen van allerlei opties tegelijk. Niet iedere optimalisatie past bij iedere website.

Een cache-plugin kan een website sneller maken, maar kan ook problemen veroorzaken wanneer hij verkeerd staat ingesteld. Denk aan formulieren die niet goed werken, winkelwagens die verkeerde informatie tonen of wijzigingen die niet zichtbaar worden omdat een oude versie van de pagina nog in de cache staat.

Waarom server-cache meestal sterker is dan alleen plugin-cache

Caching kan op verschillende plekken gebeuren. Een cache-plugin werkt binnen WordPress. Server-cache werkt een laag daaronder, dichter bij de webserver.

Dat verschil is belangrijk. Als caching pas via WordPress wordt geregeld, moet WordPress vaak nog gedeeltelijk worden geladen voordat de cache kan worden uitgeserveerd. Bij server-level caching kan de server soms al vóór WordPress reageren. Dat is efficiënter en meestal sneller.

Daarom is caching op hostingniveau vaak sterker dan alleen caching via een plugin. Zeker wanneer de hostingomgeving specifiek voor WordPress is ingericht.

Je kunt caching zien als meerdere lagen die samenwerken.

Page cache
De volledige HTML-output van een pagina wordt tijdelijk opgeslagen. Dit is vooral nuttig voor pagina’s die voor iedere bezoeker hetzelfde zijn, zoals blogartikelen, dienstenpagina’s en veel gewone landingspagina’s.

Browser cache
De browser van de bezoeker bewaart bestanden zoals afbeeldingen, CSS, JavaScript en fonts tijdelijk lokaal. Bij een volgend bezoek hoeven die bestanden niet opnieuw te worden gedownload. Dat maakt vervolgbezoeken sneller.

Object cache
Bij object caching worden bepaalde database-resultaten tijdelijk opgeslagen. WordPress en plugins hoeven daardoor niet steeds dezelfde databasevragen opnieuw te stellen. Voor grotere of dynamische websites kan dit veel verschil maken.

Een bekende oplossing hiervoor is Redis. Redis bewaart gegevens in het geheugen, waardoor veelgebruikte informatie sneller beschikbaar is dan wanneer die telkens uit de database moet komen. Dit is vooral interessant voor WooCommerce, ledenomgevingen, online leerplatformen en websites met veel ingelogde gebruikers.

CDN-cache
Een CDN, oftewel Content Delivery Network, kan statische bestanden zoals afbeeldingen, CSS en JavaScript via servers op meerdere locaties aanbieden. Daardoor worden bestanden sneller geleverd aan bezoekers, vooral wanneer zij zich verder van de oorspronkelijke server bevinden.

Een CDN is niet altijd nodig voor een kleine lokale website, maar kan wel zinvol zijn bij websites met veel media, veel verkeer of bezoekers uit verschillende regio’s.

Samen zorgen deze lagen ervoor dat de server minder vaak hetzelfde werk hoeft te doen. De kunst is om ze goed op elkaar af te stemmen.

Welke pagina’s mag je juist niet zomaar cachen?

Niet iedere pagina mag agressief worden gecachet. Dat is vooral belangrijk bij websites waar bezoekers persoonlijke of actuele informatie zien.

Een gewone informatiepagina mag meestal behoorlijk stevig worden gecachet. De tekst en afbeeldingen zijn voor iedereen hetzelfde. Of bezoeker A of bezoeker B de pagina bekijkt, maakt niet uit.

Bij WooCommerce ligt dat anders. De winkelwagen, checkout en accountpagina’s zijn persoonlijk en dynamisch. Daar wil je absoluut niet dat een bezoeker per ongeluk een oude versie ziet, of erger nog: informatie die bij een andere sessie hoort.

Daarom moeten dit soort pagina’s meestal worden uitgesloten van page caching:

• winkelwagen
• checkout
• mijn account
• betaalpagina’s
• pagina’s met persoonlijke gegevens
• ingelogde gebruikersomgevingen
• ledenpagina’s
• formulieren met dynamische tokens
• dashboards
• boekingsomgevingen
• leeromgevingen waar voortgang wordt bijgehouden

Ook zoekresultaten, filters en productpagina’s met dynamische voorraad- of prijsinformatie vragen extra aandacht. Soms kunnen ze deels worden gecachet, maar dan moet goed worden getest of alles betrouwbaar blijft werken.

Bij WooCommerce is caching dus altijd een kwestie van balans. Productpagina’s, categoriepagina’s en informatieve pagina’s kunnen vaak prima worden versneld. De checkout moet vooral betrouwbaar zijn.

Caching kan problemen verhullen

Caching maakt een website sneller doordat minder werk opnieuw hoeft te worden gedaan. Maar dat betekent ook dat caching soms verbergt hoe traag de website eigenlijk is.

Zolang de cache warm is, lijkt alles snel. De pagina’s zijn al opgebouwd en liggen klaar. Maar zodra de cache wordt geleegd, vernieuwd of omzeild, moet WordPress alles opnieuw opbouwen. Dan komen de onderliggende problemen weer tevoorschijn.

Dat zie je bijvoorbeeld bij websites met:

• een zwaar thema
• te veel plugins
• veel externe scripts
• trage databasequeries
• slecht gebouwde templates
• grote hoeveelheden autoloaded options
• slecht ingestelde WooCommerce-functionaliteit
• hosting met te weinig servercapaciteit

In zulke gevallen geeft caching een prettige snelheidswinst, maar lost het de oorzaak niet op. De website voelt snel zolang bezoekers een gecachete pagina krijgen. Maar ingelogde gebruikers, beheerders, checkoutbezoekers of bezoekers na een cacheverversing merken alsnog vertraging.

Daarom moet caching nooit de enige optimalisatiestap zijn. Het is een belangrijk onderdeel van een snelle website, maar geen vervanging voor goede hosting, nette code, beperkte plugin-ballast en een gezonde database.

4. Pak afbeeldingen en media aan

De belangrijkste performance vreter op een website is vaak een verkeerd gebruik van afbeeldingen. Dat geldt zeker voor WordPress-sites, waar afbeeldingen makkelijk rechtstreeks vanuit de mediabibliotheek op pagina’s worden geplaatst. Dat is handig, maar het zorgt er ook voor dat er vaak veel te grote bestanden online staan.

Vooral hero-afbeeldingen, sliders, grote PNG-bestanden en onnodig grote uploads kunnen een website merkbaar vertragen. Ze hebben direct invloed op de eerste indruk van de bezoeker. Als het belangrijkste beeld bovenaan de pagina langzaam verschijnt, voelt de hele website traag aan.

Dat zie je ook terug in de Core Web Vitals. De hero-afbeelding is vaak het grootste zichtbare element boven de vouw en kan daardoor bepalend zijn voor de LCP-score. LCP staat voor Largest Contentful Paint: het moment waarop het belangrijkste zichtbare onderdeel van de pagina geladen is.

Een afbeelding optimaliseren betekent dus niet alleen “het bestand kleiner maken”. Het betekent vooral: het juiste bestand op de juiste plek gebruiken.

Waarom de hero-afbeelding zo belangrijk is

De hero-afbeelding is vaak het eerste grote visuele element dat een bezoeker ziet. Op veel websites staat bovenaan een brede afbeelding met daarover een titel, intro of call-to-action. Dat ziet er mooi uit, maar technisch is het ook een gevoelig punt.

Als de hero-afbeelding te groot is, verkeerd wordt geladen of pas laat beschikbaar komt, moet de bezoeker wachten voordat de pagina echt compleet oogt. Daardoor voelt de website trager, zelfs wanneer de rest van de pagina redelijk snel is.

Een veelgemaakte fout is dat dezelfde enorme afbeelding voor alle schermformaten wordt gebruikt. Een bestand van 4000 of 5000 pixels breed wordt dan ook naar mobiele bezoekers gestuurd, terwijl hun scherm dat formaat helemaal niet nodig heeft. De browser schaalt de afbeelding wel kleiner, maar het bestand is dan al gedownload.

Dat is alsof je een vrachtwagen laat komen voor een pakketje dat door de brievenbus past.

Voor hero-afbeeldingen moet je dus bewust kiezen:

• Gebruik een formaat dat past bij de werkelijke weergave
• Zorg dat het bestand sterk genoeg gecomprimeerd is
• Gebruik moderne formaten waar mogelijk
• Voorkom dat de hero-afbeelding onnodig wordt gelazyload
• Geef de belangrijkste afbeelding prioriteit wanneer dat nodig is

Lazy loading is handig voor afbeeldingen die verderop op de pagina staan, maar bij een hero-afbeelding kan het juist averechts werken. De afbeelding moet immers direct zichtbaar zijn. Wanneer de browser die afbeelding te laat ophaalt, verslechtert de eerste indruk en vaak ook de LCP-score.

Voor afbeeldingen buiten beeld is lazy loading juist wél verstandig. Die hoeven pas geladen te worden zodra de bezoeker in de buurt komt.

WebP, AVIF en JPEG: wanneer gebruik je wat?

Er zijn meerdere afbeeldingsformaten die je op een website kunt gebruiken. Niet ieder formaat is even geschikt voor iedere situatie.

JPEG is nog steeds heel bruikbaar voor foto’s, zeker wanneer je een goede balans zoekt tussen kwaliteit en bestandsgrootte. Voor veel blogafbeeldingen, sfeerbeelden en hero’s kan een goed gecomprimeerde JPEG prima zijn.

WebP is in veel gevallen efficiënter dan JPEG en PNG. Het levert vaak kleinere bestanden op bij vergelijkbare kwaliteit. Voor WordPress-websites is WebP inmiddels een logische standaardkeuze wanneer de hosting, browserondersteuning en optimalisatieworkflow dit goed ondersteunen.

AVIF kan nog kleinere bestanden opleveren dan WebP, vooral bij foto’s en complexe beelden. Wel moet je goed testen of de kwaliteit, kleurweergave en browserondersteuning in jouw situatie goed uitpakken. In veel moderne optimalisatiestrategieën is AVIF interessant, maar WebP blijft vaak de praktischere middenweg.

PNG is vooral nuttig voor afbeeldingen met transparantie, scherpe lijnen of eenvoudige grafische elementen. Voor grote foto’s is PNG meestal ongeschikt, omdat de bestanden veel te zwaar worden. Een grote PNG als hero-afbeelding is bijna altijd een slecht idee.

SVG is geschikt voor logo’s, iconen en eenvoudige illustraties, omdat het schaalbaar is en vaak heel licht blijft. Gebruik SVG wel zorgvuldig, zeker wanneer bestanden van externe bronnen komen.

De praktische keuze is meestal:

• Foto’s: WebP, AVIF of goed gecomprimeerde JPEG.
• Grote hero-afbeeldingen: WebP of geoptimaliseerde JPEG, eventueel AVIF
• Iconen en eenvoudige illustraties: SVG
• Transparante grafische elementen: PNG of SVG
• Screenshots: vaak WebP of JPEG, afhankelijk van scherpte en kleurvlakken

Het belangrijkste is niet dat je dogmatisch één formaat kiest. Het belangrijkste is dat het formaat past bij de afbeelding en de plek waar die wordt gebruikt.

5. Verminder plugin- en pagebuilder ballast

Plugins zijn één van de sterke kanten van WordPress. Je kunt snel functionaliteit toevoegen zonder alles zelf te bouwen. Een formulier, SEO-instellingen, beveiliging, caching, sliders, pop-ups, koppelingen met nieuwsbrieven, analytics, webshops, leeromgevingen: voor bijna alles bestaat wel een plugin.

Dat is handig, maar het heeft ook een keerzijde.

Iedere plugin kan iets toevoegen aan de voorkant of achterkant van je website. Denk aan extra CSS, JavaScript, databasequeries, instellingen, cronjobs, externe verbindingen of scripts die op iedere pagina worden geladen. Dat betekent niet dat plugins slecht zijn. Integendeel: goede plugins kunnen veel werk besparen en een website juist beter maken.

Maar elke plugin moet wel een duidelijke reden hebben.

De belangrijkste vraag is daarom niet: “Kan deze plugin dit?”
De betere vraag is: “Is deze plugin de beste manier om dit te doen?”

Niet het aantal plugins, maar de impact telt

Er wordt vaak gezegd dat je zo min mogelijk plugins moet gebruiken. Dat is op zich begrijpelijk, maar het is te simpel. Tien lichte, goed gebouwde plugins kunnen minder impact hebben dan één zware plugin die op elke pagina veel scripts, stijlen en databasevragen toevoegt.

Het gaat dus niet alleen om het aantal plugins, maar vooral om de impact.

Een plugin die alleen iets doet in het WordPress-dashboard hoeft de voorkant van de website nauwelijks te vertragen. Een plugin die op iedere pagina JavaScript, CSS en externe scripts laadt, kan juist veel invloed hebben op de laadtijd.

Daarom is het verstandig om regelmatig kritisch naar de pluginlijst te kijken:

• Wordt deze plugin nog gebruikt?
• Is er functionaliteit die overlapt met een andere plugin?
• Laadt de plugin bestanden op pagina’s waar dat niet nodig is?
• Is de plugin nog actief onderhouden?
• Is de functionaliteit belangrijk genoeg voor de technische kosten?
• Kan hetzelfde eenvoudiger met het thema, Gutenberg, maatwerk of serverinstellingen?

Ongebruikte plugins kun je beter verwijderen dan alleen deactiveren. Een gedeactiveerde plugin vertraagt de voorkant meestal niet direct, maar blijft wel onderdeel van het beheer. Bovendien kunnen oude plugins later vergeten worden, terwijl ze nog steeds bestanden of databasegegevens achterlaten.

Ook overlappende functionaliteit is een bekend probleem. Denk aan meerdere plugins die iets doen met SEO, scripts, formulieren, caching, beveiliging of optimalisatie. Soms werken ze elkaar niet direct tegen, maar ze maken de website wel complexer. En hoe complexer de website, hoe lastiger het wordt om performanceproblemen te vinden.

Snippets in plaats van plugins

Iedere plugin heeft enige overhead. Wanneer je een plugin met een groot aantal functies installeert, terwijl je slechts één van deze functies nodig hebt, dan kan dit als snel leiden tot een zware ‘codeoverhead’ van diverse plugins. Soms is het mogelijk om zo’n aanpassing als aparte ‘code snippet’ op te nemen. Hier op de WordXPression website tref je een groot aantal van deze code snippets aan. Op de lange duur is het vaak voordeliger een WordPress professional enkele codesnippets te laten ontwikkelen voor je site, dan voor iedere kleine aanpassing een plugin met overhead te installeren. De WordXPression Support Strippenkaart is een prima oplossing hiervoor.

Pagebuilders: krachtig, maar niet gratis

Pagebuilders zoals Elementor maken het mogelijk om snel visueel aantrekkelijke pagina’s te bouwen. Zeker voor ondernemers, marketeers en redacteuren kan dat waardevol zijn. Je kunt layouts maken zonder direct in code te werken en pagina’s relatief eenvoudig aanpassen.

Maar ook hier geldt: gemak heeft een technische prijs.

Een pagebuilder voegt vaak extra HTML, CSS en JavaScript toe. Dat hoeft geen probleem te zijn bij een goed ingerichte website, maar het kan wel oplopen. Zeker wanneer pagina’s veel secties, animaties, sliders, pop-ups, formulieren en dynamische widgets bevatten.

Daarom moet je per website kijken wat logisch is.

Een eenvoudige bedrijfswebsite met een paar landingspagina’s kan prima met Elementor werken, mits de pagina’s netjes zijn opgebouwd en overbodige widgets worden vermeden. Een contentrijke website kan soms beter profiteren van Gutenberg en herbruikbare blokken. Een maatwerksite met veel specifieke templates kan sneller en stabieler worden wanneer onderdelen direct in het thema worden gebouwd. En bij Bedrock-sites ligt de nadruk vaak nog sterker op een professionele, beheersbare ontwikkelstructuur.

Het gaat dus niet om een simpele tegenstelling tussen “pagebuilder slecht” en “maatwerk goed”. Het gaat om de juiste keuze voor de juiste situatie.

Elementor, Gutenberg, maatwerkthema of Bedrock?

Niet iedere WordPress-site moet op dezelfde manier worden geoptimaliseerd.

Bij een Elementor-site kijk je vooral naar de opbouw van pagina’s. Zijn er veel geneste containers? Worden er zware widgets gebruikt? Zijn animaties echt nodig? Laden formulieren, sliders of pop-ups scripts op pagina’s waar ze niet worden gebruikt?

Bij een Gutenberg-site ligt de nadruk meer op het thema, de blokken en de manier waarop CSS en JavaScript worden geladen. Gutenberg kan relatief licht zijn, maar ook hier kunnen extra blokplugins of slecht gebouwde thema’s alsnog ballast toevoegen.

Bij een maatwerkthema kun je veel preciezer bepalen welke bestanden waar worden geladen. CSS en JavaScript kunnen per template of component worden toegevoegd. Dat levert vaak een schonere basis op, maar vraagt wel om meer ontwikkelwerk.

Bij een Bedrock-site komt daar nog een professionele projectstructuur bij. Plugins en thema’s worden beter beheersbaar via Composer, configuratie wordt netter gescheiden en de site sluit beter aan op moderne ontwikkel- en stagingwerkwijzen. Dat maakt Bedrock niet automatisch sneller, maar het helpt wel om de website beter beheersbaar en onderhoudbaar te houden.

De juiste aanpak hangt dus af van het doel van de website, het budget, de gewenste flexibiliteit en de mate waarin performance belangrijk is.

In een recent artikel over de ‘keuze van het theme framework’, kan je hier meer over lezen.

Waarom externe scripts vaak onderschat worden

Niet alle vertraging komt van WordPress zelf. Veel websites laden externe scripts van andere partijen. Denk aan Google Analytics, Meta Pixel, LinkedIn Insight Tag, chatwidgets, boekingssystemen, embedded maps, YouTube-video’s, trackingtools, marketingsoftware en social media feeds.

Elk extern script is afhankelijk van een andere server. Je eigen hosting kan perfect zijn, maar als een externe dienst traag reageert, kan je pagina alsnog vertragen. Bovendien voegen deze scripts vaak extra JavaScript toe dat de browser moet verwerken.

Externe scripts hebben vooral invloed op de ervaring van mobiele bezoekers. Een telefoon heeft minder rekenkracht dan een desktopcomputer. Als er tijdens het laden van de pagina veel JavaScript moet worden verwerkt, kan de pagina traag reageren. Dat zie je terug in de gebruikservaring en mogelijk ook in INP, de Core Web Vital die meet hoe snel een pagina reageert op interacties.

Daarom is het verstandig om kritisch te kijken naar ieder extern script:

• Is dit script echt nodig?
• Levert het voldoende waarde op?
• Moet het op iedere pagina laden?
• Kan het later worden geladen?
• Kan het pas laden na toestemming?
• Is er een lichtere manier om hetzelfde doel te bereiken?

Een chatwidget kan waardevol zijn wanneer bezoekers vaak vragen stellen. Maar als de widget op iedere pagina zwaar JavaScript laadt en nauwelijks wordt gebruikt, is het misschien geen goede ruil. Een kaart kan nuttig zijn op de contactpagina, maar hoeft meestal niet op de homepage of elk blogartikel geladen te worden.

Wanneer maatwerk sneller is dan een extra plugin

Een plugin is vaak de snelste manier om functionaliteit toe te voegen. Maar niet altijd de beste.

Wanneer je een kleine, specifieke functie nodig hebt, kan maatwerk soms lichter en sneller zijn dan een complete plugin met tientallen opties die je niet gebruikt. Denk aan een eenvoudige shortcode, een kleine WooCommerce-aanpassing, een specifieke template, een aangepast formulier of een kleine koppeling.

Een plugin is gebouwd voor veel verschillende situaties. Dat is handig, maar daardoor bevat een plugin vaak meer instellingen, scripts en mogelijkheden dan jouw website nodig heeft. Maatwerk kan beperkter zijn, maar juist daardoor efficiënter.

Dat betekent niet dat alles maatwerk moet worden. Voor complexe functionaliteit, zoals betalingen, beveiliging, formulieren, SEO of WooCommerce, is een goede bestaande plugin vaak verstandig. Maar voor kleine specifieke wensen kan maatwerk de website eenvoudiger houden.

Voor WordXPression is dit een belangrijk uitgangspunt: kies niet automatisch voor nóg een plugin, maar kijk eerst wat de meest logische oplossing is. Soms is dat een plugin. Soms een instelling. Soms betere hosting. Soms een stukje maatwerk.

Praktisch voorbeeld:

Stel: je gebruikt een formulierplugin voor één contactformulier op de contactpagina. De plugin werkt goed, maar laadt zijn CSS en JavaScript op iedere pagina van de website.

Dat betekent dat ook bezoekers van een blogartikel, dienstenpagina of homepage extra bestanden moeten downloaden en verwerken, terwijl daar helemaal geen formulier staat.

De oplossing kan op verschillende manieren:

• De plugininstellingen aanpassen
• Scripts alleen laden op pagina’s met een formulier
• Een lichtere formulieroplossing gebruiken
• Een klein maatwerkformulier bouwen
• De plugin behouden, maar onnodige scripts uitschakelen waar ze niet nodig zijn

De beste oplossing hangt af van de website. Maar het uitgangspunt blijft hetzelfde: laad alleen wat nodig is op de plek waar het nodig is.

6. Ruim database, autoloaded options en oude rommel op

Bij snelheid denken veel mensen eerst aan afbeeldingen, caching en hosting. Dat zijn inderdaad belangrijke onderdelen. Maar bij een WordPress-website speelt ook de database een grote rol.

WordPress bewaart veel informatie in de database: pagina’s, berichten, gebruikers, instellingen, menu’s, widgets, plugininstellingen, WooCommerce-bestellingen, tijdelijke gegevens en nog veel meer. Iedere keer dat een pagina niet uit de cache komt, moet WordPress gegevens uit die database ophalen.

Dat is op zich geen probleem. Daar is de database voor bedoeld.

Maar na verloop van tijd kan er rommel ontstaan. Oude revisies blijven staan, plugins laten tabellen achter, tijdelijke gegevens worden niet goed opgeruimd en sommige instellingen worden bij iedere paginalading automatisch opgehaald. Vooral bij oudere websites, WooCommerce-sites en websites waarop veel plugins zijn getest, kan dat merkbaar worden.

Database-optimalisatie kan dus nuttig zijn, maar je moet er voorzichtig mee omgaan. Niet blind op een knop “clean database” klikken zonder te weten wat er wordt verwijderd. En zeker niet zonder backup.

Waarom oude plugins soms sporen achterlaten

Een plugin installeren is makkelijk. Een plugin verwijderen lijkt ook makkelijk. Maar in de praktijk laat een plugin soms gegevens achter in de database.

Dat kan bewust zijn. Sommige plugins verwijderen hun gegevens niet automatisch, omdat je ze later misschien opnieuw wilt installeren zonder instellingen kwijt te raken. Denk aan formulierinzendingen, SEO-instellingen, statistieken, logbestanden of WooCommerce-gerelateerde gegevens.

Maar het gevolg is dat een WordPress-database na jaren gebruik sporen kan bevatten van plugins die allang niet meer actief zijn.

Voorbeelden zijn:

• oude plugin-tabellen
• instellingen in de wp_options-tabel
• oude shortcodes in content
• logtabellen
• tijdelijke cachegegevens
• ongebruikte metadata
• oude formulierinzendingen
• restanten van pagebuilders of sliders

Niet al deze resten vertragen de website direct. Een oude tabel die nooit wordt aangesproken, is meestal geen groot performanceprobleem. Maar rommel maakt de website wel minder overzichtelijk en kan backups groter maken. Bovendien kunnen bepaalde oude instellingen wél automatisch worden geladen.

Daarom begint database-opruiming niet met verwijderen, maar met inventariseren. Wat staat er in de database? Waar komt het vandaan? Wordt het nog gebruikt? En wat gebeurt er als het wordt weggehaald?

Revisies: Handig… maar soms te veel!

WordPress bewaart revisies van berichten en pagina’s. Dat is handig, want je kunt terug naar een eerdere versie van een tekst. Voor redactiewerk is dat een fijne veiligheidsvoorziening.

Maar op oudere websites kunnen revisies flink oplopen. Zeker wanneer pagina’s vaak zijn aangepast of wanneer pagebuilders worden gebruikt die veel gegevens in de content opslaan.

Een paar revisies zijn geen probleem. Honderden of duizenden oude revisies kunnen de database wel groter en minder overzichtelijk maken. Dat betekent niet automatisch dat iedere pagina trager wordt, maar het kan backups, zoekopdrachten en beheer wel zwaarder maken.

Een verstandige aanpak is om revisies niet volledig uit te schakelen, maar wel te beperken. Bijvoorbeeld door slechts een bepaald aantal revisies per bericht te bewaren. Zo houd je de veiligheidsfunctie, zonder dat de database eindeloos blijft groeien.

Verlopen transients: tijdelijke gegevens die soms blijven hangen

Transients zijn tijdelijke gegevens die WordPress of plugins opslaan. Ze worden bijvoorbeeld gebruikt om tijdelijk resultaten te bewaren van externe API’s, queries of berekeningen. Het idee is goed: niet steeds hetzelfde opnieuw ophalen of berekenen.

Een transient heeft meestal een vervaldatum. Na die tijd mag de informatie worden vernieuwd of verwijderd.

In de praktijk blijven verlopen transients soms langer staan dan nodig. Dat kan gebeuren door plugins, cronproblemen of websites waarop veel tijdelijke gegevens worden aangemaakt.

Verlopen transients opruimen is vaak relatief veilig, omdat het om tijdelijke informatie gaat. Toch is ook hier voorzichtigheid verstandig. Op een drukke website of webshop wil je weten wat je opruimt en wanneer je dat doet.

Wat zijn autoloaded options?

De wp_options-tabel is één van de belangrijkste tabellen in WordPress. Hierin staan allerlei instellingen van WordPress zelf, thema’s en plugins.

Sommige van die instellingen hebben het kenmerk autoload. Dat betekent dat WordPress ze automatisch ophaalt bij vrijwel iedere paginalading. Dat is handig voor instellingen die steeds nodig zijn, zoals basisinstellingen van de site.

Maar het wordt een probleem wanneer te veel of te grote gegevens automatisch worden geladen.

Stel dat een oude plugin een grote hoeveelheid instellingen of cachedata heeft opgeslagen als autoloaded option. Dan kan WordPress die gegevens bij iedere paginalading blijven ophalen, ook wanneer de plugin allang niet meer wordt gebruikt. Dat is onnodige ballast.

Autoloaded options zijn daarom een belangrijk aandachtspunt bij performanceonderzoek. Niet omdat iedere autoloaded option verkeerd is, maar omdat te veel autoloaded data de website zwaarder kan maken.

Je kunt het vergelijken met een gereedschapskist die je bij elke klus meeneemt. Een hamer, schroevendraaier en rolmaat zijn logisch. Maar als je ook steeds drie oude boormachines, kapotte kabels en ongebruikte onderdelen meesleept, wordt iedere klus onnodig zwaar.

WooCommerce-sessies en winkelgegevens

WooCommerce maakt WordPress veel dynamischer. Een gewone informatiepagina is meestal voor iedere bezoeker hetzelfde, maar een webshop werkt met winkelwagens, sessies, bestellingen, voorraad, coupons, klantaccounts en betaalprocessen.

Daarom ontstaan er in WooCommerce-websites vaak extra databasegegevens. Denk aan sessiegegevens, tijdelijke winkelwageninformatie, transients, ordermetadata en gegevens van betaal- en verzendplugins.

Dat is normaal, maar het moet wel beheersbaar blijven. Oude sessies en verlopen tijdelijke gegevens kunnen de database laten groeien. Bij grotere webshops kan vooral de hoeveelheid ordermetadata en geplande acties invloed hebben op beheer, backups en bepaalde queries.

WooCommerce-sites moeten daarom zorgvuldiger worden opgeschoond dan gewone websites. Je wilt geen gegevens verwijderen die nodig zijn voor bestellingen, boekhouding, klantaccounts of wettelijke bewaartermijnen.

Action Scheduler-data

Veel moderne WordPress- en WooCommerce-plugins gebruiken Action Scheduler. Dit systeem wordt gebruikt om taken op de achtergrond te plannen en uit te voeren. Denk aan het verwerken van webhooks, abonnementen, e-mails, synchronisaties, voorraadupdates of andere terugkerende acties.

Action Scheduler is nuttig, maar op drukke websites kan er veel data ontstaan. Afgeronde, mislukte of oude acties kunnen zich opstapelen. Dat kan het beheer vertragen en in sommige gevallen invloed hebben op de performance van achtergrondtaken.

Bij WooCommerce-websites is dit extra relevant, omdat veel WooCommerce-extensies Action Scheduler gebruiken. Het opruimen of controleren van oude acties kan zinvol zijn, maar moet zorgvuldig gebeuren. Mislukte acties kunnen namelijk ook wijzen op een echt probleem, bijvoorbeeld een koppeling die niet goed werkt.

Daarom is het verstandig om niet alleen oude acties te verwijderen, maar eerst te kijken waarom ze daar staan.

Logtabellen: nuttig voor diagnose, maar niet voor altijd

Logs zijn handig wanneer je problemen moet oplossen. Ze kunnen laten zien wat er misgaat bij betalingen, koppelingen, e-mails, API-verkeer of cronjobs.

Maar logs hoeven meestal niet voor altijd bewaard te blijven. Sommige plugins houden uitgebreide logtabellen bij. Als die nooit worden opgeschoond, kunnen ze flink groeien.

Voorbeelden zijn logs van:

• beveiligingsplugins
• SMTP-plugins
• WooCommerce-betalingen
• API-koppelingen
• import- en exporttools
• backupplugins
• cron- en foutmeldingen
• formulierplugins

Logs zijn dus waardevol, maar vooral tijdelijk. Je wilt genoeg informatie bewaren om problemen te kunnen analyseren, maar niet jarenlang technische ruis meeslepen.

Database-indexen bij grotere sites

Bij kleinere websites hoef je meestal niet veel na te denken over database-indexen. WordPress en plugins regelen de basis voldoende.

Bij grotere websites kan dat anders worden. Denk aan webshops met veel producten en orders, platforms met veel gebruikers, leeromgevingen, bedrijvengidsen of sites met veel custom post types en metadata.

Een database-index helpt de database sneller zoeken, een beetje zoals een register achterin een boek. Zonder index moet de database veel meer gegevens doorlopen om het juiste resultaat te vinden.

Vooral queries op metadata kunnen bij grotere WordPress-sites zwaar worden. Dat merk je bijvoorbeeld bij filters, zoekfuncties, rapportages, dashboards of maatwerkoverzichten.

Database-indexen zijn geen standaardklusje voor iedere WordPress-site. Verkeerd geplaatste indexen kunnen ook nadelen hebben. Maar bij grotere sites kan het analyseren en optimaliseren van databasequeries een belangrijk onderdeel zijn van performanceverbetering.

Database opschonen zonder ongelukken

Database-optimalisatie moet je nooit achteloos doen. Een database is geen map met oude bestanden waarin je zomaar wat kunt weggooien. Het is het hart van je website.

Een veilige aanpak ziet er zo uit:

1. Eerst meten
   Kijk waar de database werkelijk zwaar is. Zijn het autoloaded options, oude plugin-tabellen, transients, logs, WooCommerce-sessies of trage queries?
2. Maak een backup
   Zorg dat er een recente backup is die ook echt teruggezet kan worden. Een backup is pas waardevol als herstel mogelijk is.
3. Gebruik staging
   Voer grotere opruimacties eerst uit op een stagingomgeving. Zo kun je testen zonder risico voor de live website.
4. Ruim gericht op
   Verwijder niet alles wat een tool als “overbodig” markeert. Bepaal per categorie wat veilig is.
5. Test de website
   Controleer pagina’s, formulieren, checkout, accountomgeving, zoekfuncties en belangrijke plugins.
6. Meet opnieuw
   Kijk of de opruiming werkelijk effect heeft gehad. Soms wordt de database kleiner, maar verandert de laadtijd nauwelijks. Ook dat is nuttige informatie.

Het belangrijkste is dat database-opruiming onderdeel is van een beheerproces, niet van een wilde schoonmaakactie.

Een schone database

Een schone database kan bijdragen aan een snellere, stabielere en beter beheerbare WordPress-site. Zeker bij oudere websites, WooCommerce-sites en websites waarop veel plugins zijn getest of vervangen.

Maar database-optimalisatie vraagt voorzichtigheid. Niet alles wat oud is, is overbodig. Niet alles wat een tool markeert, mag zomaar weg. En niet iedere kleinere database levert automatisch een snellere website op.

De juiste aanpak is: eerst meten, dan backup maken, vervolgens opschonen op staging, daarna testen en pas dan live doorvoeren.

Een snelle website vraagt niet alleen om minder rommel, maar vooral om gecontroleerd onderhoud.

7. Maak snelheid een onderdeel van onderhoud

Een snelle website maken is belangrijk. Maar een snelle website snel houden is minstens zo belangrijk.

Snelheid is geen eenmalig project dat je afvinkt en daarna vergeet. Een website verandert voortdurend. Er komen nieuwe pagina’s bij, afbeeldingen worden toegevoegd, plugins krijgen updates, marketingtools worden gekoppeld, scripts veranderen en soms wordt er nieuwe functionaliteit gebouwd.

Elke wijziging kan invloed hebben op de prestaties van de website. Soms is die invloed nauwelijks merkbaar. Soms zorgt één extra plugin, trackingcode of grote afbeelding ervoor dat een pagina ineens trager wordt.

Daarom hoort performance niet alleen thuis in een eenmalige optimalisatieronde. Het moet onderdeel worden van het gewone onderhoud van de website.

Waarom snelheid langzaam kan verslechteren

Veel websites worden niet in één keer traag. Ze worden langzaam zwaarder.

In het begin is de site netjes opgebouwd. De pagina’s laden vlot, de afbeeldingen zijn geoptimaliseerd en er staan alleen noodzakelijke plugins op. Maar daarna gebeurt er van alles.

Er wordt een extra plugin geïnstalleerd voor een formulier. Later komt er een pop-up bij voor nieuwsbriefinschrijvingen. Daarna wordt er een trackingpixel toegevoegd voor advertenties. Vervolgens komt er een chatwidget, een embedded video, een externe agenda, een nieuwe slider en een paar grote afbeeldingen die rechtstreeks vanuit de camera zijn geüpload.

Geen van die keuzes hoeft op zichzelf verkeerd te zijn. Het probleem ontstaat wanneer niemand meer kijkt naar het totaal.

Een website kan daardoor ongemerkt zwaarder worden door:

• nieuwe plugins
• extra scripts
• te grote afbeeldingen
• externe marketingtools
• verouderde plugininstellingen
• databasegroei
• oude tijdelijke gegevens
• zwaardere pagina’s
• wijzigingen in thema of pagebuilder
• nieuwe functionaliteit zonder performancecontrole

Dit is ook waarom een website die vorig jaar snel was, vandaag toch trager kan aanvoelen. Niet omdat er één rampzalige fout is gemaakt, maar omdat er steeds kleine technische kosten zijn bijgekomen.

Regelmatig meten

Wie snelheid wil bewaken, moet regelmatig meten. Niet iedere dag, maar wel op vaste momenten.

Meet bijvoorbeeld:

• na grote updates
• na het toevoegen van nieuwe plugins
• na het plaatsen van een nieuwe homepage of landingspagina
• na wijzigingen in tracking of marketingtools
• na het toevoegen van video’s, sliders of zware formulieren
• periodiek, bijvoorbeeld elk kwartaal

Daarbij hoef je niet alleen naar één score te kijken. Het is nuttiger om trends te volgen. Wordt de site langzaam zwaarder? Gaat de mobiele score achteruit? Verslechtert LCP door nieuwe afbeeldingen? Reageert de pagina trager door extra JavaScript?

Gebruik daarbij PageSpeed Insights voor losse pagina’s en Google Search Console om Core Web Vitals breder te volgen. PageSpeed Insights helpt bij de technische diagnose van specifieke pagina’s. Search Console laat beter zien of groepen pagina’s in de praktijk problemen geven bij echte gebruikers.

Het doel is niet om iedere maand obsessief een perfecte score na te jagen. Het doel is om vroeg te zien wanneer de website achteruitgaat.

Updates, staging en testen

Updates zijn belangrijk voor veiligheid, stabiliteit en compatibiliteit. WordPress zelf, thema’s en plugins moeten bijgehouden worden. Maar updates kunnen ook invloed hebben op performance.

Een plugin kan na een update extra scripts laden. Een pagebuilder kan de manier veranderen waarop CSS wordt gegenereerd. Een thema-update kan nieuwe instellingen of bestanden toevoegen. Een WooCommerce-update kan invloed hebben op checkout, winkelwagen of achtergrondtaken.

Daarom is het verstandig om updates niet volledig los te zien van snelheid.

Bij kleinere websites kunnen reguliere updates vaak direct worden uitgevoerd, mits er een goede backup is. Bij grotere websites, WooCommerce-webshops, leeromgevingen of sites met maatwerk is staging belangrijker. Een stagingomgeving geeft de mogelijkheid om wijzigingen eerst te testen voordat ze live gaan.

Een veilige werkwijze is:

1. Maak vooraf een backup
2. Voer grotere updates eerst uit op staging
3. Controleer de belangrijkste pagina’s en functies
4. Test formulieren, checkout, accountpagina’s en ingelogde omgevingen
5. Meet opnieuw of de prestaties niet duidelijk verslechteren
6. Voer de update daarna pas live door

Dat klinkt misschien als extra werk, maar het voorkomt dat een update ongemerkt zorgt voor een tragere of minder betrouwbare website.

Pluginlijst controleren

Een belangrijk onderdeel van onderhoud is het controleren van de pluginlijst. Niet alleen technisch, maar ook inhoudelijk.

De vraag is niet alleen: “Zijn alle plugins up-to-date?”
De vraag is ook: “Hebben we deze plugins nog nodig?”

Veel websites bevatten plugins die ooit voor een test, tijdelijke campagne of oude functionaliteit zijn geïnstalleerd. Soms zijn ze nog actief, soms gedeactiveerd, soms vervangen door een andere plugin. Na verloop van tijd raakt het overzicht kwijt.

Controleer daarom periodiek:

• welke plugins actief zijn
• welke plugins dubbel werk doen
• welke plugins niet meer worden gebruikt
• welke plugins veel scripts laden
• welke plugins niet meer goed onderhouden worden
• welke plugins vervangen kunnen worden door lichtere oplossingen
• welke functionaliteit beter met maatwerk of themafunctionaliteit kan worden opgelost

Een plugin verwijderen moet je natuurlijk zorgvuldig doen. Soms bevat een plugin gegevens die nog nodig zijn. Test dit dus bij voorkeur op staging en maak altijd een backup voordat je opruimt.

Afbeeldingen controleren

Afbeeldingen blijven een terugkerend aandachtspunt. Zelfs als de website bij oplevering goed geoptimaliseerd is, kunnen nieuwe uploads later alsnog problemen veroorzaken.

Een redacteur, ondernemer of medewerker uploadt misschien een foto van 6000 pixels breed rechtstreeks vanaf de camera. Of een PNG-bestand wordt gebruikt waar een JPEG of WebP logischer was. Of een nieuwe hero-afbeelding wordt geplaatst zonder compressie.

Daarom hoort beeldcontrole bij onderhoud.

Let op:

• te grote uploads
• zware PNG-bestanden
• hero-afbeeldingen die niet goed zijn geoptimaliseerd
• afbeeldingen zonder passende formaten
• video-thumbnails die onnodig groot zijn
• sliders met meerdere zware afbeeldingen
• oude media die niet meer wordt gebruikt

Voor contentafbeeldingen is een webgeschikte breedte, bijvoorbeeld 1440 pixels, in veel gevallen voldoende. Voor hero-afbeeldingen kan 1920×800 een praktische verhouding zijn, mits goed gecomprimeerd. Het uitgangspunt blijft: groot genoeg voor een nette presentatie, licht genoeg voor snelle laadtijden.

Core Web Vitals monitoren

Core Web Vitals geven inzicht in hoe bezoekers de website ervaren. Het gaat daarbij niet alleen om laadtijd, maar ook om reactiesnelheid en visuele stabiliteit.

De drie belangrijkste signalen zijn:

• LCP: hoe snel verschijnt het belangrijkste zichtbare onderdeel van de pagina?
• INP: hoe snel reageert de pagina op interactie?
• CLS: verschuift de layout tijdens het laden?

Het is verstandig om deze waarden periodiek te controleren. Vooral na grotere wijzigingen aan thema, pagebuilder, scripts, tracking, formulieren, video’s of advertenties.

Een verslechtering in Core Web Vitals betekent niet automatisch dat er paniek nodig is. Het is wel een signaal om te onderzoeken wat er veranderd is. Soms is de oorzaak duidelijk: een nieuwe hero-afbeelding, een extra marketingtool of een zwaardere plugin. Soms vraagt het wat dieper onderzoek.

Performance meenemen bij iedere nieuwe functionaliteit

Iedere nieuwe functie heeft een technische prijs. Soms is die prijs laag. Soms is hij hoog.

Een eenvoudige tekstsectie toevoegen kost bijna niets. Een externe chatwidget die op iedere pagina JavaScript laadt, heeft meer impact. Een formulier met goede instellingen is meestal prima. Een formulierplugin die overal scripts laadt, kan onnodige ballast toevoegen. Een kaart op de contactpagina is logisch. Een interactieve map op iedere pagina is meestal overdreven.

Dat betekent niet dat je nieuwe functionaliteit moet vermijden. Een website moet kunnen groeien. Maar groei moet bewust gebeuren.

Bij elke nieuwe functie kun je een paar vragen stellen:

• Wat voegt deze functie toe voor de bezoeker?
• Moet dit op iedere pagina laden?
• Is er een lichtere manier om hetzelfde doel te bereiken?
• Heeft dit invloed op mobiel?
• Moeten we dit eerst op staging testen?
• Moeten we na plaatsing opnieuw meten?
• Is het voordeel groter dan de technische prijs?

Dit helpt om performance onderdeel te maken van besluitvorming. Niet als rem op ontwikkeling, maar als kwaliteitscontrole.

Van een snelle website naar een snelle werkwijze

De beste snelheidswinst komt niet alleen uit technische optimalisatie, maar uit een betere werkwijze.

Dat betekent dat snelheid wordt meegenomen bij:

• Het kiezen van plugins
• Het uploaden van afbeeldingen
• Het ontwerpen van nieuwe pagina’s
• Het toevoegen van scripts
• Het uitvoeren van updates
• Het bouwen van maatwerk
• Het beoordelen van marketingtools
• Het onderhoud van database en caching

Zo voorkom je dat performance telkens achteraf moet worden gerepareerd. De website blijft schoner, overzichtelijker en beter beheersbaar.

Voor WordXPression sluit dit goed aan bij een onderhoudsaanpak met updates, backups, staging, monitoring en periodieke controle. Niet alleen zorgen dat de website online blijft, maar ook dat hij prettig blijft werken.

De belangrijkste les

Snelheid is geen eindpunt. Het is een onderhoudsproces.

Een website verandert voortdurend, en iedere wijziging kan invloed hebben op de prestaties. Daarom is het verstandig om snelheid regelmatig te meten, updates zorgvuldig uit te voeren, plugins en afbeeldingen te controleren en grotere wijzigingen eerst op staging te testen.

Een snelle website vraagt niet alleen om goede techniek, maar ook om discipline in het beheer.

Wie performance meeneemt in de normale werkwijze, voorkomt dat de website langzaam dichtslibt. En dat is uiteindelijk veel effectiever dan één keer per jaar een grote schoonmaakactie uitvoeren.

Hulp nodig bij een snellere WordPress website?

Een snellere website begint met meten, maar daar houdt het niet op. Vaak blijkt pas na een goede analyse waar de grootste winst zit. Soms is dat hosting. Soms zijn het afbeeldingen, caching, plugins, externe scripts of oude rommel in de database. En regelmatig is het een combinatie van meerdere kleine verbeteringen.

WordXPression kan helpen om die verbeteringen gestructureerd aan te pakken. Niet door zomaar een extra optimalisatie-plugin te installeren, maar door eerst te kijken waar de vertraging werkelijk ontstaat.

Daarbij kan onder andere worden gekeken naar:

• laadtijden en Core Web Vitals
• hosting en serverinstellingen
• caching en CDN
• afbeeldingen en video
• plugin- en pagebuilder-ballast
• databasevervuiling
• WooCommerce-specifieke vertraging
• externe scripts zoals tracking, chatwidgets en maps
• onderhoud, updates en staging

Het doel is niet alleen een betere score in PageSpeed Insights, maar vooral een website die voor echte bezoekers sneller, stabieler en prettiger werkt.

Hosting als technische basis

Performance begint vaak bij de hosting. Een trage server kan niet volledig worden gerepareerd met een plugin. Daarom biedt WordXPression hosting niet aan als losse opslagruimte, maar als onderdeel van een beheerde technische oplossing voor websites, webshops, online leeromgevingen en webapplicaties.

Dat heeft praktische voordelen. Wanneer ontwikkeling, hosting en beheer onder één dak vallen, is er één aanspreekpunt voor prestaties, updates, beveiliging, back-ups, monitoring en probleemoplossing. Problemen kunnen daardoor sneller worden opgespoord en opgelost.

Voor WordPress-websites, WooCommerce-webshops en online leeromgevingen kan hosting via WordXPression onder meer interessant zijn door zaken als isolatie per website, managed WordPress-beheer, CDN, dagelijkse back-ups, staging, malware scanning, monitoring, PHP-versiebeheer, SSH en WP-CLI. Bij zwaardere projecten kan een VPS-oplossing op maat logischer zijn, bijvoorbeeld voor drukke webshops, leeromgevingen, Laravel-applicaties of bedrijfskritische websites.

Goede hosting is daarmee geen bijzaak, maar een fundament voor snelheid, veiligheid en betrouwbaarheid.

Onderhoud om snelheid vast te houden

Een website kan na optimalisatie weer snel zijn, maar snelheid moet ook worden onderhouden. Nieuwe plugins, updates, afbeeldingen, scripts en marketingtools kunnen de website langzaam weer zwaarder maken.

Daarom is het verstandig om performance onderdeel te maken van het vaste onderhoud. Denk aan periodiek meten, pluginlijsten controleren, afbeeldingen nalopen, database-opruiming, updates testen en grotere wijzigingen eerst op staging uitvoeren.

Via de WordXPression Support Strippenkaart kan hiervoor een voordelige onderhoudsafspraak worden gemaakt. Daarmee is er ruimte om op vaste momenten verbeteringen uit te voeren, zonder dat voor iedere kleine aanpassing een apart project hoeft te worden gestart.

Zo kan de strippenkaart bijvoorbeeld worden gebruikt voor:

• periodieke performancecontroles
• kleine optimalisaties
• oplossen van technische knelpunten
• controleren van plugins en scripts
• database-onderhoud
• testen na updates
• aanpassingen aan caching
• advies over nieuwe functionaliteit
• verbeteringen aan bestaande pagina’s

Dat maakt onderhoud flexibeler. Je spreekt af wat belangrijk is, plant periodiek tijd in en gebruikt de strippenkaart om gericht werk te laten uitvoeren.

Van een snelle website naar een gezonde website

Een snelle website is geen eindpunt. Het is onderdeel van een gezonde website: technisch netjes opgebouwd, goed onderhouden, veilig gehost en regelmatig gecontroleerd.

WordXPression kan helpen bij zowel de eerste optimalisatie als het onderhoud daarna. Eerst door te onderzoeken waar de meeste winst zit. Daarna door verbeteringen zorgvuldig door te voeren. En vervolgens door de website actief te blijven beheren, zodat snelheid niet langzaam weer verdwijnt.

Wil je weten waar jouw WordPress-website snelheid verliest? Dan is een technische analyse een goed startpunt. Van daaruit kan worden bepaald welke stappen het meeste effect hebben: betere hosting, slimmere caching, lichtere afbeeldingen, minder scripts, database-onderhoud of een structureel onderhoudsplan via de Support Strippenkaart.