Ajax is een webtechnologie die is gebaseerd op JavaScript en helpt je bij het bouwen van interactieve en dynamische websites. WordPress gebruikt Ajax voor allerlei belangrijke functies binnen de beheerdersomgeving, zoals het automatisch opslaan van artikelen, beheren van gebruikerssessies en meldingen.
Standaard stuurt WordPress alle Ajax calls via het bestand admin-ajax.php in de map /wp-admin.
Meerdere gelijktijdige Ajax verzoeken kunnen leiden tot een hoog vebruik van admin-ajax.php, waardoor je website en server aanzienlijk trager worden. Dit is een van de meest voorkomende problemen bij niet goed geoptimaliseerde WordPress websites. Meestal uit zich dit in symptomen zoals een tragere website, of HTTP 5xx fouten (vooral 504 of 502 errors).
In dit artikel leggen we alles uit over het bestand admin-ajax.php binnen WordPress, hoe het werkt, wat de voor- en nadelen zijn, en hoe je een hoog gebruik van admin-ajax.php kan analyseren en oplossen.
Ben je klaar voor? Aan de slag dan!
Wat is het bestand admin-ajax.php?
Het bestand admin-ajax.php bevat alle code voor het afhandelen van Ajax verzoeken binnen WordPress. Het voornaamste doel is het leggen van een verbinding tussen de client en de server door middel van Ajax. WordPress gebruikt het om de inhoud van pagina’s te verversen, zonder de pagina opnieuw te laden, waardoor het dynamisch en interactief wordt voor gebruikers.
Aangezien de WordPress kern Ajax al gebruikt om verschillende backend functies te draaien, kan je Ajax voor soortgelijke toepassingen binnen WordPress gebruiken. Het enige dat je hiervoor moet doen is het registreren van een action, het naar het bestand admin-ajax.php laten wijzen, en definiëren hoe je de relevante waarde wil retourneren. Je kan het HTML, JSON of zelfs XML laten retourneren.
Volgens WordPress Trac kwam het admin-ajax.php bestand voor het eerst voor in WordPress 2.1. Het wordt ook Ajax Admin genoemd binnen de WordPress development-community.
De grafiek hierboven laat alleen het aantal admin-ajax.php verzoeken zien, niet waar ze vandaan komen. Dit is een handige manier om te zien wanneer er pieken in je verkeer zitten. Je kan het met andere technieken combineren om de hoofdoorzaak te achterhalen. Dit beschrijven we verderop in dit aritikel.
Je kan ook Chrome DevTools gebruiken om te zien hoeveel verzoeken er naar admin-ajax.php gaan. Verder kan je in het tabblad Timings onder Network vinden hoeveel tijd het kost om deze verzoeken vervolgens te verwerken.
Wat betreft de precieze oorzaak achter het hoge verbruik van admin-ajax.php: er zijn meestal twee mogelijke hoofdoorzaken. Eén zit in de front-end, en de ander in de back-end. We zullen ze beide hieronder bespreken.
Zo debug je een hoog verbruik van admin-ajax.php bij WordPress
Externe plugins zijn een van de meest voorkomende oorzaken achter een hoog verbruik van admin-ajax.php. Meestal is het probleem goed te merken op de front-end van de site, en komt het ook terug in de snelheidstesten.
Maar plugins zijn niet de enige boosdoener, aangezien ook thema’s, de WordPress kern, de webserver of een DDoS-aanval achter een hoog Admin Ajax verbruik kunnen zitten.
Laten we ze nader bekijken.
Zo achterhaal je de bron van een hoog verbruik van admin-ajax.php door plugins en thema’s
Ajax wordt vaak gebruikt door WordPress developers om dynamische en interactieve plugins en thema’s te maken. Populaire toepassingen zijn bijvoorbeeld functies zoals live search, productfilters, oneindig scrollen, een dynamisch winkelkarretje en een chatbox.
Dat een plugin Ajax gebruikt betekent echter niet automatisch dat het je website trager maakt.
Meestal wordt Admin Ajax pas als één van de laatste zaken op een pagina geladen. Je kan het ook zo instellen dat Ajax verzoeken asynchroon geladen worden, zodat het bijna geen effect heeft op hoe je bezoekers de pagina ervaren.
Zoals je kan zien in het WebPageTest rapport hierboven, laadt admin-ajax.php bijna als laatst in de rij met verzoeken, maar duurt het wel 780ms om te laden. Dat is een hoop wachttijd voor één enkel verzoek.
Wanneer developers Ajax niet goed implementeren binnen WordPress, kan dat tot serieuze prestatieproblemen leiden. Het GTmetrix rapport hierboven is daar een typisch voorbeeld van.
Je kan GTmetrix ook gebruiken om gedetailleerder te kijken naar de data van individuele artikelen en responses. Deze functie is handig om te achterhalen wat de precieze oorzaak van het probleem is.
Om dat te doen ga je naar het tabblad Waterfall binnen GTmetrix, waar je op het item POST admin-ajax.php klikt. Hier zal je drie tabbladen zien voor dit verzoek: Headers, Post en Response.
Door naar de tabbladen Post en Response van het request te kijken krijg je wat informatie over mogelijke oorzaken van het probleem. Voor de site in het voorbeeld zie je al wat hints in het tabblad Response.
Je ziet dat een deel van het antwoord te maken heeft met een inputtag met het id “fusion-form-nonce-656”.
Een snelle zoekopdracht op deze aanwijzing brengt je naar de website van ThemeFusion, de makers van het Avada thema. Daarom kan je concluderen dat het verzoek wordt gedaan vanuit het thema, of één van de plugins die erbij horen.
In zo’n geval moet je er altijd eerst voor zorgen dat het Avada thema en de bijbehorende plugins volledig up-to-date zijn. Als dat het probleem nog niet oplost, kan je proberen het thema uit te schakelen en vervolgens te testen of het probleem is opgelost.
Maar anders dan het uitschakelen van een plugin, is het meestal niet mogelijk om het thema uit te schakelen. Daardoor kan je proberen het thema te optimaliseren om eventuele obstakels te verwijderen. Je kan ook even contact opnemen met het ondersteuningsteam van het thema om te kijken of zij wellicht goede ideeën hebben.
Het testen van een andere trage website via GTmetrix brengt ons op soortgelijke problemen met de Visual Composer page builder en de Notification Bar plugins.
Gelukkig kan je meestal allerlei alternatieve plugins proberen als je dit probleem niet kan oplossen bij je plugin. Wanneer het bijvoorbeeld om een paginabuilder gaat, kan je ook Beaver Builder of Elementor gaan gebruiken.
Zo achterhaal je de bron van een hoog gebruik van admin-ajax.php
Soms laten de Post en Response data van een snelheidstest niet meteen duidelijk zien wat het probleem is. Dan is het vinden van de bron van een hoog gebruik van admin-ajax.php een uitdaging. In dergelijke gevallen kan je het op de ouderwetse manier proberen.
Schakel alle plugins van je website uit, leeg de cache van de site (indien aanwezig), en doe opnieuw een snelheidstest. Als admin-ajax.php er nog steeds een hoog gebruik laat zien, is het thema waarschijnlijk de boosdoener. Maar mocht je nu het hoge gebruik niet meer zien, dan ligt het aan één van de plugins. Activeer je plugins één voor één, waarbij je elke keer de snelheidstest uitvoert. Door zo alle mogelijkheden bij langs te gaan, kan je uiteindelijk de bron vinden.
Tip: Door een testomgeving te gebruiken (bijv. de testomgeving van Kinsta) kan je tests op je website uitvoeren zonder dat je live site eronder lijdt. Nadat je de oorzaak hebt gevonden en binnen de testomgeving opgelost, kan je de veranderingen vervolgens naar je live site pushen.
Vaststellen van serverproblemen met admin-ajax.php aan de back-end
De op-één-na vaakst voorkomende reden voor een hoog gebruik van admin-ajax.php is dat de WordPress Heartbeat API teveel Ajax calls aanmaakt, waardoor de processor van de server intensief wordt gebruikt. Dit komt meestal doordat er veel gebruikers zijn ingelogd in het WordPress back-end dashboard. Daardoor zal je dit probleem niet terugzien in snelheidstests.
Standaard maakt de Heartbeat API elke 15 seconden contact met admin-ajax.php om automatisch artikelen of pagina’s op te slaan. Wanneer je een gedeelde hostingserver gebruikt, zijn er meestal niet al te veel resources toegewezen aan jouw site. Wanneer je een artikel of pagina aan het bewerken bent en het tabblad langere tijd open laat staan, dan kan dat resulteren in een hoop Amin Ajax requests.
Wanneer je bijvoorbeeld artikelen aan het schrijven of bewerken bent, kan een enkele gebruiker al zorgen voor 240 verzoeken binnen één uur!
Dat is een serieuze hoeveelheid verzoeken aan de back-end, voor slechts één gebruiker. Stel je nu voor dat een website meerdere editors tegelijkertijd ingelogd heeft. Dan loopt het aantal Ajax verzoeken snel op, waardoor er veel van processor wordt gevraagd.
Dat was de situatie die DARTDrones aantrof toen het bedrijf zijn WooCommerce site voorbereidde op een verwachte toename van het verkeer na een optreden in Shark Tank.
Voordat de site van DARTDrones in het televisieprogramma te zien was, kreeg hij meer dan 4.100 admin-ajax.php calls op een dag en slechts 2.000 unieke bezoekers. Dat is een behoorlijke beroerde requests-to-visits verhouding.
Het onderzoeksteam viel de /wp-admin referrer URL op en stelde de hoofdoorzaak correct vast. Deze verzoeken waren te wijten aan de admins en redacteurs van DARTDrones die de site vaak bijwerkten in afwachting van de show.
WordPress heeft dit Heartbeat API probleem deels opgelost, een tijd geleden. Zo kan je bijvoorbeeld de frequentie van verzoeken vanuit Heartbeat API verlagen bij hosts met beperkte resources. Ook kunnen de verzoeken gestopt worden na een uur zonder input van de muis of keyboard.
Veel verkeer door spambots of een DDoS aanval
Wanneer je website belaagd wordt door een DDoS aanval of door spambots kan je ook een hoog admin-ajax.php gebruik zien. Maar zo’n aanval richt zich niet per se op het verhogen van de Admin Ajax verzoeken; het is simpelweg een neveneffect.
Krijgt je website een DDoS aanval te verwerken, dan moet je prioriteit liggen bij je website te beveiligen via een robuuste CDN/WAF, zoals Cloudflare of Sucuri. Elk hostingpakket van Kinsta bevat gratis Cloudflare-integratie het Kinsta CDN, waardoor je door het offloaden van je resources minder intensief gebruik maakt van je servers.
Om meer te weten te komen over hoe je je website kan beschermen tegen kwaadwillenden, lees je onze uitgebreide gids over het stoppen van een DDoS aanval.
Samenvatting
WordPress gebruikt Ajax binnen de Heartbeat API om veel van de kernfuncties te kunnen uitvoeren. Maar dit kan tot verhoogde laadtijden leiden als dit niet goed wordt gedaan. Dit komt meestal door een te hoge frequentie van verzoeken naar het bestand admin-ajax.php.
In dit artikel hebben we het gehad over de diverse oorzaak van een hoog gebruik van admin-ajax.php, hoe je erachter kan komen wat de oorzaak is, en wat mogelijke oplossingen zijn. In deze meeste gevallen zal deze uitleg ervoor zorgen dat je website zo weer online is.
Maar in sommige gevallen is de enige goede oplossing het upgraden naar een server met meer capaciteit. Dit geldt vooral voor veeleisende use cases zoals webshops en ledenwebsites. Als je zo’n site hebt, overweeg dan een upgrade naar een managed WordPress host die ervaring heeft met dit soort prestatieproblemen.
Heb je na het doorlopen van deze stappen nog altijd een hoog gebruik van admin-ajax.php op je WordPress website, laat het ons dan weten in de reacties.
Laat een reactie achter