Naar de inhoud
NL

Home / Praktijkvoorbeelden

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

  1. 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).
  2. 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 filters pre_http_request en http_api_debug.
  3. 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.
  4. De mu-plugin en zijn log hebben we direct na de meting verwijderd en gecontroleerd dat het adres 404 geeft.
Een trage aanvraag is in alle fases trager Ongeveer elke vijftiende aanvraag duurde meer dan 3 seconden. De uitsplitsing in fases liet zien dat alle fases gelijkmatig vertraagden en dat er geen externe aanroep was. Dat wijst op een koude start van PHP, niet op een plugin. Reactietijd buiten de cache 3,3 s normaal 0,8–1 s Waar de tijd verloren gaat (fases van WordPress) snel traag Alle fases evenveel langer, zonder externe aanroepen → koude start van PHP.
Ongeveer elke vijftiende aanvraag duurde meer dan 3 seconden. De uitsplitsing in fases liet zien dat alle fases gelijkmatig vertraagden en dat er geen externe aanroep was. Dat wijst op een koude start van PHP, niet op een plugin.

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

Herken je deze symptomen?

Stuur me het adres van je website en beschrijf de symptomen. De diagnose is gratis en vrijblijvend. Ik reageer meestal binnen één werkdag.

Symptomen beschrijven

of mail direct naar [email protected]