Ghiduri practice

Cum să configurezi duratele de cache ale browserului (Browser Caching) pentru viteză maximă

Cum să configurezi duratele de cache ale browserului (Browser Caching) pentru viteză maximă

Duratele de cache ale browserului (browser caching) se stabilesc prin reguli HTTP cache care determină cât timp fișierele statice ale site-ului tău sunt stocate în browserul vizitatorului. În practică, pentru fișierele CSS, JavaScript, imagini, fonturi și iconițe se definesc antetele Cache-Control și, în unele medii, Expires; de exemplu, pentru fișierele CSS și JS cu versiuni se alege 1 an, pentru imagini 30 de zile - 1 an, iar pentru paginile HTML se preferă o durată scurtă sau revalidarea. Configurarea corectă previne descărcarea repetată a acelorași fișiere, accelerează încărcarea paginii și îmbunătățește metricile Core Web Vitals.

În acest ghid, vom explica pas cu pas cum funcționează memorarea în cache a browserului, câte secunde să aloci fiecărui tip de fișier și cum se implementează pe Apache, Nginx, LiteSpeed, WordPress și CDN. Scopul nu este doar să obții un scor verde într-un instrument de testare a vitezei, ci să folosești eficient resursele serverului în timp ce oferi fișiere actualizate utilizatorului, să reduci TTFB-ul și consumul de bandă și să obții un câștig sesizabil de viteză la vizitele repetate. Mai ales pe hostingul partajat, hostingul WordPress și proiectele web enterprise, strategia corectă de cache este una dintre cele mai eficiente îmbunătățiri de performanță pe care le poți obține cu costuri minime. Hostragons pachete hosting web

Ce este memoria cache a browserului?

Memoria cache a browserului este stocarea temporară pe dispozitivul utilizatorului a resurselor statice descărcate la deschiderea unei pagini web. Când un vizitator intră pe pagina ta principală, se descarcă logo-ul, fișierul CSS, fișierele JavaScript, fonturile și imaginile. Dacă aceste fișiere au antetele de cache corecte, când vizitatorul navighează pe a doua pagină sau revine ulterior pe site, browserul nu mai solicită o parte din aceste fișiere de la server. Astfel, pagina se încarcă mai rapid.

De exemplu, să presupunem că ai o pagină principală de 2 MB. Dacă 1,4 MB sunt imagini, 300 KB sunt fișiere CSS și JS și 100 KB sunt fonturi, aceste resurse se pot descărca la prima vizită. Însă la a doua vizită, când browserul folosește aceste resurse statice din memoria locală, cantitatea de date transferată prin rețea scade dramatic. Această diferență devine mai evidentă pe conexiunile mobile și pe site-urile cu trafic ridicat.

Nu trebuie confundată memoria cache a browserului cu memoria cache de pe server. Cache-ul de server stochează ieșirea PHP sau interogările bazei de date pe server. Cache-ul browserului permite reutilizarea resurselor de pe dispozitivul vizitatorului. Pentru o performanță optimă, ambele straturi trebuie planificate împreună. Pe site-urile care folosesc WordPress, cache-ul de pagină, cache-ul de obiecte, cache-ul CDN și cache-ul browserului sunt de obicei părți ale aceleiași strategii de optimizare. Hosting WordPress și optimizare performanță

De ce este important Browser Caching pentru SEO?

Google consideră mai valoroase din punctul de vedere al satisfacției utilizatorului site-urile care oferă o experiență rapidă și stabilă. Memoria cache a browserului nu garantează singură o poziționare mai bună, însă susține performanța SEO deoarece influențează viteza paginii, latența interacțiunii și eficiența încărcării resurselor. Face o diferență semnificativă în special în scenarii precum vizitele repetate, navigarea pe categorii, tranziția între paginile de produs și navigarea internă pe blog.

În standardele SEO din 2026, performanța tehnică nu se rezumă doar la scorul Lighthouse. Experiența utilizatorului evaluată de Google este corelată cu LCP, INP, CLS, TTFB și cu datele reale ale utilizatorilor. Descărcarea repetată inutilă a fișierelor CSS și JS poate prelungi durata LCP. Solicitarea repetată a fonturilor pe fiecare pagină poate afecta stabilitatea vizuală. Lipsa memorării în cache a imaginilor mari poate crea o senzație de lentoare pe dispozitivele mobile.

  • Revizitare mai rapidă: Utilizatorul nu mai descarcă aceleași fișiere.
  • Lățime de bandă mai mică: Traficul serverului scade, resursele de hosting sunt folosite mai eficient.
  • Eficiență mai bună a crawling-ului: Livrarea resurselor statice devine mai ordonată pentru boți și utilizatori.
  • Risc mai mic de respingere: Paginile care se deschid rapid cresc interacțiunea utilizatorului.
  • Performanță mai constantă: Fluctuațiile de sarcină pe CDN și hosting sunt mai bine echilibrate.

