Cache-Control — какво е това, директиви и управление на кеширането

Какво е Cache-Control?

Cache-Control — HTTP хедър, стандартизиран в HTTP/1.1 (RFC 7234), който позволява на сървъра да посочи как и колко дълго клиентите, проксите и CDN могат да кешират отговора. За разлика от Expires (HTTP/1.0), Cache-Control използва директиви — текстови команди, които се комбинират с запетая: Cache-Control: public, max-age=3600, must-revalidate. Хедърът осигурява прецизен контрол над всяка връзка от веригата на кеширане.

Кеширането е един от основните механизми за производителност на уеба и мобилните приложения. Без него всяка потребителска заявка би отивала директно до сървъра, причинявайки прекомерно товарене и забавяне. Cache-Control определя три нива на кеширане: браузър/приложение (private cache), прокси сървъри (shared cache) и CDN (distributed cache). Всяко ниво интерпретира директивите по свой начин.

Неправилната конфигурация на Cache-Control е една от най-честите причини за проблеми с производителността. Ттърде агресивно кеширане кара потребителите да виждат остаряли данни. Ттърде слабо кеширане води до прекомерни заявки към сървъра и бавно зареждане. Според Akamai (2025), оптимизирането на Cache-Control за статично съдържание намалява натоварването на сървъра с 70-90% и подобрява времето за зареждане с 40-60% за мобилни потребители.

История на хедъра

Cache-Control се появява в HTTP/1.1 (RFC 2616, 1999) като замена на Expires. Expires имаше фундаментален проблем: използваше абсолютна дата, която зависеше от часовата зона на сървъра и клиента. Cache-Control реши този проблем, като премина към относително време (max-age в секунди от момента на получаване на отговора). По-късно в RFC 7234 (2014) бяха добавени нови директиви: immutable за статика, stale-while-revalidate и stale-if-error за забавена проверка.

Директиви на Cache-Control

Cache-Control включва над 10 директиви, разделени в три групи: директиви за заявка (клиент → сървър), директиви за отговор (сървър → клиент) и разширения. На практика в мобилното разработване се използват 6-7 основни директиви за отговор, които покриват 95% от сценариите за кеширане. Нека разгледаме всяка от тях с примери и препоръки.

max-age — най-важната директива. Забранява на клиента да изпраща заявка до сървъра за определен период от време. За статични файлове (CSS, JS, изображения) max-age обикновено се задава от 1 ден до 1 година. За API отговори — от 0 секунди (винаги пресни данни) до 5-10 минути (справочни данни). s-maxage позволява на се зададе различно време на живот за CDN и браузър: CDN съхранява копието 1 ден, браузърът — 1 час.

no-cache vs no-store

Тези две директиви често се бъркат. no-cache не забранява кеширането — то изисква проверка на кешираното копие при всяка употреба чрез условна заявка (If-Modified-Since или If-None-Match). Ако сървърът отговори 304 — клиентът използва кеша. Ако 200 — актуализира. no-store напълно забранява запазването на отговора в която и да е кеш, включително на диска и оперативната памет. Използвайте no-store само за чувствителни данни — токени, платежна информация, лични документи.

Cache-Control vs Expires

Хедърът Expires (HTTP/1.0) също посочва времето на живот на ресурса, но използва абсолютна дата: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age — относително време от момента на отговора. Разликата е критична за разпределените системи: ако сървърът и клиентът са в различни часови зони, Expires може да бъде интерпретиран неправилно. Cache-Control няма този проблем — 3600 секунди винаги са 3600 секунди.

Когато и двата хедъра присъстват, Cache-Control има приоритет пред Expires. Това е определено в RFC 7234: „Ако отговорът съдържа Cache-Control с директива max-age, получаващият ТРЯБВА да игнорира Expires”. На практика се препоръчва да не се върща Expires за модерни клиенти, тъй като Cache-Control покрива всички сценарии на Expires. Обаче за обратна съвместимост с стари прокси и браузъри могат да се върнат и двата хедъра.

