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

Barry Pollard

প্রকাশিত: মার্চ 07, 2025

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

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

পরিকল্পনা

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

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

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

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

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

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

পৃষ্ঠার HTML-এ সরাসরি অনুমান বিধি অন্তর্ভুক্ত করুন

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

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

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

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

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

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

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

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

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

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

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

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ফটকা বিধি বাস্তবায়নের পদক্ষেপ

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

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

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

যে প্রধান বিষয়গুলি সম্পর্কে সচেতন হতে হবে তা হল যে যদি একটি 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 সেটিং সহ (হয় সেগুলিকে একটি ইউআরএল তালিকায় উল্লেখ করে বা selector_matches ব্যবহার করে) এবং তারপর একটি moderate সেটিং সহ প্রি-রেন্ডার করা যেহেতু এইচটিএমএল প্রিফেচটি লিঙ্কটি হোভার করার সময় সম্পন্ন হওয়ার সম্ভাবনা রয়েছে, তাই এটি প্রিফেচ ছাড়াই হোভারে প্রি-রেন্ডারিংকে একটি বুস্ট দেয়৷

<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 অনুমতি দেয়, আপনাকে সম্ভবত এর বাইরে যেতে হবে এবং আরও আগ্রহের সাথে পৃষ্ঠাগুলি প্রিরেন্ডার করতে হবে৷

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

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

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

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

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

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

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

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

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

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

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

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

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

প্রি-রেন্ডার অনুমান আপডেট করুন

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

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

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

বিকল্পভাবে, প্রি-রেন্ডার করা পৃষ্ঠাগুলি সার্ভার ব্যবহার করে আপডেট পেতে পারে (একটি পর্যায়ক্রমিক 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);
  }
}

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

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

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

প্রভাব পরিমাপ

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

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

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

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

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

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

আপনি সঠিক পৃষ্ঠাগুলিতে অনুমান করছেন কিনা তা পরিমাপ করা আরেকটি মূল বিবেচনা। এটি উভয়ই অপচয় এড়ায় এবং নিশ্চিত করে যে আপনি এই 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");
}

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

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

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

উপসংহার

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

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