Caching

Modulul 6: Viteză · Timp de citire: 9 minute

Obiectiv de învățare: După această lecție puteți explica ce tipuri de cache există și puteți configura și verifica corect o cache de pagini.

Concepte-cheie: cache de pagini, cache de browser, Cache-Control, cache de obiecte, Redis, OPcache, CDN, modul de cache, LiteSpeed Cache, excepții (autentificat, coș de cumpărături, finalizare comandă), golirea cache-ului, module de cache duplicate

Cache: nu faceți aceeași muncă de două ori

O cache păstrează rezultatul unei munci, astfel încât data viitoare nu mai trebuie refăcută. Pe o site WordPress există patru locuri unde se întâmplă asta, de la cel mai mare efect la cel mai mic:

Cache de pagini

Lecția 1.2 a arătat: fără cache, WordPress recreează întreaga pagină la fiecare vizită. Cu o cache de pagini, primul vizitator o creează, iar următorii primesc codul HTML salvat. Un TTFB de o secundă poate astfel ajunge la câteva sutimi de secundă, iar pachetul dumneavoastră poate face față unui număr mult mai mare de vizitatori simultani.

Modul în care obțineți o cache de pagini depinde de serverul dumneavoastră web:

• LiteSpeed (multe găzduiri partajate, inclusiv WebOké): serverul web are propria sa cache. Modulul gratuit LiteSpeed Cache o controlează din WordPress: ce pagini pot intra în cache, când sunt golite. Deoarece cache-ul se află în serverul web, PHP nu este pornit deloc pentru o pagină salvată.
• Apache sau nginx: un modul de cache care salvează codul HTML ca fișiere, precum WP Super Cache, W3 Total Cache sau un modul plătit precum WP Rocket. Sau o cache pe care furnizorul de găzduire o gestionează la nivel de server.
• Găzduirea WordPress gestionată are adesea propria sa cache; de obicei nu instalați un modul de cache în acest caz.

Alegeți unul singur. Două module de cache simultan (de exemplu LiteSpeed Cache și WP Rocket) se blochează reciproc: muncă dublă, pagini care nu sunt golite, erori ciudate. Pe un server LiteSpeed, LiteSpeed Cache funcționează împreună cu cache-ul serverului web; un alt modul de cache nu poate face asta.

Ce nu are voie în cache

O cache de pagini oferă tuturor același cod HTML. Asta merge greșit la paginile care diferă în funcție de vizitator:

• utilizatorii autentificați (bara de administrare, „Bine ați venit, Lisa”);
• coșul de cumpărături, finalizarea comenzii și Contul meu la un magazin online;
• paginile cu un formular cu un cod unic (nonce), care expiră după un timp;
• paginile care afișează ceva diferit pe baza locației, limbii sau unui cookie.

Modulele bune de cache omit automat utilizatorii autentificați și paginile WooCommerce cunoscute. La alte module (o secțiune pentru membri, un sistem de rezervări) trebuie să setați singur excepții. Semnul că ceva nu merge bine: un vizitator vede coșul de cumpărături al altcuiva, sau un formular afișează „expirat” sau „cerere invalidă”.

Golire: când este cache-ul învechit?

Dacă modificați o pagină, versiunea salvată trebuie eliminată. Modulele de cache golesc de obicei acea pagină, pagina principală și arhivele la salvarea unui articol. La o modificare a meniului, temei sau unui widget, trebuie adesea golit întregul cache. Dacă vedeți versiunea veche după o modificare, goliți cache-ul (în bara de administrare a modulului de cache) și verificați într-o fereastră privată, astfel încât propria dumneavoastră cache de browser să nu influențeze.

Cache de browser

Serverul îi spune browserului prin antete cât timp poate păstra un fișier:

cache-control: public, max-age=31536000

Acest lucru spune: păstrați asta un an. Pentru foi de stil, scripturi, fonturi și imagini, o perioadă lungă este în regulă, deoarece WordPress adaugă un alt ?ver= după adresă la o versiune nouă, iar browserul îl consideră atunci un fișier nou. Pentru codul HTML în sine, este obișnuită o perioadă scurtă (sau deloc), astfel încât vizitatorii să vadă rapid modificările.

Mulți furnizori de găzduire și module de cache gestionează asta. În exercițiul acestei lecții verificați acest lucru.

Cache de obiecte și Redis

