আপনার ক্যাশে ভালবাসা ❤️

আপনার সাইটটি দ্বিতীয়বার লোড করা ব্যবহারকারীরা তাদের HTTP ক্যাশে ব্যবহার করবে, তাই নিশ্চিত করুন যে এটি ভালভাবে কাজ করে।

Sam Thorogood

এই পোস্টটি ক্রোম ডেভ সামিট 2020-এ এক্সটেন্ডেড কন্টেন্টের অংশ, লাভ ইউর ক্যাশে ভিডিওর একটি সঙ্গী। ভিডিওটি দেখতে ভুলবেন না:

যখন ব্যবহারকারীরা আপনার সাইটটি দ্বিতীয়বার লোড করে, তখন তাদের ব্রাউজারটি দ্রুত লোড করতে সহায়তা করার জন্য তার HTTP ক্যাশের মধ্যে সংস্থান ব্যবহার করবে। কিন্তু ওয়েবে ক্যাশ করার জন্য মানগুলি 1999 সালের তারিখের, এবং সেগুলিকে বেশ বিস্তৃতভাবে সংজ্ঞায়িত করা হয়েছে - CSS বা একটি চিত্রের মতো একটি ফাইল আবার নেটওয়ার্ক থেকে আনা হতে পারে বনাম আপনার ক্যাশে থেকে লোড করা কিছুটা অযৌক্তিক। বিজ্ঞান

এই পোস্টে, আমি ক্যাশে করার জন্য একটি বুদ্ধিমান, আধুনিক ডিফল্টের মাধ্যমে কথা বলব—যা আসলে কোনো ক্যাশিং করে না । তবে এটি কেবলমাত্র ডিফল্ট, এবং এটি অবশ্যই "এটি বন্ধ করার" চেয়ে আরও সূক্ষ্ম। পড়ুন!

দ্রষ্টব্য: আপনার সাইট তৈরি করার সময় কিছু মনে রাখতে হবে যে কোর ওয়েব ভাইটালগুলির মতো পারফরম্যান্স মেট্রিক্সে সমস্ত লোড অন্তর্ভুক্ত থাকে, শুধুমাত্র ১ম লোড নয়। তবুও, Google-এর অনেক নির্দেশিকা প্রথম লোডকে অপ্টিমাইজ করার উপর ফোকাস করে (যা ব্যবহারকারীদের আনার জন্য অবশ্যই গুরুত্বপূর্ণ!), এবং Lighthouse শুধুমাত্র একটি খালি ক্যাশে আপনার সাইট পরীক্ষা করে।

গোল

যখন একটি সাইট ২য় বার লোড হয়, তখন আপনার দুটি লক্ষ্য থাকে:

1. নিশ্চিত করুন যে আপনার ব্যবহারকারীরা সবথেকে আপ-টু-ডেট সংস্করণ উপলব্ধ রয়েছে—যদি আপনি কিছু পরিবর্তন করে থাকেন তবে তা দ্রুত প্রতিফলিত হওয়া উচিত
2. নেটওয়ার্ক থেকে যতটা সম্ভব কম আনার সময় #1 করুন

বিস্তৃত অর্থে, আপনি যখন আপনার ক্লায়েন্টরা আবার আপনার সাইট লোড করবেন তখনই আপনি তাদের কাছে ক্ষুদ্রতম পরিবর্তন পাঠাতে চান। এবং যেকোনো পরিবর্তনের সবচেয়ে দক্ষ বিতরণ নিশ্চিত করার জন্য আপনার সাইটের কাঠামো তৈরি করা চ্যালেঞ্জিং (নীচে এবং ভিডিওতে সে সম্পর্কে আরও)।

