Langsom WooCommerce med mange produkter — hvad der reelt bremser

Kort svar: En WooCommerce-butik bliver ikke langsom af antallet af produkter, men af hvordan der slås op i dem. De typiske flaskehalse er filtrering på attributter via postmeta, opslag pr. variant i oversigter, manglende objektcache, cart fragments og en oppustet Action Scheduler-tabel. Mål først med Query Monitor, slå derefter Redis, opslagstabellerne og HPOS til, og ryd op – det hjælper sjældent at slette produkter.

Fagligt gennemgået: 2. oktober 2026

Produktdata i WordPress ligger spredt over flere tabeller – wp_posts, wp_postmeta og taksonomitabellerne – som skal sættes sammen ved hver visning. Med få produkter mærkes det ikke. Med tusindvis af produkter og varianter kan den samme opsætning gøre kategorisider, filtre og kassen sejt.

Derfor hjælper det sjældent at slette produkter. Det hjælper at ændre, hvordan de hentes.

Før du ændrer noget: Tag en fuld backup af filer og database. Test ændringer som HPOS, oprydning i postmeta og nye cacheregler på staging først. Slet aldrig rækker direkte i databasen uden at vide, hvilket plugin de tilhører.

De typiske flaskehalse

1. Filtrering på attributter. Farve, størrelse og pris kræver opslag på tværs af postmeta og taksonomier, og postmeta-tabellen vokser hurtigt.
2. Opslag pr. variant i oversigten, fx pris- eller lagerstatus, der beregnes for hver variant ved hver visning.
3. Ingen objektcache, så de samme forespørgsler køres forfra hver gang.
4. Cart fragments, der kalder serveren ved sidevisninger for at opdatere kurven.
5. En stor Action Scheduler-tabel og ordrer i de generelle tabeller, der gør hver ny ordre tungere.

1. Mål først – så du retter det rigtige

“Langsom” er ikke én ting. Installér Query Monitor midlertidigt, og åbn de tre sider, der er langsomme: en kategoriside, en produktside og kassen. Øverst viser den tre tal, der hver peger sin vej:

Måling	Hvad det typisk betyder	Hvor du leder
Mange forespørgsler (flere hundrede) på en kategoriside	Noget slår op pr. produkt eller variant	Varianter, lager, pris-plugin
Høj databasetid med få forespørgsler	Én tung forespørgsel	Filtrering, søgning, sortering
Høj PHP-tid med lav databasetid	Et plugin regner	Fragt, valuta, anbefalinger
Langsomme HTTP API-kald	Ekstern tjeneste bremser	Fanen “HTTP API Calls”

Tjek også fanen “Queries by component”. Står ét plugin for en stor del af databasetiden, har du fundet dit første projekt – og det er ofte et plugin, ingen bruger længere. Se find langsomme databasekald med Query Monitor.

2. Slå objektcache med Redis til

En objektcache gemmer resultatet af databaseforespørgsler i hukommelsen, så de ikke skal køres igen på næste side. På en butik med mange produkter er det ofte den enkeltændring, der flytter mest – især for indloggede kunder, kurv og kasse, som ikke kan sidecaches.

Redis skal både være tilgængelig på serveren og forbundet til WordPress på det enkelte site, fx via LiteSpeed Cache eller et Redis-plugin. Hos Hostious understøttes Redis object cache fra StartUp-pakkerne og aktiveres pr. site. Se object cache med Redis i LiteSpeed Cache.

3. Brug WooCommerce’ egne opslagstabeller

WooCommerce har i flere år flyttet data ud af de generelle WordPress-tabeller og over i egne, hurtigere tabeller:

• Produktopslagstabellen (wc_product_meta_lookup) gør sortering og filtrering på pris og lager billig. Kør “Genskab produktopslagstabeller” under WooCommerce → Status → Værktøjer, hvis sortering er langsom, eller tallene er forkerte.
• Attributopslagstabellen (wc_product_attributes_lookup) bruges til filtrering på attributter som farve og størrelse. Under WooCommerce → Indstillinger → Produkter → Avanceret kan du vælge at bruge den til katalogfiltrering. Den skal være fuldt genereret, før du slår det til.

Bruger du et filterplugin, så tjek, om det har sit eget indeks. Et filter, der slår op i postmeta ved hvert klik, bliver langsomt med mange produkter uanset hostingen.

4. Slå HPOS til og ryd op i Action Scheduler

HPOS (High-Performance Order Storage) lægger ordrer i egne tabeller i stedet for i wp_posts og wp_postmeta. Det mærkes i en butik med mange tusinde ordrer – ordreoversigten og kassen bliver hurtigere, fordi de ikke længere konkurrerer med produkter og sider om de samme tabeller. Nye butikker har haft HPOS slået til som standard siden WooCommerce 8.2; ældre butikker skal selv skifte under WooCommerce → Indstillinger → Avanceret → Funktioner, efter du har tjekket, at dine plugins understøtter det.

