Trage websites worden door Google afgestraft en jagen gebruikers weg. Het populaire CMS WordPress doet er lang over om pagina’s te laden en wordt bij hoge belasting erg traag. Met Vinyl Cache geef je je webpagina’s een boost.
WordPress versnellen zonder ingrijpende aanpassingen
Een internetgebruiker, vooral als hij via een zoekmachine naar informatie zoekt, heeft een zeer kleine aandachtspanne. Dat is een uitdaging voor websitebeheerders: als een website te lang laadt, zijn de gebruikers weg voordat de webserver alle inhoud geleverd heeft. Google merkt dat op zijn beurt ook op, waardoor de website zakt in de gunst van de zoekmachine.
Het is dan ook frustrerend dat juist WordPress van nature niet bekend staat om zijn uitmuntende snelheid. Er zijn echter verschillende manieren om WordPress-pagina’s te versnellen. Meestal grijpen ze via een plug-in diep in de WordPress-instantie in.
Een andere manier: je zet de cacheserver Vinyl naast WordPress, die kant-en-klare HTML-pagina’s in het RAM bewaart, en degradeert WordPress daarbij tot leverancier voor de cache.
We beloven niet te veel: door de aanpassing die we in dit artikel beschrijven, zul je je WordPress-website niet meer herkennen. Terloops leer je hoe je je website systematisch onder belasting kunt testen met de tool k6.
Stand van zaken
Voorafgaand aan de optimalisatie is het de moeite waard om de status quo van een WordPress-installatie en de redenen voor de traagheid te bekijken. In de standaardconfiguratie moet een webserver met al zijn diensten flink aan de bak als er een HTTP-request van een browser binnenkomt. De gebruiker wil bijvoorbeeld de pagina zien die zich op example.org/over-ons/team bevindt.
Dat request leidt niet eenvoudigweg naar een HTML-pagina in de map /over-ons/team, die de server enkel van de harde schijf hoeft te lezen. In plaats daarvan, en dat staat vastgelegd in een webserverconfiguratiebestand, wordt zo’n request doorgestuurd naar de pagina index.php. Bestanden met de extensie .php stuurt de server vervolgens door de PHP-interpreter. Via een omweg zet die de scripttaal PHP om in machinecode (iets versneld door een just-in-time-compiler en een cache voor machinecode).
De code wordt vervolgens uitgevoerd en doet zijn werk.
In het geval van WordPress betekent dat: de software bepaalt aan de hand van het doorgegeven request /over-ons/team welke pagina opgevraagd wordt, raadpleegt de databaseserver (meestal MariaDB of MySQL) en haalt daar de ruwe inhoud van de pagina op.
Die ruwe gegevens worden vervolgens samen met het WordPress-thema samengevoegd en gevormd tot een HTML-bestand. Die door het PHP-programma samengestelde pagina wordt uiteindelijk door de webserver geleverd. Onderweg worden diverse functies van het thema en de plug-ins uitgevoerd, die bijvoorbeeld verantwoordelijk zijn voor widgets en ontwerpelementen.
Dat er ondanks die verwerkingsketen doorgaans binnen milliseconden in plaats van enkele seconden een voltooide webpagina wordt teruggestuurd, hebben de websitebeheerders te danken aan de snelheid van de moderne processors.
Een dergelijk systeem bereikt echter zijn grenzen, zeker wanneer veel gebruikers tegelijkertijd zo’n pagina bezoeken. Een eenvoudig experiment laat zien hoe WordPress zich onder belasting gedraagt en waar de grenzen liggen. We hebben dat uitgevoerd op een lokale testomgeving met Docker. Een dergelijke omgeving is snel opgezet.
In het kader rechts zie je de inhoud van een Docker-Compose-bestand (de link om het te downloaden staat bij dit artikel) voor een nieuwe WordPress-instantie die reageert op poort 8080 en haar gebruikersgegevens opslaat in de map data op de lokale schijf.
Als je de tests wilt nadoen, kopieer je de regels naar een bestand met de naam docker-compose.yml op een ontwikkel-pc of server met Docker – of dat nu Windows, Linux of macOS is, maakt niet uit.
services:
db:
image: mysql
./data/sql/database/:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: secretwordpress
MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on:
- db
image: wordpress:latest
ports:
- "8080:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
working_dir: /var/www/html
volumes:
./data/wp/wp-content:/var/www/html/wp-content
Het docker-compose.yml-bestand definieert een gecontaineriseerde WordPress-instantie zonder cache en optimalisaties. Tot de basisuitrusting behoren een database en een webserver met WordPress en PHP.
Navigeer vervolgens op de commandline naar de map met het bestand en start de samenstelling met
docker compose up -d
Docker start een WordPress-instantie (met de webserver Apache) en een MySQL-database. Als je op dezelfde computer het adres http://localhost:8080 in de browser opent, moet het installatiescherm van WordPress verschijnen.
Voor de belastingtest hebben we alleen het hoogstnodige geconfigureerd: log daarvoor in op het back-end (te vinden op http:// localhost:8080/wp-admin), klik links in het menu op Instellingen / Permalinks en activeer de permalinkstructuur Berichtnaam.
Maak vervolgens een nieuwe pagina aan met de titel Belastingtest. We hebben onze testpagina gevuld met precies 5000 tekens tekst, zodat de server ook wat te doen krijgt.
Na een klik op Publiceren is de pagina bereikbaar via het adres http://localhost:8080/belastingtest.
Belasting testen
Een veelzijdig hulpmiddel voor belastingtests is de opensource commandlinetool k6, afkomstig van Grafana Labs. De software is beschikbaar als pakket voor veel besturingssystemen en pakketbeheerders (waaronder Homebrew, Apt, Dnf en Winget). De officiële documentatie legt het installeren voor alle besturingssystemen uit (zie de link bij dit artikel).
k6 verwerkt in JavaScript geschreven recepten en is in staat om op gedefinieerde intervallen gelijktijdige bezoeken aan een pagina te genereren. Het testscript om WordPress aan het zweten te brengen, staat in het kader.
import http from "k6/http";
import { check, sleep } from "k6";
export const options = {
stages: [
{ duration: "30s", target: 100 },
{ duration: "1m", target: 500 },
{ duration: "0", target: 1000 },
{ duration: "20s", target: 1000 },
{ duration: "20s", target: 0 },
],
};
export default function () {
let res = http.get("http://localhost:8080/lasttest");
check(res, { "status was 200": (r) => r.status == 200 });
sleep(1);
}
Dit zorgt voor belasting op elke server: een JavaScript-bestand wordt beschreven in welke fasen de software virtuele gebruikers naar de server moet sturen. De belastingtest simuleert tot wel 1000 gelijktijdige gebruikers.
In een JavaScript-bestand voor k6 beschrijf je welke stappen de software virtuele gebruikers naar de server moet sturen. De belastingtest simuleert tot 1000 gelijktijdige gebruikers.
Dit artikel gaat verder niet over de fijne kneepjes van k6, die software kan veel meer dan wat je nodig hebt voor een eenvoudige belastingtest.
Het eenvoudige script bevat vier fasen, stages genaamd. Per fase is één doel gedefinieerd dat aangeeft hoeveel gelijktijdige virtuele gebruikers toegang moeten krijgen tot de pagina en in welk tempo de belasting wordt opgebouwd of afgebouwd.
De instructie bij deze test luidt: 30 seconden van 0 naar 100 virtuele gebruikers, vervolgens binnen een minuut omhoog naar 500, daarna een snelle sprong naar 1000 gelijktijdige gebruikers die 20 seconden lang toegang hebben. Vervolgens wordt het aantal gebruikers binnen 20 seconden teruggebracht naar 0.
De functie aan het einde van het bestand definieert wat de virtuele gebruikers moeten doen: het adres http://localhost:8080/belastingtest oproepen met de GET-methode, controleren of er een status 200 is teruggestuurd en vervolgens een seconde wachten.
De test komt met een piek van 1000 virtuele gebruikers overeen met een scenario waarin 1000 gebruikers elke seconde de browser aan het werk zetten met de F5-toets op hun toetsenbord en de pagina steeds opnieuw laden.
Als je je lokale WordPress wilt testen, sla je het JavaScript-bestand op met een naam als load.js en voer je (na het installeren van k6) het volgende commando uit:
K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=report.html k6 run load.js
De twee omgevingsvariabelen aan het begin geven het programma de opdracht om een dashboard met de meetresultaten weer te geven en na de test een HTML-rapport naar het bestand report.html te schrijven.
De resultaten voor een WordPress-instantie zonder cache waren op ons testsysteem, een MacBook Pro uit 2021 met M1 Max-processor, enigszins ontnuchterend: tot bijna 450 virtuele gebruikers duurde het gemiddeld ongeveer 120 milliseconden om de pagina op te halen. Niet razendsnel, maar bruikbaar.
Vanaf 450 virtuele gebruikers sloeg de stemming om: de eerste HTTP-requests mislukten met een foutstatus. De server leverde op geen enkel moment meer dan 137 succesvolle responses per seconde, ongeacht het aantal virtuele gebruikers – meer requests leidden alleen maar tot meer fouten.
Bij de sprong naar 1000 virtuele gebruikers schoot het aantal mislukte requests omhoog naar een onaanvaardbare 5 procent. Zelfs een afname van de stroom aan requests leidde niet tot snelle verbetering, zoals blijkt uit de responstijden voor het 95e percentiel: terwijl de vraag al afnam, werd de traagste 5 procent van de requests in bijna 60 seconden beantwoord.
Bij zo’n hoog foutenpercentage is de gemiddelde responsetijd relatief onbelangrijk. Die lag tijdens piekuren op 60 seconden, wat precies overeenkomt met de time-outtijd van k6.
Veel belangrijker: als je tegelijkertijd probeerde de pagina lokaal in de browser te openen, gebeurde er eerst niets, totdat de browser uiteindelijk een time-outfoutmelding gaf. Zo’n website is simpelweg onbruikbaar.
En erger nog: gebruikers hebben bij dergelijke laadproblemen paradoxaal genoeg de neiging om steeds opnieuw te laden, wat het probleem alleen maar verergert.
Hulp in nood
Genoeg van het brute geweld tegen een weerloze WordPress. Als redder moet de opensource cacheserver Vinyl zich in de stroom van requests werpen en de gebruikersstroom weghouden van de webserver en de database.
Vinyl zit momenteel in een naamswijzigingsproces dat in december 2025 begonnen is: 20 jaar lang heette het Varnish en een bedrijf, Varnish Software, ontwikkelt ook een Enterprise-versie. De commerciële versie en de opensourcesoftware moeten nu duidelijker gescheiden naast elkaar bestaan, daarom is besloten om de vrije software om te dopen tot Vinyl Cache. Omdat de naamsverandering in volle gang is, zul je bij zoekopdrachten op internet naar Vinyl af en toe het woord Varnish tegenkomen.
Ook de containerimage draagt nog de oude naam. Voor zoekmachines is de nieuwe naam ook nog minder geschikt –dan leidt het zoeken naar Vinyl Cache al snel naar Varnisch Cache.
Vinyl werkt als een HTTP-reverse-proxy, waaraan je in een configuratiebestand aangeeft waar het pagina’s kan ophalen en hoe het die moet cachen. Als er bijvoorbeeld een HTTP-request binnenkomt voor de pagina /overons/team, haalt Vinyl die bij de eerste toegang intern op bij WordPress, slaat hem op in het werkgeheugen en levert hem aan de daarnaar vragende clients.
Maar als je ooit een cache beheerd hebt, weet je ook: cachen is eenvoudig, een cache ongeldig maken is moeilijk. Of concreet: Vinyl moet weten wanneer een auteur een pagina heeft bewerkt en de oude versie dan uit de cache verwijderen, zodat gebruikers voortaan de nieuwe versie zien.
Daarvoor moet het back-endsysteem, in dit geval WordPress, bij elke nieuwe publicatie intern contact opnemen met de Vinyl-server en een HTTP-request met het werkwoord PURGE (dat geen deel uitmaakt van de webstandaarden) versturen. Die taak wordt later overgenomen door een WordPress-plug-in.
Genoeg theorie. De praktijk begint met de bestaande WordPress-instantie. Als je de hierboven beschreven Docker Compose-configuratie draait, sluit je die eerst af met
docker compose down
De volgende regels in docker-compose.yml kun je dan verwijderen omdat WordPress de requests niet meer zelf moet beantwoorden:
ports:
- "8080:80"
Vervolgens moet je het Docker Compose-bestand uitbreiden met een fragment voor Varnish (zie het kader). Met die configuratie krijg je een container uit de image varnish:stable – bij de Docker-image is de naamswijziging nog niet voltooid.
vinyl:
image: varnish:stable
depends_on:
- wordpress
ports:
- 8080:80
environment:
- VARNISH_SIZE=2G
volumes:
- ./default.vcl:/etc/varnish/default.vcl:ro
tmpfs: /var/lib/varnish:exec
Een container voor Vinyl: de cacheserver zal voortaan de requests afhandelen.
De container luistert op alle netwerkinterfaces op poort 8080. Aan de container worden een configuratiebestand met de naam default.vcl en een tijdelijk bestandssysteem (tmpfs) voor de inhoud van de cache doorgegeven.
Voordat je de build start, heb je het configuratiebestand default.vcl nodig. Voor WordPress hebben we een bestand van 180 regels voorbereid, dat we niet volledig kunnen afdrukken. Je kunt het bij dit artikel downloaden.
De basis voor dat bestand is een configuratie die Varnish Software op zijn ontwikkelaarsportal gepubliceerd heeft. Aan de hand daarvan kun je goed zien hoe een Vinyl-configuratie er doorgaans uitziet en aan welke knoppen je kunt draaien.
Als die details je niet interesseren, ga dan naar het gedeelte ‘Starten met cachen’.
Aan het begin van het bestand leert Vinyl waar het back-end te vinden is waar de inhoud vandaan komt:
backend default { .host = "wordpress";
.port = "80";
}
Omdat de Vinyl- en de WordPress-container in hetzelfde Docker-Compose-bestand gedefinieerd zijn, bevinden ze zich ook in hetzelfde Docker-netwerk en vinden ze elkaar via een interne DNS-server op basis van hun servicenamen. Daarom heet de host intern wordpress.
Daarna volgt de definitie van wie bevoegd is om een pagina via PURGE uit de cache te verwijderen – dat mag alleen wordpress:
acl purge {
"wordpress";
}
Vervolgens komen de subroutines die Vinyl op verschillende momenten tijdens een request uitvoert. De eerste subroutine in de keten heet vcl_recv en wordt uitgevoerd wanneer het request bij Vinyl binnenkomt. In die fase kun je bijvoorbeeld reageren op het HTTP-verb en beslissen hoe met het request moet worden omgegaan.
Met de methode return() definieer je welke weg het request inslaat. Vinyl kent onder andere de paden return(pass) (request gaat naar het back-end, maar wordt niet in de cache opgeslagen), return(pipe) (request gaat naar het back-end en wordt in de cache opgeslagen) en return(purge) (object wordt uit de cache verwijderd).
Het volgende fragment stuurt alle HTTP-verbs die niet GET en HEAD zijn, langs de cache.
Met die configuratie wordt bijvoorbeeld formulierinvoer met de POST-methode niet in de cache opgeslagen:
if (req.method != "GET" && req.method != "HEAD") {
return(pass);
}
Het configuratiebestand bevat enkele details voor WordPress-omgevingen en geeft Vinyl bijvoorbeeld de opdracht om typische queryparameters van analysetools uit het request te verwijderen.
Als je dat niet doet, zou Vinyl elk request dat met een dergelijke parameter binnenkomt (bijvoorbeeld /overons/team?_ga=123456) afzonderlijk doorgeven aan WordPress en de response in de cache opslaan. Dan zou het cache-effect gelijk aan nul zijn en zou het geheugen van Vinyl vol raken met duplicaten.
Sterk ingekort ziet de benodigde configuratie om de trackingparameter _ga te verwijderen er als volgt uit:
if (req.url ~ "(\?|&)(_ga)= ") {
set req.url = regsuball(req.url, "(_ga)=[-_A-z0-9+(){}%.*]+&?","");
set req.url = regsub(req.url, " [?|&]+$", "");
}
Bepaalde pagina’s die bij een WordPress-installatie horen, mogen in principe niet in de cache terechtkomen, waaronder bijvoorbeeld het volledige back-end onder /wp-admin. Ook dat wordt geregeld in de subroutine vcl_recv. Sterk ingekort ziet de instructie er als volgt uit:
if (
req.url ~ "^/register.php" ||
req.url ~ "^/wp-admin" ||
req.url ~ "^/wp-login.php" ||
req.url ~ "^/wp-activate.php" ||
req.url ~ "^/wp-mail.php" ||
req.url ~ "^/wp-login.php" ||
) {
return(pass);
}
In het volledige configuratiebestand wordt de cache ook altijd omzeild als je bent ingelogd in het back-end. Daarvoor controleert Vinyl of er een sessiecookie wordt doorgegeven en stuurt dergelijke requests vervolgens via return(pass) langs de cache.
In dit artikel gaan we niet dieper in op de verdere subroutines die later in de keten verwerkt worden. Als je alle functies van Vinyl wilt verkennen, neem dan een kijkje in de uitgebreide documentatie (zie de link bij dit artikel).
In vcl_backend_response (wordt uitgevoerd wanneer de response van het back-end binnen is) en vcl_deliver kun je bijvoorbeeld de HTTP- responseheaders opschonen en nieuwe headers instellen die naar de client verzonden worden.
Starten met cachen
Om WordPress achter een Vinyl-cache te draaien, zet je het bestand default.vcl naast het Docker Compose-bestand waarin je de Vinyl-cachecontainer toegevoegd hebt.
Start de combinatie vervolgens opnieuw op met
docker compose up -d
Als je de pagina dan in de browser laadt, wordt hij waarschijnlijk al door Vinyl geleverd. Of hij uit de cache kwam, kun je zien bij de ontwikkelaarstools van de browser (vaak te openen via de F12-toets). Zoek daar naar het tabblad Netwerk en kijk naar de responsheaders.
Als op de lijst de header X-Cacheable met de waarde YES:Forced staat, is de pagina in de cache opgeslagen. Staat daar NO:Logged in/Got Sessions, dan wordt de cache momenteel omzeild omdat je momenteel bent ingelogd bij het WordPress-back-end en de voor WordPress typische cookies geplaatst zijn.
Verwijder ter test de cookies voor de pagina (ook dat kan bij de ontwikkelaarstools van de browser) of gebruik een incognitobrowser of de incognitomodus.
Op de lijst met headers staan nog meer headers zoals X-Varnish, X-Powered-By, Via en Server, die details over de server, Varnish en PHP onthullen. Sommige zijn afkomstig van Vinyl, andere van WordPress. Als je die informatie niet wilt delen, kun je het bestand default.vcl helemaal aan het einde bij de subroutine vcl_deliver met enkele regels aanvullen en die (en eventueel andere) headers vóór de levering verwijderen:
unset resp.http.x-varnish;
unset resp.http.x-powered-by;
unset resp.http.via;
unset resp.http.server;
# optioneel: X-Cacheable verwijderen:
unset resp.http.x-cacheable;
Na een wijziging volstaat een herstart van de container en zijn de headers verdwenen:
docker compose restart vinyl
Cache verwijderen
Voor de voltooide installatie ontbreekt nog de plug-in die Vinyl met PURGE-commando’s informeert dat een pagina bijgewerkt is. Log in met beheerdersrechten bij het WordPress-back-end en ga links in het menu naar Plugins / Plugin toevoegen.
Typ bovenaan bij de zoekbalk Proxy Cache Purge in en installeer die plug-in, die een mediterend konijn met tulband als afbeelding gebruikt. Activeer hem vervolgens, waarna hij links in het menu verschijnt.
Open de instellingenpagina van de plug-in en scroll naar beneden. Voer daar bij Set custom IP de naam van de Vinyl-container in: vinyl. De interne DNS-server van Docker doet de rest.
Sla helemaal onderaan op met Save Purge Header Settings.
Je kunt de ingebouwde testfuncties van de plug-in alleen gebruiken als je server bereikbaar is via internet, bij een lokale testomgeving werken ze niet. Test de PURGE-functie daarom het beste handmatig door twee browsers te openen. Bij de eerste ben je aangemeld en wijzig je iets op de pagina /belastingtest. Bij de tweede browser zou je die wijzigingen meteen moeten zien.
Test onder belasting
Dan is Vinyl klaar voor het echte werk. Open opnieuw een commandline-sessie en start k6 voor een nieuwe ronde. De resultaten moeten deze keer in het bestand vinyl.html terechtkomen:
K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=vinyl.html k6 run load.js
Bij onze tests waren de resultaten indrukwekkend: zelfs bij lage belasting is er al een duidelijk verschil te zien. Duurde het laden van een pagina zonder cache bij een lage belasting nog meer dan 120 milliseconden, het gemiddelde daalde met Vinyl naar 4 milliseconden. Daarbij werd 99 procent van alle requests door de cache in minder dan 22 milliseconden geleverd.
Zelfs de sprong naar 1000 virtuele gebruikers bracht Vinyl niet ten val. Op het hoogtepunt leverde de server 1000 HTTP-responses per seconde (zonder cache werd bij 137 responses per seconde de bovengrens bereikt), geen enkel request mislukte en zelfs bij de hoogste belasting duurden de responses gemiddeld slechts 20 milliseconden.
Tussentijdse conclusie: een Vinyl-server die door 1000 gebruikers per seconde tegelijk benaderd wordt, reageert nog steeds sneller dan een WordPress-server zonder enige belasting!
Gedurende de gehele testperiode duurde een response met cache gemiddeld 7 milliseconden, zonder cache 2 seconden.
In de praktijk
Om die kennis toe te passen op je eigen WordPress-website zijn, afhankelijk van de omgeving, nog enkele extra stappen nodig. Als je je website tot nu toe bij een webhost beheert, waarbij je alleen bestanden via SFTP of soortgelijke methoden in een map uploadt, kun je daar niet zo makkelijk een Vinyl-cache voor plaatsen. Bij dergelijke webhostingproducten beheert de aanbieder de serversoftware.
Ook bij Managed WordPress-pakketten ben je niet in de positie om een Vinyl-server in te zetten. Je hebt absoluut een server nodig waarop je zelf bepaalt wat er draait – bijvoorbeeld een zelf beheerde of gehuurde virtuele of fysieke machine waarop je volledige root-toegang hebt.
Het goede nieuws: met Vinyl Cache wordt zelfhosting weer aantrekkelijk, zelfs als je veel bezoekers verwacht. In theorie heeft zelfs een Raspberry Pi voldoende rekenkracht en werkgeheugen om een met Vinyl gecachete WordPress-website aan veel bezoekers tegelijk te leveren.
Tijdens de belastingtest met k6 nam de Vinyl-container zelfs bij 1000 virtuele gebruikers niet meer dan 1 GB RAM in beslag. Als je over een geschikte Linux-omgeving beschikt, kun je bijvoorbeeld je bestaande installatie naar Docker-containers verplaatsen en het Docker-Compose-bestand uit dit artikel als sjabloon gebruiken.
Een essentieel onderdeel dat Vinyl niet levert en dat het project ook niet wil leveren, is de omgang met TLS en certificaten. Maar dat is geen probleem: plaats Vinyl achter een reverse-proxy zoals Traefik of Caddy, die zorgt voor het verkrijgen en automatisch vernieuwen van certificaten.
Ondanks die reverse-proxy-cascade wordt de pagina snel geleverd, ook Traefik kan hoge belasting aan. De verhuizing kost ongetwijfeld werk, maar dat is de moeite waard: enerzijds beloont Google snelle websites, anderzijds ben je met een cache goed voorbereid op de situatie dat je organisatie plotseling in de publieke belangstelling staat.
Het zou gênant zijn als je bedrijf voor het eerst voor veel geld televisiereclame vertoont en seconden later de WordPress-server crasht.
Responssnelheid met Vinyl Cache
Bij de belastingtest verhoogt k6 het aantal virtuele gebruikers tot maximaal 1000. Vinyl Cache heeft daar geen problemen mee, de responssnelheid stijgt tot bijna 1000 responses per seconde.
Jan Mahn en Noud van Kruysbergen
Praat mee