Website-এ নতুন banner বসিয়েছেন, কিন্তু নিজের laptop-এ পুরোনোটাই দেখা যাচ্ছে। অন্যদিকে সহকর্মীর phone-এ নতুন ছবি। এমন হলে সঙ্গে সঙ্গে আবার file upload বা design বদলানোর দরকার নেই। আগে বোঝা দরকার পুরোনো copy কোথা থেকে আসছে। Browser cache, website server, CDN এবং application প্রত্যেকে content-এর copy রাখতে পারে। এই guide website owner ও সাধারণ user-কে ধাপে ধাপে সমস্যা আলাদা করতে সাহায্য করবে। উদ্দেশ্য হল প্রয়োজনীয় evidence নিয়ে সঠিক জায়গায় কাজ করা, অকারণে সব browsing data মুছে ফেলা নয়।

একই URL ও একই page state মিলান

প্রথমেই address bar-এর পুরো URL তুলনা করুন। Testing domain আর production domain, www আর non-www, অথবা পুরোনো path আলাদা page দেখাতে পারে। Login করা অবস্থায় dashboard preview দেখছেন, আর অন্যজন public page দেখছেন কি না দেখুন। কোন text বা image বদলানোর কথা তা নির্দিষ্ট করে লিখুন। “Website ঠিক হয়নি” বলার বদলে “হোমের delivery banner-এ আগের date আছে” বললে developer একই বিষয় পরীক্ষা করতে পারবেন। Screenshot-এ সময় এবং URL রাখুন, sensitive data ঢেকে দিন।

Cache কেন থাকে বুঝে নিন

Cache হল আগে পাওয়া response পরে আবার ব্যবহার করার ব্যবস্থা। একই logo প্রতিবার নতুন করে download না করলে bandwidth ও loading time বাঁচে। MDN-এর HTTP caching guide browser-এর private cache এবং shared cache-এর পার্থক্য ব্যাখ্যা করে। তাই cache থাকাই error নয়। সমস্যা হয় যখন update-এর পরে কোন copy কখন বদলাবে তার নিয়ম মেলে না। শুধু visitor-এর computer পরিষ্কার করিয়ে মূল delivery সমস্যা স্থায়ীভাবে ঠিক করা যায় না।

Unsaved কাজ রেখে reload করবেন না

Page-এ form লিখছেন বা admin editor খোলা থাকলে আগে কাজ save করুন। Reload-এর আগে payment submission চলছে কি না দেখুন; loading থেমে আছে বলে payment button বারবার চাপবেন না। প্রথমে সাধারণ reload দিন, তারপর browser-এর documented force reload ব্যবহার করতে পারেন। Windows-এর অনেক desktop browser-এ Ctrl+F5 কাজ করে, তবে keyboard ও browser অনুযায়ী shortcut আলাদা হতে পারে। Force reload নতুন request করতে সাহায্য করে; এটি সব server cache purge হওয়ার guarantee নয়।

অন্য browser দিয়ে একটি controlled comparison

একই public URL অন্য browser বা অন্য device-এ খুলুন। শুধু একটি browser-এ সমস্যা হলে local cache বা extension-এর দিকটি আগে দেখা যায়। সব device-এ পুরোনো result এলে deployment ও shared cache পরীক্ষা বেশি জরুরি। তবে এটি clue, নিশ্চিত diagnosis নয়। Different login, language, location বা network-এ site ভিন্ন response দিতে পারে। একটি comparison note রাখুন: device, browser, login state, URL এবং কোন version দেখা গেল। একসঙ্গে পাঁচটি setting বদলালে কোনটি কাজ করল বোঝা কঠিন।

Cached files আর cookies গুলিয়ে ফেলবেন না

Browser-এর clear-data dialog-এ cached images/files, cookies, history এবং saved passwords আলাদা option হতে পারে। শুধু পুরোনো asset দেখার জন্য সব category নির্বাচন করবেন না। Cookies বা site data মুছলে login session ও কিছু local state হারাতে পারেন। অপ্রকাশিত offline কাজ থাকলে আগে export বা sync নিশ্চিত করুন। নির্দিষ্ট site-এর data clear করার সুযোগ থাকলে scope বুঝে ব্যবহার করুন। কাজ শেষে একই public URL খুলে দেখা পরিবর্তন note করুন; improvement না হলে বারবার একই কাজ না করে পরের স্তরে যান।

Developer কোন evidence দেখবেন

একজন developer browser-এর Network panel-এ HTML ও সংশ্লিষ্ট CSS, JavaScript বা image request আলাদা করে দেখতে পারেন। Response header, asset filename এবং কোন cache থেকে result এসেছে তা diagnosis-এ কাজে লাগে। MDN-এর ব্যাখ্যায় no-cache response সংরক্ষণ নিষিদ্ধ করে না; reuse-এর আগে validation চায়। no-store নতুন response সংরক্ষণ আটকায়, পুরোনো সব copy নিজে মুছে দেয় না। তাই নাম দেখে header পাল্টানো ঠিক নয়। ব্যক্তিগত account response shared cache-এ যাচ্ছে কি না সেটিও security review-এর বিষয়।

Update যাচাইয়ের ছোট checklist

  • Target: public domain, path ও expected পরিবর্তন লিখে রাখুন।
  • Save: unsaved form, draft ও চলতি payment আগে নিরাপদ করুন।
  • Compare: একই URL অন্য browser-এ একই login state-এ দেখুন।
  • Scope: প্রয়োজন ছাড়া cookies, password বা সব site data মুছবেন না।
  • Assets: HTML নতুন হলেও linked image বা stylesheet পুরোনো কি না দেখুন।
  • Server: সঠিক release ও directory-তে file গেছে কি না owner যাচাই করুন।
  • Evidence: একটি করে পরিবর্তন করে result ও সময় লিখুন।

Server, CDN ও offline app layer দেখুন

Hosting cache এবং CDN থাকলে owner-এর অনুমোদিত dashboard দিয়ে প্রয়োজনীয় page বা asset purge করতে হতে পারে। পুরো cache একসঙ্গে purge করলে origin load বাড়তে পারে, তাই narrow scope ভালো। Website-টি offline support দেওয়া app হলে service worker আলাদা cached response দিতে পারে; তখন developer-কে update lifecycle দেখতে হবে। Visitor-কে অজানা script console-এ paste করতে বলবেন না। Developer handoff-এ account password বা পুরো network export পাঠানোর বদলে প্রয়োজনীয় redacted evidence দিন।

পরের update-এর জন্য predictable delivery

স্থায়ী সমাধানে পরিবর্তিত static asset-এর versioned filename এবং HTML-এর উপযুক্ত cache policy কাজে আসতে পারে। এগুলো developer-এর release workflow-এর অংশ; প্রতিবার random query যোগ করে symptom চাপা দেওয়ার বিকল্প নয়। নতুন image দেখা গেলেও menu, form ও mobile layout একবার পরীক্ষা করুন। শেষে আগের failing device-এও public page মিলান। তখনই বলা যায় এই update দেখা যাচ্ছে। একটি সফল reload দিয়ে পুরো website-এর cache configuration ঠিক বলে ঘোষণা করবেন না।