Er draait in uw beheerscherm een functie waar u nooit iets van ziet en die toch de meest voorkomende oorzaak is van een onverklaarbaar hoge serverbelasting. De wordpress heartbeat stuurt met vaste tussenpozen een verzoek naar uw eigen server, ook als u alleen maar een pagina open heeft staan en koffie haalt.

Dat is geen fout in WordPress; die functie doet nuttige dingen. Het probleem is dat de standaardinstelling is bedacht voor een redactie met meerdere schrijvers, en niet voor een ondernemer die met twee tabbladen open werkt op gedeelde hosting.

Wat die functie eigenlijk doet

De hartslagfunctie zorgt voor de communicatie tussen uw browser en de server terwijl u werkt. Concreet regelt hij vier dingen.

  • Automatisch opslaan van concepten. Uw tekst wordt periodiek bewaard, zodat u niets kwijt bent bij een crash.
  • Berichtvergrendeling. Opent een collega hetzelfde bericht, dan krijgt hij de melding dat u eraan werkt.
  • Sessiecontrole. Bent u uitgelogd geraakt, dan verschijnt er een inlogvenster in plaats van dat uw werk verdwijnt.
  • Meldingen op de achtergrond, bijvoorbeeld het aantal nieuwe bestellingen in WooCommerce of de voortgang van een import.

Dat zijn stuk voor stuk redelijke functies. De vraag is alleen hoe vaak dat moet gebeuren.

Waarom de WordPress Heartbeat uw server belast

Standaard vuurt de functie in de berichtbewerker elke vijftien seconden een verzoek af, en elders in het beheerscherm elke zestig seconden. Elk verzoek is geen statisch bestand maar een volledige aanroep van WordPress: PHP start op, plugins laden, de database wordt bevraagd.

Reken het eens door. Eén persoon die een uur in de bewerker zit, is 240 verzoeken. Drie collega’s die tegelijk werken, zijn 720. Laat iemand een tabblad de hele dag openstaan, dan loopt dat op tot enkele duizenden aanroepen per dag, waarvan het overgrote deel niets nuttigs doet.

Op een eigen server valt dat nog mee. Op gedeelde hosting met een limiet op het aantal processen is dit een reële oorzaak van meldingen over overbelasting, en soms zelfs van een tijdelijke blokkade door uw provider. Het wordt vaak verward met de klachten die u ook krijgt van drukke buren, zoals beschreven in het artikel over overbelaste gedeelde servers.

Herkennen of dit bij u speelt

  1. Open het netwerktabblad terwijl u in de berichtbewerker staat en laat het een minuut lopen. Ziet u regelmatig een verzoek naar admin-ajax.php verschijnen, dan is dat de hartslag.
  2. Kijk in uw toegangslogboek hoeveel aanroepen van admin-ajax.php er per dag zijn. Duizenden per dag bij een site met drie beheerders is een signaal.
  3. Let op het patroon in de tijd. Belasting die precies tijdens kantooruren piekt en ‘s nachts wegvalt, komt vaak uit het beheerscherm en niet van bezoekers.
  4. Merkt u dat uw laptop warm wordt bij een openstaand beheerscherm, dan is dat hetzelfde verschijnsel aan de andere kant van de lijn.

Instellen: hoe ver gaat u?

De eenvoudigste weg loopt via een plugin die dit regelt, zoals Heartbeat Control of de bijbehorende instelling in Perfmatters, WP Rocket of LiteSpeed Cache. U kunt daarin per locatie kiezen: de startpagina van het beheerscherm, de bewerker en de voorkant van de site.

Een verstandige indeling ziet er zo uit:

  • Voorkant van de site: uitschakelen. Daar heeft de hartslag zelden een functie, tenzij u een plugin gebruikt die live gegevens toont aan bezoekers.
  • Beheerscherm algemeen: naar 60 of 120 seconden. Meer dan genoeg voor meldingen.
  • Berichtbewerker: naar 30 tot 60 seconden. Zet hem niet uit, want dan verliest u het automatisch opslaan en de vergrendeling.

Draait u een webshop waarin medewerkers bestellingen live volgen, laat de bewerker dan op een korter interval staan. Datzelfde geldt als u met meerdere redacteuren aan dezelfde teksten werkt: de vergrendeling voorkomt dat twee mensen elkaars werk overschrijven, en dat is meer waard dan wat serverbelasting.

Test na het aanpassen twee dingen. Open een bericht, typ een zin en wacht af of de melding over het automatisch bewaarde concept nog verschijnt. Laat daarna een collega hetzelfde bericht openen en kijk of de vergrendeling nog werkt. Doen beide het niet meer, dan staat het interval te lang of is de functie per ongeluk helemaal uitgezet in de bewerker. Dat merkt u anders pas op het moment dat er werk verloren gaat, en dat is een dure manier om het te ontdekken.

Wat u er niet mee oplost

Dit is een ingreep voor het beheergedeelte, niet voor uw bezoekers. Uw laadtijd op de openbare pagina’s verandert er nauwelijks van, dus verwacht geen sprong in uw score. Wat u wel wint is rust op de server, en daarmee een site die niet meer traag wordt zodra er twee mensen tegelijk aan het werk zijn.

Is uw beheerscherm daarna nog steeds stroperig, dan zit de oorzaak elders: een uitgedijde database, een plugin die bij elke schermweergave externe gegevens ophaalt, of te weinig geheugen. Die kant staat uitgewerkt in het stuk over een traag WordPress-beheerscherm.

Een kleine ingreep met blijvend effect

Wat deze aanpassing aantrekkelijk maakt, is dat hij vijf minuten kost, geen risico voor uw ontwerp meebrengt en zonder gevolgen terug te draaien is. Bij klanten op krappe gedeelde pakketten zien we het aantal aanroepen van admin-ajax.php hiermee met tachtig tot negentig procent teruglopen, en daarmee verdwijnen de waarschuwingen van de provider vaak vanzelf.

Bij WebMaintor zetten we dit standaard goed bij het inrichten van een site, omdat het een van de weinige instellingen is die niets kost en op termijn altijd iets oplevert. Het hoort thuis in het rijtje instellingen dat een site rustig houdt onder belasting en niet in de categorie ingewikkelde trucs.

Concrete volgende stap: open uw berichtbewerker met het netwerktabblad ernaast en tel hoeveel verzoeken er in twee minuten voorbijkomen. Zijn dat er acht of meer, dan weet u dat hier iets te winnen valt.