U kijkt een keer in de logbestanden van uw hosting, of iemand van de helpdesk stuurt u een overzicht, en één regel springt eruit: wp-admin/admin-ajax.php. Duizenden keren per dag, soms met een responstijd van meerdere seconden. Dat ziet er alarmerend uit, en het is de reden dat mensen gaan zoeken op admin-ajax traag.

De eerlijke samenvatting vooraf: in de meeste gevallen is dit bestand niet stuk en is uw site niet gehackt. Het is een normaal onderdeel van WordPress dat door plugins wordt gebruikt. Maar het is wel een prima indicator. Waar dit bestand oploopt, zit vrijwel altijd een plugin die meer werk doet dan nodig is. In dit artikel leest u hoe het bestand werkt, wanneer u zich zorgen mag maken en hoe u de veroorzaker aanwijst zonder gok- en giswerk.

Wat dit bestand eigenlijk doet

WordPress heeft een vaste plek waar de browser tussentijds iets aan de server kan vragen zonder de hele pagina opnieuw te laden. Dat is admin-ajax.php. Ondanks de naam wordt het net zo goed aan de voorkant van uw site gebruikt als in het beheerscherm.

Voorbeelden die u waarschijnlijk herkent:

  • Een winkelwagen die het aantal artikelen bijwerkt terwijl u op de pagina blijft.
  • Een productfilter dat de lijst ververst zonder herladen.
  • Een contactformulier dat de verzending afhandelt.
  • Een zoekveld dat suggesties toont terwijl u typt.
  • Een teller in het beheerscherm die bijhoudt hoeveel bestellingen er binnen zijn.

Elk van die acties is één aanroep. Een site met tien bezoekers die allemaal wat rondklikken, kan zo honderden aanroepen per uur veroorzaken. Dat is niet verkeerd; dat is het bestand dat zijn werk doet.

Het pijnpunt zit in hoe zo’n aanroep wordt afgehandeld. WordPress start bij elke aanroep opnieuw op: de kern wordt geladen, alle actieve plugins worden geladen en het thema komt erbij. Pas daarna wordt het kleine taakje uitgevoerd. Bij een site met veertig plugins kost dat opstarten meer tijd dan het antwoord zelf. En omdat het geen gewone pagina is, slaat uw cacheplugin het antwoord meestal niet op.

Wanneer admin-ajax traag echt een probleem is

Drie signalen bepalen of u iets moet doen.

Het aantal aanroepen staat niet in verhouding tot uw bezoek. Heeft u tweehonderd bezoekers per dag en ziet u twintigduizend aanroepen, dan gebeurt er iets buiten uw bezoekers om. Vaak is dat een plugin die elke vijftien seconden bij de server informeert of er nieuws is, ook bij een tabblad dat al een uur openstaat.

De gemiddelde responstijd loopt op. Onder de driehonderd milliseconden is prima. Boven de anderhalve seconde merkt uw bezoeker het: het filter blijft draaien, de winkelwagen loopt achter, de knop reageert traag.

Het valt samen met andere klachten. Wordt uw beheerscherm zwaar op momenten dat er niets bijzonders gebeurt, of geeft uw hosting aan dat u tegen de limiet van gelijktijdige processen aanloopt, dan is dit meestal de bron. Bij gedeelde hosting is dat aantal processen krap, en elke aanroep bezet er een.

Ziet u geen van deze drie, dan is een hoog aantal regels in het logbestand simpelweg het bewijs dat uw site gebruikt wordt. Laat het dan met rust.

De veroorzaker opsporen