এটি বলার পরে, আপনি যখন ক্যাশে করার কথা বিবেচনা করেন তখন আপনার কাছে অন্যান্য নবও থাকে—সম্ভবত আপনি একটি ব্যবহারকারীর ব্রাউজার HTTP ক্যাশে আপনার সাইটে দীর্ঘ সময়ের জন্য ধরে রাখার সিদ্ধান্ত নিয়েছেন যাতে এটি পরিবেশন করার জন্য কোনও নেটওয়ার্ক অনুরোধের প্রয়োজন না হয়। অথবা আপনি একটি পরিষেবা কর্মী তৈরি করেছেন যা একটি সাইট আপ-টু-ডেট কিনা তা পরীক্ষা করার আগে সম্পূর্ণ অফলাইনে পরিবেশন করবে। এটি একটি চরম বিকল্প, যা বৈধ—এবং অনেক অফলাইন-প্রথম অ্যাপ-এর মতো ওয়েব অভিজ্ঞতার জন্য ব্যবহার করা হয়—কিন্তু ওয়েবকে ক্যাশে-অনলি এক্সট্রিম, এমনকি সম্পূর্ণ নেটওয়ার্ক-অনলি এক্সট্রিম হতে হবে না।

পটভূমি

ওয়েব ডেভেলপার হিসাবে, আমরা সবাই একটি "বাসি ক্যাশে" থাকার ধারণায় অভ্যস্ত। কিন্তু আমরা জানি, প্রায় সহজাতভাবে, এটি সমাধান করার জন্য উপলব্ধ সরঞ্জামগুলি: একটি "হার্ড রিফ্রেশ" করুন, বা একটি ছদ্মবেশী উইন্ডো খুলুন, বা একটি সাইটের ডেটা সাফ করতে আপনার ব্রাউজারের বিকাশকারী সরঞ্জামগুলির কিছু সংমিশ্রণ ব্যবহার করুন৷

ইন্টারনেটে নিয়মিত ব্যবহারকারীদের একই বিলাসিতা নেই। তাই যখন আমাদের ব্যবহারকারীদের তাদের ২য় লোডের সাথে একটি দুর্দান্ত সময় আছে তা নিশ্চিত করার কিছু মূল লক্ষ্য রয়েছে, তাদের সময় খারাপ না হয় বা আটকে না যায় তা নিশ্চিত করাও সত্যিই গুরুত্বপূর্ণ। (আমরা কীভাবে web.dev/live সাইট আটকে গেছি সে সম্পর্কে আপনি যদি আমাকে কথা বলতে চান তবে ভিডিওটি দেখুন!)

কিছুটা ব্যাকগ্রাউন্ডের জন্য, "বাসি ক্যাশে" এর একটি সত্যই সাধারণ কারণ হল ক্যাশিংয়ের জন্য 1999-যুগের ডিফল্ট। এটি Last-Modified হেডারের উপর নির্ভর করে:

বিভিন্ন সময়ে (ধূসর রঙে) উত্পন্ন সম্পদগুলি বিভিন্ন সময়ের জন্য ক্যাশে করা হবে, তাই একটি 2য় লোড ক্যাশে করা এবং তাজা সম্পদের সংমিশ্রণ পেতে পারে

আপনার লোড করা প্রতিটি ফাইল তার বর্তমান জীবনকালের অতিরিক্ত 10% জন্য রাখা হয়, যেমন আপনার ব্রাউজার এটি দেখে। উদাহরণস্বরূপ, যদি index.html এক মাস আগে তৈরি করা হয়, তাহলে এটি আপনার ব্রাউজার দ্বারা আরও তিন দিনের জন্য ক্যাশে করা হবে।

এটি আগের দিনের একটি সুচিন্তিত ধারণা ছিল, কিন্তু আজকের ওয়েবসাইটগুলির দৃঢ়ভাবে সমন্বিত প্রকৃতির পরিপ্রেক্ষিতে এই ডিফল্ট আচরণের অর্থ হল এমন একটি অবস্থায় যাওয়া সম্ভব যেখানে ব্যবহারকারীর আপনার ওয়েবসাইটের বিভিন্ন রিলিজের জন্য ডিজাইন করা ফাইল রয়েছে (যেমন, JS থেকে মঙ্গলবারের রিলিজ, এবং শুক্রবারের রিলিজ থেকে CSS), কারণ এই ফাইলগুলি ঠিক একই সময়ে আপডেট করা হয়নি।

