Het valt meestal op bij iemand anders. U stuurt een link naar een klant en die zegt terloops dat de site “even nodig had”. Zelf merkt u er weinig van, want uw browser heeft alles al bewaard en u zit op glasvezel. Pas als u de site opent op een telefoon, op straat, met een normale verbinding, ziet u wat uw bezoekers zien.
De vraag waarom is mijn website traag heeft zelden één antwoord. Meestal zijn het drie of vier dingen die samen optellen tot vijf seconden. Hieronder de acht oorzaken die wij in de praktijk het vaakst tegenkomen, ongeveer in volgorde van hoe vaak ze de hoofdrol spelen. Per oorzaak staat erbij hoe u herkent of dit uw probleem is.
1. Afbeeldingen die veel te groot zijn
Dit is met afstand nummer één. Iemand uploadt een foto rechtstreeks van een camera of telefoon: 4000 bij 3000 pixels, vier megabyte. WordPress maakt daar wel kleinere versies van, maar als het thema of de paginabouwer het origineel gebruikt, of als iemand de foto in een tekstblok plakt, laadt de bezoeker die vier megabyte gewoon.
Hoe u het herkent: klik met de rechtermuisknop op een afbeelding op uw site, kies “afbeelding openen in nieuw tabblad” en kijk naar de afmetingen. Staat er iets van 3000 pixels breed voor een foto die op het scherm 600 pixels beslaat, dan heeft u dit probleem.
Wat helpt: foto’s vooraf schalen naar de maat waarop ze getoond worden, comprimeren en in een modern formaat zoals WebP serveren. Dat is meestal de grootste snelheidswinst die u met de minste moeite haalt.
2. Te veel plugins, of de verkeerde
Het aantal plugins zegt op zichzelf weinig; wat ze doen des te meer. Twintig kleine plugins kunnen prima samengaan, terwijl één zware plugin die op elke pagina een database-opdracht uitvoert de hele site vertraagt.
De echte boosdoeners zijn plugins die op elke pagina scripts en stijlbestanden laden, ook waar ze niets doen. Een boekingsformulier dat alleen op de contactpagina staat maar zijn bestanden op de homepage meelaadt, is een klassiek voorbeeld. Ook plugins die bij elke paginaweergave een externe server bevragen, zorgen voor onvoorspelbare vertraging.
Hoe u het herkent: kijk in uw pluginoverzicht hoeveel er actief zijn en of u ze allemaal nog gebruikt. Deactiveer op een testomgeving eens de helft en meet opnieuw.
3. Geen of verkeerd ingestelde caching
WordPress bouwt elke pagina bij elk bezoek opnieuw op: hij vraagt de database om de inhoud, laat het thema en de plugins hun werk doen en stelt de HTML samen. Dat kost tijd, elke keer weer, ook als er niets veranderd is.
Caching slaat het resultaat op en serveert dat aan de volgende bezoeker. Voor een informatieve website is dat een van de grootste versnellers die er is. De praktijk laat drie problemen zien: er is helemaal geen caching, er is caching maar hij is niet actief door een instelling, of er zijn twee cachingoplossingen die elkaar in de weg zitten.
Hoe u het herkent: laadt de tweede keer dat u een pagina opent net zo traag als de eerste keer bij een andere bezoeker, dan werkt er waarschijnlijk niets. Meet uitgelogd, want voor ingelogde beheerders wordt caching vaak overgeslagen.
4. Trage hosting
Een goedkoop hostingpakket kan prima werken. Maar er is een categorie pakketten waarbij honderden sites op één server staan met te weinig geheugen, verouderde PHP-versies en een sterk begrensd aantal processen per klant. Dan bouwt uw site dezelfde pagina simpelweg langzamer op dan elders.
Hoe u het herkent: kijk naar de tijd tot de eerste byte, in meettools aangeduid als TTFB. Zit die structureel boven een halve seconde terwijl uw site verder licht is, dan wijst dat richting de server. Wat die maatstaf precies zegt, leggen wij uit in het artikel over TTFB.
Let op: hosting krijgt vaker de schuld dan verdiend. Controleer eerst de punten 1 tot en met 3, want een verhuizing lost een zware pagina niet op.
5. Een opgeblazen database
WordPress bewaart veel meer dan u denkt. Elke keer dat u een pagina opslaat, komt er een revisie bij. Verwijderde plugins laten hun instellingen achter. Formulierplugins bewaren jarenlang inzendingen. Statistiekplugins schrijven elke paginaweergave weg.
Bij sites die vijf jaar draaien zien wij regelmatig databases van honderden megabytes waarvan het grootste deel nooit meer wordt opgevraagd. Dat maakt zoekopdrachten trager, vooral in de beheeromgeving en op overzichtspagina’s.
Hoe u het herkent: het beheer voelt merkbaar trager dan de voorkant, of overzichten met veel items laden langzaam. Kijk in phpMyAdmin naar de grootte van de tabellen.
6. Een zware paginabouwer of een zwaar thema
Paginabouwers zijn handig: u zet zelf een pagina in elkaar zonder code. De prijs is dat ze veel HTML, CSS en JavaScript produceren, ook voor eenvoudige pagina’s. Een thema met tientallen ingebouwde functies laadt die functies vaak allemaal, ook de sliders en portfolio-onderdelen die u niet gebruikt.
Hoe u het herkent: de bronnenlijst in een meettool toont tientallen losse CSS- en JS-bestanden, allemaal met de naam van uw thema of bouwer erin.
Wat helpt: overstappen is zelden realistisch. Wat wel kan: ongebruikte onderdelen uitzetten, laden per pagina beperken en niet-kritieke scripts uitstellen. Daarmee is meestal veel te winnen zonder de site opnieuw te bouwen.
7. Externe scripts van derden
Chatwidgets, statistiektools, advertentiepixels, ingesloten video’s, kaarten, reviewwidgets en lettertypen van een externe server. Elk daarvan is een verzoek naar een andere partij, en u heeft geen invloed op hoe snel die antwoordt. Is die server traag of onbereikbaar, dan wacht uw pagina mee.
Hoe u het herkent: in een watervalgrafiek van een meettool staan verzoeken naar domeinen die niet van u zijn, soms met lange balken.
Wat helpt: inventariseer wat er echt gebruikt wordt. Wij komen regelmatig pixels tegen van campagnes die drie jaar geleden zijn gestopt. Zet lettertypen op uw eigen server en laad een video pas zodra iemand op afspelen drukt.
8. Alles tegelijk laden
De laatste is geen losse oorzaak maar een patroon: alles wordt bij het openen van de pagina meteen opgehaald. Twintig afbeeldingen die pas onderaan staan, video’s die niemand afspeelt, scripts die pas nodig zijn bij een klik.
Wat helpt: afbeeldingen onder de vouw pas laden bij het scrollen, niet-kritieke JavaScript uitstellen, en de belangrijkste afbeelding bovenaan juist met voorrang laden. Dat laatste wordt vaak vergeten: uitstellen is goed, behalve voor het element dat de bezoeker als eerste ziet.
Hoe u dit voor uw eigen site uitzoekt
Meet eerst, en meet goed. Test uitgelogd, in een privévenster, en test naast de homepage ook een productpagina of een lange blogpagina. Kijk niet alleen naar het cijfer maar naar de lijst met aanbevelingen en de watervalgrafiek: daar staat welke bestanden hoeveel tijd kosten. Wat de verschillende cijfers betekenen en welke ertoe doen, hebben wij uitgewerkt in de uitleg over Core Web Vitals.
Pak daarna de oorzaken in volgorde van opbrengst aan, en verander één ding tegelijk. Wie afbeeldingen, caching en plugins tegelijk aanpakt en daarna meet, weet niet wat het verschil maakte, en dat wreekt zich zodra er iets kapotgaat.
Komt u er niet uit, of durft u niet aan de instellingen te komen omdat de site in gebruik is, dan is een eenmalige snelheidsoptimalisatie een optie: meten, verbeteren op een testomgeving en pas live zetten als het aantoonbaar sneller is. Wat u ook doet, bewaar de meetresultaten van vóór de ingreep. Zonder nulmeting is elke verbetering een gevoel.