Antetele HTTP Cache de bază

Duratele de cache ale browserului sunt gestionate prin antetele de răspuns HTTP. Cele mai comune antete sunt Cache-Control, Expires, ETag și Last-Modified. În proiectele moderne, punctul principal de control este antetul Cache-Control; Expires este folosit mai mult pentru compatibilitatea cu versiunile mai vechi.

Cache-Control

Cache-Control îi spune browserului și sistemelor intermediare de cache cum să stocheze un fișier. Cele mai frecvent utilizate directive sunt:

  • max-age: Specifică câte secunde este considerată proaspătă resursa. De exemplu, max-age=31536000 înseamnă aproximativ 1 an.
  • public: Indică faptul că resursa poate fi stocată în sisteme de cache partajate, cum ar fi browserul și CDN-ul.
  • private: Indică faptul că resursa trebuie stocată doar în browserul utilizatorului.
  • no-cache: Indică faptul că resursa trebuie validată la server înainte de a fi utilizată; nu înseamnă dezactivarea completă a cache-ului.
  • no-store: Indică faptul că resursa nu trebuie stocată nicăieri; este potrivit pentru paginile de plată, panouri de administrare și date personale.
  • immutable: Anunță că resursa nu se va modifica până la expirare; este ideal pentru activele cu nume de fișier versionate.

Un exemplu de antet pentru un fișier static ar putea fi: Cache-Control: public, max-age=31536000, immutable. Aceasta îi spune browserului că poate păstra fișierul timp de 1 an și că nu este necesar să îl verifice din nou atâta timp cât numele fișierului nu se schimbă.

Expires

Antetul Expires specifică până la ce dată și oră este valabilă resursa. De exemplu, se poate atribui o valoare Expires care să indice peste 30 de zile pentru o imagine. Totuși, deoarece Expires folosește o dată absolută, nu este la fel de flexibil ca Cache-Control. În configurațiile moderne, Cache-Control are prioritate; Expires poate fi adăugat pentru browserele mai vechi.

ETag și Last-Modified

ETag și Last-Modified sunt mecanisme de validare. Browserul poate întreba serverul dacă versiunea pe care o deține a fișierului este actualizată. Dacă fișierul nu s-a modificat, serverul returnează un răspuns 304 Not Modified, iar corpul fișierului nu este descărcat din nou. Această metodă este utilă în special pentru conținutul care se poate modifica frecvent, cum ar fi HTML-ul, sau pentru fișierele cărora nu dorești să le acorzi o durată lungă de cache.

Ce durată de cache să folosești pentru fiecare tip de fișier?

Cea mai frecventă greșeală este să acorzi aceeași durată tuturor tipurilor de fișiere. Însă HTML, CSS, JS, imaginile, fonturile și răspunsurile API au comportamente diferite de actualizare. Regula de bază este simplă: dacă numele fișierului poate fi schimbat, se poate acorda o durată lungă de cache; dacă conținutul se modifică frecvent fără ca numele fișierului să se schimbe, trebuie folosită o durată scurtă sau validarea.

Ce durată de cache să folosești pentru fiecare tip de fișier?
Tipul resurseiDurata recomandatăAntetul recomandatNotă
Pagini HTML0-10 minute sau validareno-cache, max-age=0Actualitatea are prioritate dacă conținutul se modifică frecvent.
CSS și JS30 de zile - 1 anpublic, max-age=31536000, immutableNumele fișierului trebuie versionat: ex. style.v3.css.
Imagini30 de zile - 1 anpublic, max-age=2592000 sau 31536000Logo-urile și iconițele pot avea durată lungă; imaginile de campanie pot fi mai scurte.
Fișiere de fonturi6 luni - 1 anpublic, max-age=31536000, immutableFișierele WOFF2 se modifică de obicei rar.
PDF și media7 zile - 6 lunipublic, max-age=604800 sau 15552000Durata trebuie aleasă cu atenție pentru cataloagele actualizate.
Pagini de administrare și platăFără cacheno-store, privateSecuritatea și datele personale au prioritate.