আলোকিত পথ

ক্যাশিং-এর জন্য একটি আধুনিক ডিফল্ট হল আসলে কোনো ক্যাশিং না করা এবং আপনার বিষয়বস্তুকে আপনার ব্যবহারকারীদের কাছাকাছি আনতে CDN ব্যবহার করা। প্রতিবার একজন ব্যবহারকারী আপনার সাইট লোড করলে, তারা নেটওয়ার্কে গিয়ে দেখতে পাবে যে এটি আপ-টু-ডেট কিনা। এই অনুরোধটির বিলম্ব কম হবে, কারণ এটি প্রতিটি শেষ ব্যবহারকারীর কাছে ভৌগলিকভাবে একটি CDN দ্বারা সরবরাহ করা হবে।

আপনি এই শিরোনাম দিয়ে ওয়েব অনুরোধের প্রতিক্রিয়া জানাতে আপনার ওয়েব হোস্ট কনফিগার করতে পারেন:

Cache-Control: max-age=0,must-revalidate,public

এটি মূলত বলে; ফাইলটি কোনো সময়ের জন্য বৈধ নয়, এবং আপনি এটিকে আবার ব্যবহার করার আগে আপনাকে অবশ্যই এটিকে নেটওয়ার্ক থেকে যাচাই করতে হবে (অন্যথায় এটি শুধুমাত্র "প্রস্তাবিত")।

দ্রষ্টব্য: max-age=0,must-revalidate এর পরিবর্তে, আপনি no-cache নির্দিষ্ট করতে পারেন: এটি সমতুল্য। যাইহোক, no-cache একটি বিভ্রান্তিকর নাম, কারণ এটিকে "এই ফাইলটি কখনই ক্যাশে করবেন না" হিসাবে ব্যাখ্যা করা যেতে পারে - যদিও এটি এমন নয়। কিছু ভারী পড়ার জন্য, MDN-এ ক্যাশে-কন্ট্রোল দেখুন।

বাইটের স্থানান্তরের ক্ষেত্রে এই বৈধতা প্রক্রিয়া তুলনামূলকভাবে সস্তা—যদি একটি বড় ইমেজ ফাইল পরিবর্তিত না হয়, তাহলে আপনার ব্রাউজার একটি ছোট 304 প্রতিক্রিয়া পাবে—কিন্তু এটির জন্য লেটেন্সি খরচ হয় কারণ ব্যবহারকারীকে এখনও নেটওয়ার্কে যেতে হবে। এবং এটি এই পদ্ধতির প্রাথমিক খারাপ দিক। এটি প্রথম বিশ্বে দ্রুত সংযোগে থাকা লোকেদের জন্য সত্যিই ভাল কাজ করতে পারে এবং যেখানে আপনার পছন্দের CDN-এর দুর্দান্ত কভারেজ রয়েছে, তবে সেই লোকেদের জন্য নয় যারা ধীরগতির মোবাইল সংযোগে বা দুর্বল অবকাঠামো ব্যবহার করছেন৷

যাই হোক না কেন, এটি একটি আধুনিক পদ্ধতি যা একটি জনপ্রিয় CDN, Netlify-এ ডিফল্ট , কিন্তু প্রায় যেকোনো CDN-এ কনফিগার করা যেতে পারে। Firebase হোস্টিংয়ের জন্য, আপনি এই শিরোনামটি আপনার firebase.json ফাইলের হোস্টিং বিভাগে অন্তর্ভুক্ত করতে পারেন:

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

তাই যখন আমি এখনও এটিকে একটি বুদ্ধিমান ডিফল্ট হিসাবে সাজেস্ট করছি, এটি শুধুমাত্র এটিই-ডিফল্ট! কিভাবে ধাপে ধাপে প্রবেশ করতে হয় এবং ডিফল্ট আপগ্রেড করতে হয় তা জানতে পড়ুন।

