Af en toe 3 seconden trager zonder boosdoener tussen de plugins
Symptomen
Uit de cache laadden pagina's in ongeveer 0,15 s. Zonder cache (winkelwagen, checkout, inloggen, eerste bezoek na het legen van de cache) schommelde het tussen 0,8 en 4 s. Gevoelsmatig: „de website is soms lui”.
Omgeving
WordPress met WooCommerce, een page builder en zo'n 40 actieve plugins, gedeelde hosting met LiteSpeed en de bijbehorende cache.
Diagnose
- Herhaalde metingen. Een paar pagina's hebben we buiten de cache elke 75 s geladen, een aantal minuten lang. De vertraging was niet gebonden aan de homepage: een gewone tekstpagina had er net zo vaak last van. Ongeveer de helft van de aanvragen in de reeks had +3 s. Precies 3 s extra leek op een time-out van een externe aanroep (licentieserver, API, lettertypen).
- Tijdelijke diagnostische mu-plugin (met toestemming, zonder persoonsgegevens). Die logde de tijd tot de belangrijkste fases van de aanvraag (
muplugins_loaded,plugins_loaded,init,wp_loaded,template_redirect,shutdown) en elke externe HTTP-aanroep via de filterspre_http_requestenhttp_api_debug. - Het resultaat was verrassend: trage aanvragen (ongeveer 3,3 s, grofweg één op de vijftien) hadden geen enkele externe HTTP-aanroep. Alle fases waren gelijkmatig vertraagd, het meest de start tot
plugins_loaded(1,3 s in plaats van 0,12 s). Geen enkele plugin sprong er dus uit. - De mu-plugin en zijn log hebben we direct na de meting verwijderd en gecontroleerd dat het adres 404 geeft.
Oorzaak
Een gelijkmatige vertraging van de hele aanvraag zonder externe aanroepen past bij een koud PHP-proces op gedeelde hosting. De aanvraag krijgt een nieuw proces met een lege opcache, dat de code van alle plugins opnieuw moet laden en compileren. Een plugin of de website kan daar niets aan doen.
Wat er dreigt als je niets doet
Juist de pagina's waarop je verdient, zijn traag: winkelwagen, checkout en klantaccount. Elke seconde extra wachten verhoogt het aantal verlaten winkelwagens en Google telt een trage serverreactie mee in de beoordeling van de snelheid. Bovendien kost zoeken naar een boosdoener tussen de plugins tijd en geld voor onnodige ingrepen.
Reparatie
Aan de kant van de website valt niets te repareren. We hebben aangeraden:
- de support van de hosting te vragen naar het aantal PHP-processen, hoe lang ze leven en hoe groot de opcache is,
- op termijn het aantal actieve plugins te verminderen, zodat een koude start korter duurt.
Bezoekers die pagina's uit de cache krijgen, hebben er geen last van.
Controle
De belangrijkste bevinding was een uitsluiting: geen externe aanroep en geen afzonderlijke plugin. Daarmee hebben we uren blind plugins uitzetten bespaard.
Preventie en lessen
Meet voordat je een boosdoener tussen de plugins gaat zoeken welke fases van de aanvraag vertragen. Vertragen ze allemaal evenveel, dan zit het probleem onder WordPress (PHP, schijf, hosting), niet erin.
Gerelateerde diensten: Storingen en fouten Website versnellen