আরও জটিল সাইটের জন্য অনুমান বিধি বাস্তবায়নের নির্দেশিকা, আরও জটিল সাইটের জন্য অনুমান বিধি বাস্তবায়নের নির্দেশিকা

Barry Pollard

প্রকাশিত: ৭ মার্চ, ২০২৫, সর্বশেষ আপডেট: ২৩ অক্টোবর, ২০২৫

স্পেকুলেশন রুলস এপিআই ব্যবহারকারীদের ভবিষ্যতের পৃষ্ঠা নেভিগেশনগুলিকে প্রিফেচিং বা প্রিরেন্ডার করে দ্রুত - এমনকি তাৎক্ষণিক - পৃষ্ঠা নেভিগেশন প্রদানের মাধ্যমে কর্মক্ষমতা বৃদ্ধির সুবিধা প্রদান করে।

এপিআইটি বিশেষভাবে বাস্তবায়নের সহজতার কথা মাথায় রেখে তৈরি করা হয়েছে, তবে কিছু বিবেচ্য বিষয় রয়েছে যা বিশেষ করে জটিল সাইটগুলিকে এটি ব্যবহারের আগে বিবেচনা করা উচিত। এই নির্দেশিকা সাইট মালিকদের এই বিবেচ্য বিষয়গুলি বুঝতে সাহায্য করে।

পরিকল্পনা

অনুমানের নিয়ম বাস্তবায়নের আগে, API কীভাবে বাস্তবায়ন করা যায় (কারণ কয়েকটি বিকল্প আছে), এবং অনুমানের খরচ (যা আপনাকে কোন পৃষ্ঠাগুলি অনুমান করতে হবে সে সম্পর্কে নির্দেশনা দেবে) বিবেচনা করা মূল্যবান।

অনুমান সংক্রান্ত নিয়ম কীভাবে বাস্তবায়ন করবেন তা নির্ধারণ করুন

আপনার সাইটে অনুমান সংক্রান্ত নিয়মগুলি কীভাবে বাস্তবায়ন করবেন তা প্রথমেই আপনাকে যে সিদ্ধান্ত নিতে হবে তা হল, কারণ আপনি বিভিন্ন পদ্ধতি ব্যবহার করতে পারেন:

• সরাসরি পৃষ্ঠার HTML-এ
• জাভাস্ক্রিপ্ট ব্যবহার করা
• HTTP হেডার ব্যবহার করা

পরিশেষে, প্রতিটি পদ্ধতির একই প্রভাব রয়েছে, তবে বাস্তবায়নের সহজতা এবং নমনীয়তার দিক থেকে সুবিধা থাকতে পারে।

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

পৃষ্ঠার HTML-এ সরাসরি অনুমানের নিয়ম অন্তর্ভুক্ত করুন।

<script type="speculationrules"> উপাদানটি HTML-এ অন্তর্ভুক্ত করে স্পেকুলেশন রুলস সরাসরি পৃষ্ঠায় প্রয়োগ করা যেতে পারে। টেমপ্লেট ব্যবহার করে স্ট্যাটিক সাইটগুলির জন্য বিল্ড টাইমে এটি যোগ করা যেতে পারে, অথবা পৃষ্ঠাটি অনুরোধ করা হলে সার্ভার দ্বারা রান টাইমে এটি যোগ করা যেতে পারে। এমনকি এজ কর্মীদের দ্বারা এগুলি HTML-এ ইনজেক্ট করা যেতে পারে (যদিও এই নির্দেশিকায় পরে আলোচনা করা HTTP হেডার পদ্ধতি সম্ভবত এর জন্য সহজ)।

এটি আপনাকে পুরো সাইট জুড়ে স্ট্যাটিক নিয়ম অন্তর্ভুক্ত করতে দেয়, তবে ডকুমেন্ট নিয়মগুলি এখনও গতিশীল হতে পারে কারণ এটি আপনাকে CSS ক্লাস দ্বারা ট্রিগার করা নিয়মগুলি ব্যবহার করে পৃষ্ঠা থেকে রেন্ডার করার জন্য URL গুলি বেছে নেওয়ার অনুমতি দেয়:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "selector_matches": ".prerender" }
    }],
    "prefetch": [{
      "where": { "selector_matches": ".prefetch" }
    }]
  }
</script>

