Förstå cachning i WordPress, del 2
I förra inlägget delade jag en grundläggande primer för hur databasstödda applikationer – specifikt WordPress – fungerar utan cachning.
Och innan vi pratar om hur grundläggande cachning fungerar i WordPress, nämligen med Transients API, är det viktigt att diskutera de grundläggande principerna för cachning. Detta inkluderar varför vi gör det, dess fördelar och hur det fungerar.
Sedan ska vi gå in på hur vi kan dra nytta av grundläggande faciliteter i WordPress för att faktiskt göra detta.
Förstå Caching i WordPress: Cachning?
Varför vi gör det
Generellt sett gör vi detta för att se till att våra sajter är snabba. Vi vet att hastigheten spelar roll för hur en sida rankas i sökresultaten. Och även om det kanske inte är den primära orsaken, är det en viktig anledning.
Det kanske enklaste och bästa argumentet för cachning är att ha en snabb sida (eller en presterande sida). Och i detta sammanhang kan detta betyda en webbplats eller en webbapplikation.
Oavsett vad vet vi hur det känns när vi sitter där och väntar på att en sida eller en del av en sida ska laddas. Om vi inte gillar det, varför skulle vi vilja att våra besökare ska uppleva det?
Dess fördelar
Fördelarna med cachelagring kommer inom minst två huvudområden:
- användarupplevelse,
- dags att ladda.
I det sista avsnittet sa jag att fördelarna med cachning kan kännas om du är en användare. Det är något vi alla har upplevt och som utvecklare är det något vi kan erbjuda våra användare genom en mängd olika tekniker.
Men "tid att ladda" är också något som spelar roll och det här talar inte bara om fördelarna med hur lång tid det tar för en användare att ladda sidan, utan det är istället lite mer tekniskt.
Minns i förra inlägget att en förfrågan – eller en resa – börjar när användarna begär information från servern och sedan går processen från användarens maskin till servern till databasen och tillbaka igen.
När vi har introducerat caching behöver vi inte göra allt detta. Istället förkortas en resa eftersom uppgifterna faktiskt förvaras någon annanstans. Och om resan är kortare (och då menar jag inte från användarens dator till där servern finns i världen) så borde den också vara snabbare.
Men hur?
Hur det fungerar
Det finns många typer av cachning som är tillgängliga men jag håller just denna serie på hög nivå. Det vill säga, jag kommer inte att skilja mellan webbläsarcache, sidcache, objektcache, etc.
Kanske i ett framtida inlägg. Men för tillfället pratar jag specifikt om cachelagring på hög nivå.
Hur som helst, så här fungerar det:
- Under den första resan till en sida, samlas all information som krävs för att ladda sidan.
- Istället för att kassera den när användaren lämnar webbplatsen (eller sidan), lagras informationen någonstans som är lättillgänglig som serverns minne.
- När nästa användare kommer till sidan behöver resan inte gå till databasen för att få all information, samla ihop den och sedan returnera den till användaren. Istället hämtar den den fullständigt sammansatta informationen från serverns minne (vilket i de flesta fall redan är snabbare, och returnerar den sedan till användaren.
Det finns många varningar att tänka på när du gör detta, till exempel anpassad användardata, partiella sidladdningar och så vidare, men principen bakom resan förblir densamma.
WordPress Transients
Så hur fungerar detta i WordPress? På den mest grundläggande nivån tillhandahåller Transients API vissa grundläggande funktioner för detta.
Men det är viktigt att förstå hur det fungerar och varför det fungerar som det gör. Så i nästa inlägg i den här serien ska jag prata specifikt om det.