Langsomt wp-admin: heartbeat, autoload og plugins

Kort svar: wp-admin får aldrig page cache, så hastigheden er serverens rå PHP-fart plus alt det, dine plugins laver på hver admin-side. De fire klassiske syndere er opsvulmede autoloadede options, tunge plugins der kører på alle admin-sider, Heartbeat- og 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.

Fagligt gennemgået: 2. oktober 2026

Forsiden flyver, men wp-admin sejtrækker: indlægslisten tager sekunder, editoren hakker, og alting føles tungt. Det er ikke et paradoks, men cache-asymmetri: 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 – den samme tilstand, som kurv, checkout, søgning og første besøg efter en cache-rydning rammer.

Før du ændrer noget: Tag en backup af databasen, før du ændrer autoload eller sletter options, og test gerne på en staging-kopi først. Mål også admin-hastigheden, før du ændrer noget, så du kan se, om ændringen faktisk hjalp.

1. Autoload – den usynlige bagage

Autoloadede options indlæses ved hver sidevisning – også i admin. Efter år med installerede og slettede plugins ligger mange sites med flere MB autoload, og så bærer hver eneste admin-side den bagage med sig.

Siden WordPress 6.6 har autoload-feltet flere værdier end det gamle „yes/no“: on og off for eksplicitte valg samt auto, auto-on og auto-off, hvor WordPress selv vurderer. Options over ca. 150 KB autoloades ikke længere som standard, medmindre pluginnet udtrykkeligt beder om det. Site Health viser desuden en advarsel, når de autoloadede options tilsammen fylder over 800 KB – en brugbar grænse at sigte efter.

Tjek størrelsen, og find de største poster:

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

Ret tabelpræfikset, hvis dit site ikke bruger wp_. Navnet på en option afslører ofte, hvilket plugin der ejer den. Stammer de største poster fra plugins, du har slettet, kan de typisk fjernes eller sættes til ikke at autoloade. Fremgangsmåden – inklusive hvad der er sikkert at ændre – står i guiden til databaseoprydning og den dybere guide til optimering af databasen.

2. Find plugin-synderen

Mange plugins læsser arbejde på alle admin-sider: dashboardwidgets, notifikationer, licenstjek, statistikindsamling. Installér Query Monitor, åbn en langsom admin-side, og se, hvilken komponent der bruger tiden. Metoden står i guiden til Query Monitor.

Typiske fund:

• sikkerhedsplugins, der scanner eller logger ved hvert sideskift;
• statistikplugins med tunge forespørgsler i dashboardwidgets;
• page builders og store plugin-suiter, der indlæser scripts og data på alle admin-sider;
• webshopplugins med rapporter og analyser, der beregnes, når dashboardet åbnes.

Rettelsen er sjældent at slette pluginnet. Oftere er det nok at slå dets dashboardwidget og live-funktioner fra eller at flytte tunge rapporter til planlagte kørsler.

Eksterne HTTP-kald og licenstjek

Et plugin, der kontakter en ekstern server ved hver admin-sidevisning – for at tjekke licens, hente nyheder eller sende statistik – gør admin lige så langsomt som den langsomste server, det spørger. Query Monitor viser kaldene under HTTP API Calls med tid pr. kald. Ser du kald på flere hundrede millisekunder på hver side, er det næsten altid den direkte vej til en hurtigere admin.

wp-cron, der kører på dine sidevisninger

WordPress’ planlagte opgaver udløses som standard af sidevisninger. Hænger der mange eller tunge opgaver, kan de forsinke den admin-side, der tilfældigvis starter dem. Flyt cron til en rigtig servercron, hvis sitet har mange planlagte opgaver; se planlagte opgaver uden wp-cron-fælder.

3. Heartbeat og AJAX-støj

Heartbeat-API’et sender løbende små kald til admin-ajax.php til autosave, låsning af indlæg og notifikationer. Som standard sker det hvert 15. sekund i editoren og hvert 60. sekund på andre admin-sider. På en sund server er kaldene billige; på en presset server, eller med mange faner åbne, bliver de til konstant baggrundslast.

