Hoppa till innehåll 
Jag gör WordPress märkbart snabbare genom att NGINX-cache använder på servernivå och levererar HTML-svar direkt. På så sätt minskar TTFB avsevärt, PHP-FPM förblir ledigt och databasen behöver bearbeta mindre Frågor.
Centrala punkter
- På serversidan I stället för ett plugin: FastCGI Cache avlastar PHP och minskar latensen.
- Utrensning Vid ändringar: Innehållet hålls uppdaterat och förnyas på ett målinriktat sätt.
- Undantag För inloggning, varukorg och kassa behåller dynamiska områden sin dynamiska karaktär.
- Skalning under belastning: Cachen används oftare och minskar belastningen på servern.
- Mätbar snabbare: TTFB-, RPS- och CPU-värdena förbättras avsevärt.
Hur NGINX FastCGI Cache gör WordPress snabbare
Vid det första anropet renderar WordPress sidan, varefter NGINX lagrar det färdiga svaret som HTML och levererar framtida identiska förfrågningar utan PHP-FPM. På så sätt minskar jag CPU-tid och kontextbyten, medan filsystemet respektive operativsystemets cache snabbt Träffar levererar. Särskilt vid trafiktoppar förblir svarstiden låg, eftersom inga PHP-processer behöver startas. På så sätt minimerar jag TTFB och möjliggör fler förfrågningar per sekund. Resultatet märks i en smidigare interaktion, färre timeout-fel och en tydlig prestandareserv för verkligt dynamiska processer.
Cache på serversidan jämfört med cache via plugin (inkl. jämförelse)
Ett cache-plugin fungerar i PHP-stack och utlöser ofta processer även vid träffar, medan FastCGI Cache svarar direkt på webbservernivå. På så sätt undviks många överheadkostnader, såsom PHP-initialisering och plugin-hooks. För återkommande besökare satsar jag främst på den serversidiga metoden och kombinerar den vid behov med ett lättviktigt plugin för frontend-optimering. Den som vill granska detaljerna noggrant bör börja med en smidig Testfas och mäter TTFB, CPU och cache-hit-rate separat. Skillnaderna blir mycket snabbt tydliga – särskilt under belastning.
| Kriterium | Plugin-cache (PHP) | NGINX FastCGI-cache |
|---|---|---|
| Svarväg | PHP har startats, plugin kontrollerar cachen | Webbservern levererar filen direkt |
| TTFB | högre på grund av PHP-start | mycket låg vid cacheträffar |
| Resurser | mer CPU/RAM per begäran | betydligt färre resurser |
| Skalning | begränsat av PHP-processer | skalar effektivt med NGINX |
| Beroenden | Möjliga konflikter mellan teman och plugins | fungerar på WordPress-plattformen |
Jag använder dessutom tydliga cache-nycklar och en överskådlig mappstruktur så att innehållet separeras per värd, schema och URI. Den som vill komma igång kan läsa min guide till Optimering av NGINX-cachen använda som vägledning. På så sätt förblir konfigurationen överskådlig och framtida utökningar går snabbare att genomföra.
Lämpliga scenarier och viktiga undantag
Den som gynnas mest Innehåll, det vill säga bloggar, tidskrifter, landningssidor och företagswebbplatser med många anonyma besök. Jag cachelagrar alla sidor som förblir identiska för besökarna och utesluter allt som är personaliserat. Detta inkluderar inloggning, profil, kommentarformulär, WooCommerce-varukorg, kassa och ”Mina konton”. Cookies och rubriker används som kriterier för att målmedvetet kringgå cachen. På så sätt förblir offentliga sidor blixtsnabba, medan känsliga områden förblir korrekt dynamiska och användarna får en smidig upplevelse serverar bli.
Tekniska grunder: cachezon, nyckel, rubrik
Jag definierar först Cache-sökväg och en zon i NGINX-konfigurationen, inklusive storlek och inaktivitetstid. Cache-nyckeln innehåller schema, värd och URI, samt eventuellt frågesträngar, så att varianter hålls åtskilda. Med hjälp av fastcgi_cache_valid, bypass- och no-cache-regler styr jag när förfrågningar ska kringgå cachen. Viktiga rubriker som Set-Cookie, Authorization och vissa cookies från WordPress eller WooCommerce signalerar dynamik. Dessutom anger jag vilka felsidor eller 50x-svar som ska cachelagras tillfälligt, så att sidan fortsätter att fungera även under hög belastning svar.
Cachehantering och rensningsstrategi
En cache fungerar först när uppdateringarna sker pålitligt Rulla ut. När jag sparar ett inlägg startar jag en riktad rensning av de berörda URL:erna, inklusive startsidor, kategorier och flöden. Dessutom ställer jag in en lämplig TTL så att innehållet genereras på nytt med jämna mellanrum. För stora webbplatser underlättar förladdning av viktiga landningssidor, så att den första besökaren inte upplever en kallstart. Efter varje ändring kontrollerar jag cache-hit-frekvensen och ser till att rensningarna inte lämnar kvar föråldrade fragment lämna efter sig.
Regler för WordPress och WooCommerce
Jag låter inloggade användare konsekvent använda cachen förbi, vanligtvis med hjälp av cookien wordpress_logged_in. För WooCommerce utesluter jag varukorgen, kassan och ”Mina konton” genom URI-mönster och tar hänsyn till cookies som woocommerce_items_in_cart. Produktsidor, kategorisidor och innehållssidor cachelagrar jag däremot som vanligt. Dessutom rensar jag cachen när lagerstatus eller pris ändras via en hook. Denna uppdelning håller de offentliga sidorna snabba utan att påverka köpprocesserna. stör.
Att välja rätt TTL, Stale och Locking
Jag ställer in innehållets TTL utifrån praktiska behov, till exempel från några minuter till några timmar, beroende på Aktualitet och trafik. Stale-alternativen gör det möjligt för mig att tillfälligt leverera utgångna objekt medan en ny version skapas i bakgrunden. Låsning förhindrar ”stampede-effekten” när många förfrågningar samtidigt riktas mot ett utgånget objekt. Lämpliga fel- och timeout-regler säkerställer att besökare får ett svar även vid korta störningar. Mer bakgrundsinformation om riktlinjerna ger jag i min kortfattade Strategier för kontroll av cacheminnet, som går bra att kombinera med FastCGI Cache.
Övervakning och mätvärden som spelar roll
Först mäter jag TTFB, därefter antal förfrågningar per sekund och CPU-belastning, uppdelat på cacheträffar och cachemissar. NGINX-loggar och svarhuvuden visar om det rör sig om en HIT, MISS, BYPASS eller EXPIRED. En stigande träfffrekvens vid sjunkande CPU-belastning är mitt tecken på att reglerna fungerar. Dessutom övervakar jag filsystemets I/O och antalet aktiva PHP-processer. För villkorlig cachelagring använder jag ETag/Last-Modified på ett meningsfullt sätt och hänvisar till min guide om Villkorlig cachelagring med ETag, så att webbläsarens och serverns cache fungerar i samklang och nätverksbelastningen märkbart fall.
Vanliga fel och hur jag löser dem
Ett vanligt hinder är att man går för långt Cache-nyckel, som döljer varianter och levererar felaktigt innehåll. Lika kritiskt: avsaknaden av undantag för cookies som wordpress_logged_in eller WooCommerce-signaler. Om rensningarna endast gäller enskilda sidor förblir arkiv- och startsidorna inaktuella; därför utökar jag de berörda målen. Jag behöver ofta även inkludera frågesträngar i nyckeln, annars skriver en variant över den andra. För korta TTL:er ger upphov till onödiga MISS-frekvenser, medan för långa TTL:er ökar risken för föråldrade Sidor.
Praktiskt arbetsflöde för genomförandet
Jag inleder varje projekt med en tydlig Planera: Definiera mål, markera sökvägar som ska cachelagras, fastställa dynamiska undantag. Därefter konfigurerar jag cachesökväg, zon, nyckel och header-reglerna. I nästa steg testar jag HIT/MISS, kontrollerar cookies och övervakar TTFB under en lätt belastningstest. Därefter optimerar jag TTL, Stale och Locking tills kurvorna ser bra ut. Till slut dokumenterar jag rensningsvägar, ansvarsområden och en kort beskrivning av processen för redaktörer, så att innehållet alltid färsk kvarstår.
Praktisk NGINX-konfiguration och exempel
Jag anser att konfigurationen klar strukturerad: en central cachezon, unika nycklar, tydliga hoppregler och användbara diagnostikrubriker. En bra utgångspunkt ser ut så här:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m \
inactive=60m use_temp_path=off loader_files=200 loader_sleep=50ms loader_threshold=300ms;
map $request_method $skip_non_get {
default 1;
GET 0;
HEAD 0;
}
map $http_cookie $skip_cookie {
default 0;
~*(wordpress_logged_in|comment_author|woocommerce_items_in_cart|wp_woocommerce_session|woocommerce_cart_hash) 1;
}
map $arg_preview $is_preview { standard 0; 1 1; }
map $request_uri $is_search { standard 0; ~*\?s= 1; }
server {
# ...
set $skip_cache 0;
if ($skip_non_get) { set $skip_cache 1; }
if ($skip_cookie) { set $skip_cache 1; }
if ($is_preview) { set $skip_cache 1; }
if ($is_search) { set $skip_cache 1; }
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_cache WORDPRESS;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_valid 404 1m;
fastcgi_cache_use_stale updating error timeout http_500 http_502 http_503;
fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 5s;
add_header X-Cache $upstream_cache_status always;
add_header X-Cache-Key $scheme$host$request_uri always;
}
}Jag kommer senare att utöka detta beroende på projektet med Vary-signaler (t.ex. språk, valuta) och mer detaljerade undantag. Viktigt: POST, PUT, DELETE och allt med Auktorisering eller . Set-Cookie Jag låter det konsekvent gå förbi PHP.
Variant- och cookiestrategier i detalj
Ju färre varianter ett HTML-dokument har, desto högre är träfffrekvensen. Jag minskar medvetet antalet varianter och delar upp endast där Utgåvan skiljer sig åt:
- Språk: En enda responsiv HTML-version är idealisk. Om det finns separata språkversioner använder jag en språkcookie eller URI:n (t.ex. /de/, /en/) i nyckeln, inte User-Agent.
- Apparater: Jag undviker UA-splits. Mobile-first-CSS och responsiva layouter bevarar cachen kompakt.
- Valuta/Land: När det gäller webbutiker med geolokalisering eller valutaväljare anpassar jag inställningarna specifikt utifrån en stabil cookie, inte utifrån IP-adressen. Annars blir antalet kombinationer alldeles för stort.
- Frågesträngar: Jag lägger till användbara parametrar (t.ex. paginering, filter) på vitlistan och ignorerar spårningsparametrar (utm_*, gclid) för att undvika att onödiga varianter uppstår.
Man bör vara särskilt försiktig med cookies från samtyckes-/banner-plugins: Om de redan på startsidan placerar cookies kan NGINX felaktigt tolka detta som dynamik. Jag ser till att enbart visuell Banners som inte har någon funktionell inverkan utlöser inte någon Cache-BYPASS-kaskad.
Filsystem, cachezon och optimering av laddaren
Valet av cacheminne har en enorm inverkan på prestandan. Jag använder snabba lokala SSD-enheter och planerar att keys_zone rymligt (t.ex. 100–256 MB för index), så att metadata inte trängs undan. Den inaktiv– Jag bestämmer tiden utifrån trafikprofilen: mycket long-tail-innehåll gynnas av längre inaktivitet, medan mycket dynamiska portaler snarare inte gör det. Med loader_*-parametrar reglerar jag hur aggressivt NGINX förladdar objekt – så att systemet under belastning tyst kvarstår. För mycket belastade webbplatser kan en delcache i tmpfs vara lämpligt, men då kontrollerar jag noggrant RAM-belastningen och inodförbrukningen. Loggrotation och begränsningar för antalet filer förhindrar att volymen blir full; övervakningen håller koll på I/O-väntetider, ledigt utrymme och öppna fildeskriptorer.
Strukturera CDN- och webbläsarcachen på ett överskådligt sätt
Jag kombinerar gärna NGINX-cachen med en Edge-CDN och stabila TTL-värden i webbläsaren. Här gäller följande: Källan (NGINX) levererar konsekventa HTML-sidor, CDN-nätverket cachar dem dessutom, och webbläsaren får måttligt korta max-age-värden så att redaktörerna snabbt kan se ändringarna. Stale-mekanismer och revalidate– Jag ställer in strategierna så att Edge-noderna kan fortsätta leverera innehåll medan NGINX omrenderar i bakgrunden. Jag utlöser rensningar i en definierad ordning (först CDN, sedan Origin) eller synkront på båda ställena, så att inga föråldrade flanker uppstår. Jag kontrollerar dessutom att CDN-headers som Age, Cache-status och Vary inte kolliderar med mina serverregler.
Förvärmning, driftsättning och redaktionella arbetsflöden
För att undvika att tusentals användare utlöser en kallstart efter en rensning värmer jag upp viktiga sidor riktade t.ex.: startsidor, bästsäljare, kategorier, magasinsidor. En smidig förladdare läser upp webbplatskartan, hämtar sidorna parallellt och respekterar hastighetsbegränsningarna så att varken PHP eller databasen överbelastas. Vid driftsättningar skiljer jag mellan fullständig uppdatering (tema-/kodändring) och partiell uppdatering (innehållsuppdatering) och dokumenterar Steg för redaktionen och driftsteamet. På så sätt förblir lanseringsfönstren korta och med låga risker.
Flera webbplatser, flerspråkighet och valutalogik
I WordPress Multisite separerar jag cache-nycklarna strikt efter värdnamn eller webbplats-ID, så att Undersidor är tydligt isolerade. För flerspråkiga sidor med WPML/Polylang föredrar jag att använda språkvägar (de/en) eller särskilda domäner; nyckeln innehåller då schema, värd och sökväg. I webbutiker tar jag noggrant hänsyn till valutacookies och geolokalisering: jag cachelagrar produkt- och kategorisidor per valuta, medan varukorgen och kassan förblir dynamiska. Om priser eller skattesatser ändras, utlöser jag en delvis Rensa bort (produkt, kategori, teaser-moduler) så att centrala startsidor snabbt blir enhetliga.
Belastningstestning, mätvärden och återställning
Innan driftsättningen simulerar jag realistiska Toppar (GET/HEAD-mix, tillgångar, HTML) och skiljer noggrant mellan mätningarna: varmt mot kallt, med/utan CDN, inloggade mot anonyma användare. Jag tittar på P50/P95-TTFB, felprocent, CPU-belastning, I/O-väntetid och antal PHP-processer. I NGINX aktiverar jag ett lämpligt log_format med $upstream_cache_status och kontrollerar stickprov direkt i svarhuvudet (HIT/MISS/BYPASS/EXPIRED). En kort återställningsväg (skip-knapp för cache-drift, reducerad TTL, inaktivering av enskilda regler) säkerställer att jag vid avvikelser omedelbart kan reagera utan att destabilisera hela systemet.
Säkerhet, korrekthet och dataskydd
Jag ser konsekvent till att konfidentiellt innehåll inte hamnar i cachen: administratörsområden, förhandsgranskningslägen, privata sidor, nonce-skyddade åtgärder. Jag följer skillnaden mellan HEAD och GET, medan POST förblir icke-cachelagringsbar. Set-Cookie och Authorization betraktas som hårda BYPASS‑Signaler. Förhandsgranskningssidor (preview=true) och sökresultat (s=) utelämnar jag för att undvika felaktiga träffar. Dessutom kontrollerar jag att inga personuppgifter hamnar i HTML-svaren, som sedan skulle lagras i cachen i stor utsträckning. Vid behov kapslar jag in personaliserade fragment via separata AJAX-ändpunkter, som jag medvetet inte cache.
Hantera gränsfall och undantag på ett korrekt sätt
Vissa mönster återkommer hela tiden: XML-sitemaps och feed-ändpunkter cachelagrar jag under en kort tid (t.ex. 1–5 minuter). 301/302-omdirigeringar omvärderar jag separat för att undvika omdirigeringsloopar. Arkiv- och pagineringssidor får måttliga TTL-värden, eftersom de ofta innehåller länkar till fräsch Innehåll. Parametrar som endast påverkar sorteringen kan ingå i nyckeln, men får inte artificiellt förkorta TTL. Och om ett plugin oväntat sätter cookies, kontrollerar jag om dessa verkligen behövs för HTML-utmatningen relevant är – annars markerar jag dem som ”ignorera” för att undvika onödiga BYPASS-träffar.
Kortfattat sammanfattat
Med NGINX FastCGI Cache snabbar jag upp WordPress på Källa, leverera HTML direkt och undvik kostsamma PHP-processer. Väl genomtänkta undantag och en pålitlig rensning håller innehållet uppdaterat, samtidigt som TTFB- och CPU-värdena sjunker avsevärt. En praktiskt användbar TTL med ”stale” och ”locking” säkerställer en smidig leverans även vid belastningstoppar. Den som konsekvent övervakar mätvärdena och kontinuerligt finjusterar reglerna uppnår hållbart snabba sidor. På så sätt blir webbplatsen mer responsiv, förblir lätt att underhålla och växer smidigt i takt med ökande Trafik in.
