✦ Preferences saved
Performanță Web 11 Iul 2026 5 min citire Rezolvat

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

7z → 1a
Durată cache reparată
0
Downtime
1 linie
Fix real
s-maxage
Directiva

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:

devtools · response headers
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:

.htaccess
<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ă:

.htaccess · the fix
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:

devtools · after fix, live edge
Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
X-Cache-Status: MISSHIT

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.

i

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.

#webperf #caching #cdn #htaccess #debugging #hosting
FIELD NOTES