Acest tabel este un punct de plecare general. Pe un site de comerț electronic, paginile HTML care conțin informații despre stoc și preț nu ar trebui să fie cache-uite agresiv. În schimb, imaginile de produs pot fi cache-uite timp de 1 an atâta timp cât numele fișierului este schimbat. Pe un site corporate, logo-ul, fonturile și fișierele temei pot fi stocate pe termen lung, dar bannerele de campanie, dacă se modifică frecvent, pot fi mai sigure la 7-30 de zile.

Cum planifici duratele de cache ale browserului?

Pentru o strategie de cache de succes, clasifică mai întâi fișierele de pe site-ul tău. Din punct de vedere tehnic, trebuie să scrii reguli bazate pe extensiile fișierelor; din punct de vedere strategic, trebuie să stabilești duratele în funcție de frecvența actualizărilor.

1. Separă resursele statice de cele dinamice

Fișiere precum CSS, JS, JPG, PNG, WebP, SVG, WOFF2 sunt resurse statice. HTML-ul, coșul de cumpărături, panoul utilizatorului, rezultatele căutării și răspunsurile API sunt considerate dinamice. În timp ce resursele statice sunt cache-uite pe termen lung, conținutul dinamic trebuie gestionat cu mai multă atenție. Cache-ul public nu trebuie folosit în special pentru conținutul personalizat.

2. Folosește versionarea fișierelor

Calea sigură pentru o durată lungă de cache este versionarea fișierelor. De exemplu, dacă cache-uiești fișierul style.css timp de 1 an și apoi îi modifici conținutul, unii utilizatori pot continua să vadă designul vechi. În schimb, dacă folosești o denumire precum style.2026.01.css, app.v12.js sau app.8f3a2.js care conține un hash al fișierului, în momentul actualizării se publică un nume nou de fișier, iar browserul descarcă noua resursă.

Temele WordPress și instrumentele moderne de build pot face acest lucru automat. Dacă dezvolți o temă, folosirea parametrului version în funcțiile wp_enqueue_style și wp_enqueue_script facilitează gestionarea versiunilor prin query string sau nume de fișier. Totuși, deoarece comportamentul cache-ului pentru query string poate fi diferit în unele configurații CDN, adăugarea unui hash la numele fișierului este o metodă mai robustă.

3. Nu fi agresiv cu HTML-ul

Paginile HTML, deoarece conțin conținutul principal vizibil pentru utilizator, sunt de obicei gestionate cu cache pe termen scurt sau prin revalidare. Pe un blog, un cache de 5-10 minute poate fi suficient; pe paginile de știri, campanii sau prețuri este necesară o durată mai scurtă. Dacă folosești cache de pagină pe WordPress, trebuie să iei în considerare antetul de cache al browserului împreună cu mecanismul de cache al serverului și de invalidare (purge) CDN.

4. Dezactivează cache-ul pe paginile care necesită securitate

Pe paginile de autentificare, panoul clientului, pașii de plată, rezumatul comenzii, factura și paginile care conțin date personale, trebuie preferate antete precum Cache-Control: no-store, private. Memoria cache a browserului este pentru performanță, dar nu trebuie să pună în pericol securitatea datelor personale. Utilizarea SSL este, de asemenea, o cerință de bază în acest punct. Hostragons certificate SSL

Configurarea cache-ului browserului cu Apache .htaccess

Pe serverele Apache, cache-ul browserului se configurează de obicei prin fișierul .htaccess. Aceasta este metoda cea mai practică pentru mulți proprietari de site-uri care folosesc hosting partajat. Mai întâi, modulele mod_expires și mod_headers trebuie să fie active. În majoritatea mediilor de hosting de calitate, aceste module sunt disponibile implicit.

Poți folosi următoarea logică: durată lungă pentru imagini și fonturi, durată lungă pentru CSS și JS, validare scurtă pentru HTML. În regulile pe care le vei adăuga în fișierul .htaccess, se fac definiții ExpiresByType și Header set Cache-Control în funcție de tipurile de fișiere. De exemplu, pentru fișierele image/webp, image/jpeg, image/png, image/svg+xml se poate aplica 1 an; pentru text/css și application/javascript 1 an; pentru text/html se poate aplica no-cache.

