WordPress-site traag? Zo vind je waar de tijd zit

Je klikt op een link naar je eigen site en het duurt. Eerst een wit scherm, dan de tekst, dan schuift alles nog even op omdat de afbeeldingen binnenkomen. Op je laptop valt het mee. Op je telefoon, buiten op 4G, niet.

De reflex is een snelheidsplugin installeren. Soms helpt dat. Vaak niet, omdat de tijd ergens anders zit. In dit artikel lees je hoe je eerst meet waar het aan ligt, en daarna gericht oplost.

Eerst meten, en het goede getal lezen

Open PageSpeed Insights en vul de URL in van een pagina die ertoe doet. Niet alleen je homepage, maar ook een dienstpagina of een productpagina.

Bovenaan staan de gegevens van echte bezoekers, als Google daar genoeg van heeft. Dat blok is belangrijker dan de score van 0 tot 100 eronder. Die score komt uit één testrun op een gesimuleerde, trage telefoon en springt bij elke meting een paar punten op en neer. Drie getallen tellen:

• Largest Contentful Paint (LCP). Hoe lang het duurt tot het grootste blok in beeld staat, meestal je headerafbeelding of de kop. Goed is binnen 2,5 seconde.
• Interaction to Next Paint (INP). Hoe snel de pagina reageert als iemand ergens op tikt. Goed is binnen 200 milliseconden.
• Cumulative Layout Shift (CLS). Hoeveel de pagina verspringt tijdens het laden. Goed is onder 0,1.

Scroll daarna naar de diagnose. Kijk vooral naar de reactietijd van de server, bij Google “Time to First Byte”. Daarmee kun je de oorzaken grofweg in twee groepen verdelen.

Is de server traag of de pagina zwaar?

Een pagina laden gebeurt in twee stappen. Eerst bouwt de server de pagina op: PHP draait, WordPress haalt gegevens uit de database, plugins doen hun werk. Daarna haalt de browser alles op wat in die pagina staat: afbeeldingen, lettertypes, CSS en JavaScript.

• Duurt het lang voordat de server iets terugstuurt, ruim boven een halve seconde, dan zit het probleem op de server of in WordPress zelf. Dan helpen de stappen hieronder over hosting, caching en de database.
• Antwoordt de server snel, maar duurt het toch lang, dan is de pagina zelf te zwaar. Dan helpen de stappen over afbeeldingen, scripts en lettertypes.

Dat onderscheid scheelt veel zoekwerk. Afbeeldingen verkleinen helpt niets als de server twee seconden nadenkt voor hij begint. En een betere server lost een headerfoto van 4 MB niet op.

Als de server traag is

Paginacache

Zonder cache bouwt WordPress elke pagina bij elk bezoek opnieuw op. Met een paginacache gebeurt dat één keer, en krijgen volgende bezoekers een kant-en-klare kopie. Dat is meestal de grootste winst die je kunt halen. Hoe dat werkt en welke soorten cache er zijn, lees je in caching in WordPress uitgelegd.

Onder Gereedschap, Sitestatus geeft WordPress zelf aan of er een paginacache actief is. Staat daar dat er geen is gevonden, dan is dat de eerste stap.

Te veel of te zware plugins

Niet het aantal plugins telt, maar wat ze doen. Twintig kleine plugins kunnen sneller zijn dan één die op elke pagina een externe dienst aanroept. Wil je weten welke plugin tijd kost, installeer dan tijdelijk Query Monitor. Die laat per pagina zien hoeveel databasevragen er zijn, welke plugin ze stelt en hoe lang ze duren. Verwijder hem daarna weer.

Een volle database

WordPress laadt bij elke pagina een deel van de tabel met instellingen in één keer in, de zogenoemde autoload. Plugins zetten daar gegevens in, en laten die vaak staan als je ze verwijdert. Dat kan oplopen tot megabytes die bij elk bezoek opnieuw worden ingeladen. Sitestatus waarschuwt als het te veel wordt. Met WP-CLI zie je wat de grootste zijn:

wp db query "SELECT option_name, LENGTH(option_value) AS grootte FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY grootte DESC LIMIT 20;"

