Kort svar: Query Monitor er gratis og viser pr. sidevisning, hvilke databasekald der kører, hvad de koster, og – vigtigst – hvilken komponent (plugin, tema, kerne) der udløste dem. Installér det, åbn en langsom side, og sortér queries efter tid og efter komponent: synderen står øverst. Brug det på staging eller kortvarigt på live (kun administratorer ser det), og afinstallér efter brug – det er et diagnoseinstrument, ikke fast inventar.
Når en u-cachet side er langsom, gættes der ofte: “det er nok hostingen” – “det er nok det nye plugin”. Query Monitor erstatter gætteriet med en regning: hvert databasekald med tid, kilde og stak. Ti minutter med værktøjet afgør diskussionen om, hvorvidt problemet er koden eller serveren – og præcis hvilket plugin, der i så fald sender regningen.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med illustrative tal.
Efter installation får admin-bjælken en ny statuspost: sidetid, hukommelse og antal queries. Klik på den, og åbn panelet. De to visninger, der afgør næsten alle sager: Queries → efter tid (de dyreste kald øverst) og Queries by Component (samlet regning pr. plugin/tema). Start altid med komponent-visningen – den fortæller på ti sekunder, om ét plugin dominerer:
Fundet bestemmer vejen: Er synderen et plugin, så tjek først indstillingerne (logs, statistik og “live”-funktioner kan ofte slås fra), dernæst om en opdatering løser det – og ellers om et lettere alternativ findes. Er det temaet, er det typisk tællere og “relaterede indlæg”-funktioner uden cache. Er det egne tilpasninger, så cache resultatet med en transient. Og er kaldene sunde, men alting jævnt langsomt, er det ikke databasens skyld – gå til næste afsnit. Store oprydninger i selve databasen – autoload og tabeller – hører til i databaseoprydnings-guiden.
Query Monitor giver også det ærlige svar den anden vej: når queries er få og hurtige, men sidetiden stadig høj, ligger tiden i PHP-afvikling eller ventetid på serveren. Sammenlign samme side på staging og live, og på forskellige tidspunkter: svinger tallene med døgnet, er det belastning – og så er det TTFB-sporet og i sidste ende serverkraft, der flytter noget. Med Query Monitor-tal i hånden bliver dialogen med hostingudbyderen også konkret: “95 queries på 80 ms, men 1,8 s sidetid” er en helt anden samtale end “sitet er langsomt”.
Diagnosen er færdig, når du kan pege på komponenten bag den langsomme side, rettelsen er målt (samme side, før/efter, gerne tre kørsler) – og Query Monitor er afinstalleret igen. Værktøjet koster selv lidt overhead, så det skal ikke ligge fast på live. Notér fundet i jeres driftslog: “plugin X’s statistikmodul slog 400 ms af kategorisiderne” er guld værd, næste gang nogen overvejer at slå modulet til igen.
Kortvarigt, ja – panelet vises kun for administratorer, og besøgende mærker næsten intet. Men det tilføjer selv måle-overhead, så brug det som termometer: ind, mål, ud.
En slank side ligger på 30-100; komplekse WooCommerce-sider gerne 100-200. Tallet alene dømmer ikke – 200 hurtige kald kan være fint, mens 40 med ét på 800 ms er et problem. Kig på tid før antal.
Ja – men husk, at page-cachede visninger slet ikke kører queries. Mål som logget ind (cache-bypass) eller på u-cachebare sider som checkout og søgning – det er alligevel dem, databasetiden gør ondt på.
