Hur cachning fungerar

Den här sidan täcker Templ Cache: vad det är, vad som cachas, hur du kontrollerar cache-status och hur du rensar eller inaktiverar den.

Templ Cache

Templ Cache är Templs inbyggda sidcache på servernivå, byggd på nginx fastcgi cache-modulen och förinstallerad och aktiv på varje hemsida vi hostar. Ett hjälpplugin i WP Admin rensar cachen automatiskt när du redigerar innehåll. Om plugin-programmet saknas, installera det med Installera Templ-plugins-verktyget i vår panel.

Vad är en sidcache och hur fungerar den?

Att ladda en WordPress-sida kör normalt många PHP-filer och databasfrågor. För sidor som inte ändras konstant upprepas detta arbete vid varje besök. En sidcache lagrar den genererade HTML-koden en gång och serverar den till efterföljande besökare, vilket ger:

• Mycket snabbare sidladdningar
• Skalbarhet: fler sidor serverade med mindre serverbelastning

Kontrollera cache-status

Templ lägger till en X-Cache-Status svarshuvud så att du kan se om en sida kom från cachen. Den har ett av fyra värden:

• HIT - serverad från cache.
• MISS - cachningsbar, men inte i cachen än (eller ombedd att inte lagras). Den första förfrågan till en sida är en MISS; nästa är en HIT.
• BYPASS - cachning är på, men denna förfrågan hoppar över den: den matchade en regel såsom en frågesträng eller en aldrig-cachad sökväg, eller så är du inloggad i WP Admin.
• disabled - cachning är helt avstängd, vanligtvis för att Templ Cache-hjälpplugin inte är aktivt på hemsidan.

Kontrollera det med Pingdom:

I Chrome (högerklicka → Inspect → Network-fliken → svarshuvuden för domänen):

Eller från din terminal med curl -I https://templ.io:

Cache-undantag

En sida cachas när dess URL inte har någon frågesträng. Vilken frågesträng som helst får normalt förfrågan att hoppa över cachen (BYPASS), så sidan serveras färsk.

Undantaget är dessa spårningsparametrar. De ignoreras för cachning, så en URL som endast bär dessa cachas som om den inte hade någon frågesträng:

gclid
fbclid
twclid
utm_term
utm_source
utm_campaign
utm_medium
utm_content
fb_action_ids
fb_action_types
fb_source

Följande URL-mönster är också undantagna från cache:

/wp-admin/
xmlrpc.php
wp-.*.php
/login
/logout
/signin
/signup
/register/
/cart
/my-account/
/wc-api/
/checkout
/addons
/lost-password

(wp-.*.php är ett mönster som matchar vilken PHP-fil som helst vars namn börjar med wp-, såsom wp-login.php och wp-cron.php.)

Rensa cachen

Rensa från Templ Cache-inställningarna, eller från genvägen högst upp på WP Dashboard:

Cachen rensas också automatiskt när du gör ändringar i WP Admin.

För att rensa programmatiskt, till exempel från ett deploy-skript, använd Templ CLI över SSH med templ cache purge, eller kör det på distans i en rad.

Inaktivera sidcachen

Avaktivera hjälpplugin:

FAQ

Kan jag använda Templ-cachen tillsammans med ett annat sidcache-plugin?

Nej. Endast en sidcache ska vara aktiv åt gången, oavsett om det är WP Rocket, WP Fastest Cache, Autoptimize eller något annat.

För att använda de avancerade optimeringarna i ett plugin som WP Rocket, inaktivera Templ Cache-hjälpplugin först så att det körs istället för Templ Cache.

Plugins som Templ Optimizer som endast lägger till optimeringar utan cache (minifiering, kombinera CSS och JS) kan köras tillsammans med Templ Cache.

Vad är skillnaden mellan andra cache-plugins och Templs sidcache?

Vår cache fungerar på servernivå för maximal prestanda och effektivitet; plugin-programmet är bara en hjälpare som rensar cachen när du redigerar innehåll.

Andra cache-plugins lägger till extra funktioner som minifiering och kombinering av CSS/JS-filer. Vår sidcache replikerar inte dessa, eftersom så många plugins redan gör det.

När läggs en sida till i cachen?

Första gången den besöks, eller första gången den besöks efter att cachen har rensats.

Hur länge cachas en sida?

24 timmar som standard. För att ändra det, kontakta support.

Felsökning

En sida returnerar alltid X-Cache-Status: MISS

Om en sida aldrig når HIT oavsett hur många gånger du laddar den, skickar WordPress nästan alltid ett svarshuvud som säger åt cachen att inte lagra sidan.

no-store i Cache-Control-huvudet är det enda direktivet som stoppar Templ-sidcachen (ett svar som sätter X-Accel-Expires: 0 hoppas över på samma sätt). Det är ofta en del av ett längre värde, men no-store ensamt är tillräckligt för att tvinga MISS på varje förfrågan:

cache-control: no-store, no-cache, must-revalidate

Andra direktiv som ser ut som om de skulle inaktivera cachning ignoreras av Templ-cachen, och sidan serveras fortfarande som en HIT:

• Cache-Control: no-cache
• Cache-Control: private
• Cache-Control: must-revalidate
• Cache-Control: max-age=0
• Ett Expires-huvud med ett gammalt datum
• Ett Set-Cookie-huvud (cookien tas bort från det cachade svaret)

Dessa påverkar fortfarande webbläsar- och CDN-cachning, men de kommer inte att stoppa en sida från att lagras i Templ-servercachen. Så när du ser upprepade MISS, leta specifikt efter no-store.

För att diagnostisera, begär sidan och kontrollera cache-control-värdet tillsammans med x-cache-status:

curl -I https://your-domain.com/the-page/

Vanliga källor till ett no-store-huvud:

• PHP-sessioner. Att anropa session_start() (direkt eller via ett plugin/tema) får PHP att skicka ut Cache-Control: no-store, no-cache, must-revalidate på varje påverkad sida.
• Medlemskaps-, e-handels- och säkerhetsplugins, som ofta anropar WordPress nocache_headers() på sidor de anser vara privata.

Avaktivera de misstänkta plugins en i taget och kontrollera cache-control igen tills no-store försvinner och sidan returnerar HIT.