Prestandaoptimering av WooCommerce bör minska arbetet innan en förfrågan når PHP, inte bara få PHP att arbeta hårdare. En butik som skickar varje katalogförfrågan genom WordPress, plugins, WooCommerce-sessioner, Redis och MySQL kommer förr eller senare att drabbas av köer, överbelastade workers eller konkurrens om databasen när trafiken ökar.
För butiker med hög trafik optimerar vi hela förfrågans väg: Cloudflare → Nginx → PHP-FPM → WordPress → Redis → MySQL. Målet är tydligt. Cacha anonym trafik på ett säkert sätt, bevara de dynamiska köpflödena, ta bort onödig kod från varje förfrågan och skydda dyra workers mot botar och plötsliga trafiktoppar.
WooCommerce beskriver själv den här skillnaden tydligt: varukorgs-, kassa- och kontosidor måste förbli dynamiska eftersom de visar kundspecifik information. Katalogen och andra anonyma sidor är något annat. Där går det att hålla det mesta av den återkommande trafiken borta från applikationen, om cachereglerna utformas efter hur sessioner och cookies faktiskt beter sig. WooCommerces vägledning om cachning stöder den här gränsen.
Den verkliga flaskhalsen är onödigt arbete
En långsam butik beskrivs ofta som ett hostingproblem. Ibland är det så. Oftare är det underliggande problemet att för många förfrågningar går igenom samma dyra väg.
Varje katalogförfrågan utan cache kan starta PHP-FPM, ladda WordPress, aktiva plugins och WooCommerce-data, fråga MySQL och generera ett svar som kan vara identiskt för tusentals anonyma besökare. Att lägga till PHP-workers utan att ta bort det arbetet flyttar oftast bara trycket vidare till CPU, Redis, MySQL eller externa API:er.
Vår metod är att stoppa arbetet i det tidigaste säkra lagret. Cloudflare bör leverera cachebara publika resurser och svar som uppfyller kraven. Nginx FastCGI Cache bör leverera anonym HTML utan att starta PHP. PHP-FPM bör bara ta emot förfrågningar som kräver applikationslogik. Redis bör ta hand om upprepade objektuppslag. MySQL bör vara tillgängligt för skrivningar och för läsningar som verkligen inte går att cacha.
| Lager | Huvudansvar | Vanligt misstag | Vad som ska valideras |
|---|---|---|---|
| Cloudflare | Leverans från kanten av publika resurser och verifierade cachebara svar | Att gå förbi kanten eftersom varje svar har cookies eller restriktiva cache-headers | Cachestatus, headers, variation efter språk och valuta |
| Nginx | FastCGI-cachning, routning, köskydd, gränser för förfrågningar | Att skicka anonym HTML till PHP som standard | Träffgrad i cachen, svarstid från upstream, händelser med hastighetsbegränsning |
| PHP-FPM | Dynamisk körning av applikationen | Att sätta antalet workers på känn | Kötid, aktiva workers, CPU, minne, p95-latens |
| WordPress och plugins | Ladda bara den kod som förfrågan behöver | Att ladda varje integration på varje sida | Uppstartstid, hooks, frågor, funktionella regressioner |
| Redis | Objektcache och lagring av sessioner | Att slå ihop orelaterade arbetslaster utan att planera utrymning | Minne, utrymningar, träffgrad, TTL för nycklar, overhead för persistens |
| MySQL | Beständiga data och nödvändiga läsningar och skrivningar | Att använda databasen som första cachelager | Långsamma frågor, lås, tryck på anslutningar, skrivlatens |
Ordningen spelar roll eftersom varje lager har en egen kostnadsprofil. Nginx kan leverera en giltig cacheträff utan att starta PHP. Nginx dokumenterar styrningen av FastCGI-cachen, bland annat cachelåsning och leverans av inaktuella svar, vilket kan minska trycket på upstream medan en cachepost uppdateras.
Så optimerar du en WooCommerce-butik med hög trafik
Börja med att klassificera förfrågningarna. Använd inte en enda cachepolicy för hela butiken.
Publika katalogsidor, kategoriarkiv, produktsidor, redaktionellt innehåll och utvalda publika API-svar kan vara aktuella för cachning. Varukorg, kassa, kundkonto, betalningscallbacks, autentiserade förfrågningar och förfrågningar med aktiv varukorg behöver en medvetet utformad dynamisk väg. Den skillnaden är inte valfri. En cachad kassasida kan bli en incident som gäller korrekthet och säkerhet, inte en prestandaförbättring.
WooCommerces vägledning om prestanda rekommenderar också villkorlig laddning av resurser, effektiva databasfrågor, testning av plugin och prestandamätning. De principerna gäller för butiken som helhet och inte bara för det enskilda pluginet.
Arkitekturen bör göra en anonym produktvisning billig och reservera applikationens kapacitet för att lägga i varukorgen, uppdatera varukorgen, kassan, betalningar, sparande av ordrar, kundåtgärder och integrationer.
Cacha anonym trafik utan att förstöra personanpassad handel
Vi använder Nginx FastCGI Cache så att de flesta anonyma besökare inte startar PHP eller WordPress alls. Det är särskilt värdefullt på stora katalogsidor, där upprepad rendering utan cache kan binda upp workers utan att ge något större affärsvärde.
Cachenycklarna måste spegla hur butiken varierar. I flerspråkiga butiker med flera valutor innehåller vår cachenyckel det aktiva WPML-språket och valutakontexten. Utan den variationen kan även en giltig cacheträff visa besökaren fel språk eller fel prisvisning.
Efter att cachen har tömts kan vi automatiskt värma upp upp till 2 000 URL:er från webbplatskartan. Uppvärmning ersätter inte kapacitetsplanering, men den förhindrar att de första riktiga besökarna efter tömningen får betala för att populära sidor byggs upp igen. Vi går också igenom utvalda REST-ändpunkter en och en. En ändpunkt blir cachebar vid kanten först när det har verifierats att svaret inte beror på kundens cookies och onödigt Set-Cookie- eller Vary: Cookie-beteende har tagits bort på ett säkert sätt.
För medielagring kan vi hålla bilderna i Cloudflare R2 och leverera dem via en lämplig resursväg. Det skiljer medielagringen från körningen av WordPress-applikationen. Det tar dock inte bort behovet av att optimera bildernas dimensioner, format, responsiv uppmärkning och cachepolicy.
Den praktiska regeln är enkel: cacha ett svar bara när det går att visa att det är detsamma för alla användare som kan få det. WooCommerce anger varukorg, kassa och konto som dynamiska sidor eftersom innehållet är kundspecifikt.
För en bredare genomgång av flaskhalsar utanför cachelagret kan du använda vår tjänst för granskning av WordPress-webbplatser för att identifiera begränsningar i applikation, databas, plugins och infrastruktur innan du ändrar reglerna i produktion.
Minska arbetet i WordPress och databasen med Redis
En beständig objektcache i Redis minskar upprepat databasarbete när WordPress och WooCommerce begär samma objekt om och om igen. Den ersätter inte helsidescachning. Den är nästa lager för förfrågningar som ändå måste nå applikationen.
Vi håller WordPress objektcache och WooCommerce sessioner i separata Redis-instanser. Arbetslasterna, nycklarnas livslängd, felbeteendena och minnesbeteendet skiljer sig åt. Nycklar i objektcachen är kopior av databasdata som går att kasta bort. Sessionsnycklar representerar aktivt kundtillstånd och måste hanteras varsammare.
För WooCommerce-sessioner flyttar vi lagringen från wp_woocommerce_sessions till Redis. Sessionsnycklarna har TTL, och Redis-instansen för sessioner kan använda volatile-lru, så att utrymningen riktas mot nycklar med utgångstid i stället för godtyckliga permanenta nycklar. Redis dokumenterar att volatile-lru utrymmer de minst nyligen använda nycklarna som har en tilldelad TTL, och rekommenderar separata instanser när arbetslasterna har väsentligt olika behov av persistens (Redis eviction).
Där driftsmiljöns topologi gör det lämpligt kan vi ansluta PHP till Redis via en Unix-socket i stället för TCP. Det är ett implementationsval som bör mätas, inte en universell regel. Socketbehörigheter, containergränser, design för failover och observerbarhet spelar alla in.
Sessionsinstansen kan använda RDB-ögonblicksbilder så att sessionerna kan överleva en kontrollerad omstart eller en återställning från en tillgänglig ögonblicksbild. RDB är dock persistens vid en given tidpunkt, inte ett löfte om noll dataförlust. Redis påpekar att de senaste skrivningarna kan gå förlorade om ett fel inträffar mellan två ögonblicksbilder.
I ett kontrollerat IMADO-test slutförde vi ungefär 78 % fler iterationer efter att WooCommerce-sessionerna flyttats till Redis. Ett mer försiktigt planeringsintervall är 40–60 % ökad genomströmning vid en jämförbar flaskhals. Det är ett observerat resultat från en specifik miljö, inte en garanti. Pluginbeteende, katalogens storlek, sessionsvolym, PHP-inställningar, databasprestanda och testmix kan ändra resultatet avsevärt.
WooCommerce fortsätter själv att minska frågearbetet i kärnan. WooCommerce 10.7 införde till exempel cache priming som i det beskrivna scenariot minskade en dokumenterad REST-väg för orderfrågor från 271 till 132 databasfrågor. Det bekräftar samma princip: minska upprepat arbete innan du skalar infrastrukturen (WooCommerce 10.7).
Justera PHP-FPM och uppstarten av WordPress efter förfrågans kontext
Fler PHP-FPM-workers är inte automatiskt bättre. Varje worker använder minne och kan öka det samtidiga trycket på MySQL och externa tjänster. Vi dimensionerar workers med tester som omfattar realistisk trafik mot katalog, varukorg, kassa, AJAX och integrationer.
OPcache och WP_CACHE bör vara aktiverade och validerade. Därefter kommer den större vinsten ofta av att minska det som WordPress laddar vid varje förfrågan.
Vi använder kontextberoende regler för pluginladdning med Dynamic Plugin Loader. På katalogsidor kan det utesluta betalningslösningar, fraktintegrationer, administrationsverktyg och andra plugins som inte spelar någon roll när en anonym produktlista renderas. I kassan finns betalningsfunktionerna kvar, medan SEO-funktioner som inte är nödvändiga, produktflöden, önskelistor och administrationsverktyg kan uteslutas där tester visar att de inte behövs.
Reglerna bör skilja sig åt för produkter, kategorier, varukorg, kassa och AJAX. WordPress-administrationen, WP-CLI, cron och REST API får hela uppsättningen plugins om inte ett specifikt undantag har testats. Att avlasta plugins kan ge märkbara besparingar, men det är en optimering som är känslig för kompatibilitet. Testa varukorgens beständighet, sessionernas kontinuitet, fraktberäkning, betalningsmetoder, webhooks, kuponger, åtgärder på kundkontot och tredjepartsintegrationer före driftsättning.
Om butiken under flera år har samlat på sig plugin och egen logik kan prestandaarbetet också kräva en bredare underhållsplan för WordPress i stället för en engångskonfiguration av cachen.
Skydda dyra workers under trafiktoppar
Trafiktoppar är inte bara ett kapacitetsproblem. De är ett problem med att forma trafiken.
Vi justerar anslutningsköerna i Nginx och operativsystemet så att korta toppar kan hanteras utan att legitima förfrågningar avvisas direkt. Vi använder också hastighetsbegränsning i Nginx innan PHP startar. Det förhindrar att illasinnade botar, försök till credential stuffing, pratsamma integrationer och överdriven API-polling förbrukar de workers som riktiga kunder behöver.
Gränserna bör inte vara likadana för allt. Inloggning, REST API, AJAX, varukorg och kassa har olika förväntade trafikmönster och olika affärsrisk. Skyddet av kassan måste vara tillräckligt strikt för att stoppa missbruk, men inte så aggressivt att det blockerar riktiga kunder under en kampanj.
Generering av e-post är en annan vanlig källa till onödigt arbete i kassan. Där butikens och integrationernas utformning tillåter det flyttar vi hanteringen av icke-kritisk e-post till en kö och kör den som schemalagda jobb. Kassaförfrågan bör prioritera att validera ordern, registrera betalningsstatus och returnera ett tillförlitligt svar.
Därför behöver stora kampanjer också en generalrepetition. Testa en produktionslik mix av surfning i cachad katalog, sökning, åtgärder för att lägga i varukorgen, kassaförsök, API-förfrågningar, botar och bakgrundsjobb. Ett belastningstest som bara träffar startsidan är ingen kapacitetsplan för WooCommerce.
Det här ska du mäta före och efter varje ändring
Prestandaoptimering utan mätning blir konfigurationsfolklore. Fastställ en utgångsnivå, ändra en betydelsefull variabel och jämför resultaten med samma trafikmix.
- Besöksupplevelse: p50-, p95- och p99-svarstid för katalog-, produkt-, varukorgs- och kassavägar.
- Cachebeteende: träffgrad i cachen hos Cloudflare och Nginx, orsaker till att cachen förbigås, variation i cachenyckeln och slutförd uppvärmning.
- PHP-kapacitet: aktiva och köade PHP-FPM-workers, processminne, CPU-mättnad och väntetid mot upstream.
- Redis hälsa: träffgrad i objektcachen, minnesanvändning, utrymningar, TTL för nycklar, latens och persistensaktivitet.
- Databastryck: antal långsamma frågor, frågelatens, väntan på lås, anslutningar och skrivprestanda i kassan.
- Affärsmässig korrekthet: lyckade åtgärder för att lägga i varukorgen, slutförda köp, betalningscallbacks, skapande av ordrar och förändringar i felfrekvensen.
Använd mätningarna för att välja nästa flaskhals. Hög träffgrad i cachen kombinerat med en långsam kassa pekar mot arbete i den dynamiska applikationen, databasen, betalningarna eller integrationerna. Låg träffgrad på publika katalogsidor pekar mot cacheregler, headers, cookies, variation eller uppvärmning.
För butiker med mycket specialbyggd funktionalitet kan vårt team för WordPress-utveckling ta itu med prestandan på kod- och arkitekturnivå i stället för att behandla symtomen vid kanten.
Checklista för driftsättning i produktion
- Registrera en utgångsnivå för katalog, varukorg, kassa, PHP-FPM, Redis, MySQL och felfrekvenser.
- Kartlägg varje route efter hur cachebar den är och vilka krav den har på personanpassning.
- Inför variation i cachen för språk, valuta, enhetsspecifikt beteende där det är motiverat samt gränser för kundtillstånd.
- Testa FastCGI- och kantcacheregler mot anonym surfning, uppdateringar av varukorgen, kassa, inloggning, kontoåtgärder och betalningscallbacks.
- Flytta objektcache och sessioner medvetet, med definierade minnesgränser, utrymningspolicy, TTL, övervakning och återställningsbeteende.
- Bestäm antalet PHP-FPM-workers med tester med realistisk samtidighet i stället för att maximera antalet processer.
- Inför regler för pluginladdning en kontext i taget och ha en snabb väg tillbaka.
- Sätt routespecifika gränser för förfrågningar och testa kampanj- och botscenarier innan topptrafiken kommer.
- Driftsätt stegvis, följ p95- och p99-latens samt affärstransaktioner och behåll den tidigare konfigurationen tills ändringen har visat sig fungera.
När prestandaoptimering av WooCommerce kräver utvecklingsarbete
Ett cacheplugin kan hjälpa en enkel butik. Det räcker inte när butiken har hög katalogtrafik, flerspråkiga priser, egen kassalogik, ERP- eller CRM-integrationer, betalningslösningar, externa API:er, många plugins, återkommande kampanjer eller en historik av incidenter i produktion.
Då handlar arbetet om arkitektur och drift: cachegränser, svarsheaders, sessionshantering, körning av plugins, PHP-kapacitet, köskydd, databasbeteende, kontroll över driftsättningar och övervakning. Rätt implementation minskar belastningen utan att försämra kundresan.
Behöver du en butiksarkitektur som förblir snabb under kampanjtrafik och toppar i kassan? Se vår tjänst för hastighetsoptimering av WordPress eller prata med våra utvecklare.
