Waarom deze site trager laadde dan hij zou moeten
We onderhouden de website van een winkel met hersteldienst, onderdeel van ons webdesign-werk voor klanten. Die site had alles wat een snelle site nodig heeft: een cache stond aan. Een cache is de kopie van een pagina die de server al klaar heeft liggen, zodat hij niet voor elke bezoeker alles opnieuw moet berekenen. Zonder cache bouwt de server elke pagina van nul op, met cache toont hij gewoon de kopie. Dat scheelt in normale omstandigheden een veelvoud aan snelheid.
Toch voelde de site traag aan. Niet af en toe, maar structureel, op elke pagina. Dat is een vreemd signaal als de cache wel degelijk draait. Als de kopie klaarligt, waarom bouwt de server dan toch nog alles opnieuw op?
Het antwoord zat in één plugin voor herstelaanvragen, en in de naam die die plugin aan zijn eigen cookie gaf. Een cookie is een klein tekstbestandje dat een site in je browser achterlaat om je te herkennen.
Hoe één cookie de hele cache omzeilde
WordPress gebruikt een cookie om te onthouden of iemand ingelogd is. Zodra die cookie aanwezig is, weet de server: deze bezoeker is ingelogd, toon hem geen algemene kopie maar bouw zijn pagina apart op, want een ingelogde gebruiker ziet soms andere knoppen of gegevens dan een gewone bezoeker.
De plugin voor herstelaanvragen gaf zijn eigen cookie, bedoeld om een lopende aanvraag te volgen, een naam die begon zoals die cookie van WordPress. Voor de cache maakte het niet uit wie de cookie geplaatst had. Ze zag alleen de naam, herkende het patroon van een ingelogde bezoeker, en sloeg zichzelf over. Voor elke bezoeker met die cookie aan boord.
Het gevolg: zo goed als elke bezoeker kreeg de site steeds opnieuw vers berekend, alsof er helemaal geen cache stond. De cache zelf werkte perfect. Ze kreeg alleen nooit de kans om iets te doen.
Wat dat in de praktijk betekende, in cijfers
We hebben dit gemeten in juli 2026. Met de cookie erbij antwoordde de server na 1.433 milliseconden, in de browser gemeten. Zonder die cookie, via een rechtstreekse test, antwoordde diezelfde server na 120 milliseconden. Dat is het verschil tussen wachten en meteen laden.
Na het hernoemen van die ene cookie zakte de reactietijd naar 45 milliseconden. Het grootste beeld op de pagina, wat Google "LCP" noemt (de tijd tot het grootste zichtbare element op het scherm staat), ging van 1.743 naar 882 milliseconden. Beide metingen komen uit dezelfde controle, juli 2026.
Dat is geen kwestie van een paar tellen sneller. Het is het verschil tussen een cache die werkt zoals bedoeld, en een cache die er wel staat maar nooit iets doet.
Voor en na, in drie metingen
Serverantwoord
Grootste beeld zichtbaar
Paginagewicht
Eigen meting, juli 2026. Serverantwoord en grootste zichtbare beeld gemeten voor en na de fix. Paginagewicht apart gemeten met PageSpeed Insights op 20 augustus 2026, na het herencoderen van video.
Waarom hetzelfde probleem twee maanden later terugkwam
Op 20 augustus 2026 kwam een update van diezelfde plugin binnen. Die update zette de naam van de cookie gewoon terug naar de oude, foute vorm. Niet uit slordigheid van onze kant: de plugin overschreef zijn eigen bestand, en daarmee ook onze correctie. De site was opnieuw traag, om exact dezelfde reden als in juli.
Dat is de les die je moet onthouden als je een externe partij je site laat onderhouden. Een fix die je aanbrengt in de plugin van iemand anders, overleeft de volgende update van die plugin niet. Wie dat niet weet, denkt bij een nieuwe traagheidsklacht dat het om een nieuw probleem gaat, terwijl het gewoon hetzelfde lek is dat terug openging.
Sinds die tweede keer staat er een controle die dit meteen opmerkt zodra het weer gebeurt, plus een klein stukje eigen code dat losstaat van de plugin. Dat stukje ruimt de foute cookie op bij bezoekers die hem al hadden meegekregen, zodat zij niet nog wekenlang buiten de cache blijven vallen terwijl de rest van de site alweer snel is.
Wat er nog meer speelde, onzichtbaar voor de bezoeker
Een traagheidsonderzoek stopt zelden bij de eerste vondst. Op deze site stonden ook een aantal ontwikkelinstellingen aan die eigenlijk enkel bedoeld zijn om fouten op te sporen tijdens het bouwen van een site, niet om op een live site te laten staan. Daardoor werden 38 scriptbestanden onverkort naar elke bezoeker gestuurd in plaats van in een verkleinde vorm. Na het uitzetten van die instellingen bleven er nog 11 over, en dat zijn bestanden van plugins die zelf geen verkleinde versie meeleveren.
Er stonden ook twee video's over elkaar in dezelfde sectie, waarvan er eentje nooit zichtbaar was omdat de andere er precies overheen lag. Die onzichtbare video werd wel gewoon geladen en afgespeeld, voor niets. Daarnaast waren de video's op de site veel groter geëxporteerd dan nodig. Na herencoderen zakte het totale paginagewicht van 7.517 kB naar 2.273 kB, gemeten met PageSpeed Insights op 20 augustus 2026.
Tot slot stonden er drie meetcontainers van Google tegelijk op de site. Dat betekent hoogstwaarschijnlijk dat bepaalde bezoeken dubbel geteld werden in de statistieken, iets wat je cijfers over bezoekers en aanvragen vertekent zonder dat je het meteen doorhebt.
Waarom de score van Google niet meteen omhoogging
De totaalscore die Google geeft voor snelheid bleef na al deze fixes rond de 60 hangen. Dat oogt teleurstellend als je net een reeks problemen hebt opgelost, dus het verdient uitleg. Voor de fix draaide op deze site de helft van de scripts nooit, door een tweede storing die we tegelijk oplosten. Een pagina die minder doet, scoort op sommige onderdelen toevallig beter, gewoon omdat er minder gebeurt. Die oude score was dus geflatteerd, geen echte prestatie.
Nu de cache wel werkt en de site zijn scripts wel degelijk uitvoert, meet Google eerlijker wat er werkelijk gebeurt. De volgende stap naar een hogere score zit niet meer in caching, want dat stuk staat nu goed. Ze zit in minder scripts laten draaien in de eerste plaats.
Dat is meteen waar dit soort onderhoud zijn geld waard is: niet in een belofte over een score, maar in het blijven volgen van wat er na elke wijziging echt verandert. Het is ook een reden om, als je de kostprijs van een website bekijkt, niet enkel naar de bouw te kijken, maar ook naar wie erna nog meet.
“De cache stond aan en werkte perfect. Ze kreeg alleen nooit de kans om iets te doen.”
Veelgestelde vragen
Kan zoiets ook op mijn eigen site gebeuren?
Ja, telkens als een plugin zijn eigen cookie een naam geeft die toevallig lijkt op een cookie die WordPress al gebruikt. Hoe meer plugins een site heeft, hoe groter die kans. Het valt niet te zien aan de buitenkant van de site, enkel in de techniek erachter.
Hoe weet ik of mijn cache echt werkt en niet gewoon aanstaat?
Aanstaan en werken zijn twee dingen. Vraag na of iemand regelmatig meet hoe snel de server antwoordt, en niet enkel controleert of de cache-instelling op "aan" staat.
Moet ik me zorgen maken telkens ik een plugin update?
Niet zelf uitpluizen, maar wel vragen of degene die je site onderhoudt na een update controleert of alles nog even snel is als ervoor. Een update kan een eerdere fix ongedaan maken zonder dat er iets op de site zelf verandert.
