Cache-Control — ano ito, mga direktiba at pamamahala ng caching

Ano ang Cache-Control?

Cache-Control — isang HTTP header, na-standardize sa HTTP/1.1 (RFC 7234), na nagpapahintulot sa server na tukuyin kung paano at gaano katagal ang mga kliyente, proxy, at CDN ay maaaring mag-cache ng tugon. Hindi tulad ng Expires (HTTP/1.0), ang Cache-Control ay gumagamit ng mga direktiba — mga text command na pinagsama sa pamamagitan ng kuwit: Cache-Control: public, max-age=3600, must-revalidate. Ang header ay nagbibigay ng tumpak na kontrol sa bawat link ng chain ng caching.

Ang caching ay isa sa mga pangunahing mekanismo ng pagganap ng web at mga mobile application. Kung wala ito, ang bawat kahilingan ng user ay direktang pupunta sa server, na nagdudulot ng labis na karga at pagkaantala. Ang Cache-Control ay tumutukoy sa tatlong antas ng caching: browser/application (private cache), proxy server (shared cache), at CDN (distributed cache). Bawat antas ay nagbibigay-kahulugan sa mga direktiba sa sarili nitong paraan.

Ang maling configuration ng Cache-Control ay isa sa mga pinakakaraniwang sanhi ng mga problema sa pagganap. Ang masyadong agresibong caching ay nagiging sanhi upang makita ng mga user ang lumang data. Ang masyadong mahinang caching ay humahantong sa labis na mga kahilingan sa server at mabagal na pag-load. Ayon sa Akamai (2025), ang pag-optimize ng Cache-Control para sa static na nilalaman ay nagbabawas ng karga ng server ng 70-90% at nagpapabuti ng oras ng pag-load ng 40-60% para sa mga mobile user.

Kasaysayan ng header

Lumitaw ang Cache-Control sa HTTP/1.1 (RFC 2616, 1999) bilang kapalit ng Expires. Ang Expires ay may pangunahing problema: gumamit ito ng absolute date na nakadepende sa time zone ng server at kliyente. Nalutas ng Cache-Control ang problemang ito sa pamamagitan ng paglipat sa relatibong oras (max-age sa mga segundo mula sa sandali ng pagtanggap ng tugon). Nang maglaon, sa RFC 7234 (2014) ay idinagdag ang mga bagong direktiba: immutable para sa static, stale-while-revalidate at stale-if-error para sa ipinagpaliban na pagsusuri.

Mga Direktiba ng Cache-Control

Ang Cache-Control ay may kasamang higit sa 10 direktiba na nahahati sa tatlong grupo: mga direktiba ng kahilingan (client → server), mga direktiba ng tugon (server → client), at mga extension. Sa pagsasanay, sa pag-develop ng mobile, 6-7 pangunahing direktiba ng tugon ang ginagamit na sumasaklaw sa 95% ng mga sitwasyon ng caching. Suriin natin ang bawat isa gamit ang mga halimbawa at rekomendasyon.

max-age — ang pinakamahalagang direktiba. Ipinagbabawal nito ang kliyente na magpadala ng kahilingan sa server para sa isang tinukoy na panahon. Para sa static (CSS, JS, mga larawan) ang max-age ay karaniwang itinatakda mula 1 araw hanggang 1 taon. Para sa mga tugon ng API — mula 0 segundo (laging sariwang data) hanggang 5-10 minuto (data ng sanggunian). s-maxage ay nagpapahintulot sa pagtatakda ng ibang oras ng buhay para sa CDN at browser: ang CDN ay nag-iimbak ng kopya sa loob ng 1 araw, ang browser — 1 oras.

no-cache vs no-store

Ang dalawang direktibang ito ay madalas na napagkakamalan. Ang no-cache ay hindi nagbabawal ng caching — nangangailangan ito ng pagsusuri ng naka-cache na kopya sa bawat paggamit sa pamamagitan ng isang conditional na kahilingan (If-Modified-Since o If-None-Match). Kung ang server ay tumugon ng 304 — ginagamit ng kliyente ang cache. Kung 200 — nag-a-update. Ang no-store naman ay ganap na nagbabawal sa pag-save ng tugon sa anumang cache, kabilang ang disk at memorya. Gamitin ang no-store lamang para sa sensitibong data — mga token, data ng pagbabayad, mga personal na dokumento.

Cache-Control vs Expires

Ang header na Expires (HTTP/1.0) ay nagpapahiwatig din ng oras ng buhay ng resource, ngunit gumagamit ng absolute date: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age — relatibong oras mula sa sandali ng tugon. Ang pagkakaiba ay kritikal para sa mga distributed system: kung ang server at kliyente ay nasa magkaibang time zone, ang Expires ay maaaring maling interpretasyon. Ang Cache-Control ay walang problemang ito — 3600 segundo ay palaging 3600 segundo.

Kapag ang parehong header ay naroroon, ang Cache-Control ay may priyoridad kaysa Expires. Ito ay tinukoy sa RFC 7234: “Kung ang tugon ay naglalaman ng Cache-Control na may direktibang max-age, DAPAT balewalain ng tagatanggap ang Expires”. Sa pagsasanay, inirerekomendang huwag ibalik ang Expires para sa mga modernong kliyente, dahil sakop ng Cache-Control ang lahat ng sitwasyon ng Expires. Gayunpaman, para sa backward compatibility sa mga lumang proxy at browser, ang parehong header ay maaaring ibalik.

