En langsom WooCommerce-webshop har som regel en bestemt årsag: serveren, databasen, et plugin, et baggrundsjob eller det, browseren skal hente. Det er sjældnere, at det hele er lidt for langsomt. Derfor er det første skridt ikke at installere et cache-plugin, men at finde ud af, hvor tiden går.
Her gennemgår vi fejlfindingen i en fast rækkefølge: hvilke sider der er langsomme, hvordan du måler, og hvad du kigger efter i hvert lag. Vil du først forstå, hvad der sker, fra et klik til en færdig side i WordPress, så start dér.
Hvor er den langsom?
“Shoppen er langsom” dækker over meget forskellige problemer. Før du måler noget, så skriv ned, hvilke sider det gælder, og for hvem. Det peger som regel direkte på det lag, du skal starte i.
| Det, du oplever | Hvor årsagen typisk ligger | Start her |
|---|---|---|
| Alle sider er langsomme, også forsiden | Serveren, PHP eller manglende page cache | Serveren, caching |
| Forsiden er hurtig, men kurv og checkout er langsomme | Sider, der ikke kan caches: databasen, plugins og betalings- eller fragtmoduler | Databasen, plugins, guiden om langsom checkout |
| Admin er langsom, især ordrelisten | Ordredata i wp_postmeta, baggrundsjob og admin-ajax | Databasen, baggrundsjob, guiden om langsom admin |
| Kategorier med filtre eller søgning er langsomme | Tunge databaseforespørgsler | Databasen |
| Siden vises hurtigt, men er længe om at blive klar | Billeder, scripts og tredjepartskode i browseren | Frontend |
| Den er blevet langsommere med tiden | Data, der vokser: ordrer, sessioner, autoload, planlagte handlinger | Databasen, baggrundsjob |
Mål, før du ændrer noget
Den vigtigste skelnen er mellem serverens svartid og alt det, der sker bagefter i browseren. Serverens svartid hedder TTFB (time to first byte): tiden fra browseren beder om siden, til den første byte kommer tilbage. Googles egen vejledning på web.dev kalder en TTFB på 0,8 sekunder eller derunder god. Er den høj, hjælper det ikke at komprimere billeder, og så er guiden om høj TTFB stedet at starte. Er den lav, men siden føles langsom, ligger problemet i browseren.
Mål den side, der rent faktisk er langsom, og mål den uden cache. En produktside, der kommer fra page cachen, siger intet om, hvor hurtig checkout er. Sådan får du et brugbart billede:
- Åbn browserens udviklerværktøjer (F12), fanen Network, og genindlæs siden. Klik på selve sidens forespørgsel og se “Waiting for server response” under Timing. Gør det et par gange, og læg en vare i kurven først, når du måler kurv og checkout.
- Kør siden gennem PageSpeed Insights. Øverst står data fra rigtige besøgende (hvis siden har trafik nok), nederst en enkelt testmåling. Det første er det, Google bruger.
- Installér Query Monitor, helst på en kopi af shoppen. Det viser for hver side, hvor lang tid databasen og PHP bruger, og hvilket plugin der står bag de langsomste forespørgsler.
Skriv tallene ned. Når du senere ændrer noget, er det den eneste måde at vide, om det hjalp.
Serveren og hostingen
Er TTFB høj på alle sider, også de enkleste, så start med serveren. WooCommerce har egne serveranbefalinger, og en shop på en gammel PHP-version eller med for lidt hukommelse til WordPress bliver langsom, uanset hvad du ellers gør. Tjek PHP-versionen og hukommelsesgrænsen under WooCommerce → Status.
Det næste er, hvor mange forespørgsler serveren kan håndtere på én gang. Hver side, der ikke kommer fra en cache, optager en PHP-proces, mens den bliver bygget. På delt hosting eller små planer er der få af dem, og når de er optaget, står de næste besøgende i kø. Det mærkes først i travle perioder og i checkout, fordi det netop er de sider, der ikke kan caches. Står du foran en kampagne, så gå tjeklisten til Black Friday igennem i god tid. Det og resten af PHP-siden, OPcache og antallet af workers, gennemgår vi i guiden om PHP-optimering i WordPress.
Mere hosting er ikke altid svaret. Bruger én forespørgsel flere sekunder i databasen, gør en større server den kun lidt hurtigere. Flyt først, når målingerne viser, at serveren er flaskehalsen.
Caching: hvad en webshop kan cache, og hvad den ikke kan
En page cache gemmer den færdige side og sender den til næste besøgende uden at køre WordPress igen. På en blog dækker det næsten alle sidevisninger. I en webshop gør det ikke. Kurv, checkout og Min konto er forskellige for hver kunde og må aldrig caches, og så snart en kunde har lagt noget i kurven, sætter WooCommerce en cookie, som mange cache-løsninger bruger til at springe cachen over resten af besøget. Det betyder, at de besøgende, der er tættest på at købe, er dem, der får sider bygget fra bunden. Hvad der kan caches, og hvordan du sætter det op, gennemgår vi i guiden om caching i WooCommerce.
Page cache er stadig værd at have til produkt- og kategorisider for nye besøgende. Men det, der gør resten hurtigere, er en object cache: en hukommelsesbaseret cache, typisk Redis, der gemmer resultater af databaseforespørgsler mellem sidevisninger. Den hjælper netop de sider, page cachen ikke dækker. Hvordan du sætter den op, står i guiden om Redis object cache. Vi har sammenlignet de mest brugte object cache-plugins i en test af object cache-plugins til WooCommerce (på engelsk).
Tjek også, at din cache faktisk virker. Mange cache-plugins skriver en header eller en kommentar i sidens kildekode, når siden kom fra cachen. Står den der ikke for en almindelig produktside, er cachen sat forkert op.
Databasen: ordrer, postmeta og autoload
Databasen er et lag, der ofte gør en webshop langsommere over tid, fordi den vokser med hver ordre, hver kunde og hvert plugin. Fire steder er værd at se på først.
Ordrer i wp_postmeta. I ældre WooCommerce-shops ligger ordrer som indlæg, og alle deres oplysninger ligger som rækker i wp_postmeta, den samme tabel som produkternes og alt andets ekstra felter. Med mange ordrer bliver tabellen stor, og ordrelisten i admin, rapporter og søgning bliver langsomme. WooCommerce har derfor High-Performance Order Storage (HPOS), som gemmer ordrer i egne tabeller. Det har været standard for nye shops siden WooCommerce 8.2, men ældre shops skal selv skifte. Se under WooCommerce → Indstillinger → Avanceret → Funktioner, hvilken ordrelagring din shop bruger. Hvad HPOS ændrer, står i guiden om HPOS, og hvordan du skifter, i HPOS-migrering uden nedetid.
Autoloaded options. WordPress henter alle indstillinger markeret som autoload på hver eneste sidevisning. Plugins, der gemmer store mængder data der, eller som er afinstalleret uden at rydde op, gør hver side lidt tungere. WordPress’ Site Health-side under Værktøjer advarer, når de fylder meget. Hvordan du finder og fjerner dem, står i guiden om autoloaded options.
Tunge forespørgsler. Filtre på farve, størrelse eller pris og brugerdefinerede sorteringer bliver ofte til forespørgsler, der læser hele wp_postmeta. Med få hundrede produkter mærker ingen det, med mange tusinde bliver det sekunder. Query Monitor viser, hvilke forespørgsler det er, og hvilket plugin der laver dem.
Data, der vokser af sig selv. Sessioner i wp_woocommerce_sessions, udløbne transients, gamle revisioner og logtabeller fra plugins. Hver for sig er de små problemer, men de lægger sig oven i hinanden.
Hvordan du finder og retter det enkelte problem, gennemgår vi i guiden om at gøre WordPress-databasen hurtig.
Baggrundsjob: Action Scheduler, WP-Cron og admin-ajax
Meget af det, en webshop laver, sker ikke, når kunden klikker, men bagefter: ordremails, lageropdateringer, synkronisering med regnskab eller fragt, webhooks. WooCommerce lægger de opgaver i en kø, Action Scheduler, og afvikler dem i baggrunden. Det går godt, så længe køen bliver tømt. Fejler et job igen og igen, eller kommer der flere ind, end der bliver afviklet, vokser tabellerne, og hver afvikling bliver tungere. Du ser køen under WooCommerce → Status → Planlagte handlinger. Mange tusinde ventende eller fejlede handlinger er et tegn på, at noget skal ses efter. Hvordan du finder årsagen og får køen til at køre igen, gennemgår vi i guiden om Action Scheduler.
Køen bliver som standard sat i gang af WP-Cron, og WP-Cron kører, når nogen besøger siden. På en travl shop betyder det, at baggrundsjob kører oven i almindelige sidevisninger. På en stille shop betyder det, at de bliver forsinket. Begge dele løses ved at lade serveren køre WP-Cron på et fast interval i stedet for at vente på besøgende. Det kan mange hostingudbydere sætte op.
I admin er der en tredje kilde: admin-ajax.php. WordPress’ Heartbeat API og mange plugins sender forespørgsler til den med faste mellemrum, så længe et admin-vindue står åbent. Har flere medarbejdere admin åben hele dagen, kan det alene give serveren mærkbart arbejde.
Plugins og tema
Antallet af plugins siger ikke meget. Ét plugin, der kører en tung forespørgsel på hver sidevisning, koster mere end tyve små, der kun gør noget, hvor de skal. Det, du vil vide, er, hvad hvert plugin laver på den side, der er langsom.
Query Monitor viser det under “Queries by Component”, hvor forespørgslerne er fordelt på plugins og tema. Står ét plugin for en stor del af tiden, har du en mistænkt. Kan du ikke se det dér, så slå plugins fra ét ad gangen på en kopi af shoppen og mål siden igen efter hver. Gør det aldrig på den rigtige shop: et plugin, der er slået fra, kan stoppe betalinger eller ordrer. Hele fremgangsmåden står i guiden om at finde det plugin, der gør siden langsom.
Typiske syndere er plugins, der tilføjer funktioner til hver produktvisning (filtre, relaterede produkter, “andre købte også”), statistik- og log-plugins, der skriver til databasen ved hver sidevisning, og sidebyggere eller temaer, der indlæser meget, også på sider, hvor det ikke bruges.
Frontend: billeder, scripts og cart fragments
Er TTFB lav, men siden stadig længe om at blive brugbar, ligger tiden i browseren. I webshops er det ofte tre ting: store produktbilleder, der ikke er skaleret eller lazy-loaded, tredjepartsscripts (tracking, chat, anmeldelser, nyhedsbrevs-popups), der hver især henter kode fra andre servere, og JavaScript fra plugins, der indlæses på alle sider.
En særlig WooCommerce-ting er cart fragments: et script, der efter sidevisningen spørger serveren om kurvens indhold, så mini-kurven i headeren er opdateret, også på en side fra cachen. Det er én ekstra forespørgsel, som ikke kan caches, på hver sidevisning. Siden WooCommerce 7.8 indlæses scriptet ikke længere på alle sider som standard, men mange temaer og plugins slår det til igen. Du kan se det i fanen Network som ?wc-ajax=get_refreshed_fragments. Hvordan du ser, om det koster tid, og hvad du gør ved det, står i guiden om langsom “Læg i kurv” og cart fragments.
Billeder, CSS, JavaScript og fonte gennemgår vi i guiden om hurtigere billeder, CSS og JavaScript i WordPress.
Rækkefølgen, vi ville tage det i
- Skriv ned, hvilke sider der er langsomme, og for hvem.
- Mål TTFB på de sider uden cache, og kør dem gennem PageSpeed Insights.
- Tjek PHP-version, hukommelse og om serveren løber tør for processer i travle perioder.
- Tjek, at page cachen virker på produkt- og kategorisider, og overvej en object cache.
- Find de langsomste forespørgsler og det plugin, der laver dem, med Query Monitor på en kopi.
- Se på ordrelagring (HPOS), autoload og køen af planlagte handlinger.
- Til sidst frontenden: billeder, scripts og cart fragments.
Ret én ting ad gangen, og mål igen efter hver. Retter du fem ting på én gang, ved du ikke, hvilken der hjalp, eller hvilken der gjorde noget værre.
Ofte stillede spørgsmål
Er WooCommerce bare langsomt?
Nej. WooCommerce gør mere arbejde pr. sidevisning end en simpel hjemmeside, fordi kurv, priser og lager skal være rigtige for hver kunde. Men en shop med fornuftig hosting, page cache og object cache og uden tunge plugins kan være hurtig. Når den ikke er det, er der en årsag, der kan findes.
Hjælper dyrere hosting?
Kun hvis serveren er flaskehalsen. Viser målingerne, at tiden går i én tung forespørgsel eller ét plugin, bliver det kun lidt bedre på en større server. Mål først, og flyt så, hvis det er serveren.
Hvor mange plugins er for mange?
Der er ikke et tal. Det, der tæller, er, hvad hvert plugin gør på hver sidevisning. Fjern dem, du ikke bruger, og mål dem, du er i tvivl om.
Vil du have hjælp?
Fejlfinding tager tid, især når årsagen ligger i et plugin eller i data, der har vokset i årevis. Vil du hellere have, at vi finder den, så læs om hastighedsoptimering af din WooCommerce-shop. Vi kigger gratis på din shop først og fortæller dig, hvad der skal til.