Jan Reilink

Een trage website is een grote ergernis, voor jou en voor je bezoekers. Mocht je denken dat dit door WordPress komt, dan heb je het mis. Waarom is jóuw website wel traag? Onze Jan Reilink heeft de antwoorden en weet wat je er zelf aan kunt doen. Vandaag deel 2.

WordPress database in topconditie houden

We hebben het al even kort gehad over de database configuratie van WordPress. Je hebt in deel 1 kunnen lezen dat het gebruiken van de juiste hostnaam erg belangrijk is.

Maar stel je eens voor dat we nu ruim een jaar verder zijn en je website een groot succes is. Door alle berichten en pagina’s die je hebt gemaakt, plugins in- en uitgeschakeld, alle reacties die jouw berichten hebben ontvangen – en waarvan je er vast een paar hebt verwijderd – is je achterliggende MySQL-database enorm traag geworden.

Alles wat jij en jouw bezoekers op de website doen slaat WordPress op in zijn database. Het is hierom van essentieel belang de database in topconditie te houden! Dat de databaseservers goed en optimaal geconfigureerd zijn, kun je overlaten aan de experts van Vevida, maar je database… die moet je toch zelf onderhouden en optimaal houden. “Hoe?”, vraag je je nu wellicht af. Dat behandelen we hieronder.

WordPress post-revisies

Elke keer dat je een bericht of pagina schrijft slaat WordPress dit op als een revisie. Na verloop van tijd heb je berichten al een aantal keer herschreven, en elke keer is het volledig gewijzigde bericht ook opgeslagen als revisie. Zo heb je voor één bericht misschien wel 15 revisies opgeslagen. Vermenigvuldig dit met 200 berichten, dan zijn dat 3000 onnodige revisie-berichten! Allemaal loze data.

Je kunt daarom het beste het aantal revisies beperken, of zelfs helemaal uitschakelen. Dit doe je in het wp-config.php bestand, neem daarin op

define('WP_POST_REVISIONS', 5);

om maximaal 5 revisies op te slaan. En met

define('WP_POST_REVISIONS', false);

schakel je de revisies geheel uit.

Maar ja, nu heb je 200 berichten en 3000 revisies in je database en je leest nu pas deze handleiding. Wat nu? Gelukkig is het relatief eenvoudig om alle bestaande revisies rechtstreeks in de database te verwijderen. Je hoeft hiervoor alleen maar de volgende query te kopiëren en plakken in het SQL-venster van phpMyAdmin van je database:

DELETE a, b, c
FROM `wp_posts` a
LEFT JOIN `wp_term_relationships` b on a.id = b.object_id
LEFT JOIN `wp_postmeta` c on a.id = c.post_id
LEFT JOIN `wp_term_taxonomy` d on b.term_taxonomy_id = d.term_taxonomy_id
WHERE a.post_type = "revision"
AND d.taxonomy != "link_category";
DELETE FROM `wp_posts` WHERE post_type="revision";

Uiteraard moet je het tabelvoorvoegsel wp_ nog even veranderen naar het voorvoegsel dat je gebruikt voor WordPress.

Alle revisies zijn hiermee verwijderd.

Optimaliseer MySQL tabellen

Door berichten, pagina’s, revisies en reacties te verwijderen ontstaat er loze ruimte in je database tabellen. Men noemt dat wel gefragmenteerde data. Net als de harde schijf van je computer geregeld moet worden gedefragmenteerd, moeten je database tabellen ook worden gedefragmenteerd.

Dit kan met het OPTIMIZE TABLE SQL-statement en phpMyAdmin maakt dat erg eenvoudig:

  1. Vink alle tabellen aan in het tabeloverzicht (Selecteer alles onderaan)
  2. Kies voor Optimaliseer tabel in het Met geselecteerd dropdown-menu
  3. Je krijgt een bevestiging dat de SQL-query succesvol is uitgevoerd

Tip
Ben je helemaal thuis in het schrijven van je eigen WordPress code en plugins? Dan kun je de volgende MySQLi multi_query() gebruiken om in één keer alle tabellen te optimaliseren:

SELECT CONCAT('OPTIMIZE TABLE
',GROUP_CONCAT(CONCAT(table_schema,'.',table_name)),';')
INTO @optimizecmd FROM information_schema.tables WHERE table_schema=database();
PREPARE s1 FROM @optimizecmd; EXECUTE s1;

Je kunt dit eenvoudig automatiseren in WordPress met een cron-opdracht: Optimize WordPress MySQL tables through Cron, behind the scenes

WordPress traagheid onderzoeken

Zoals eerder genoemd is het verstandig het door jou gebruikte thema en de plugins te testen op prestaties. Twee veel gebruikte plugins hiervoor zijn Debug Objects en Debug Bar:

De Debug Objects en Debug Bar plugins geven erg veel informatie, zoals trage database queries, laad- en uitvoertijd, thema- en template informatie, PHP $_GET en $_POST informatie, enzovoort. Aan de hand van al deze informatie kun je slecht presterende plugins vinden en uitschakelen, PHP code herschrijven als dat nodig is, of zelfs indices plaatsen op MySQL tabellen waar die ontbreken.

Debug Objects en Debug Bar zijn typische plugins die je tijdens het ontwikkelen van een thema en website gebruikt en daarna veelal niet meer. Misschien na verloop van tijd, om er zeker van te zijn dat alle onderdelen nog steeds goed presteren.

WordPress bonus tip, Google Page Speed Insights

Staar je niet blind op Google Page Speed Insights! Ook van belang zijn snelheidsgegevens zoals Pingdom en GTMetrix.

Een erg hoge Page Speed Insights score garandeert nog niet een snelle website en het zou zonde van alle inspanningen zijn om een score van 95/100 of hoger te hebben als de website nog steeds 3 seconden nodig heeft om geladen te zijn. Zoals WordPress ontwikkelaar Caspar Hübinger al eens schreef: F*ck PageSpeed.

WordPress bonus tip 2, all for the fun of it

Als je helemaal thuis bent in WordPress en wat diepgaandere kennis hebt van de werking van websites, IIS webservers en het herschrijven van URL’s, dan kun je heel leuke dingen doen. Just for the fun of it!

  1. Heb je meerdere webhosting pakketten bij Vevida en je gebruikt op geen enkele website de volledige webruimte? Waarom gebruik je die ongebruikte ruimte niet om content van andere sites te offloaden? Met een klein stukje PHP-code, een .htaccess-bestand en de CDN-functionaliteit van WP-Super-Cache kun je heel eenvoudig afbeeldingen, stylesheets en JavaScript van site1 opslaan binnen de webruimte van site2 en daarvandaan inladen op site1.
    In het jargon heet dat een Origin-Pull CDN: de originele content wordt van de website getrokken (pull) en beschikbaar gemaakt op een externe locatie.
  2. Met behulp van IIS Outbound Rules kun je de html-uitvoer herschrijven. Dat wil zeggen: de HTML-code die door WordPress en PHP is gemaakt kan nog worden veranderd, nog voordat deze naar de browser van de bezoeker wordt gestuurd. Leuk! Hiermee kun je bestanden op www.example.com aan de bezoeker aanbieden via cdn.example.com. Of je kunt analytics zoals Google Analytics of Matomo, in de html-uitvoer injecteren voor statistische gegevens.

Google is your friend in deze, maar met HTTP/2 is deze content-offloading niet verstandig.

Conclusie en afsluiting

Dit artikel ging niet over websiteoptimalisatie en een aantal belangrijke aspecten daarvan hebben we daarom achterwege gelaten. Dit artikel ging over WordPress optimalisatie. We hebben het eenvoudig voor elkaar gekregen om de laadtijd van een WordPress site drastisch naar beneden te brengen, door simpelweg gebruik te maken van instellingen die WordPress, IIS en Vevida jou bieden.

Deel 1 van dit artikel kun je hier vinden.

Jan Reilink Systeembeheerder

Jan Reilink is ruim 10 jaar in dienst bij Vevida als systeembeheerder. Zijn specialiteiten zijn Windows Server, IIS, PHP, websites, optimalisatie en beveiliging. Daarnaast houdt Jan al jaren een technisch blog saotn.org bij met nieuws en artikelen over deze onderwerpen.