{"id":19330,"date":"2018-06-25T01:39:47","date_gmt":"2018-06-24T23:39:47","guid":{"rendered":"https:\/\/kinsta.com\/?p=10106"},"modified":"2023-09-25T07:27:40","modified_gmt":"2023-09-25T05:27:40","slug":"admin-ajax","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/admin-ajax\/","title":{"rendered":"Zo onderzoek je een hoog admin-ajax verbruik op je WordPress website"},"content":{"rendered":"

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.<\/p>\n

Standaard stuurt WordPress alle Ajax calls via het bestand admin-ajax.php<\/code><\/strong> in de map \/wp-admin<\/code><\/strong>.<\/p>\n

Meerdere gelijktijdige Ajax verzoeken kunnen leiden tot een hoog vebruik van admin-ajax.php<\/code><\/strong>, 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 \u00a0504<\/a>\u00a0of\u00a0502<\/a>\u00a0errors).<\/p>\n

In dit artikel leggen we alles uit over het bestand\u00a0admin-ajax.php<\/code><\/strong> binnen WordPress, hoe het werkt, wat de voor- en nadelen zijn, en hoe je een hoog gebruik van admin-ajax.php<\/code><\/strong> kan analyseren en oplossen.<\/p>\n

Ben je klaar voor? Aan de slag dan!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Wat is het bestand admin-ajax.php?<\/h2>\n

Het bestand admin-ajax.php<\/code><\/strong> 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<\/a> wordt voor gebruikers.<\/p>\n

\"Een
Een vereenvoudigd overzicht van hoe Admin Ajax werkt bij WordPress<\/figcaption><\/figure>\n

Aangezien de WordPress kern Ajax al gebruikt om verschillende backend functies<\/a> 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<\/code><\/strong> laten wijzen, en defini\u00ebren hoe je de relevante waarde wil retourneren. Je kan het HTML, JSON of zelfs XML laten retourneren.<\/p>\n

\"admin-ajax.php
admin-ajax.php bestand in WordPress<\/figcaption><\/figure>\n

Volgens WordPress Trac<\/a> kwam het admin-ajax.php<\/code><\/strong>\u00a0bestand voor het eerst voor in WordPress 2.1. Het wordt ook Ajax Admin<\/strong> genoemd binnen de WordPress development-community.<\/p>\n

\"Controleren
Controleren van Ajax gebruik in het MyKinsta dashboard<\/figcaption><\/figure>\n

De grafiek hierboven laat alleen het aantal admin-ajax.php<\/code><\/strong> 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.<\/p>\n

\"Controleren
Controleren van het aantal admin-ajax.php verzoeken in Chrome DevTools<\/figcaption><\/figure>\n

Je kan ook Chrome DevTools gebruiken om te zien hoeveel verzoeken er naar admin-ajax.php<\/code><\/strong> gaan. Verder kan je in het tabblad Timings<\/strong> onder Network<\/strong> vinden hoeveel tijd het kost om deze verzoeken vervolgens te verwerken.<\/p>\n

Wat betreft de precieze oorzaak achter het hoge verbruik van admin-ajax.php<\/code><\/strong>: er zijn meestal twee mogelijke hoofdoorzaken. E\u00e9n zit in de front-end, en de ander in de back-end. We zullen ze beide hieronder bespreken.<\/p>\n\n

Zo debug je een hoog verbruik van admin-ajax.php bij WordPress<\/h2>\n

Externe plugins<\/a> 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.<\/p>\n

Maar plugins zijn niet de enige boosdoener, aangezien ook thema’s<\/a>, de WordPress kern, de webserver<\/a> of een DDoS-aanval<\/a> achter een hoog Admin Ajax verbruik kunnen zitten.<\/p>\n

Laten we ze nader bekijken.<\/p>\n

Zo achterhaal je de bron van een hoog verbruik van admin-ajax.php door plugins en thema’s<\/h3>\n
\"Door
Door Ajax aangedreven plugins in WordPress.org repository<\/figcaption><\/figure>\n

Ajax wordt vaak gebruikt door WordPress developers<\/a> om dynamische en interactieve plugins en thema’s te maken. Populaire toepassingen zijn bijvoorbeeld functies zoals live search<\/a>, productfilters, oneindig scrollen, een dynamisch winkelkarretje<\/a> en een chatbox<\/a>.<\/p>\n

Dat een plugin Ajax gebruikt betekent echter niet automatisch dat het je website trager maakt<\/a>.<\/p>\n

\"Bekijken
Bekijken van het admin-ajax.php verzoek in het rapport van WebPageTest<\/figcaption><\/figure>\n

Meestal wordt Admin Ajax pas als \u00e9\u00e9n 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.<\/p>\n

Zoals je kan zien in het WebPageTest<\/a> rapport hierboven, laadt admin-ajax.php<\/code><\/strong> bijna als laatst in de rij met verzoeken, maar duurt het wel 780ms om te laden. Dat is een hoop wachttijd voor \u00e9\u00e9n enkel verzoek.<\/p>\n

\"Een
Een GTmetrix rapport dat aangeeft dat er een hoge piek in het gebruik van admin-ajax.php zit<\/figcaption><\/figure>\n

Wanneer developers Ajax niet goed implementeren binnen WordPress<\/a>, kan dat tot serieuze prestatieproblemen leiden. Het GTmetrix rapport hierboven is daar een typisch voorbeeld van.<\/p>\n

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.<\/p>\n

Om dat te doen ga je naar het tabblad Waterfall<\/strong> binnen GTmetrix, waar je op het item POST admin-ajax.php<\/strong> klikt. Hier zal je drie tabbladen zien voor dit verzoek: Headers, Post en Response.<\/p>\n

\"POST
POST admin-ajax.php verzoek: Headers data<\/figcaption><\/figure>\n

Door naar de tabbladen Post<\/strong> en Response<\/strong> 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.<\/p>\n

\"POST
POST admin-ajax.php request: Response data<\/figcaption><\/figure>\n

Je ziet dat een deel van het antwoord te maken heeft met een inputtag met het id \u201cfusion-form-nonce-656\u201d.<\/p>\n

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 \u00e9\u00e9n van de plugins die erbij horen.<\/p>\n

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.<\/p>\n

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<\/a> 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\u00ebn hebben.<\/p>\n

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.<\/p>\n

\"Een
Een ander POST admin-ajax.php request: Response data<\/figcaption><\/figure>\n
\"POST
POST admin-ajax.php request: Post data<\/figcaption><\/figure>\n

Gelukkig kan je meestal allerlei alternatieve plugins proberen als je dit probleem niet kan oplossen bij je plugin. Wanneer het bijvoorbeeld om een paginabuilder<\/a> gaat, kan je ook Beaver Builder of Elementor gaan gebruiken.<\/p>\n

Zo achterhaal je de bron van een hoog gebruik van admin-ajax.php<\/h3>\n

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<\/code><\/strong> een uitdaging. In dergelijke gevallen kan je het op de ouderwetse manier proberen.<\/p>\n

Schakel alle plugins van je website uit<\/a>, leeg de cache van de site<\/a> (indien aanwezig), en doe opnieuw een snelheidstest. Als admin-ajax.php<\/code><\/strong> 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 \u00e9\u00e9n van de plugins. Activeer je plugins \u00e9\u00e9n voor \u00e9\u00e9n, waarbij je elke keer de snelheidstest uitvoert. Door zo alle mogelijkheden bij langs te gaan, kan je uiteindelijk de bron vinden.<\/p>\n

Tip:<\/strong> Door een testomgeving<\/a> te gebruiken (bijv. de testomgeving van Kinsta<\/a>) 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<\/a>.<\/p>\n

Vaststellen van serverproblemen met admin-ajax.php aan de back-end<\/h3>\n

De op-\u00e9\u00e9n-na vaakst voorkomende reden voor een hoog gebruik van admin-ajax.php<\/code><\/strong> 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.<\/p>\n

Standaard maakt de Heartbeat API elke 15 seconden contact met admin-ajax.php<\/code><\/strong> om automatisch artikelen of pagina’s op te slaan. Wanneer je een gedeelde hostingserver<\/a> 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.<\/p>\n

Wanneer je bijvoorbeeld artikelen aan het schrijven of bewerken bent, kan een enkele gebruiker al zorgen voor 240 verzoeken binnen \u00e9\u00e9n uur!<\/p>\n

\"Regelmatige
Regelmatige autosave admin-ajax.php verzoeken<\/figcaption><\/figure>\n

Dat is een serieuze hoeveelheid verzoeken aan de back-end, voor slechts \u00e9\u00e9n 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.<\/p>\n

Dat was de situatie die DARTDrones<\/a> aantrof toen het bedrijf zijn WooCommerce site voorbereidde op een verwachte toename van het verkeer na een optreden in Shark Tank.<\/p>\n

Voordat de site van DARTDrones in het televisieprogramma te zien was, kreeg hij meer dan 4.100 admin-ajax.php<\/strong><\/code> calls op een dag en slechts 2.000 unieke bezoekers. Dat is een behoorlijke beroerde requests-to-visits verhouding.<\/p>\n

\"Heavy
Heavy admin-ajax.php usage on dartdrones.com<\/figcaption><\/figure>\n

Het onderzoeksteam viel de \/wp-admin<\/strong> referrer URL<\/a> 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.<\/p>\n

WordPress heeft dit Heartbeat API probleem<\/a> 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.<\/p>\n