En långsam WooCommerce-butik kostar i kronor, inte bara i tålamod. Ju längre kassan tar att ladda, desto fler kunder hoppar av innan de betalat. Det som gör en butik trög är sällan en enda sak, utan en kombination av dynamiska sidor som inte kan cachas rakt av, en databas som svällt över tid, och en värd som inte är byggd för e-handel. Den här guiden går igenom var tiden faktiskt tar vägen i en butik, och de åtgärder som gör verklig skillnad. Inga påhittade siffror, bara de orsaker vi ser om och om igen och vad du gör åt dem.
Varför en butik är svårare att snabba upp än en bloggsajt
En vanlig sajt kan servera nästan varje sida från cache: samma HTML till alla besökare. En butik kan inte det rakt av. Varukorgen, kassan och Mitt konto är personliga för varje inloggad besökare, och de måste byggas på nytt vid varje anrop. Det är därför det generella rådet ”slå på cache” inte räcker för WooCommerce. Utmaningen är att cacha allt som går att cacha, produktlistor, kategorisidor, startsidan, samtidigt som de dynamiska sidorna förblir dynamiska. Får du inte den gränsen rätt riskerar du antingen en långsam butik eller, värre, att en kunds varukorg visas för en annan.
Cache för dynamiska sidor, gjord rätt
Lösningen är sidcache med undantagsregler. Merparten av butiken serveras då från cache, snabbt och utan att PHP ens startar, medan varukorg, kassa och inloggade vyer alltid går live. På Celestio är just det här hur plattformen är byggd: full sidcache där du styr reglerna, så att kassor och inloggade vyer förblir dynamiska medan resten cachas. Det du vill säkerställa, oavsett värd:
- Cart, checkout och my-account är undantagna från sidcache.
- WooCommerce-cookies som markerar en icke-tom varukorg kringgår cachen, så att ingen ser en cachad sida med fel varukorg.
- Produkt- och kategorisidor cachas, och cachen rensas automatiskt när du ändrar en produkt eller ett lagersaldo.
Utöver sidcache hjälper ett objektcache-lager för databasresultat på tunga butiker, eftersom det avlastar upprepade databasfrågor mellan sidladdningar. Det är ett lager du lägger till på servernivå, och värt att fråga din värd om ifall butiken är stor.
Databasen som svällt över tid
En butik som funnits ett par år bär ofta på en databas full av data som inte längre behövs. Det saktar ner varje fråga, särskilt i admin och i kassan. De vanligaste källorna till svullnad:
- Utgångna transients. Tillfälliga cacheposter i wp_options som aldrig städats bort.
- Övergivna varukorgar och gamla sessioner. Kan bli hundratusentals rader på en aktiv butik.
- Inläggsrevisioner. Varje produkt kan bära på dussintals sparade versioner du aldrig behöver.
- Loggar och data från avinstallerade plugins. Tabeller som ligger kvar långt efter att pluginet är borta.
En autoloaded options-rad som växt sig stor är en klassisk och osynlig bromskloss, eftersom den läses in vid varje enda sidladdning. Med SSH-åtkomst kan du mäta det direkt och rensa med WP-CLI i stället för att gissa.
En snabb butik är summan av små, tråkiga beslut: rätt cache-gränser, en städad databas, och en värd som kör en modern PHP-version. Ingen enskild knapp gör den snabb, men varje utebliven bromskloss märks i kassan.
PHP-versionen och servern under
WooCommerce är PHP-tung, och PHP-versionen betyder mycket. Nyare versioner kör samma kod snabbare och får dessutom säkerhetsfixar. Kör din butik på en flera år gammal PHP-version lämnar du prestanda på bordet utan att göra något annat. Kontrollera din version och planera att hålla dig på en som fortfarande stöds. Lika viktigt är att butiken inte delar en överbelastad server med hundratals andra sajter, eftersom din kassa då konkurrerar om samma processorkraft varje gång någon handlar. Per-site PHP, där du styr version och resurser för just din butik, tar bort den osäkerheten.
Mät innan du optimerar
Gissa aldrig var flaskhalsen sitter. Mät först, så att du åtgärdar rätt sak:
- Testa både en produktsida och kassan, inte bara startsidan. De beter sig helt olika.
- Titta på tiden till första byte för att se om servern eller PHP är trög innan sidan ens börjar ritas.
- Använd Query Monitor för att hitta långsamma databasfrågor och plugins som drar tid.
- Mät en inloggad vy, inte bara som utloggad besökare, eftersom det är där cachen inte hjälper.
De flesta av de här åtgärderna går att göra själv, men de kräver åtkomst till servern och tid att mäta. Vill du ha en butik som redan står på en plattform med sidcache och regler byggda för WooCommerce, per-site PHP och riktig åtkomst för att mäta, läs mer om vår plattform och om hur vi tänker kring WooCommerce-drift. Du kan också starta ett konto och flytta över butiken.