Kontrollpanelet er tregt

Når siden er rask for besøkende, men kontrollpanelet er tregt, er det fordi wp-admin aldri blir cachet. Sidecachen gjelder bare besøkende som ikke er logget inn, så PHP bygger hver side i wp-admin på nytt. I kontrollpanelet gjør utvidelsene dessuten mer enn på resten av siden: de henter nyheter og lisensstatus fra egne servere, viser statistikk og ser etter oppdateringer.

I tillegg sender hver fane med wp-admin åpen jevnlige forespørsler gjennom Heartbeat API. Typiske flaskehalser er Heartbeat, store tabeller i databasen og utvidelser som kontakter eksterne servere.

Lukk faner du ikke bruker

Heartbeat API holder låsen på innlegg som redigeres, varsler når innloggingen har utløpt og står for autolagring i den klassiske redigeringen. Hver fane med wp-admin åpen sender en forespørsel til admin-ajax.php hvert 10. til 60. sekund, og hver forespørsel starter WordPress og PHP på serveren. Faner i bakgrunnen sender hvert annet minutt, og etter ti minutter uten aktivitet stopper fanen helt.

Unntaket er redigeringsskjermen for innlegg. Der stopper Heartbeat først etter en time uten aktivitet. Har du og kollegene dine mange innlegg åpne samtidig, blir det mange forespørsler. Lukk fanene du ikke bruker, og se om kontrollpanelet blir raskere.

Rydd på forsiden av kontrollpanelet

Gå til Kontrollpanel og åpne «Visningsinnstillinger» øverst til høyre. Fjern haken ved boksene fra utvidelser som viser nyheter, statistikk eller annonser. Mange av dem henter data fra eksterne servere hver gang kontrollpanelet lastes.

Finn utvidelsen som bremser

Utvidelsen Query Monitor viser hva som skjer når en side i wp-admin lastes.

1. Installer og aktiver Query Monitor under Utvidelser.
2. Gå til en treg side i kontrollpanelet, og åpne menyen til Query Monitor i adminlinjen øverst.
3. Panelet «HTTP API Calls» viser forespørsler til eksterne servere og hvor lang tid de tok. Kontakter en utvidelse lisensserveren sin ved hver sidevisning, venter PHP på svaret før siden vises.
4. Panelet «Queries by Component» viser hvilke utvidelser som kjører flest databasespørringer, og hvilke som er tregest.

Deaktiver utvidelsen som skiller seg ut, og mål på nytt. Noen utvidelser lar deg slå av lisenssjekken i innstillingene, og ellers kan en nyere versjon ha rettet feilen.

Senk frekvensen på Heartbeat

Lag filen wp-content/mu-plugins/heartbeat.php med innholdet under. Finnes ikke mappen mu-plugins, lager du den. WordPress laster filene i denne mappen automatisk, uten at de må aktiveres.

<?php
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['minimalInterval'] = 120;
    return $settings;
} );

Da sender hver fane høyst én forespørsel hvert annet minutt. Sett ikke verdien høyere enn 120 sekunder. Låsen på et innlegg utløper etter 150 sekunder uten svar fra Heartbeat, og da kan to personer redigere det samme innlegget samtidig.

Se etter store tabeller

Gå til Verktøy → Nettstedshelse. Meldingen «Automatisk lastede innstillinger kan påvirke ytelsen» betyr at innstillingene i wp_options som lastes ved hver forespørsel, til sammen er på 800 kB eller mer. Utvidelser du har slettet, kan ha latt innstillingene sine bli liggende. De største radene finner du med denne spørringen i phpMyAdmin. Bruker siden et annet prefiks enn wp_, bytter du det ut i spørringen.

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY bytes DESC
LIMIT 20;

Står det også «Du bør bruke et vedvarende objektmellomlager», kan du be hostingleverandøren om Redis eller Memcached. Da henter WordPress data fra minnet i stedet for å spørre databasen på nytt ved hver forespørsel, og det merkes særlig i wp-admin.

Databaseverktøyet i hostingpanelet viser også hvor store tabellene er. Store tabeller med actionscheduler_ i navnet er køen for planlagte oppgaver i WooCommerce og andre utvidelser. Ta alltid en sikkerhetskopi av databasen før du sletter noe.

Når utvidelsene ikke er årsaken

Er kontrollpanelet fortsatt tregt med alle utvidelser deaktivert, ligger årsaken i temaet, databasen eller på serveren. Da trenger du tilgang til hostingpanelet og en erfaren utvikler som kan gå gjennom databasen og serverloggene. Ta en sikkerhetskopi før noen rydder i tabellene.