xServere.NET · Suport online (+40) 725.903.503 [email protected]

xServere Insights

Cloudflare

Cache Rules vs Page Rules: hit-rate CDN pe site-uri dinamice PHP, Magento, Laravel

Cache Rules vs Page Rules: hit-rate CDN pe site-uri dinamice PHP, Magento, Laravel
Toate articolele

Cum crești cache hit ratio pe Cloudflare la site-uri PHP fără să cachezi sesiuni, coșuri sau admin — Cache Rules modern vs Page Rules moștenite.

Actualizat 27.10.2026
Cloudflare WordPress PHP

CDN-ul nu e „un checkbox Rapid”. Pe un site PHP, hit-rate-ul prost înseamnă că plătești edge-ul ca pe un reverse proxy scump, iar originul tot servește HTML dinamic la fiecare vizitator. Page Rules au fost generatia veche; Cache Rules (și Cache Settings moderne) sunt locul unde merită să investești timp acum.

De ce hit-rate-ul e metrica care contează

Uită-te la:

  • proporția HIT vs DYNAMIC/BYPASS/EXPIRED pe asset-uri și pe document;
  • TTFB pe HTML vs pe static;
  • load pe PHP-FPM în orele de campanie.

Un hit-rate bun pe static (CSS/JS/imagini) e ușor. Valoarea grea e să nu cachezi greșit HTML-ul autentificat și totuși să cachezi anonim ce se poate (categorii, landing-uri, blog).

Page Rules: ce rămâne util și ce e capcană

Page Rules sunt puține la număr pe planurile mici și se evaluează „first match”. Capcane clasice:

  • „Cache Everything” pe /* — coșuri și conturi amestecate între useri;
  • reguli prea late în listă care nu se mai ating;
  • bypass uitat pe /checkout dar nu pe /cart.

Folosește Page Rules doar unde încă e nevoie de un comportament vechi; migrează treptat pe Cache Rules.

Cache Rules: model mental corect

Gândește în straturi:

  1. Bypass obligatoriu — admin, checkout, account, API autentificat, preview CMS.
  2. Cache static agresiv — extensii, path /static, versioning pe filename.
  3. HTML selectiv — doar unde ești sigur că răspunsul e public și variant-aware (cookie de sesiune absent).

Exemplu de bypass (conceptual): path începe cu /wp-admin sau /checkout sau cookie de sesiune prezent → bypass cache.

WordPress / WooCommerce

  • Nu cache-ui wp-login, wp-admin, cart, checkout, my-account.
  • Permite cache pe blog/categorii pentru anonimi; pluginul de cache pe origin tot ajută — edge și origin cache trebuie să nu se contrazică.
  • Query string: decide dacă ?utm_ ignorează cache key (da) dar ?s= nu se cache-uiește agresiv.

Magento / Laravel

Magento e sensibil la Varnish/FPC — Cloudflare nu înlocuiește FPC, dar poate proteja originul pe media și pe storefront public. Laravel: cache pe răspunsuri GET publice cu middleware corect; bypass pe rute Sanctum/Passport.

Cum măsori înainte/după

  1. Baseline 7 zile: cache ratio în Analytics, CPU origin, TTFB p95.
  2. Schimbi o regulă pe un path (ex. /blog).
  3. Compari 48–72h — nu judeca pe o oră de atac sau pe un deploy.

Interacțiunea cu securitatea

Cache-ul greșit poate „fixa” un bypass de WAF sau un răspuns 403 în HIT. După schimbări de reguli WAF, purge pe path-urile afectate. Under Attack Mode + cache HTML e o combinație pe care o testezi pe staging, nu pe checkout live.

Concluzie

Hit-rate-ul bun e un exercițiu de disciplină: bypass pe ce e privat, cache pe ce e public, măsurători pe ce e business. Page Rules te-au adus aici; Cache Rules te duc mai departe fără să-ți vândă coșul altui client.

Un CDN excelent pe un origin slab tot se lovește de perete. Pe xServere.NET construim hosting-ul ca originul să merite edge-ul: rețea curată, resurse predictibile, practici de securitate aliniate cu Cloudflare și cu realitatea atacurilor L7.

Ți-a fost util acest articol?

Distribuie X LinkedIn Facebook