প্রিক্যাচিং করণীয় এবং না করা৷

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

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

করবেন: সমালোচনামূলক স্ট্যাটিক সম্পদগুলিকে প্রিক্যাচ করুন

প্রিক্যাচিংয়ের জন্য সেরা প্রার্থীগুলি হল সমালোচনামূলক স্ট্যাটিক সম্পদ, কিন্তু "সমালোচনামূলক" সম্পদ হিসাবে কী গণনা করা হয়? একটি বিকাশকারীর দৃষ্টিকোণ থেকে, এটি একটি সম্পূর্ণ অ্যাপ্লিকেশনটিকে "সমালোচনামূলক" হিসাবে ভাবতে প্রলুব্ধ হতে পারে, তবে ব্যবহারকারীর দৃষ্টিকোণটি সবচেয়ে গুরুত্বপূর্ণ। একটি ব্যবহারকারীর অভিজ্ঞতা প্রদানের জন্য অত্যন্ত প্রয়োজনীয় হিসাবে সমালোচনামূলক সম্পদগুলিকে ভাবুন:

• গ্লোবাল স্টাইলশীট।
• জাভাস্ক্রিপ্ট ফাইল যা বিশ্বব্যাপী কার্যকারিতা প্রদান করে।
• অ্যাপ্লিকেশন শেল HTML, যদি এটি আপনার আর্কিটেকচারে প্রযোজ্য হয়।

অনুস্মারক: এগুলি সাধারণ নির্দেশিকা, কঠিন সুপারিশ নয়। অ্যাসেট প্রিক্যাচ করার সময়, বেশি না করে কম প্রিক্যাচিংয়ের পক্ষে ভুল করাই ভালো।

করুন: মাল্টিপেজ ওয়েবসাইটের জন্য একটি অফলাইন ফলব্যাক প্রিক্যাচ করুন

সাধারণ মাল্টিপেজ ওয়েবসাইটগুলির জন্য, আপনি নেভিগেশন অনুরোধগুলি মোকাবেলা করার জন্য একটি নেটওয়ার্ক-প্রথম বা নেটওয়ার্ক-শুধুমাত্র ক্যাশিং কৌশলের উপর নির্ভর করতে পারেন।

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

import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';

navigationPreload.enable();

// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);

// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
  return request.mode === 'navigate';
}, new NetworkOnly({
  plugins: [
    new PrecacheFallbackPlugin({
      fallbackURL: '/offline.html'
    })
  ]
}));

registerRoute(networkOnlyNavigationRoute);

এটি নিশ্চিত করে যে যদি একজন ব্যবহারকারী অফলাইনে যান এবং একটি পৃষ্ঠায় নেভিগেট করেন যা তাদের ক্যাশে নেই, তারা অন্তত কিছু অফলাইন সামগ্রী পাবেন৷

হতে পারে: অনুমানমূলক প্রচার বিবেচনা করুন

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

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

হয়তো করবেন না: precache স্ট্যাটিক HTML

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

একটি সম্পূর্ণ সাইটের মূল্যের এইচটিএমএল ফাইলগুলিকে প্রিক্যাচ করার ক্ষেত্রে একটি সমস্যা হল যে মার্কআপটি যেটি এখন প্রিক্যাচ করা হয় তা সর্বদা পরে ক্যাশে থেকে পরিষেবা কর্মী আপডেট না হওয়া পর্যন্ত পরিবেশন করা হবে৷ এটি পারফরম্যান্সের জন্য দুর্দান্ত, তবে আপনার ওয়েবসাইটের এইচটিএমএল ঘন ঘন পরিবর্তন হলে এটি উল্লেখযোগ্য ক্যাশে মন্থন করতে পারে।

যদিও এই নিয়মের কয়েকটি ব্যতিক্রম আছে। আপনি যদি কয়েকটি স্ট্যাটিক এইচটিএমএল ফাইল সহ একটি ছোট ওয়েবসাইট স্থাপন করেন, তবে সম্ভবত সেই সমস্ত পৃষ্ঠাগুলিকে প্রিক্যাচ করা ভাল যাতে সেগুলি অফলাইনে পাওয়া যায়। আপনার যদি একটি বিশেষ করে বড় ওয়েবসাইট থাকে, তাহলে অনুমানমূলকভাবে কয়েকটি উচ্চ মূল্যের পৃষ্ঠা এবং একটি অফলাইন ফলব্যাক প্রিক্যাচ করার কথা বিবেচনা করুন এবং আপনার জন্য অন্যান্য পৃষ্ঠাগুলি ক্যাশে করার জন্য রানটাইম ক্যাশিংয়ের উপর নির্ভর করুন।