Under overgangen kan du køre med synkronisering mellem gamle og nye tabeller (kompatibilitetstilstand). Den koster ekstra skrivninger ved hver ordre, så slå den fra, når migreringen er færdig, og alt virker.

Hertil kommer Action Scheduler-tabellen. Hundredtusindvis af gamle, gennemførte handlinger gør hver ny ordre langsommere. Standarden er at gemme gennemførte handlinger i omkring en måned, men nogle plugins skaber så mange, at tabellen alligevel vokser til gigabyte. Ryd op under WooCommerce → Status → Planlagte handlinger, og sænk opbevaringstiden med filteret action_scheduler_retention_period, hvis det sker igen:

add_filter( 'action_scheduler_retention_period', function () {
    return 7 * DAY_IN_SECONDS;
} );

Ligger der mange forfaldne eller fejlede handlinger, er det et symptom i sig selv. Se forfaldne planlagte handlinger i WooCommerce.

5. Ryd op i postmeta og autoload

Slettede produkter, gamle varianter og data fra plugins, der er fjernet for længst, bliver liggende i postmeta og options. Store autoloadede options indlæses ved hver eneste request. Med WP-CLI kan du se, hvor meget der autoloades:

wp option list --autoload=on --format=total_bytes
wp transient delete --expired

Se optimering af WordPress-databasen og databaseoprydning i LiteSpeed Cache.

6. Begræns, hvad der vises

• Vis fx 24 produkter pr. side frem for 100.
• Undgå at vise pris- og lagerstatus for alle varianter i oversigten – det tvinger et opslag pr. variant.
• Har et produkt mange varianter, indlæser WooCommerce dem via AJAX over en vis grænse (som standard 30). Hæv ikke grænsen med filteret woocommerce_ajax_variation_threshold uden at måle effekten.
• Erstat WordPress’ standardsøgning, der søger med LIKE i indholdet, med en søgning, der har et indeks bag sig, hvis søgningen er langsom.

7. Deaktivér cart fragments, hvor de ikke bruges

Cart fragments opdaterer minikurven via et AJAX-kald, der ikke kan caches. På sider uden minikurv er kaldet spild. Se sådan deaktiverer du cart fragments uden plugin.

Det, kunderne mærker, sidder ofte i frontenden

Når databasen er hurtig, er resten et spørgsmål om, hvad browseren skal hente. Produktbilleder i fuld opløsning i et grid med 24 varer er den hyppigste synder; brug de skalerede størrelser, og lever WebP eller AVIF. Live-søgning, der spørger serveren ved hvert tastetryk, bør have en lille pause og et indeks bag sig. Og sidecache på alle sider undtagen kurv, kasse og Min konto gør, at de fleste anonyme besøg aldrig når PHP. Se LiteSpeed Cache til WooCommerce.

Når det er ressourcer

Er databasen optimeret og cachen på plads, men butikken stadig langsom under travlhed, er der for få PHP-processer eller for lidt databasekapacitet til trafikken. Det kan ikke løses i WordPress. Se tegnene på at webshoppen mangler bedre hosting.

Verificér effekten

Mål de samme tre sider med Query Monitor efter hver ændring, og notér antal forespørgsler, databasetid og samlet tid. Gennemfør et testkøb til sidst. Ændrer du flere ting på én gang, ved du ikke, hvad der hjalp – og hvad der evt. gik i stykker.

Læs også

• Hub: WooCommerce fejl og fejlfinding
• Langsom checkout i WooCommerce
• LiteSpeed Cache til WooCommerce
• WooCommerce-kurven bliver tom mellem sider
• WooCommerce hosting hos Hostious – LiteSpeed, NVMe og daglig backup til webshops
• WordPress hastighedsoptimering – vi finder og fjerner flaskehalsene for dig

Ofte stillede spørgsmål om langsom WooCommerce

Hjælper et cache-plugin på en webshop?

På produkt- og kategorisider ja. På kurv, kasse og Min konto må der ikke caches, ellers kan kunder se forkerte kurve eller miste indholdet.

Hvor mange produkter er for mange?

Der er ingen fast grænse. En butik med mange tusinde produkter kan køre hurtigt med den rigtige opsætning, mens en lille butik kan være langsom uden. Det afgørende er, hvordan der slås op i produkterne.

Hvad er HPOS, og gør det butikken hurtigere?

High-Performance Order Storage gemmer ordrer i egne tabeller i stedet for i wp_posts og wp_postmeta. I butikker med mange ordrer bliver ordreoversigt og kasse typisk hurtigere. Tjek, at dine plugins understøtter det, før du slår det til.

Hvor mange databaseforespørgsler er normalt på en produktside?

Det varierer med tema og plugins, men som tommelfingerregel ligger en sund produktside på et par hundrede forespørgsler eller færre uden objektcache og langt færre med. Stiger tallet markant med antallet af varianter eller produkter på siden, slår noget op pr. vare, og så er det dér, du skal lede.