Fă o copie de rezervă a fișierului .htaccess înainte de implementare. O regulă scrisă greșit poate cauza o eroare 500 Internal Server Error. După modificare, deschide site-ul într-o filă privată, apoi verifică secțiunea response headers a fișierului relevant în fila Network din DevTools. Dacă nu apare Cache-Control, este posibil ca modulul serverului să fie dezactivat, CDN-ul să modifice antetul sau un alt plugin să suprascrie antetele.

Exemple de durate pe Apache: max-age=31536000 pentru CSS și JS, max-age=31536000 pentru imagini, max-age=2592000 pentru PDF, max-age=0 și no-cache pentru HTML. Aceste valori sunt bune pentru început și trebuie revizuite în funcție de fluxul de publicare al site-ului tău. Când folosești setările de performanță ce pot fi făcute prin .htaccess pe infrastructura de hosting Hostragons, este recomandat să verifici dacă există conflicte cu setările de cache ale temei și pluginurilor tale. Setări de performanță Apache .htaccess

Configurarea Browser Caching cu Nginx

Pe serverele care folosesc Nginx, antetele de cache sunt definite în blocurile server sau location. Nginx este preferat în special în proiectele cu trafic intens datorită livrării de înaltă performanță a fișierelor statice. Logica de bază aici este să stabilești valorile expires și add_header Cache-Control printr-o regulă de location bazată pe extensie.

O abordare exemplu este următoarea: pentru resursele statice precum CSS, JS, WebP, JPG, PNG, SVG, WOFF2 se acordă expires 1y și Cache-Control public, immutable. Pentru ieșirile HTML se preferă expires off sau no-cache. Dacă folosești un CDN, trebuie să testezi și modul în care antetele Cache-Control provenite de la serverul de origine sunt interpretate de CDN.

Un aspect de care trebuie să ții cont în setările Nginx este că directiva add_header se aplică în unele cazuri doar anumitor coduri de răspuns. În configurațiile moderne Nginx se poate folosi parametrul always. De asemenea, dacă același antet este adăugat de aplicație, Nginx și CDN, pot apărea valori Cache-Control conflictuale sau duplicate. În această situație, lanțul de prioritate trebuie clarificat și trebuie stabilită o singură sursă ca autoritate.

Cache-ul pe site-urile LiteSpeed și WordPress

Cache-ul pe site-urile LiteSpeed și WordPress

Serverele LiteSpeed oferă un avantaj semnificativ de performanță, în special în proiectele WordPress, cu pluginul LiteSpeed Cache. Totuși, memoria cache a browserului și cache-ul de pagină trebuie separate. Când opțiunea Browser Cache este activată în pluginul LiteSpeed Cache, antetele de cache pentru fișierele statice pot fi aplicate automat. Cu toate acestea, este important să controlezi duratele.

Practica recomandată în WordPress este să cache-uiești activele statice pe termen lung și să menții activă versionarea fișierelor. Când faci o actualizare a temei, o modificare CSS sau JS, trebuie să golești cache-ul pluginului și, dacă folosești un CDN, să aplici o operațiune de purge CDN. Altfel, unii utilizatori se pot confrunta cu designul vechi sau cu un comportament JavaScript defectuos.

Pluginurile de cache populare includ opțiuni precum Browser Cache, Minify, Combine, Critical CSS, integrare CDN și Object Cache. Nu este întotdeauna corect să le activezi pe toate simultan și agresiv. Mai întâi configurează antetele de cache ale browserului, apoi testează setările de minimizare și combinare. Deoarece HTTP/2 și HTTP/3 sunt răspândite în 2026, combinarea fiecărui fișier nu mai este la fel de critică ca în trecut; ba chiar, în unele cazuri, poate reduce eficiența cache-ului.

Dacă site-ul tău WordPress este lent, problema poate să nu fie doar browser cache. Umflarea bazei de date, o temă grea, prea multe pluginuri, imaginile neoptimizate și hostingul cu resurse reduse afectează de asemenea performanța. Prin urmare, evaluează setările de cache împreună cu un hosting de calitate, o versiune PHP actualizată și o configurare SSL corectă. Hostragons hosting WordPress

Cum să configurezi duratele de cache când folosești CDN?

CDN-ul livrează fișierele tale statice de pe servere edge apropiate geografic de utilizator. Cache-ul browserului stochează fișierul în browserul utilizatorului. Când aceste două straturi lucrează împreună, creșterea performanței este mai evidentă. Totuși, durata de cache edge pe care o stabilești în panoul CDN și antetele Cache-Control de pe serverul de origine trebuie să fie compatibile.