করবেন না: প্রতিক্রিয়াশীল ছবি বা ফেভিকন প্রিক্যাচ করুন

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

ফেভিকনগুলি একটি অনুরূপ পরিস্থিতি উপস্থাপন করে, এতে ওয়েবসাইটগুলি প্রায়শই বিভিন্ন পরিস্থিতির জন্য ফ্যাভিকনের একটি সম্পূর্ণ সেট স্থাপন করে। প্রায়শই, শুধুমাত্র একটি ফেভিকন অনুরোধ করা হয়, যার ফলে একটি সম্পূর্ণ ফেভিকন সেটের প্রিক্যাচিং একইভাবে অপচয় হয়।

আপনার ব্যবহারকারীদের একটি উপকার করুন এবং প্রতিক্রিয়াশীল ইমেজ এবং ফেভিকন সেট precache না. পরিবর্তে রানটাইম ক্যাশে নির্ভর করুন। আপনি যদি ইমেজগুলিকে প্রিক্যাচ করতেই হবে , তাহলে ব্যাপকভাবে ব্যবহৃত ছবিগুলিকে প্রিক্যাচ করুন যেগুলি প্রতিক্রিয়াশীল ছবি বা ফেভিকনগুলির একটি সেটের অংশ নয়৷ এসভিজি ডেটা ব্যবহারের ক্ষেত্রে কম ঝুঁকিপূর্ণ, একটি প্রদত্ত স্ক্রিনের পিক্সেল ঘনত্ব নির্বিশেষে একটি একক এসভিজি সর্বোত্তমভাবে রেন্ডার করে।

করবেন না: precache polyfills

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

যেহেতু শর্তসাপেক্ষে পলিফিল লোড করা বর্তমান পরিবেশের সাথে সাপেক্ষে রানটাইমের সময় ঘটে, তাই পলিফিলগুলি প্রিক্যাচ করা একটি জুয়া। কিছু ব্যবহারকারী এটি থেকে উপকৃত হবে, অন্যরা অপ্রয়োজনীয় পলিফিলের জন্য ব্যান্ডউইথ নষ্ট করবে।

Polyfills precache করবেন না. রানটাইম ক্যাশিং-এর উপর নির্ভর করুন যাতে নিশ্চিত করা যায় যে সেগুলি কেবলমাত্র সেই ব্রাউজারগুলিতেই ক্যাশে করা হয়েছে যাতে ডেটা নষ্ট করা এড়াতে হয়।

উপসংহার

প্রিক্যাচিংয়ের জন্য আপনার ব্যবহারকারীদের প্রকৃতপক্ষে সময়ের আগে কী সম্পদ প্রয়োজন সে সম্পর্কে কিছু পূর্বচিন্তা প্রয়োজন, তবে আপনি অবশ্যই এটি এমনভাবে সঠিকভাবে পেতে পারেন যা ভবিষ্যতের কর্মক্ষমতা এবং নির্ভরযোগ্যতাকে অগ্রাধিকার দেয়।

আপনি যদি নির্দিষ্ট সম্পদগুলি প্রিক্যাচ করা উচিত কিনা সে সম্পর্কে নিশ্চিত না হন, তাহলে আপনার সেরা বাজি হতে পারে ওয়ার্কবক্সকে সেই সম্পদগুলি বাদ দিতে এবং সেগুলি পরিচালনা করার জন্য একটি রানটাইম ক্যাশিং রুট তৈরি করতে বলা৷ যেভাবেই হোক, এই ডকুমেন্টেশনে পরবর্তীতে প্রিক্যাচিং বিস্তারিতভাবে কভার করা হয়েছে , তাই আপনি ভবিষ্যতে এই নীতিগুলি আপনার প্রিক্যাচিং যুক্তিতে প্রয়োগ করতে সক্ষম হবেন।