U hoeft hiervoor geen ontwikkelaar te zijn. Werk deze volgorde af.

  1. Open het netwerktabblad in uw browser. Druk op F12, kies Netwerk, filter op “admin-ajax” en laad uw pagina. Blijf daarna dertig seconden stilzitten zonder te klikken. Komen er dan nog steeds aanroepen binnen, dan is er iets dat uit zichzelf blijft pollen.
  2. Klik op zo’n aanroep en kijk bij de verzonden gegevens naar het veld action. Daar staat een naam, bijvoorbeeld iets met “wc_” voor WooCommerce of een naam die duidelijk bij een pluginmerk hoort. Dat is uw aanwijzing.
  3. Zoek die naam op in uw pluginmap. Kunt u niet bij de bestanden, plak de naam dan in een zoekmachine; bij bekende plugins levert dat direct een treffer op.
  4. Meet de zwaarte, niet alleen het aantal. Een gratis profileringsplugin als Query Monitor laat zien hoeveel databasevragen zo’n aanroep kost. Vijftig vragen voor het bijwerken van een winkelwagentelling is veel.
  5. Test met uitschakelen op een testomgeving. Zet de verdachte plugin daar uit en kijk of het aantal aanroepen instort. Doe dit nooit rechtstreeks op uw live site tijdens kantooruren.

Vaste verdachten die we in de praktijk vaak tegenkomen: winkelwagenfragmenten van WooCommerce op elke pagina, chatvensters die permanent verbinding zoeken, bezoekersstatistieken die in WordPress zelf worden bijgehouden, en pagebuilder-onderdelen zoals tellers en tickers die zichzelf verversen.

Wat u eraan kunt doen

De oplossing is bijna nooit “dat bestand blokkeren”. Doet u dat, dan sneuvelen uw formulieren en uw winkelwagen. Werk van licht naar zwaar.

  • Beperk waar het nodig is. De winkelwagenteller hoeft niet op uw blogartikelen te werken. Veel snelheidsplugins hebben hiervoor een kant-en-klare optie.
  • Verhoog het interval van de hartslag. WordPress zelf klopt standaard elke vijftien seconden in de editor en elke minuut daarbuiten. Naar zestig seconden zetten scheelt merkbaar, zonder dat u iets verliest behalve een fractie van de automatische opslag.
  • Vervang een zware plugin door een lichte. Statistieken die u ook in een extern pakket kunt bekijken, hoeven niet in uw eigen database te worden weggeschreven.
  • Zet objectcaching aan als uw hosting dat aanbiedt. Dat scheelt vooral bij aanroepen die telkens dezelfde gegevens ophalen; meer daarover leest u in de uitleg over objectcaching met Redis.
  • Kijk of uw hosting toereikend is. Loopt u tegen een limiet van gelijktijdige processen aan, dan is een pakket met meer ruimte soms goedkoper dan dagen sleutelen.

Een voorbeeld: een groothandel met een besloten klantportaal zag bij piekmomenten foutmeldingen. In het netwerktabblad bleek een meldingenplugin elke tien seconden te vragen of er nieuwe berichten waren, bij elk ingelogd tabblad. Met vijftien medewerkers die de hele dag ingelogd stonden, waren dat ruim vijftigduizend aanroepen per dag. Het interval naar vijf minuten zetten loste het op; niemand heeft het gemerkt.

Waar de grens ligt

Dit is een onderwerp waarbij u ver komt met kijken en één instelling wijzigen. Wordt het ingewikkelder, bijvoorbeeld omdat de aanroepen uit uw eigen maatwerkcode komen of omdat het uitschakelen van de verdachte plugin de bestelflow breekt, dan is meekijken door iemand die dagelijks in dit soort logbestanden zit sneller dan zelf doorspitten. Dat is precies het werk dat onder het doorlichten van een trage WordPress-site valt, en bij WebMaintor begint zo’n traject standaard met een meting in plaats van met een aanname.

Concrete volgende stap: open uw site, druk op F12, filter het netwerktabblad op admin-ajax en wacht een halve minuut zonder te klikken. Wat er in die dertig seconden binnenkomt, vertelt u binnen een minuut of u een probleem heeft of alleen een druk logbestand. Wilt u het bredere plaatje, kijk dan ook naar welke meettools bruikbare cijfers geven.