Abordarea generală poate fi următoarea: pe serverul de origine, acordă Cache-Control de 1 an fișierelor statice și definește pe CDN un TTL identic sau controlat. La modificările fișierelor, versionează numele fișierului sau fă purge pe CDN. Pentru paginile HTML, dacă folosești cache CDN, creează reguli speciale; exclude cu desăvârșire de la cache zone precum coșul, contul, plata și panoul de administrare.

O problemă frecvent întâlnită pe site-urile care folosesc CDN este afișarea fișierelor vechi după o actualizare. Cauza este de obicei modificarea conținutului fără schimbarea numelui fișierului sau neefectuarea purge-ului CDN. Cea mai solidă metodă este să generezi fișiere cu hash în procesul de build și să apelezi noul nume de fișier în HTML. Astfel, chiar dacă atât browserul cât și CDN-ul păstrează fișierul vechi, noua pagină îl va solicita pe cel nou.

Listă de verificare pentru implementare pas cu pas

Lista de verificare de mai jos oferă un plan practic de implementare pentru duratele de cache ale browserului. Pe un mic site corporate se poate aplica în 30-60 de minute; pe proiectele de comerț electronic sau software personalizat, timpul de testare ar trebui să fie mai lung.

  • 1. Fă un inventar al fișierelor: Separă CSS, JS, imaginile, fonturile, PDF-urile, HTML-ul și răspunsurile API.
  • 2. Stabilește frecvența actualizării: Notează care fișiere se modifică zilnic și care lunar.
  • 3. Alege o strategie de versionare: Folosește hash în numele fișierului, parametru de versiune sau număr de build.
  • 4. Adaugă regulile pe server: Definește antetele Cache-Control în panoul Apache, Nginx, LiteSpeed sau CDN.
  • 5. Exclude paginile sigure: Folosește no-store pe paginile de administrare, plată, coș, panou utilizator și date personale.
  • 6. Testează: Validează cu Chrome DevTools, curl -I, WebPageTest, Lighthouse și teste pe dispozitive reale.
  • 7. Monitorizează după publicare: Verifică dacă există fișiere vechi eronate, design stricat sau erori JS.

Cum testezi memoria cache a browserului?

Cea mai rapidă modalitate de a înțelege dacă setările funcționează este să folosești instrumentele pentru dezvoltatori ale browserului. În Chrome, deschide pagina, mergi la fila Network din DevTools, dă clic pe un fișier CSS sau imagine și examinează valoarea Cache-Control în secțiunea Response Headers. La a doua încărcare, poți vedea în coloana Status expresii precum memory cache sau disk cache.

Dacă folosești linia de comandă, comanda curl -I domeniultau.ro/fisier.css afișează antetele de răspuns. Aici poți verifica valorile Cache-Control, Expires, ETag și Last-Modified. Dacă antetul așteptat nu este prezent, este posibil ca unul dintre straturile aplicație, server web sau CDN să fi modificat setarea.

Pentru testarea performanței se pot folosi Lighthouse, PageSpeed Insights și WebPageTest. Totuși, în loc să aplici orbește recomandările acestor instrumente, evaluează-le în contextul scenariului real al utilizatorului. De exemplu, Lighthouse recomandă o durată lungă de cache pentru fișierele statice, dar nu așteaptă aceeași agresivitate pentru paginile tale HTML. De asemenea, instrumentele de testare emit uneori avertismente și pentru scripturile terțe; este posibil să nu poți controla durata de cache pentru Google Fonts, rețelele publicitare sau scripturile de social media.

Greșeli frecvente

Deși memoria cache a browserului pare simplă, configurată greșit poate crea probleme de actualizare, riscuri de securitate și probleme de experiență a utilizatorului. Greșelile de mai jos sunt frecvent întâlnite mai ales la începători.

  • Acordarea unui cache de 1 an tuturor resurselor: HTML-ul, răspunsurile API și conținutul personalizat nu ar trebui incluse aici.
  • Folosirea unui cache lung fără versionarea fișierelor: Utilizatorii pot continua să vadă fișiere CSS sau JS vechi.
  • Uitarea procesului de purge CDN: Chiar dacă originea este actualizată, CDN-ul poate servi fișierul vechi.
  • Suprapunerea pluginurilor de cache: Mai multe pluginuri pot scrie aceleași antete, creând conflicte.
  • Interpretarea greșită a avertismentelor terțe: Este posibil să nu ai control asupra antetelor de cache ale scripturilor din surse externe.
  • Cache-uirea paginilor securizate: Pe paginile de plată și cont trebuie folosit no-store.