আঙুলের ছাপযুক্ত URL

আপনার সাইটে পরিবেশিত সম্পদ, ছবি ইত্যাদির নামে ফাইলের বিষয়বস্তুর একটি হ্যাশ অন্তর্ভুক্ত করে, আপনি নিশ্চিত করতে পারেন যে এই ফাইলগুলিতে সর্বদা অনন্য সামগ্রী থাকবে—এর ফলে উদাহরণ স্বরূপ sitecode.af12de.js নামে ফাইলগুলি আসবে৷ যখন আপনার সার্ভার এই ফাইলগুলির জন্য অনুরোধে সাড়া দেয়, তখন আপনি নিরাপদে আপনার শেষ-ব্যবহারকারীর ব্রাউজারগুলিকে এই শিরোনামটির সাথে কনফিগার করে দীর্ঘ সময়ের জন্য ক্যাশে করার নির্দেশ দিতে পারেন:

Cache-Control: max-age=31536000,immutable

এই মান এক বছর, সেকেন্ডে। এবং স্পেস অনুযায়ী, এটি কার্যকরভাবে "চিরকাল" এর সমান।

গুরুত্বপূর্ণভাবে, এই হ্যাশগুলি হাতে তৈরি করবেন না—এটি খুব বেশি ম্যানুয়াল কাজ! আপনি এই বিষয়ে সাহায্য করার জন্য Webpack, Rollup ইত্যাদির মত টুল ব্যবহার করতে পারেন। টুলিং রিপোর্টে তাদের সম্পর্কে আরও পড়তে ভুলবেন না।

মনে রাখবেন যে এটি শুধুমাত্র জাভাস্ক্রিপ্ট নয় যা আঙ্গুলের ছাপযুক্ত URL থেকে উপকৃত হতে পারে; আইকন, সিএসএস এবং অন্যান্য অপরিবর্তনীয় ডেটা ফাইলের মতো সম্পদেরও এইভাবে নামকরণ করা যেতে পারে। (এবং কোড বিভাজন সম্পর্কে আরও কিছু জানতে উপরের ভিডিওটি দেখতে ভুলবেন না, যা আপনার সাইট পরিবর্তন করার সময় আপনাকে কম কোড পাঠাতে দেয়।)

দ্রষ্টব্য: আমরা উপরের Cache-Control সুপারিশে immutable কীওয়ার্ড অন্তর্ভুক্ত করি। এই কীওয়ার্ড ছাড়া, আমাদের দীর্ঘ Cache-Control শুধুমাত্র একটি পরামর্শ হিসাবে বিবেচিত হয়, এবং কিছু ব্রাউজার এখনও এটি উপেক্ষা করবে এবং সার্ভারে যাবে। (2017 সালে, ক্রোম তার আচরণ পরিবর্তন করেছে , তাই এটি সর্বদা এমনভাবে কাজ করে যেন অপরিবর্তনীয় কীওয়ার্ডটি যেভাবেই হোক-তাই এখনই, এটি শুধুমাত্র Safari এবং Firefox-এর জন্য প্রয়োজন)।

আপনার সাইট ক্যাশিং-এর কাছে যেভাবেই আসুক না কেন, এই ধরনের আঙ্গুলের ছাপযুক্ত ফাইলগুলি আপনার তৈরি করা যেকোন সাইটের জন্য অবিশ্বাস্যভাবে মূল্যবান। বেশিরভাগ সাইট প্রতি প্রকাশে পরিবর্তন হয় না।

