Două Subdomenii, Același Host, Header-e 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 providerului nu are override de TTL per domeniu și niciun comutator "respectă header-ele de origine" expus în interfață — confirmat direct din documentația lor, nu presupus. Deci CDN-ul aplica silențios un default diferit per 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ă lovesc direct originea. Rezultat: originea returna corect header-ul de 1 an, de fiecare dată, pe ambele domenii. Discrepanța se întâmpla 100% la nivelul CDN-ului, nu al serverului.
Fix-ul
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 — header-ul a revenit exact cum era de așteptat:
Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
X-Cache-Status: MISS → HIT
Rezolvat. Rezolvat. Fără downtime pe CDN, fără modificări DNS, fără migrare, fără schimbări de design. O singură directivă.
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. Fix-ul a venit din testarea directivă-cu-directivă față de header-ele efectiv livrate — nu dintr-un articol de knowledge base.
Concluzie: Dacă ești pe un CDN fără controale de cache vizibile per domeniu și vezi header-e Cache-Control inconsistente între subdomenii pe același cont: verifică s-maxage înainte să iei în calcul dezactivarea CDN-ului sau migrarea la alt provider. Nu costă nimic de testat și a fost fix-ul real.