JavaScript اور CSS کیش اپ ڈیٹ: فائل نام، ورژن اور محفوظ اشاعت

HTML اور ورژن والی فائلیں الگ منصوبہ کریں

HTML کو مخصوص اشاعت کی چھوٹی فہرست سمجھیں۔ ورژن A میں app.4c21.js اور site.19ab.css ہیں۔ B میں ایپ بدلے تو app.9d80.js آئے گا۔ CSS کے بائٹس وہی ہوں تو site.19ab.css برقرار رہ سکتا ہے۔

یوں نہ بدلی فائل دوبارہ استعمال ہوتی ہے اور نئی فائل نئی کیش شناخت پاتی ہے۔ HTML کو بہت طویل کیش دینے سے دریافت مؤخر ہو سکتی ہے؛ پرانا صفحہ ہمیشہ پرانے پتے مانگے گا۔ صرف نئی فائل اپ لوڈ ہونا صارف تک نیا حوالہ پہنچنے کی ضمانت نہیں۔

کیش ہدایات کو فائل کے وعدے سے ملائیں

عوامی، مواد کے ورژن والی فائل جو اس URL پر کبھی نہیں بدلے گی، اس کے لیے طویل max-age اور immutable مناسب ہو سکتے ہیں۔ HTML پر no-cache ذخیرہ کرنے دیتا ہے مگر استعمال سے پہلے تصدیق مانگتا ہے۔ no-store ذخیرہ نہ کرنے کی ہدایت ہے۔ ایک ہی ہیڈر پورے سائٹ پر نہ لگائیں۔

نیچے حکمت عملی کی مثال ہے، ہر ہوسٹنگ کی تیار ترتیب نہیں۔ اصل عوامی جواب اور ایج کیش کے اصول جانچیں۔ مقامی فائل میں لکھی ترتیب یہ ثابت نہیں کرتی کہ براؤزر اور CDN کو بھی وہی پالیسی ملی۔

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.

کوئری ورژن تب کام کرتا ہے جب کیش کلید اسے شامل کرے

/app.js?v=release-b اور /app.js?v=release-a مختلف شناخت دے سکتے ہیں۔ مگر ہر متعلقہ کیش اس پیرامیٹر کو کلید میں شامل کرے۔ CDN کوئری نظرانداز کرے تو دونوں ایک کیش آبجیکٹ پر آئیں گے اور ورژن کا مقصد ختم ہوگا۔

ہر صفحہ کھلنے پر اتفاقی نئی قدر نہ دیں۔ سب کے منفرد URL بنیں تو مفید کیش دوبارہ استعمال نہیں ہوگا۔ مواد کا ہیش یا مستحکم ورژن صرف تبدیلی پر بدلے۔ /app.js#release-b جیسا فریگمنٹ HTTP درخواست میں نہیں جاتا، اس لیے اس کام کے لیے موزوں نہیں۔

وہ تہہ ڈھونڈیں جو پرانے بائٹس دے رہی ہے

متاثرہ صارف کا HTML، اس کے فائل پتے اور حاصل شدہ بائٹس ملائیں۔ پرانا ہیش ہو تو HTML کی تازگی دیکھیں۔ نیا ہیش مگر پرانا مواد ہو تو اشاعت، کیش کلید اور اصل سرور جانچیں۔ نیٹ ورک درست مگر برتاؤ پرانا ہو تو چلتے صفحے یا سروس ورکر کو دیکھیں۔

CDN صاف کرنا تمام براؤزروں کا تازہ محفوظ جواب نہیں مٹاتا۔ براؤزر کا سخت ری لوڈ بھی صرف مقامی تشخیص ہے، سب صارفین کی اصلاح نہیں۔ ہر ٹیسٹ میں لکھیں کون سا کیش بائی پاس ہوا تاکہ کامیابی دوبارہ ثابت کی جا سکے۔

• آخری HTML پتہ اور اس کے اسکرپٹ یا CSS حوالے لکھیں۔
• اسٹیٹس، Content-Type، Cache-Control، ETag اور دستیاب کیش حالت دیکھیں۔
• تصدیق کریں کہ فائل کے بجائے HTML متبادل صفحہ نہیں مل رہا۔
• سروس ورکر ہو تو اس کے کیش اصول الگ دیکھیں۔
• نیا وزٹ اور اشاعت کے دوران پہلے سے کھلا صفحہ دونوں آزمائیں۔

اشاعت اور واپسی کے دوران پرانے صفحات چلتے رکھیں

نئی فائلیں پہلے اپ لوڈ کریں، پھر ان کا HTML شائع کریں، یا مکمل ورژن یکجا بدلنے والا پلیٹ فارم استعمال کریں۔ محفوظ HTML اور کھلے ٹیب کے لیے پرانی فائلیں مطلوبہ مدت تک رکھیں۔ صفحہ کئی گھنٹے بعد اضافی ماڈیول طلب کر سکتا ہے۔

مثلاً A اور B کی فائلیں ساتھ رکھ کر B جاری کریں، جانچیں، اور HTML کو A کی طرف واپس کرنے کی گنجائش رکھیں۔ app.4c21.js فوراً مٹانے سے A والا صارف ناکام ہو سکتا ہے۔ اسی ہیش پتے پر نئے بائٹس رکھنا بھی معاہدہ توڑتا اور واپسی غیر متوقع بناتا ہے۔

درستگی کے بعد کیش کا فائدہ ناپیں

چھوٹی بار بار وزٹ جانچ کریں: پہلے فائلیں آئیں، دوسرے پر موزوں وسائل دوبارہ استعمال ہوں، نئی اشاعت پر صرف بدلے ورژن آئیں۔ تصدیقی درخواست سمیت اصل نیٹ ورک دیکھیں؛ تمام کیش جواب ایک جیسے نہیں۔

کیش بچت کیلکولیٹر اپنے مفروضہ ہٹ ریٹ سے اصل سرور کی درخواستوں میں کمی بتاتا ہے، منتقل بائٹس والا تعداد اور سائز سے حجم نکالتا ہے۔ یہ عوامی ہیڈر اور اصل ہٹ ریٹ ناپنے کا بدل نہیں؛ درست کام کرنے والی اشاعت کے منصوبوں کا موازنہ ہیں۔