Når “Læg i kurv” er langsom, er det enten selve tilføjelsen, der tager tid, eller de forespørgsler, WooCommerce sender bagefter for at opdatere kurven i headeren. Ofte er det det sidste, og det rammer ikke kun knappen: på mange shops sender hver eneste side en ekstra forespørgsel, der ikke kan caches.
Her gennemgår vi, hvad der sker, når kunden lægger en vare i kurven, hvordan du finder ud af, hvor tiden går, og hvad du kan gøre ved cart fragments, beregningen af kurven og sessionerne.
Hvad sker der, når kunden trykker “Læg i kurv”?
På kategorisider lægger WooCommerce typisk varen i kurven med en forespørgsel i baggrunden, ?wc-ajax=add_to_cart. På produktsiden sendes formularen, og siden indlæses igen. I begge tilfælde gør WooCommerce det samme: opretter en session til kunden, hvis der ikke er en, lægger varen i kurven, regner totalerne igennem og sender de opdaterede dele af siden tilbage, fx minikurven i headeren.
Fra det øjeblik har kunden en kurv, og mange sidecacher holder op med at servere cachede sider til kunden. Alt, hvad kunden ser derefter, bygges fra bunden. Hvorfor det er sådan, står i vores guide til caching i WooCommerce.
Find ud af, hvor tiden går
Åbn browserens udviklerværktøjer (F12), gå til Network, og læg en vare i kurven. Se efter tre forespørgsler:
| Forespørgsel | Hvad den gør |
|---|---|
?wc-ajax=add_to_cart eller produktsiden selv | Selve tilføjelsen og beregningen af kurven |
?wc-ajax=get_refreshed_fragments | Henter den opdaterede minikurv. Kan også komme på helt almindelige sidevisninger |
Kald til /wp-json/wc/store/v1/ | Den nyere minikurv-blok, der henter kurven gennem WooCommerce’ Store API |
Den, der tager længst tid, er der, du skal lede. Åbn også en almindelig side uden at røre kurven, og se, om get_refreshed_fragments bliver sendt alligevel.
Cart fragments og get_refreshed_fragments
Cart fragments er WooCommerce’ script til at holde minikurven opdateret, også på sider, der kommer fra sidecachen. Det gør det ved at spørge serveren om kurven med ?wc-ajax=get_refreshed_fragments. Den forespørgsel kan ikke caches, så den skal igennem PHP og databasen hver gang. Kører den på hver sidevisning, sender hver besøgende en ekstra forespørgsel pr. side, der ikke kan caches, også dem uden noget i kurven.
Fra WooCommerce 7.8 bliver scriptet kun indlæst på sider, der viser WooCommerce’ kurv-widget, ifølge WooCommerce’ egen vejledning om cart fragments (på engelsk). Men mange temaer og sidebyggere viser en minikurv i headeren på alle sider, og så bliver det indlæst overalt igen. Det samme gælder plugins, der selv beder om det.
Hvad du kan gøre, afhænger af, hvad headeren skal vise:
- Skal headeren kun linke til kurven, så brug et kurv-ikon uden indhold, og scriptet er ikke nødvendigt.
- Skal den vise antal og indhold, så overvej WooCommerce’ minikurv-blok, der henter kurven gennem Store API, eller et tema, der kun spørger serveren, når kunden har en kurv.
- Bruger du et hastighedsplugin, der kan slå cart fragments fra, så test bagefter, at antallet i headeren stadig passer på cachede sider, efter kunden har lagt noget i kurven.
Når selve tilføjelsen er langsom
Er det add_to_cart, der tager tid, ligger årsagen i beregningen af kurven. Hver gang kurven ændres, kører WooCommerce priser, rabatter, moms og ofte fragt igennem, og plugins kan hægte sig på hvert trin. Typiske syndere er plugins til mængderabatter og dynamiske priser, B2B-priser, pakker og tilvalg, og plugins, der tjekker lager mod et andet system, mens kunden venter.
Det er de samme mekanismer, der gør checkout langsom, og fremgangsmåden er den samme: find den langsomme forespørgsel, og se, hvilke plugins der bruger tiden i den. Den står i vores guide til langsom checkout i WooCommerce.
Sessioner i databasen
Når en kunde lægger noget i kurven, gemmer WooCommerce kurven i tabellen wp_woocommerce_sessions med en cookie, der peger på den. Udløbne sessioner bliver ryddet op af et planlagt job. Kører WP-Cron ikke, eller sjældent, vokser tabellen, og opslagene i den bliver langsommere. Hvorfor WP-Cron skal køre fra serveren, står i afsnittet om baggrundsjob i fejlfindingsguiden.
Bots kan også skabe sessioner. Følger en crawler links med ?add-to-cart=, lægger den varer i kurven og får en session for hver. Se i serverens adgangslog, om der er mange af de forespørgsler fra bots, og bed din hostingudbyder om at blokere dem.
Både sessionerne og beregningen af kurven bliver hurtigere med et object cache, fordi en stor del af de data, WooCommerce slår op, så ligger i hukommelsen. Opsætningen står i vores guide til Redis object cache.
Ofte stillede spørgsmål
Kan jeg bare slå cart fragments fra?
Ja, hvis minikurven ikke behøver at være opdateret på cachede sider. Ellers risikerer du, at headeren viser en tom kurv, selv om kunden har lagt noget i den. Test det i et privat vindue, før det går live.
Hvorfor er produktsiden langsom, efter jeg har lagt noget i kurven?
Fordi mange sidecacher springer over, så snart der er en kurv. Siden bygges fra bunden, og det viser, hvor hurtig serveren er uden cache. Det er de sider, der skal gøres hurtigere.
Vil du have hjælp?
En langsom kurv rammer kunderne i det øjeblik, de har besluttet sig. Vil du have, at vi finder ud af, hvor tiden går i din shop, så læs om optimering af en langsom WooCommerce-shop. Vi kigger gratis på din shop først og siger, hvad der skal til.