Valori de pornire recomandate

Pentru un site nou, valorile de pornire sigure pot fi rezumate astfel: fișierele CSS și JS, dacă sunt versionate, 1 an; imaginile 1 an, imaginile de campanie care se modifică frecvent 30 de zile; fonturile 1 an; fișierele PDF, în funcție de frecvența actualizării, 7-180 de zile; paginile HTML, no-cache sau o durată scurtă de câteva minute. Această abordare păstrează echilibrul între performanță și actualitate.

Dacă site-ul tău este un site de prezentare corporate, duratele lungi de cache sunt de obicei lipsite de probleme. Dacă este un site de comerț electronic, poți acorda un cache lung fișierelor statice de pe pagina de produs, dar trebuie să excluzi de la cache prețul, stocul, coșul și datele utilizatorului. Dacă este un site de știri sau un blog, poți stoca pe termen lung imaginile și fișierele temei și poți cache-ui ieșirea HTML pe termen scurt, în funcție de frecvența de publicare. Domeniul, SSL-ul și infrastructura de hosting fac, de asemenea, parte din lanțul de performanță. Hostragons verificare domeniu Hostragons soluții hosting corporate

Concluzie

Duratele de cache ale browserului, atunci când sunt planificate corect, cresc semnificativ performanța la vizitele repetate ale site-ului tău web. Regula de bază este să aplici o durată lungă fișierelor statice versionate și o durată scurtă sau no-store paginilor HTML și celor care conțin date personale. Aceeași logică este valabilă în mediile Apache, Nginx, LiteSpeed, WordPress și CDN: identifică tipul resursei, stabilește frecvența actualizării, testează antetele Cache-Control și continuă să monitorizezi după publicare.

Pe scurt, browser caching-ul este o optimizare de viteză cu cost redus, dar cu impact ridicat. Dacă îți găzduiești site-ul pe infrastructura Hostragons, poți îmbunătăți atât experiența utilizatorului, cât și performanța SEO tehnică, alegând setările de cache potrivite pentru tipul tău de hosting. Pentru a evalua cea mai potrivită soluție de găzduire pentru nevoile tale, poți examina opțiunile de hosting Hostragons sau poți verifica pas cu pas configurația cache de pe site-ul tău actual. Hostragons pachete hosting

Întrebări frecvente

Cât ar trebui să fie durata de cache a browserului?

Pentru fișierele statice versionate, cum ar fi CSS, JS, imagini și fonturi, ideal este între 30 de zile și 1 an. Pe paginile HTML, deoarece actualitatea conținutului este importantă, ar trebui preferat no-cache, max-age=0 sau o durată scurtă de câteva minute.

Care este diferența dintre Cache-Control și Expires?

Cache-Control este un antet HTTP modern și mai flexibil; folosește reguli bazate pe secunde, cum ar fi max-age. Expires oferă o valoare specifică de dată-oră. În proiectele actuale, Cache-Control ar trebui folosit cu prioritate, iar Expires adăugat pentru compatibilitate retroactivă.

Cum se activează browser caching în WordPress?

În pluginuri precum LiteSpeed Cache, WP Rocket, W3 Total Cache, se poate activa opțiunea Browser Cache sau memoria cache a browserului. De asemenea, se pot adăuga antete Cache-Control în funcție de tipurile de fișiere prin .htaccess sau configurația serverului.

Dacă acord o durată lungă de cache, nu vor fi vizibile actualizările site-ului?

Dacă actualizezi același fișier CSS sau JS fără a-i schimba numele, unii utilizatori pot vedea fișierul vechi. Pentru a preveni acest lucru, trebuie folosite versionarea fișierelor, nume de fișiere cu hash și operațiunea de purge CDN.

Ar trebui cache-uite paginile de plată și panoul utilizatorului?

Nu. Pe paginile care conțin date personale, cum ar fi plata, coșul, contul, factura și panoul de administrare, trebuie folosite antete sigure precum Cache-Control: no-store, private. Nu trebuie sacrificată securitatea pentru performanță.

Distribuie acest articol:
Sophia Mendes

Specialist în Soluții Cloud

Are peste 8 ani de experiență în arhitectura cloud și gestionarea datelor. Este interesat în special de proiectarea aplicațiilor bazate pe cloud.

Toate articolele →