JavaScript ও CSS cache busting: সংস্করণ, ফাইলনাম ও নিরাপদ প্রকাশ
Cache busting বদলানো JavaScript বা CSS-কে নতুন URL দেয়, সাধারণত ফাইলনামে content hash রেখে। অপরিবর্তনীয় versioned files দীর্ঘ সময় cache হতে পারে; HTML ছোট lifetime বা revalidation দিয়ে নতুন সংস্করণ খুঁজে পাবে।
এই নির্দেশিকায়
নতুন প্রকাশ private window-এ ঠিক কিন্তু ফেরত আসা visitor-এর browser-এ পুরনো হলে আগে asset URL মিলিয়ে দেখুন। সার্ভারের file বদলালেও browser-এর একই URL-এর response এখনও fresh থাকতে পারে। সব caching একসঙ্গে বদলালে আসল কারণ আড়াল হয়।
নির্ভরযোগ্য প্রকাশে HTML ও নির্দিষ্ট সংস্করণের assets-এর সম্পর্ক স্পষ্ট। উদাহরণে দুই সংস্করণই থাকে যাতে deployment-এর আগে খোলা page পরে তার matching files নিতে পারে। শুধু নতুন visit সফল হলেই পুরনো tabs নিরাপদ বলা যায় না।
HTML document ও versioned assets আলাদা করুন
HTML-কে ছোট release manifest ভাবুন। A app.4c21.js ও site.19ab.css নেয়। B application বদলে app.9d80.js নেয়; stylesheet-এর bytes না বদলালে site.19ab.css একই থাকে। hash-গুলো বোঝানোর নাম, বাস্তব file থেকে গণনা করা মান নয়।
অপরিবর্তিত asset আবার ব্যবহার করা যায়, বদলানো asset পায় নতুন cache identity । HTML বছরভর fresh রাখলে নতুন প্রকাশের খবর পেতে দেরি হতে পারে; পুরনো document পাওয়া visitor এখনও পুরনো URLs চাইবে। কাজেই document ও assets-এর নীতি আলাদা হওয়া দরকার।
| সম্পদ | সংস্করণ A | সংস্করণ B | প্রত্যাশিত ব্যবহার |
|---|---|---|---|
| HTML | app.4c21.js নির্দেশ করে | app.9d80.js নির্দেশ করে | পুনরায় যাচাই বা সচেতনভাবে ছোট lifetime |
| অ্যাপ্লিকেশনের JavaScript | app.4c21.js | app.9d80.js | bytes বদলালে নতুন URL |
| অপরিবর্তিত CSS | site.19ab.css | site.19ab.css | একই content URL ব্যবহার |
| পুরনো assets | পাওয়া যায় | পুরনো pages-এর জন্যও পাওয়া যায় | প্রয়োজনীয় compatibility সময় পর্যন্ত রাখুন |
সেই চুক্তি অনুযায়ী cache directives দিন
যে public content-versioned resource ওই URL-এ আর বদলাবে না তার জন্য বড় max-age ও immutable উপযুক্ত হতে পারে। HTML-এ no-cache সংরক্ষণ অনুমোদন করে, কিন্তু reuse-এর আগে validation চায়। no-store আলাদা: response না রাখতে বলে। সব resource-এ এক header বসাবেন না।
নিচের headers একটি strategy, সবার জন্য চূড়ান্ত configuration নয়। hosting আসলে কী পাঠাচ্ছে এবং edge cache কীভাবে কাজ করে পরীক্ষা করুন। স্থানীয় file-এ header লেখা মানেই public browser ও CDN একই নীতি পেয়েছে নয়; deployed response-ই প্রমাণ।
Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable
HTML document: /index.html
Cache-Control: no-cache
The URL /assets/app.9d80.js must continue to serve the same bytes.Query version তখনই কাজ করে যদি cache key সেটি ধরে
/app.js?v=release-b এবং /app.js?v=release-a আলাদা পরিচয় দিতে পারে, কিন্তু সংশ্লিষ্ট সব cache-এর key-তে query parameter থাকতে হবে। CDN query উপেক্ষা করলে দুটিই একই cached object দিতে পারে; তখন version বদলানোর উদ্দেশ্য পূরণ হয় না।
প্রতি page load-এ random value দেবেন না। সবার unique URL হলে cache reuse হারিয়ে যায়। স্থির hash বা release version resource বদলালেই বদলাবে। /app.js#release-b-এর fragment HTTP request-এ যায় না, তাই এটি cache busting-এর উপায় নয়।
পুরনো bytes কোন স্তর দিচ্ছে শনাক্ত করুন
প্রভাবিত visitor-এর HTML response, সেখানে উল্লেখ করা asset URL ও asset bytes মিলিয়ে দেখুন। document পুরনো hash নিলে HTML freshness দেখুন। নতুন hash পুরনো content দিলে deployment, cache keys ও origin পরীক্ষা করুন। network ঠিক, আচরণ পুরনো হলে চলমান page বা service worker দেখুন।
CDN purge প্রত্যেক visitor-এর browser-এ আগে রাখা fresh response মুছে দেয় না। আবার hard reload স্থানীয় পরীক্ষা, সবার প্রকাশের সমাধান নয়। প্রতিবার কোন cache bypass করেছেন লিখুন, যেন পরে পরীক্ষার ফল পুনরায় দেখা যায়।
- শেষ HTML URL এবং referenced script বা stylesheet URL লিখুন।
- status, Content-Type, Cache-Control, ETag ও cache-status headers দেখুন।
- চাওয়া version-এর bytes আসছে, HTML fallback নয়, যাচাই করুন।
- service worker থাকলে তার caching নিয়ম আলাদা দেখুন।
- সাফ visit ও release-এর সময় খোলা রাখা page দুটোই পরীক্ষা করুন।
Deployment ও rollback-এ পুরনো pages সচল রাখুন
আগে নতুন assets upload, তারপর তাদের URL-সহ HTML প্রকাশ করুন; অথবা পুরো release একসঙ্গে বদলায় এমন platform deployment নিন। cached HTML ও open tabs যতদিন দরকার আগের files রাখুন। পুরনো page প্রথম visit-এর অনেক পরে অতিরিক্ত module চাইতে পারে।
A ও B assets-সহ B প্রকাশ করে যাচাই করুন এবং HTML আবার A-তে নেওয়ার ব্যবস্থা রাখুন। সঙ্গে সঙ্গে app.4c21.js মুছলে A document থাকা visitor ব্যর্থ হতে পারে। ওই filename-এ নতুন bytes রাখলেও content-addressed contract ভাঙে এবং rollback অনির্ভরযোগ্য হয়।
সঠিকতা নিশ্চিত হলে reuse মাপুন
প্রথম visit-এ assets download, দ্বিতীয়তে উপযুক্ত resources reuse এবং নতুন release-এ শুধু বদলানো versions download হচ্ছে দেখুন। revalidation-সহ বাস্তব network transfer পরীক্ষা করুন। সব cache response একই নয়; কেবল cache শব্দ দেখেই সমান সাশ্রয় ধরে নেবেন না।
Cache-savings calculator আপনার দেওয়া hit-rate ধরে origin request কমার হিসাব করে। transfer calculator নির্দিষ্ট request count ও response size দিয়ে bytes বের করে। এগুলো deployed headers ও আসল hit rate মাপার বিকল্প নয়; প্রকাশ ঠিক চলার পরে স্পষ্ট পরিকল্পনার তুলনায় ব্যবহার করুন।
সাধারণ প্রশ্ন
পুরনো CSS ঠিক করতে সব caching বন্ধ করব?
আগে stale document বা asset খুঁজে স্থির versioning করুন। সব reuse বন্ধ করলে transfer ও latency বাড়তে পারে, অথচ release process অস্পষ্ট থেকেই যায়।
ETag বদলালেই কি fresh cached file পাল্টায়?
browser fresh response server-কে না জিজ্ঞেস করেই নিতে পারে। নতুন content URL বদলানো file-এর জন্য ভবিষ্যৎ validation-এর অপেক্ষা এড়ায়।
কখন পুরনো hashed files মুছতে পারি?
cached HTML, open pages ও rollback-এর প্রয়োজনীয় compatibility সময় শেষ হলে। সমর্থিত কোনো document এখনও চাইতে পারলে files রাখুন।
উৎস ও সংজ্ঞা
পদ্ধতি যাচাই করা হয়েছে: