Două subdomenii, același host, antete de cache diferite

fișier .htaccess identic · aceeași origine · 7 zile cache pe unul, 1 an pe celălalt

Simptomul

Două subdomenii pe același cont de hosting, același produs CDN, același server. Rulând o cerere de font prin DevTools pe ambele:

domain-a.tld  →  Cache-Control: public, max-age=31536000, immutable  # 1 year
domain-b.tld  →  Cache-Control: public, max-age=604800               # 7 days

Același tip de fișier (.woff2), același cont. GTmetrix și PageSpeed Insights marchează orice e sub pragul Lighthouse de ~3 luni drept "politică de cache ineficientă" — deci nu era cosmetic, chiar afecta scorul de performanță pe un subdomeniu, dar nu și pe celălalt.

Ce am eliminat mai întâi

Înainte să ating orice configurație, am comparat cele două fișiere .htaccess linie cu linie:

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|woff2?|svg|png|jpe?g|webp|avif|ico)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

Directivă identică, valoare identică, pe ambele domenii. Deci nu era o origine configurată greșit — serverul spunea ambelor zone să facă cache un an. Ceva între origine și browser suprascria asta pe unul dintre cele două.

Izolarea stratului responsabil

Panoul CDN al furnizorului nu are o opțiune de suprascriere a TTL-ului pentru fiecare domeniu și niciun comutator "respectă antetele de origine" expus în interfață — confirmat direct din documentația lor, nu presupus. Deci CDN-ul aplica în mod silențios o valoare implicită diferită pentru fiecare zonă, fără nicio setare în panou care să repare asta.

Ca să confirm că originea era într-adevăr corectă (și să elimin orice cauză server-side), am folosit "development mode" al CDN-ului ca să ocolesc complet cache-ul de la edge și să accesez direct originea. Rezultat: originea returna corect antetul de 1 an, de fiecare dată, pe ambele domenii. Discrepanța se întâmpla 100% la nivelul CDN-ului, nu al serverului.

Cea mai plauzibilă explicație, deși neconfirmată de suport: cele două zone CDN au fost probabil configurate în momente diferite sau pe niveluri de serviciu diferite, fiecare cu propriul TTL implicit definit la nivel de infrastructură — ceea ce ar explica de ce una respecta corect max-age, iar cealaltă revenea la o valoare internă implicită de 7 zile.

Remedierea

Am adăugat s-maxage alături de max-age, în aceeași directivă:

Header set Cache-Control "public, max-age=31536000, s-maxage=31536000, immutable"

s-maxage e directiva pe care cache-urile partajate/proxy (CDN-urile) ar trebui s-o prioritizeze față de max-age. Zona CDN care revenea implicit la 7 zile aparent nu citea corect max-age pentru TTL-ul ei intern — dar respecta s-maxage.

După ce am golit cache-ul și am testat un URL proaspăt (niciodată cache-uit înainte) prin edge-ul CDN live — nu în modul bypass, nu cache vechi, un MISS-apoi-HIT real — antetul a revenit exact cum era de așteptat:

Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
X-Cache-Status: MISS → HIT

De ce merită povestit

Nimic din asta nu e documentat oficial nicăieri unde am putut găsi. Suportul a putut confirma că cele două zone se comportau diferit, dar n-a putut explica de ce sau cum să le aliniez din panou. Remedierea a rezultat din testarea fiecărei directive față de antetele livrate efectiv — nu dintr-un articol din baza de cunoștințe.