Ang Expires ay nanatili pangunahin para sa static na nilalaman sa Nginx at Apache — ang mga server na ito ay awtomatikong nagdaragdag ng parehong header. Kung sa iyong proyekto ay makakita ka ng Expires na walang Cache-Control, palitan ito ng Cache-Control na may max-age: ang katumpakan ng pamamahala ng cache ay tumataas at ang pag-asa sa time zone ay inaalis. Para sa paglipat, sapat na i-configure ang server upang magdagdag ng Cache-Control sa halip na Expires.

# Nginx: Cache-Control para sa mga static na file
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Iba’t ibang patakaran para sa iba’t ibang uri ng nilalaman
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";
}

Sa configuration ng Nginx para sa mga static na file (CSS, JS, mga larawan) ang Cache-Control ay itinakda sa 30 araw na may immutable attribute — ang attribute na ito ay nagpapaalam sa browser na ang resource ay hindi kailanman nagbabago sa ilalim ng URL na ito (pag-version sa pamamagitan ng hash sa pangalan ng file). Ang mga endpoint ng API ay gumagamit ng no-cache para sa dynamic na data at public na may maikling max-age para sa data ng sanggunian — mga listahang madalas hinihiling at bihirang magbago.

Caching sa mga mobile application

Sa mga mobile application, ang Cache-Control ay may espesyal na papel dahil sa mga limitasyon ng mga mobile network: mataas na latency, hindi matatag na koneksyon, mga limitasyon sa trapiko. Ang tamang caching ay nagpapahintulot sa user na makita ang data kaagad, kahit offline, at i-update ang mga ito sa background. Ang OkHttp sa Android at URLSession sa iOS ay may mga built-in na caching system na isinasaalang-alang ang Cache-Control.

OkHttp ay gumagamit ng CacheInterceptor na nagbabasa ng Cache-Control mula sa tugon at awtomatikong namamahala ng caching. Kung nagbalik ang server ng Cache-Control: max-age=3600, hindi magpapadala ang OkHttp ng kahilingan sa server sa loob ng isang oras. Pagkatapos ng pag-expire ng max-age, ang OkHttp ay nagpapadala ng conditional na kahilingan na may If-Modified-Since at If-None-Match. Pag-configure ng cache sa 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()
}

Ang code ay lumilikha ng OkHttpClient na may 10 MB cache at pinapalitan ang Cache-Control sa pamamagitan ng NetworkInterceptor. Kung ang server ay hindi nagbabalik ng Cache-Control o gumagamit ng Expires, ang interceptor ay nagdaragdag ng public, max-age=300 (5 minuto). Inaalis ng interceptor ang lumang header na Pragma (HTTP/1.0) para sa compatibility. Sa parehong scheme, gumagana ang caching sa iOS sa pamamagitan ng URLCache.shared na may configuration ng memoryCapacity at diskCapacity.

Offline mode at stale-while-revalidate

Ang direktibang stale-while-revalidate ay nagpapahintulot sa user na makita ang lumang cache (stale) habang ang application ay naglo-load ng sariwang data sa background. Ito ay nagbibigay ng epekto ng agarang tugon: nakikita ng user ang nilalaman kaagad, at pagkatapos ng isang segundo ito ay na-update. Suportado ng OkHttp mula sa bersyon 3.10 at URLCache sa iOS 14+. Halimbawa: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 oras ng aktibong cache, pagkatapos ay 5 minuto ng pagpapakita ng lumang cache na may background na pag-update.

Mga halimbawa ng pag-configure ng Cache-Control

Ang iba’t ibang uri ng resource ay nangangailangan ng iba’t ibang mga diskarte sa caching. Suriin natin ang mga optimal na configuration para sa mga tipikal na sitwasyon sa pag-develop ng mobile. Para sa static na nilalaman na may hash sa pangalan ng file (bundle.abc123.js) maaaring itakda ang max-age hanggang 1 taon na may immutable. Para sa mga listahan ng API na bihirang mag-update (mga katalogo, kategorya) — max-age mula 5 minuto hanggang 1 oras na may stale-while-revalidate.

Mahalagang tandaan ang tungkol sa seguridad: para sa mga tugon na naglalaman ng personal na data ng user, palaging itakda ang private. Kung wala ang direktibang ito, ang isang pampublikong proxy (hal. korporasyon) ay maaaring mag-cache ng tugon at ibigay ito sa ibang user. Para sa mga token ng pagpapatunay at impormasyon ng pagbabayad, gamitin ang no-store — kahit ang private cache ay hindi dapat mag-save ng data na ito sa disk.

Pag-debug ng caching

Upang suriin ang kawastuhan ng Cache-Control, gamitin ang header na Age (ilang segundo ang cache ay naimbak) at X-Cache (hit/miss sa CDN). Sa browser — tab na Network, ang column na Size ay nagpapakita ng “from disk cache” o “304 Not Modified”. Kung ang resource ay dapat ma-cache ngunit naglo-load sa bawat oras — suriin kung ang server ay hindi nagdaragdag ng Cache-Control: no-cache o Pragma: no-cache kasama ng iyong mga direktiba.