Heeft je database een ander voorvoegsel dan wp_, pas dat dan aan in de opdracht. Zie je opties van plugins die je al lang niet meer gebruikt, dan kun je die verwijderen. Altijd met een back-up vooraf.

Ook revisies stapelen zich op. Elke keer dat je een pagina opslaat, bewaart WordPress de oude versie. Met deze regel in wp-config.php beperk je dat tot vijf per pagina:

define( 'WP_POST_REVISIONS', 5 );

De hosting en PHP

Pas als het bovenstaande op orde is, kijk je naar de hosting. Een goedkoop pakket op een volle server merk je vooral als het druk is. Draai je nog een oude PHP-versie, dan laat je ook snelheid liggen: nieuwere versies zijn merkbaar sneller. In je hostingpaneel zie je welke versie je site gebruikt.

Als de pagina te zwaar is

Afbeeldingen

Dit is bijna altijd de grootste. Een foto rechtstreeks van een telefoon of camera is al snel 4.000 pixels breed en een paar megabyte groot, terwijl hij op je site 1.200 pixels breed wordt getoond.

• Verklein voor het uploaden. Geen afbeelding hoeft breder te zijn dan 2.560 pixels. Voor de meeste is 1.600 ruim genoeg.
• Gebruik een modern formaat. WebP is vaak een stuk kleiner dan JPG bij dezelfde kwaliteit. Sinds versie 6.5 kan WordPress ook AVIF aan. Een plugin als Smush kan bestaande afbeeldingen omzetten en comprimeren.
• Laat de bovenste afbeelding niet lazy laden. Lazy loading stelt het laden van afbeeldingen uit tot ze in beeld komen. Voor afbeeldingen verderop is dat goed. Voor de grote foto bovenaan juist niet, want die bepaalt je LCP. WordPress houdt daar zelf rekening mee, maar een paginabouwer of plugin gooit dat soms weer om.
• Geef afbeeldingen een breedte en hoogte. Dan houdt de browser er ruimte voor vrij en verspringt de pagina niet. Dat scheelt in je CLS.

Scripts en stylesheets

Thema’s en paginabouwers laden vaak CSS en JavaScript in voor functies die je niet gebruikt: een slider, animaties, een icoonset van honderden iconen voor de drie die op je site staan. Verkleinen en samenvoegen helpt een beetje. Niet laden helpt meer. Kijk in PageSpeed bij “ongebruikte JavaScript” en “ongebruikte CSS” welke bestanden het zijn. Ook externe scripts tellen mee: een chatwidget, een ingesloten Instagram-feed, drie trackingcodes.

Lettertypes en video

Lettertypes van Google Fonts laden vanaf de servers van Google. Zet je ze op je eigen server, dan scheelt dat een verbinding met een externe partij, en het is beter voor de AVG. Een ingesloten YouTube-video laadt een flinke hoeveelheid scripts in, ook als niemand op afspelen drukt. Toon dan een afbeelding met een afspeelknop, en laad de video pas bij een klik.

Waar het meestal misgaat

• Jagen op de score. Van 78 naar 95 komen kost veel werk en levert je bezoekers soms niets op. Kijk naar de gegevens van echte bezoekers en de drie getallen hierboven.
• Twee snelheidsplugins tegelijk. Ze cachen en verkleinen allebei, en zitten elkaar in de weg. Gebruik er één, en zet bij je hoster uit wat dubbel is.
• Alleen de homepage meten. Je homepage is vaak goed geoptimaliseerd. De pagina’s waar mensen via Google binnenkomen, zijn vaak trager.
• Afbeeldingen comprimeren die veel te groot zijn. Een foto van 4.000 pixels comprimeren levert een kleiner bestand op, maar het blijft een foto van 4.000 pixels.
• Testen terwijl je bent ingelogd. Ingelogde gebruikers krijgen meestal geen cache te zien. Test in een privévenster.

Tot slot

Een trage site heeft bijna altijd één of twee duidelijke oorzaken. Meet eerst, kijk of de tijd op de server of in de pagina zit, en los dat op. Pas daarna is het zinvol om aan de rest te sleutelen.

Kom je er niet uit, of wil je weten waar de tijd bij jouw site precies zit? Als WordPress specialist zoek ik het voor je uit. En met WordPress onderhoud houd ik het daarna ook snel.