O cache de pagini nu ajută la utilizatorii autentificați și nici la coșul de cumpărături. Acolo ajută o cache de obiecte: WordPress păstrează rezultatul interogărilor bazei de date în memorie, într-un program precum Redis sau Memcached. Data viitoare când vine aceeași interogare, WordPress preia răspunsul din memorie în loc din baza de date.

Asta este util mai ales pentru magazine online, site-uri pentru membri și site-uri cu mulți redactori autentificați. Pentru o site informativă obișnuită cu o cache de pagini, diferența este mică. O cache de obiecte necesită ca furnizorul dumneavoastră de găzduire să ofere Redis sau Memcached; apoi o activați cu un modul (LiteSpeed Cache poate face asta, există și module separate).

Un CDN

Un CDN (content delivery network) este o rețea de servere în multe locuri din lume care păstrează copii ale fișierelor dumneavoastră (și uneori întregile dumneavoastră pagini). Un vizitator le primește de la serverul cel mai apropiat. Asta ajută mai ales la vizitatorii de la mare distanță și la trafic mare. Pentru o site europeană cu vizitatori europeni pe un server european, câștigul este mic. Un CDN cu proxy (precum Cloudflare) vă schimbă și DNS-ul și certificatul (cursul DNS, lecția 7.5); nu faceți asta fără să înțelegeți ce face.

În practică: cum arată într-un panou

Ca exemplu folosim LiteSpeed Cache pe un server LiteSpeed. Alte module de cache au setări similare sub alte denumiri.

1. Instalați și activați LiteSpeed Cache la Module (plugin) > Adaugă modul nou.
2. Deschideți LiteSpeed Cache > Cache: „Activați cache-ul” este pornit, „Cache utilizatori autentificați” este oprit (cu excepția cazului în care știți ce faceți).
3. La un magazin online: verificați la Exclude că sunt incluse coșul de cumpărături, finalizarea comenzii și Contul meu (la WooCommerce se face automat).
4. Lăsați celelalte componente (optimizarea CSS și JavaScript, imagini) mai întâi oprite. Activați-le una câte una și testați după fiecare pas: tocmai aceste componente uneori strică o temă.
5. Verificați într-o fereastră privată cu instrumentele pentru dezvoltatori (F12, Rețea, prima cerere): la a doua încărcare ar trebui să apară x-litespeed-cache: hit.

Rezumat

• Există patru tipuri de cache: de pagini (cel mai mare câștig), de browser, de obiecte și OPcache.
• Pe un server LiteSpeed, LiteSpeed Cache controlează cache-ul serverului web; pe Apache sau nginx folosiți un alt modul de cache. Alegeți unul singur.
• Utilizatorii autentificați, coșul de cumpărături, finalizarea comenzii și paginile personale nu au ce căuta în cache-ul de pagini.
• Goliți cache-ul după modificări la meniu sau temă și verificați într-o fereastră privată.
• O cache de obiecte (Redis) ajută la magazine online și utilizatori autentificați; un CDN ajută mai ales la distanțe mari și trafic mare.

Test (quiz)

Exercițiu

Exercițiu A6.2: Funcționează cache-ul dumneavoastră de pagini? Introduceți adresa site-ului dumneavoastră. Programul solicită pagina principală de două ori, la scurt timp una după alta, fără cookie-uri, și la a doua cerere verifică antetele care indică o lovitură de cache (x-litespeed-cache: hit, x-cache: HIT, cf-cache-status: HIT, un age mai mare decât 0, sau antetul unui alt tip de cache cunoscut). Apoi solicită o foaie de stil din pagina principală și verifică dacă browserul are voie să o păstreze cel puțin șapte zile (cache-control: max-age sau expires). Notați ce cache folosiți.

Lecturi suplimentare

Aceste articole descriu pașii în panourile de la WebOké; în alte panouri funcționează similar.

• Manual DirectAdmin 18.3: Website-ul meu este lent
• Manual DirectAdmin 15.7: Redis
• Site-ul meu web este lent sau utilizează prea mult CPU: iată cum îl puteți face mai rapid
• OPcache: întârziere de 30 de secunde la modificarea unui fișier PHP
• Este gzip activat în DirectAdmin și LiteSpeed sau Apache
• Cache în WordPress (developer.wordpress.org, în engleză): https://developer.wordpress.org/advanced-administration/performance/cache/