অবশ্যই, আমরা আমাদের 'বন্ধুত্বপূর্ণ', ব্যবহারকারী-মুখী পৃষ্ঠাগুলির এইভাবে নাম পরিবর্তন করতে পারি না: আপনার index.html ফাইলের নাম পরিবর্তন করে index.abcd12.html -এটা অসম্ভাব্য, আপনি ব্যবহারকারীদের প্রতিবার একটি নতুন URL-এ যেতে বলতে পারবেন না তারা আপনার সাইট লোড! এই 'বন্ধুত্বপূর্ণ' ইউআরএলগুলিকে এইভাবে পুনঃনামকরণ এবং ক্যাশে করা যাবে না, যা আমাকে একটি সম্ভাব্য মধ্যবর্তী স্থানে নিয়ে যায়।

মাঝখানের মাটি

ক্যাশিংয়ের ক্ষেত্রে একটি মধ্যম স্থলের জন্য স্পষ্টতই জায়গা রয়েছে। আমি দুটি চরম বিকল্প উপস্থাপন করেছি; ক্যাশে কখনও বা ক্যাশে চিরতরে । এবং অনেকগুলি ফাইল থাকবে যা আপনি কিছু সময়ের জন্য ক্যাশে করতে চান, যেমন "বন্ধুত্বপূর্ণ" ইউআরএলগুলি আমি উপরে উল্লেখ করেছি।

আপনি যদি এই "বন্ধুত্বপূর্ণ" ইউআরএল এবং তাদের এইচটিএমএল ক্যাশে করতে চান, তাহলে এগুলি কী নির্ভরতা অন্তর্ভুক্ত করে, কীভাবে সেগুলি ক্যাশে করা যেতে পারে এবং একটি সময়ের জন্য তাদের ইউআরএলগুলি কীভাবে ক্যাশ করা আপনাকে প্রভাবিত করতে পারে তা বিবেচনা করা মূল্যবান৷ আসুন একটি এইচটিএমএল পৃষ্ঠা দেখি যা এইরকম একটি চিত্র অন্তর্ভুক্ত করে:

<img src="/images/foo.jpeg" loading="lazy" />

আপনি যদি এই অলস-লোড করা চিত্রটি মুছে বা পরিবর্তন করে আপনার সাইট আপডেট বা পরিবর্তন করেন, যে ব্যবহারকারীরা আপনার HTML এর একটি ক্যাশ করা সংস্করণ দেখেন তারা একটি ভুল বা অনুপস্থিত চিত্র পেতে পারেন—কারণ তারা এখনও আসল /images/foo.jpeg ক্যাশে করে থাকে যখন তারা আপনার সাইটে পুনরায় যান।

আপনি যদি সতর্ক থাকেন তবে এটি আপনাকে প্রভাবিত করতে পারে না। কিন্তু বিস্তৃতভাবে এটা মনে রাখা গুরুত্বপূর্ণ যে আপনার সাইটটি—যখন আপনার শেষ ব্যবহারকারীদের দ্বারা ক্যাশে করা হয়—আর কেবলমাত্র আপনার সার্ভারে বিদ্যমান থাকে না। বরং, এটি আপনার শেষ ব্যবহারকারীর ব্রাউজারগুলির ক্যাশের ভিতরে টুকরো টুকরো হয়ে থাকতে পারে।

সাধারণভাবে, ক্যাশিং-এ বেশিরভাগ গাইড এই ধরনের সেটিং সম্পর্কে কথা বলবে—আপনি কি এক ঘণ্টা, কয়েক ঘণ্টা ইত্যাদি ক্যাশে করতে চান। এই ধরনের ক্যাশে সেট আপ করতে, এইরকম একটি হেডার ব্যবহার করুন (যা 3600 সেকেন্ড বা এক ঘন্টার জন্য ক্যাশে করে):

Cache-Control: max-age=3600,immutable,public