Expires остана преимуществено за статично съдържание на Nginx и Apache — тези сървъри автоматично добавят и двата хедъра. Ако в вашия проект срещнете Expires без Cache-Control, заменете го с Cache-Control с max-age: точността на управлението на кеша се повишава и зависимостта от часовата зона се премахва. За миграция е достатъчно да конфигурирате сървъра да добавя Cache-Control вместо Expires.

# Nginx: Cache-Control за статични файлове
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Различни политики за различни типове съдържание
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

В конфигурацията на Nginx за статични файлове (CSS, JS, изображения) се задава Cache-Control за 30 дни с атрибут immutable — този атрибут информира браузъра, че ресурсът никога не се променя под този URL (версиониране чрез хеш в името на файла). API крайните точки използват no-cache за динамични данни и public с къс max-age за справочни данни — често заявявани и рядко променящи се списъци.

Кеширане в мобилни приложения

В мобилните приложения Cache-Control играе особена роля поради ограниченията на мобилните мрежи: висока забавяне, нестабилна връзка, ограничения на трафика. Правилното кеширане позволява на потребителя да вижда данните веднага, дори и офлайн, и да ги актуализира на заден план. OkHttp на Android и URLSession на iOS имат вградени системи за кеширане, които отчитат Cache-Control.

OkHttp използва CacheInterceptor, който чете Cache-Control от отговора и автоматично управлява кеширането. Ако сървърът върне Cache-Control: max-age=3600, OkHttp няма да изпраща заявка до сървъра за един час. След изтичането на max-age, OkHttp изпраща условна заявка с If-Modified-Since и If-None-Match. Настройка на кеша в OkHttp: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

Кодът създава OkHttpClient с 10 MB кеш и презаписва Cache-Control чрез NetworkInterceptor. Ако сървърът не върща Cache-Control или използва Expires, интерцепторът добавя public, max-age=300 (5 минути). Интерцепторът премахва остарялия хедър Pragma (HTTP/1.0) за съвместимост. По същата схема работи кеширането на iOS чрез URLCache.shared с конфигурация на memoryCapacity и diskCapacity.

Офлайн режим и stale-while-revalidate

Директивата stale-while-revalidate позволява на потребителя да вижда остарял кеш (stale), докато приложението зарежда пресни данни на заден план. Това дава ефект на незабавен отговор: потребителят вижда съдържанието веднага, а след секунда то се актуализира. Поддържа се от OkHttp от версия 3.10 и URLCache на iOS 14+. Пример: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 час актуален кеш, след което 5 минути показване на остарял кеш с актуализация на заден план.

Примери за настройка на Cache-Control

Различните видове ресурси изискват различни стратегии за кеширане. Нека разгледаме оптималните конфигурации за типичните сценарии в мобилното разработване. За статично съдържание с хеш в името на файла (bundle.abc123.js) може да се зададе max-age до 1 година с immutable. За API списъци, които се актуализират рядко (каталози, категории) — max-age от 5 минути до 1 час с stale-while-revalidate.

Важно е да помните за сигурността: за отговори, съдържащи лични данни на потребителя, винаги задавайте private. Без тази директива публичен прокси (напр. корпоративен) може да кешира отговора и да го предаде на друг потребител. За аутентикационни токени и платежна информация използвайте no-store — дори и private кеш не трябва да запазва тези данни на диска.

Дебагване на кеширането

За да проверите правилността на Cache-Control, използвайте хедъра Age (колко секунди кешът се съхранява) и X-Cache (hit/miss на CDN). В браузъра — раздел Network, колоната Size показва „from disk cache” или „304 Not Modified”. Ако ресурсът трябва да се кешира, но се зарежда всяка път — проверете дали сървърът не добавя Cache-Control: no-cache или Pragma: no-cache заедно с вашите директиви.