পূর্ববর্তী স্ক্রিপ্টটি একটি prerender ক্লাসের সাথে লিঙ্কগুলিকে প্রিরেন্ডার করবে, এবং একইভাবে যখন একটি লিঙ্কে একটি prefetch ক্লাস থাকবে তখন প্রিফেচ করবে। এটি ডেভেলপারদের জল্পনা-কল্পনা শুরু করার জন্য HTML-এ এই ক্লাসগুলি অন্তর্ভুক্ত করতে দেয়।

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

বিকল্পভাবে, যদি আপনার আরও নির্দিষ্ট অনুমানের নিয়ম ব্যবহার করার প্রয়োজন হয়, তাহলে পৃষ্ঠা-নির্দিষ্ট বা টেমপ্লেট-নির্দিষ্ট নিয়মগুলি নির্দিষ্ট পৃষ্ঠা বা পৃষ্ঠার ধরণের জন্য বিভিন্ন নিয়মের অনুমতি দিতে পারে।

পরিশেষে, সার্ভার-সাইড রেন্ডার করা পৃষ্ঠাগুলিতে সার্ভারে উপলব্ধ তথ্যের উপর ভিত্তি করে আরও গতিশীল নিয়ম থাকতে পারে—যেমন সেই পৃষ্ঠার বিশ্লেষণ তথ্য বা নির্দিষ্ট পৃষ্ঠাগুলির জন্য সাধারণ ব্যবহারকারীর ভ্রমণ।

জাভাস্ক্রিপ্ট ব্যবহার করে অনুমানের নিয়ম যোগ করুন

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

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

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

HTTP হেডার ব্যবহার করে অনুমানের নিয়ম যোগ করুন

ডেভেলপারদের জন্য চূড়ান্ত বিকল্প হল HTTP হেডার ব্যবহার করে নিয়মগুলি অন্তর্ভুক্ত করা:

Speculation-Rules: "/speculationrules.json"

নিয়ম রিসোর্স (এই উদাহরণে /speculationrules.json ) কীভাবে সরবরাহ এবং ব্যবহার করা হয় তার জন্য কিছু অতিরিক্ত প্রয়োজনীয়তা রয়েছে।

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

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

খরচের প্রভাব বিবেচনা করুন

অনুমান সংক্রান্ত নিয়ম বাস্তবায়নের আগে, এই API ব্যবহার করে আপনার ব্যবহারকারী এবং আপনার সাইট উভয়ের জন্য খরচের প্রভাব বিবেচনা করার জন্য একটু সময় নেওয়া উচিত। খরচের মধ্যে রয়েছে ব্যান্ডউইথ (ব্যবহারকারী এবং সাইট উভয়ের জন্যই অর্থ ব্যয়!) এবং প্রক্রিয়াকরণ খরচ (ক্লায়েন্ট এবং সার্ভার উভয় দিকেই)।

ব্যবহারকারীদের জন্য খরচ বিবেচনা করুন

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

• ভবিষ্যতের নেভিগেশন ডাউনলোড করার জন্য অতিরিক্ত ব্যান্ডউইথ ব্যবহার করা হবে—বিশেষ করে মোবাইলে যেখানে ব্যান্ডউইথের সীমাবদ্ধতা বেশি হতে পারে।
• প্রিরেন্ডার ব্যবহার করার সময় সেই পৃষ্ঠাগুলি রেন্ডার করতে অতিরিক্ত প্রক্রিয়াকরণ খরচ।

সম্পূর্ণ নির্ভুল ভবিষ্যদ্বাণীর সাথে, কোনও অতিরিক্ত খরচ নেই, কারণ দর্শকরা পরবর্তীতে সেই পৃষ্ঠাগুলি পরিদর্শন করবে, একমাত্র পার্থক্য হল যে সেই খরচগুলি সামনের দিকেই লেখা থাকে। যাইহোক, সম্পূর্ণ নির্ভুলতার সাথে ভবিষ্যতের ভবিষ্যদ্বাণী করা অসম্ভব, এবং অনুমান কৌশল যত বেশি আক্রমণাত্মক হবে, অপচয়ের ঝুঁকি তত বেশি হবে।

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

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

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

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

অতিরিক্ত ব্যাকএন্ড লোড বিবেচনা করুন

ব্যবহারকারীর অতিরিক্ত খরচ বিবেচনা করার পাশাপাশি, সাইট মালিকদের তাদের নিজস্ব অবকাঠামোগত খরচ বিবেচনা করা উচিত। যদি প্রতিটি পৃষ্ঠায় দুই, তিন বা তারও বেশি পৃষ্ঠা লোড হয়, তাহলে এই API ব্যবহার করে ব্যাকএন্ড খরচ বাড়তে পারে।

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

একটি সার্ভার বা CDN ব্যবহার করে sec-purpose HTTP হেডার দ্বারা চিহ্নিত অনুমানের ফলাফল নিয়ন্ত্রণ করা যেতে পারে। উদাহরণস্বরূপ, Cloudflare এর Speed ​​Brain পণ্য শুধুমাত্র CDN এর edge সার্ভারে ইতিমধ্যেই ক্যাশে থাকা অনুমানগুলিকেই অনুমতি দেয় এবং মূল স্থানে অনুরোধগুলি ফেরত পাঠায় না।

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

খুব বেশি বা খুব কম অনুমানের মধ্যে ভারসাম্য খুঁজুন

স্পেকুলেশন রুলস এপিআই-এর সর্বাধিক ব্যবহার করার মূল চাবিকাঠি হল অতিরিক্ত অনুমান করার মধ্যে ভারসাম্য খুঁজে বের করা—অর্থাৎ, যখন খরচ অপ্রয়োজনীয়ভাবে পরিশোধ করা হয় এবং অনুমান ব্যবহার করা হয় না—এবং খুব রক্ষণশীলভাবে—হয় খুব কম, অথবা খুব দেরিতে যেখানে খুব কম সুবিধা পাওয়া যায়।

যেখানে খরচ কম (উদাহরণস্বরূপ, CDN এজ নোডে ক্যাশে করা ছোট, স্ট্যাটিক্যালি জেনারেট করা পৃষ্ঠা), সেখানে আপনি অনুমানের ক্ষেত্রে আরও আক্রমণাত্মক হতে পারেন।

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

জল্পনা-কল্পনার নিয়ম বাস্তবায়নের পদক্ষেপ

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

প্রিফেচ দিয়ে শুরু করুন

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

প্রধান যে বিষয়গুলো সম্পর্কে সচেতন থাকা উচিত তা হলো, যদি URL প্রিফেকচার করার ফলে কোন অবস্থা পরিবর্তন হয় এবং সার্ভার-সাইড খরচ হয়, বিশেষ করে আনক্যাচেবল পৃষ্ঠাগুলির জন্য। আদর্শভাবে অবস্থা পরিবর্তনগুলি - উদাহরণস্বরূপ, একটি /logout পৃষ্ঠা প্রিফেকচার করা - GET লিঙ্ক হিসাবে প্রয়োগ করা উচিত নয়, তবে দুঃখের বিষয় হল এটি ওয়েবে অস্বাভাবিক নয়।

এই ধরনের URL গুলিকে বিশেষভাবে নিয়ম থেকে বাদ দেওয়া যেতে পারে:

<script type="speculationrules">
  {
    "prefetch": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

প্রিফেচগুলি এক পৃষ্ঠা থেকে অন্য পৃষ্ঠায় সাধারণ নেভিগেশনের মধ্যে সীমাবদ্ধ থাকতে পারে, অথবা হোভার বা ক্লিকের মাধ্যমে moderate বা conservative eagerness সেটিং ব্যবহার করে সমস্ত একই-অরিজিন লিঙ্কের জন্য সীমাবদ্ধ থাকতে পারে। conservative সেটিং সর্বনিম্ন ঝুঁকি বহন করে, তবে সর্বনিম্ন সম্ভাব্য পুরষ্কারও বহন করে। যদি সেখান থেকে শুরু করে থাকেন, তাহলে অন্তত moderate পর্যায়ে এগিয়ে যাওয়ার লক্ষ্য রাখুন, তবে আদর্শভাবে এর বাইরে eager আরও বেশি কর্মক্ষমতা সুবিধা প্রদান করবে (এবং তারপরে prerender আরও আপগ্রেড করা হবে যেখানে এটি বোধগম্য)।

কম ঝুঁকিপূর্ণ প্রিরেন্ডার

প্রিফেচ স্পেকুলেশন স্থাপন করা সহজ কিন্তু API-এর চূড়ান্ত পারফরম্যান্স সুবিধা হল প্রিরেন্ডার। স্পেকুলেশন করার কিছুক্ষণ পরেই পৃষ্ঠাটি ভিজিট না করা হলে (যা আমরা পরবর্তী বিভাগে আলোচনা করব), এর কিছু অতিরিক্ত বিবেচনা থাকতে পারে, তবে একটি moderate বা conservative প্রিরেন্ডারের ক্ষেত্রে, যেখানে নেভিগেশনের কিছুক্ষণ পরেই ঘটতে পারে, এটি পরবর্তী পদক্ষেপের তুলনামূলকভাবে কম ঝুঁকিপূর্ণ হতে পারে।

<script type="speculationrules">
  {
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

আগ্রহী নয় এমন প্রি-রেন্ডার উন্নত করতে সাধারণ পৃষ্ঠাগুলি প্রিফেকচার করুন

একটি সাধারণ কৌশল হল লোড করার সময় ঘন ঘন পরিদর্শন করা পরবর্তী পৃষ্ঠাগুলিকে একটি eager সেটিং দিয়ে কম সংখ্যক প্রিফেচ করা (হয় URL তালিকায় নির্দিষ্ট করে অথবা selector_matches ব্যবহার করে), এবং তারপর একটি moderate সেটিং দিয়ে প্রিরেন্ডার করা। যেহেতু লিঙ্কটি হোভার করার সময় HTML প্রিফেচ সম্পূর্ণ হয়ে যাওয়ার সম্ভাবনা থাকে, তাই এটি প্রিফেচ ছাড়াই হোভারে প্রিরেন্ডার করার চেয়ে বেশি সুবিধা দেয়।

<script type="speculationrules">
  {
    "prefetch": [{
      "urls": ["next.html", "next2.html"],
      "eagerness": "eager"
    }],
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

পূর্ববর্তী প্রিরেন্ডারগুলি

যদিও moderate ডকুমেন্ট নিয়মগুলি API-এর তুলনামূলকভাবে কম ঝুঁকিপূর্ণ ব্যবহারের অনুমতি দেয় এবং বাস্তবায়নের সুবিধাও দেয়, এটি প্রায়শই সম্পূর্ণ প্রিরেন্ডারের জন্য যথেষ্ট সময় নয়। এই API-এর মাধ্যমে তাৎক্ষণিক নেভিগেশন অর্জনের জন্য, আপনাকে সম্ভবত এর বাইরে যেতে হবে এবং পৃষ্ঠাগুলি আরও আগ্রহের সাথে প্রিরেন্ডার করতে হবে।

এটি করা যায় একটি স্ট্যাটিক URL তালিকার মাধ্যমে (যেমন পূর্ববর্তী প্রিফেচ উদাহরণ) অথবা selector_matches মাধ্যমে অল্প সংখ্যক URL (আদর্শভাবে এক বা দুটি পৃষ্ঠা) সনাক্ত করে, যেখানে অন্যান্য URL গুলিকে অন্তর্ভুক্ত করে ডকুমেন্ট নিয়ম:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "selector_matches": : ".prerender"
        },
        "eagerness": "eager",
      },
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": {"href_matches": "/logout"}}
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

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

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

বিশ্লেষণ, বিজ্ঞাপন এবং জাভাস্ক্রিপ্ট

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

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

পৃষ্ঠাগুলি সক্রিয় বা দৃশ্যমান না হওয়া পর্যন্ত নির্দিষ্ট কোডের বিটগুলি কার্যকর করা রোধ করতে আপনি জাভাস্ক্রিপ্টে চেক যুক্ত করতে পারেন, এমনকি এই চেকগুলিতে সম্পূর্ণ <script> উপাদানগুলিও মুড়ে দিতে পারেন। যেখানে পৃষ্ঠাগুলি এই জাতীয় স্ক্রিপ্টগুলি ইনজেক্ট করার জন্য ট্যাগ ম্যানেজার ব্যবহার করে, সেখানে ট্যাগ ম্যানেজার স্ক্রিপ্টটি বিলম্বিত করে একবারে এই সমস্ত কিছু মোকাবেলা করা সম্ভব হতে পারে।

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

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

অতিরিক্তভাবে, যদি কোনও কন্টেন্ট জাভাস্ক্রিপ্টের উপর নির্ভর করে (উদাহরণস্বরূপ, ক্লায়েন্ট-সাইড রেন্ডার করা কন্টেন্ট), তাহলে এটি বিলম্বিত করলে LCP এবং CLS-এর উপর প্রি-রেন্ডারিংয়ের ইতিবাচক প্রভাব কমবে। প্রি-রেন্ডারিং পর্যায়ে আরও বেশি জাভাস্ক্রিপ্ট চালানোর অনুমতি দেওয়ার জন্য একটি আরও লক্ষ্যযুক্ত পদ্ধতির ফলে আরও ভাল অভিজ্ঞতা হবে, তবে বাস্তবায়ন করা কম তুচ্ছ হতে পারে।

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

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

প্রিরেন্ডারের জল্পনা আপডেট করুন

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

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

ব্রডকাস্ট চ্যানেল এপিআই হল ব্রাউজারের একটি পৃষ্ঠাকে অন্য পৃষ্ঠায় এই ধরণের আপডেট সম্প্রচার করার অনুমতি দেওয়ার একটি উপায়। এটি একাধিক ট্যাব সমস্যারও সমাধান করবে। প্রি-রেন্ডার করা পৃষ্ঠাগুলি সম্প্রচার বার্তা শুনতে পারে - যদিও সক্রিয় না হওয়া পর্যন্ত তাদের নিজস্ব সম্প্রচার বার্তা পাঠাতে পারে না।

বিকল্পভাবে, প্রিরেন্ডার করা পৃষ্ঠাগুলি সার্ভার ব্যবহার করে (একটি পর্যায়ক্রমিক fetch() , অথবা একটি WebSocket সংযোগ ব্যবহার করে) আপডেট পেতে পারে, তবে আপডেটগুলিতে সম্ভাব্য পিছিয়ে থাকতে পারে।

প্রিরেন্ডারের জল্পনা বাতিল বা রিফ্রেশ করুন

ব্যবহারকারীদের বিভ্রান্তি এড়াতে পূর্ব-রেন্ডার করা পৃষ্ঠাগুলি ব্যবহার চালিয়ে যাওয়ার জন্য একটি পূর্ব-রেন্ডার করা পৃষ্ঠা আপডেট করা হল প্রস্তাবিত পদ্ধতি। যেখানে এটি সম্ভব নয়, সেখানে অনুমান বাতিল করা সম্ভব।

যদি সাইটগুলি এমন অন্যান্য পৃষ্ঠাগুলিকে প্রি-রেন্ডার করতে চায় যা দেখার সম্ভাবনা বেশি, তাহলে Chrome-এর সীমার মধ্যে থাকার জন্যও এটি ব্যবহার করা যেতে পারে।

জল্পনা বাতিল করার জন্য, আপনাকে পৃষ্ঠা থেকে জল্পনা নিয়মগুলি সরিয়ে ফেলতে হবে—অথবা যদি আপনি সেই পদ্ধতি ব্যবহার করেন তবে ক্লাস বা অন্যান্য মিলের মানদণ্ডগুলি সরিয়ে ফেলতে হবে। বিকল্পভাবে, যদি জল্পনা করা পৃষ্ঠাটি সনাক্ত করে যে এটি আর বর্তমান নেই তবে window.close() কল করতে পারে। যদিও পৃষ্ঠাটি যদি এটি সনাক্ত করতে সক্ষম হয়, তবে একটি ভাল বিকল্প হবে এটির অবস্থা আপডেট করে এটিকে আপডেট করা যাতে এটি আবার আপডেট করা যায়।

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

async function refreshSpeculations() {
  const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');

  for (const speculationScript of speculationScripts) {
    // Get the current rules as JSON text
    const ruleSet = speculationScript.textContent;

    // Remove the existing script to reset prerendering
    speculationScript.remove();
    
    // Await for a microtask before re-inserting.
    await Promise.resolve();

    // Reinsert rule in a new speculation rules script
    const newScript = document.createElement('script');
    newScript.type = 'speculationrules';
    newScript.textContent = ruleSet;
    console.log(newScript);

    // Append the new script back to the document
    document.body.appendChild(newScript);
  }
}

নিয়মগুলি অপসারণ করলে বিদ্যমান প্রিটেন্ডারগুলি (অথবা প্রিফেচগুলি) বাতিল হয়ে যাবে কিন্তু নিয়মগুলি পুনরায় সন্নিবেশ করালে কেবল তাৎক্ষণিক বা আগ্রহী নিয়মগুলি অনুমান করা হবে (তাৎক্ষণিকের ডিফল্ট ব্যবহার করে URL তালিকার নিয়মগুলি সহ)। তবে, মাঝারি বা রক্ষণশীল অনুমানগুলি অপসারণ করা হবে তবে লিঙ্কটির সাথে আবার ইন্টারঅ্যাক্ট না করা পর্যন্ত স্বয়ংক্রিয়ভাবে পুনরায় ট্রিগার করা হবে না।

এই রিফ্রেশ বিকল্পটি জাভাস্ক্রিপ্ট-ইনসার্ট করা নিয়মের মধ্যেই সীমাবদ্ধ নয়। HTML-এ অন্তর্ভুক্ত স্ট্যাটিক নিয়মগুলিও একইভাবে সরানো বা পরিবর্তন করা যেতে পারে, কারণ এটি একটি স্ট্যান্ডার্ড DOM পরিবর্তন। HTTP অনুমান নিয়মগুলি সরানো যাবে না, তবে মিলিত মানদণ্ড (উদাহরণস্বরূপ, prerender ক্লাস) সরানো যেতে পারে এবং জাভাস্ক্রিপ্ট দ্বারা পুনরায় যুক্ত করা যেতে পারে।

ক্রোম একটি Clear-Site-Data HTTP হেডারও যুক্ত করেছে যাতে সার্ভারের প্রতিক্রিয়াগুলি প্রিফেক্ট বা প্রিরেন্ডার বাতিল করতে পারে (উদাহরণস্বরূপ, যখন একটি আপডেট বাস্কেট অনুরোধ করা হয়)।

প্রভাব পরিমাপ করুন

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

একাধিক ধাপ (প্রিফেচ, কম ঝুঁকিপূর্ণ প্রিরেন্ডার এবং তারপর প্রাথমিক প্রিরেন্ডার) দিয়ে বাস্তবায়ন করার সময় আপনার প্রতিটি ধাপের সাথে পরিমাপ করা উচিত।

সাফল্য কীভাবে পরিমাপ করা যায়

অনুমানের নিয়মগুলি LCP (এবং সম্ভবত CLS এবং INP)-এর মতো গুরুত্বপূর্ণ কর্মক্ষমতা মেট্রিক্সের উপর ইতিবাচক প্রভাব ফেলবে, তবে সামগ্রিক সাইট-স্তরের মেট্রিক্সে এগুলি স্পষ্ট নাও হতে পারে। এর কারণ হল সাইটগুলি মূলত অন্যান্য নেভিগেশন ধরণের (উদাহরণস্বরূপ, ল্যান্ডিং পৃষ্ঠা) দ্বারা গঠিত হতে পারে অথবা একই-অরিজিন নেভিগেশনগুলি ইতিমধ্যেই যথেষ্ট দ্রুত যে তাদের নাটকীয়ভাবে উন্নত করাও Chrome ব্যবহারকারী অভিজ্ঞতা প্রতিবেদনে (CruX) রিপোর্ট করা 75 তম শতাংশ মেট্রিক্সকে প্রভাবিত করতে পারে না।

আপনি CrUX-এ পেজ নেভিগেশন টাইপ ব্যবহার করে কত শতাংশ নেভিগেশন navigate_cache বা prerender এবং সময়ের সাথে সাথে তা বাড়ছে কিনা তা পরীক্ষা করতে পারেন। তবে, বিস্তারিত বিশ্লেষণের জন্য আপনাকে রিয়েল ইউজার মনিটরিং ব্যবহার করে আপনার ডেটাকে অনুমানকৃত নেভিগেশনে ভাগ করতে হতে পারে যাতে তারা অন্যান্য নেভিগেশনের তুলনায় কতটা দ্রুত তা দেখতে পারে।

ব্যবহার এবং অপচয় কীভাবে পরিমাপ করা যায়

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

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

if (document.prerendering) {
  console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
  console.log("Page has already prerendered");
} else {
  console.log("This page load was not using prerendering");
}

এই পৃষ্ঠাটি তখন সার্ভারগুলিকে ব্যাকএন্ড করার অনুমানমূলক প্রচেষ্টা লগ করতে পারে।

অ্যানালিটিক্সের একটি জটিলতা হল প্রোভাইডাররা (যেমন গুগল অ্যানালিটিক্স) যারা প্রিরেন্ডার-সচেতন এবং পৃষ্ঠাটি সক্রিয় না হওয়া পর্যন্ত অ্যানালিটিক্স কল উপেক্ষা করে—এমনকি পৃথক ইভেন্ট কলও। তাই গুগল অ্যানালিটিক্স ব্যবহারকারীদের অন্য একটি বিকল্প সার্ভার-সাইড লগিং বিকল্প ব্যবহার করতে হবে।

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

উপসংহার

জল্পনা-কল্পনার নিয়মগুলি আপনার পৃষ্ঠার কর্মক্ষমতায় নাটকীয় পারফরম্যান্স বৃদ্ধির সম্ভাবনা প্রদান করে। এই নির্দেশিকাটি সম্ভাব্য সমস্যা এড়াতে এবং API থেকে সর্বাধিক সুবিধা পেতে এই API বাস্তবায়নের সময় বিবেচনার বিষয়ে পরামর্শ দেয়।

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