একটি শেষ বিন্দু. আপনি যদি সময়োপযোগী বিষয়বস্তু তৈরি করেন যা সাধারণত ব্যবহারকারীদের দ্বারা শুধুমাত্র একবার অ্যাক্সেস করা যেতে পারে—যেমন সংবাদ নিবন্ধ!—আমার মতামত হল যে এগুলি কখনই ক্যাশে করা উচিত নয়, এবং আপনার উপরে আমাদের সংবেদনশীল ডিফল্ট ব্যবহার করা উচিত। আমি মনে করি আমরা প্রায়শই একজন ব্যবহারকারীর সর্বদা সর্বশেষ এবং সর্বশ্রেষ্ঠ বিষয়বস্তু যেমন একটি সংবাদ গল্প বা বর্তমান ইভেন্টে একটি সমালোচনামূলক আপডেট দেখার আকাঙ্ক্ষার চেয়ে ক্যাশিংয়ের মূল্যকে অত্যধিক মূল্যায়ন করি।

অ-এইচটিএমএল বিকল্প

এইচটিএমএল ছাড়াও, মাঝখানে থাকা ফাইলগুলির জন্য কিছু অন্যান্য বিকল্পের মধ্যে রয়েছে:

• সাধারণভাবে, এমন সম্পদের সন্ধান করুন যা অন্যদের প্রভাবিত করে না

  • উদাহরণস্বরূপ: CSS এড়িয়ে চলুন, কারণ এটি আপনার HTML রেন্ডার করার পদ্ধতিতে পরিবর্তন ঘটায়

• সময়োপযোগী নিবন্ধের অংশ হিসেবে ব্যবহৃত বড় ছবি

  • আপনার ব্যবহারকারীরা সম্ভবত একটি মুষ্টিমেয় বারের বেশি কোনো একক নিবন্ধ দেখতে যাচ্ছেন না, তাই ফটো বা নায়কের ছবিগুলিকে চিরতরে ক্যাশে করবেন না এবং স্টোরেজ নষ্ট করবেন না

• একটি সম্পদ যা এমন কিছুর প্রতিনিধিত্ব করে যা নিজের জীবনকাল রয়েছে

  • আবহাওয়া সম্পর্কে JSON ডেটা শুধুমাত্র প্রতি ঘন্টায় প্রকাশিত হতে পারে, যাতে আপনি এক ঘন্টার জন্য পূর্ববর্তী ফলাফল ক্যাশে করতে পারেন-এটি আপনার উইন্ডোতে পরিবর্তন হবে না
  • একটি ওপেন-সোর্স প্রকল্পের বিল্ডগুলি রেট-সীমিত হতে পারে, তাই স্ট্যাটাস পরিবর্তন হতে পারে এমন সম্ভাবনা না হওয়া পর্যন্ত একটি বিল্ড স্ট্যাটাস ইমেজ ক্যাশে করুন

সারাংশ

যখন ব্যবহারকারীরা আপনার সাইটটি দ্বিতীয়বার লোড করে, তখন আপনি ইতিমধ্যেই আস্থার ভোট পেয়েছেন—তারা ফিরে আসতে চায় এবং আপনি যা অফার করছেন তার থেকে আরও বেশি কিছু পেতে চান। এই মুহুর্তে, এটি সর্বদা কেবল সেই লোডের সময়কে কমিয়ে আনার জন্য নয়, এবং আপনার ব্রাউজারটি দ্রুত এবং একটি আপ-টু-ডেট উভয় অভিজ্ঞতা প্রদানের জন্য প্রয়োজনীয় কাজটি করে তা নিশ্চিত করার জন্য আপনার কাছে অনেকগুলি বিকল্প উপলব্ধ রয়েছে।

ক্যাশিং ওয়েবে একটি নতুন ধারণা নয়, তবে সম্ভবত এটির একটি বুদ্ধিমান ডিফল্ট প্রয়োজন—একটি ব্যবহার করার কথা বিবেচনা করুন এবং আপনার যখন প্রয়োজন তখন আরও ভাল ক্যাশিং কৌশলগুলির জন্য দৃঢ়ভাবে অপ্ট-ইন করুন৷ পড়ার জন্য ধন্যবাদ!

এছাড়াও দেখুন

HTTP ক্যাশে একটি সাধারণ গাইডের জন্য, HTTP ক্যাশে দিয়ে অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধ প্রতিরোধ করুন চেক আউট করুন।