Förstå cachning i WordPress, del 1
Tillbaka i maj skrev jag en artikel om att använda WordPress Transients API. Jag sammanfattar artikeln så här:
För att simulera cookies och deras funktion av utgångsdatum kan det vara en gångbar lösning att använda WordPress-transienter.
https://wordpress.mediadoma.com/sv/anvaender-du-wordpress-transients-istaellet-foer-cookies/
Även om syftet med artikeln var att lägga en grund för hur vi kan designa en klass för att fungera med Transients API för att simulera beteendet hos cookies, är en av bieffekterna med artikeln att den inte gjorde ett bra jobb att förklara hur Transients API (och, genom proxy, hur MySQL) fungerar.
Detta uppmärksammades på mig via e-post av David på UpDraft Plus.
Så jag tyckte det var användbart att prata om konceptet med cachning från en praktisk nivå, hur det implementeras i WordPress, och sedan kanske titta på hur vi använder plugins eller nyare teknik för att bättre driva våra webbplatser och applikationer samt få en bättre förståelse.
Förstå cachelagring: grunderna
Konceptet med cachning är relativt enkelt. Men jag tror att det bäst demonstreras genom att först prata om dataserialisering och hämtning utan cachning.
Utan Caching
Att skriva data
När du skriver information till den underliggande databasen, spelar du in en post – eller en serie av poster – till databasen.
Till exempel, när du publicerar ett inlägg kommer du att skriva en post till tabellen för inlägg och tabell för inläggsmetadata som var och en är relaterade till ett inläggs-ID.
Hur de är relaterade är inte viktigt för det här inlägget.
Istället är det som ska förstås i den här delen att när data skrivs till databasen skapas minst en post, om inte flera.
Läser data
När en besökare landar på webbplatsen för att läsa just det inlägget kommer all information för inlägget att begäras från databasen, skickas till WordPress-applikationen och sedan renderas i front-end.
Se hela denna process som en resa:
- ❓besökaren begär sidan,
- 🔍 webbservern identifierade vilken sida som skulle laddas,
- 📂 sidan begärs från databasen från flera tabeller,
- 🏗 data samlas och skickas till kärnapplikationen,
- 🖥 uppgifterna presenteras för användaren.
Så resan startar när användaren begär en sida och slutar när informationen presenteras för dem i deras webbläsare.
Det är en resa
Och utan cachning händer detta för varje enskild användare. Det vill säga, för varje användare som besöker din webbplats måste en resa göras.
Det kan bli väldigt dyrt i form av resurs och tid (särskilt beroende på storleken på din databas).
Men det är här caching kan spela in.
Innan du går in i cachelagring
Tanken bakom cachning är att göra hela processen snabbare. Det vill säga, om vi vet att en resa är på väg att hända kan vi förvara informationen på en plats så att den redan är sammansatt och snabbare att hämta.
Innan jag pratar om dock, vilket jag kommer att i nästa inlägg, notera att detta är som att göra en resa till hårddisken på servern som webbplatsen är värd på varje gång webbplatsen besöks.
Eftersom, i slutändan, databasen, filerna och alla tillgångar som krävs för att driva webbplatsen finns på en hårddisk. Och ja, saker som solid-state-enheter kan göra den här processen snabbare, den är fortfarande inte så optimal som möjligt.
Och det är där caching kommer in i bilden. För att bättre förstå Transients API är det viktigt att förstå cachning, vilket först kräver en grundläggande förståelse för hur saker fungerar utan cachning.
Det är en Primer
Så betrakta detta som en grundläggande utgångspunkt för hur en databasstödd webbplats utan cachning fungerar. Och sedan bygger vi vidare på detta mer i nästa inlägg.