Kort svar: wp-admin får aldrig page cache – dets hastighed er serverens rå PHP-fart plus alt det, dine plugins laver på hver admin-side. De fire klassiske syndere: opsvulmede autoloadede options, tunge plugins der kører på alle admin-sider, Heartbeat/AJAX-støj og manglende object cache. Gå dem igennem i den rækkefølge – og mål undervejs, så du ved, hvilken der var din.
Forsiden flyver, men wp-admin sejtrækker: indlægslisten tager sekunder, editoren hakker, og alting føles tungt. Det er ikke et paradoks – det er cache-asymmetrien: besøgende får færdige sider fra cache, mens hver admin-side bygges forfra. Derfor er et langsomt wp-admin også et ærligt signal: her måles serverens og pluginsenes reelle tilstand.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med illustrative tal.
Autoloadede options indlæses ved hver sidevisning – også i admin. Sundt niveau: under ~1 MB. Efter år med installerede og slettede plugins ligger mange sites på flere MB, og så bærer hver eneste admin-side den bagage med sig. Tjek størrelsen, og ryd de største forældreløse poster:
Fremgangsmåden – inklusive hvad der er sikkert at sætte til autoload=nej – står i databaseoprydnings-guiden og den dybere databaseguide.
Mange plugins læsser arbejde på alle admin-sider: dashboards-widgets, notifikationer, licenstjek, statistikindsamling. Installér Query Monitor, åbn en langsom admin-side, og se hvilken komponent der bruger tiden – metoden står i Query Monitor-guiden. Typiske fund: sikkerhedsplugins der scanner ved hvert sideskift, statistikplugins med tunge dashboard-forspørgsler og page builders, der indlæser alt overalt. Rettelsen er sjældent at slette pluginnet – oftere at slå dets dashboard-widget og live-funktioner fra.
Heartbeat API’et sender løbende små admin-ajax-kald (autosave, lås-status, notifikationer). På en sund server er de billige; på en presset server, eller med mange faner åbne, bliver de til konstant baggrundslast. Cache-plugins kan skrue frekvensen ned (fx hvert 60. sekund i stedet for hvert 15.) – gør det, men sluk ikke Heartbeat helt i editoren: autosave og indlægslåse er prisen. Ser du derimod en strid strøm af admin-ajax i Netværk-fanen, er det typisk ét plugin, der poller – find det via kaldets “action”-parameter.
Når bagagen er ryddet og synderne tæmmet, er resten infrastruktur: object cache (Redis) fjerner de gentagne databaseopslag, der fylder i admin; en nyere PHP-version gør al afvikling hurtigere; og hjælper intet af det, er serveren reelt for lille til opgaven – især på webshops med mange samtidige redaktører. Dér flytter hosting med NVMe og flere PHP-workers mere end nogen indstilling.
Mål det samme før og efter: tiden for indlægslisten og dashboardet (Netværk-fanens dokument-request), autoload-størrelsen og antallet af admin-ajax-kald pr. minut. Succes er en admin, hvor sider svarer på under ~1 sekund, autoload er under 1 MB, og baggrundskaldene er få og rolige. Og gør målingen igen efter hvert nyt plugin – admin-hastighed forsvinder ét plugin ad gangen og genvindes på samme måde.
Fordi page cache aldrig gælder wp-admin – hver side er personlig og bygges forfra. Admin hjælpes af object cache, PHP-version, oprydning og færre tunge plugins – ikke af page cache.
Ikke automatisk – 20 lette plugins kan være billigere end ét tungt. Det er ikke antallet, men adfærden: mål med Query Monitor, og døm på data i stedet for at tælle.
Indirekte, ja: samme autoload-bagage og tunge plugins kører også på u-cachede frontend-requests (søgning, checkout, første besøg efter purge). Rydder du op for admins skyld, vinder de sider med.