Cache- og optimeringsplugins kan skrue frekvensen ned, fx til hvert 60. sekund i editoren. 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-kald i Netværk-fanen, er det typisk ét plugin, der poller. Find det via kaldets action-parameter.

4. Object cache og serverkraft

Når bagagen er ryddet og synderne tæmmet, er resten infrastruktur. En object cache med Redis fjerner de gentagne databaseopslag, der fylder i admin. En aktuel PHP-version som PHP 8.3 eller 8.4 gør al afvikling hurtigere (læs guiden til fejl efter PHP-opgradering, før du skifter).

Hjælper intet af det, er serveren reelt for lille til opgaven – især på webshops med mange samtidige redaktører. Dér flytter mere CPU, hurtigere lager og flere samtidige PHP-processer mere end nogen indstilling.

Når kun én admin-side er langsom

Er det kun indlægslisten, produktlisten eller ordreoversigten, der er tung, ligger årsagen sjældent i serveren generelt. Ofte er det kolonner og filtre, som plugins tilføjer: SEO-scorer, lagerstatus, oversættelser eller statistik beregnes for hver række, hver gang listen vises.

• Skjul unødvendige kolonner via Skærmindstillinger øverst på listen, og sænk antallet af rækker pr. side.
• Brug søgning og filtre i stedet for at bladre gennem tusindvis af rækker.
• På WooCommerce: tjek, om butikken bruger High-Performance Order Storage (HPOS), hvor ordrer ligger i egne tabeller i stedet for i de generelle indlægstabeller. Det er standard for nye butikker siden WooCommerce 8.2, men ældre butikker kører ofte stadig med den gamle lagring og kan migreres under WooCommerce → Indstillinger → Avanceret → Funktioner, efter test på staging.
• Er editoren selv langsom, så se efter meget store sider med mange indlejrede blokke, tunge mønstre eller page builder-moduler. Del lange sider op, eller test med færre aktive plugins.

Query Monitor på netop den side viser, om tiden går i databasen, i PHP-koden eller i eksterne kald, så du ikke skal gætte.

Hvad du skal måle

Måling	Hvor du finder den	Sundt niveau
Svartid for indlægslisten og dashboardet	Netværk-fanen, dokument-requesten (TTFB)	Under ca. 1 sekund
Autoload-størrelse	Site Health eller SQL-forespørgslen ovenfor	Under 800 KB
Databasekald pr. admin-side	Query Monitor	Ingen enkeltkald på flere hundrede millisekunder
Eksterne HTTP-kald	Query Monitor, HTTP API Calls	Få og hurtige – ikke på hver sidevisning
admin-ajax-kald pr. minut	Netværk-fanen, filtrér på admin-ajax	Få og regelmæssige

Grænserne er tommelfingerregler, ikke garantier. Det vigtige er at måle det samme før og efter hver ændring.

Verifikation

Mål de samme punkter som før ændringerne: tiden for indlægslisten og dashboardet, autoload-størrelsen og antallet af admin-ajax-kald pr. minut. Succes er en admin, hvor siderne svarer på omkring et sekund eller mindre, autoload er under 800 KB, og baggrundskaldene er få og rolige.

Gør målingen igen efter hvert nyt plugin. Admin-hastighed forsvinder typisk ét plugin ad gangen og genvindes på samme måde.

Læs også

• Hub: WordPress performance og cache
• Find langsomme databasekald med Query Monitor
• Object cache med Redis eller Memcached i LiteSpeed Cache
• Databaseoprydning i LiteSpeed Cache: revisioner, transients og autoload
• Høj TTFB i WordPress: cache, PHP, database eller origin?
• WordPress hosting hos Hostious – Redis object cache understøttes fra WP StartUp

Ofte stillede spørgsmål om langsomt wp-admin

Hvorfor hjælper mit cache-plugin ikke på admin?

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.

Er mange plugins lig med langsomt admin?

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.

Kan et langsomt admin påvirke besøgende?

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.

Kan jeg slå Heartbeat helt fra?

På dashboardet og de fleste admin-sider kan det sagtens slås fra eller sættes ned. I editoren bør du kun sænke frekvensen, for uden Heartbeat mister du autosave og advarslen om, at en kollega redigerer samme indlæg.