তাত্ক্ষণিক পৃষ্ঠা নেভিগেশনের জন্য Chrome-এ পৃষ্ঠাগুলি প্রি-রেন্ডার করুন

Barry Pollard

প্রকাশিত: 2 ডিসেম্বর, 2022, শেষ আপডেট: সেপ্টেম্বর 4, 2025

ক্রোম টিম ভবিষ্যত পৃষ্ঠাগুলির সম্পূর্ণ প্রিরেন্ডারিং ফিরিয়ে এনেছে যা একজন ব্যবহারকারী নেভিগেট করতে পারে৷

প্রি-রেন্ডারের একটি সংক্ষিপ্ত ইতিহাস

অতীতে, ক্রোম <link rel="prerender" href="/next-page"> রিসোর্স ইঙ্গিত সমর্থন করেছিল, তবে এটি ক্রোমের বাইরে ব্যাপকভাবে সমর্থিত ছিল না এবং এটি একটি খুব অভিব্যক্তিপূর্ণ API ছিল না।

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

Chrome টিম এখন Chrome-এ সম্পূর্ণ প্রিরেন্ডারিং আবার চালু করেছে। বিদ্যমান ব্যবহারের সাথে জটিলতা এড়াতে এবং ভবিষ্যতে প্রিরেন্ডারিংয়ের সম্প্রসারণের অনুমতি দিতে, এই নতুন প্রি-রেন্ডার পদ্ধতিটি <link rel="prerender"...> বাক্য গঠন ব্যবহার করবে না, যা NoState Prefetch-এর জন্য রয়ে গেছে, ভবিষ্যতে কোনো সময়ে এটিকে অবসর নেওয়ার দৃশ্যের সাথে।

কিভাবে একটি পৃষ্ঠা প্রি-রেন্ডার করা হয়?

একটি পৃষ্ঠা চারটি উপায়ের মধ্যে একটিতে প্রি-রেন্ডার করা যেতে পারে, যার সবকটিরই লক্ষ্য নেভিগেশন দ্রুত করা:

1. আপনি যখন Chrome অ্যাড্রেস বারে একটি URL টাইপ করেন ("অমনিবক্স" নামেও পরিচিত), Chrome স্বয়ংক্রিয়ভাবে আপনার জন্য পৃষ্ঠাটি প্রি-রেন্ডার করতে পারে, যদি এটির উচ্চ আত্মবিশ্বাস থাকে আপনি আপনার পূর্ববর্তী ব্রাউজিং ইতিহাসের উপর ভিত্তি করে সেই পৃষ্ঠাটি দেখতে পাবেন৷
2. আপনি যখন বুকমার্ক বার ব্যবহার করেন, Chrome স্বয়ংক্রিয়ভাবে বুকমার্ক বোতামগুলির একটিতে পয়েন্টার ধরে রেখে আপনার জন্য পৃষ্ঠাটি প্রি-রেন্ডার করতে পারে।
3. আপনি যখন Chrome ঠিকানা বারে একটি অনুসন্ধান শব্দ টাইপ করেন, সার্চ ইঞ্জিন দ্বারা এটি করার নির্দেশ দেওয়া হলে Chrome স্বয়ংক্রিয়ভাবে অনুসন্ধান ফলাফল পৃষ্ঠাটি প্রি-রেন্ডার করতে পারে৷
4. কোন পৃষ্ঠাগুলি প্রি-রেন্ডার করতে হবে তা ক্রোমকে প্রোগ্রাম্যাটিকভাবে জানাতে সাইটগুলি স্পেকুলেশন রুলস API ব্যবহার করতে পারে৷ এটি <link rel="prerender"...> যা করত তা প্রতিস্থাপন করে এবং পৃষ্ঠার অনুমান নিয়মের উপর ভিত্তি করে সাইটগুলিকে সক্রিয়ভাবে একটি পৃষ্ঠা প্রি-রেন্ডার করার অনুমতি দেয়। এগুলি পৃষ্ঠাগুলিতে স্থিরভাবে বিদ্যমান থাকতে পারে, বা পৃষ্ঠার মালিক উপযুক্ত মনে করলে জাভাস্ক্রিপ্ট দ্বারা গতিশীলভাবে ইনজেক্ট করা যেতে পারে৷

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

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

প্রি-রেন্ডারিংয়ের প্রভাব

প্রি-রেন্ডারিং নিম্নলিখিত ভিডিওতে দেখানো একটি কাছাকাছি-তাত্ক্ষণিক পৃষ্ঠা লোডের অনুমতি দেয়:

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

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

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

কিভাবে আপনার বিশ্লেষণে প্রকৃত কর্মক্ষমতা প্রভাব পরিমাপ করতে হয় সে সম্পর্কে আরও তথ্যের জন্য পরিমাপ কর্মক্ষমতা বিভাগটি দেখুন।

Chrome এর ঠিকানা বার পূর্বাভাস দেখুন

প্রথম ব্যবহারের ক্ষেত্রে, আপনি chrome://predictors পৃষ্ঠায় URL-এর জন্য Chrome এর পূর্বাভাস দেখতে পারেন:

সবুজ লাইন প্রি-রেন্ডারিং ট্রিগার করার জন্য যথেষ্ট আত্মবিশ্বাস নির্দেশ করে। এই উদাহরণে "s" টাইপ করা একটি যুক্তিসঙ্গত আত্মবিশ্বাস দেয় (অ্যাম্বার), কিন্তু একবার আপনি "sh" টাইপ করলে Chrome-এর যথেষ্ট আত্মবিশ্বাস থাকে যে আপনি প্রায় সবসময় https://sheets.google.com এ নেভিগেট করেন।

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

এই ভবিষ্যদ্বাণীগুলি হল অ্যাড্রেস বারে প্রস্তাবিত বিকল্পগুলি যা আপনি লক্ষ্য করেছেন:

আপনার টাইপিং এবং নির্বাচনের উপর ভিত্তি করে Chrome ক্রমাগত তার ভবিষ্যদ্বাণী আপডেট করবে।

• 50%-এর বেশি আত্মবিশ্বাসের স্তরের জন্য (অ্যাম্বারে দেখানো হয়েছে), ক্রোম সক্রিয়ভাবে ডোমেনের সাথে প্রি-কানেক্ট করে, কিন্তু পৃষ্ঠাটিকে প্রি-রেন্ডার করে না।
• 80%-এর বেশি আত্মবিশ্বাসের স্তরের জন্য (সবুজ রঙে দেখানো হয়েছে), Chrome ইউআরএল প্রি-রেন্ডার করবে।

স্পেকুলেশন রুলস এপিআই

স্পেকুলেশন রুলস এপিআই প্রিরেন্ডার বিকল্পের জন্য, ওয়েব ডেভেলপাররা তাদের পৃষ্ঠাগুলিতে JSON নির্দেশাবলী সন্নিবেশ করতে পারে যাতে ব্রাউজারকে কোন URLগুলি প্রি-রেন্ডার করতে হবে তা জানাতে:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

অথবা নথির নিয়ম অনুসারে (Chrome 121 থেকে পাওয়া যায়), যা href নির্বাচক ( ইউআরএল প্যাটার্ন API এর উপর ভিত্তি করে) বা CSS নির্বাচকদের উপর ভিত্তি করে নথিতে পাওয়া লিঙ্কগুলিকে প্রি-রেন্ডার করে:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

ক্রোম টিম একটি স্পেকুলেশন রুলস কোডল্যাব তৈরি করেছে যা আপনাকে একটি সাইটে স্পেকুলেশন রুলস যোগ করার মাধ্যমে নিয়ে যাবে।

আকুলতা

কখন অনুমান করা উচিত তা নির্দেশ করার জন্য একটি eagerness সেটিং ব্যবহার করা হয়, যা নথির নিয়মগুলির জন্য বিশেষভাবে কার্যকর:

• conservative : এটি পয়েন্টার বা টাচ ডাউনের উপর অনুমান করে।
• moderate : ডেস্কটপে, যদি আপনি পয়েন্টারটিকে 200 মিলিসেকেন্ডের জন্য একটি লিঙ্কের উপর ধরে রাখেন (অথবা pointerdown ইভেন্টে যদি এটি তাড়াতাড়ি হয়, এবং মোবাইলে যেখানে কোনও hover ইভেন্ট নেই)। মোবাইলে, আমরা আগস্ট 2025 থেকে জটিল ভিউপোর্ট হিউরিসিটিক্সের ভিত্তিতে এটি পরিবর্তন করেছি।
• eager : এটি মূলত immediate অভিন্নভাবে আচরণ করেছিল কিন্তু immediate এবং moderate অবস্থার মধ্যে একটি মধ্যবর্তী অবস্থার মধ্যে পরিবর্তন হচ্ছে। আমরা Chrome 141 অনুযায়ী 5-35 মিলিসেকেন্ডের একটি হোভারে পরিবর্তন করব (আমরা এখনও সঠিক সংখ্যা নিয়ে পরীক্ষা করছি)। আমরা ভবিষ্যতে মোবাইলে সাধারণ ভিউপোর্ট হিউরিসিটক্সে আরও পরিবর্তন করার পরিকল্পনা করছি।
• immediate : এটি যত তাড়াতাড়ি সম্ভব অনুমান করতে ব্যবহৃত হয়, অর্থাৎ যত তাড়াতাড়ি অনুমান করার নিয়মগুলি পরিলক্ষিত হয়।

list নিয়মের জন্য ডিফল্ট eagerness immediate । moderate এবং conservative বিকল্পগুলি ইউআরএলগুলিতে list নিয়মগুলিকে সীমাবদ্ধ করতে ব্যবহার করা যেতে পারে যেগুলির সাথে ব্যবহারকারী একটি নির্দিষ্ট তালিকার সাথে ইন্টারঅ্যাক্ট করে৷ যদিও অনেক ক্ষেত্রে, document নিয়ম where উপযুক্ত সেখানে আরও উপযুক্ত হতে পারে।

document নিয়মের জন্য ডিফল্ট eagerness conservative । প্রদত্ত একটি নথিতে অনেকগুলি URL থাকতে পারে, document নিয়মগুলির জন্য immediate বা eager ব্যবহার সতর্কতার সাথে ব্যবহার করা উচিত (পরবর্তী Chrome সীমা বিভাগটিও দেখুন)৷

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

moderate বিকল্পটি একটি মধ্যম স্থল, এবং অনেক সাইট নিম্নলিখিত অনুমান বিধি থেকে উপকৃত হতে পারে যা 200 মিলিসেকেন্ডের জন্য লিঙ্কের উপর পয়েন্টার ধরে রাখার সময় বা পয়েন্টারডাউন ইভেন্টে একটি মৌলিক-তবুও শক্তিশালী-অনুমান নিয়মের বাস্তবায়নের জন্য একটি লিঙ্ক প্রি-রেন্ডার করবে:

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

প্রিফেচ

স্পেকুলেশন নিয়মগুলি সম্পূর্ণ প্রিরেন্ডার ছাড়াই শুধুমাত্র পৃষ্ঠাগুলি প্রিফেচ করতে ব্যবহার করা যেতে পারে। এটি প্রায়শই প্রিরেন্ডারিংয়ের পথে একটি ভাল প্রথম পদক্ষেপ হতে পারে:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Chrome সীমাবদ্ধতা

স্পেকুলেশন রুলস API-এর অতিরিক্ত ব্যবহার রোধ করতে Chrome-এর সীমাবদ্ধতা রয়েছে:

moderate এবং conservative সেটিংস-যা ব্যবহারকারীর ইন্টারঅ্যাকশনের উপর নির্ভর করে—একটি ফার্স্ট ইন, ফার্স্ট আউট (FIFO) পদ্ধতিতে কাজ করে : সীমাতে পৌঁছানোর পরে, একটি নতুন অনুমান বাতিল হয়ে যাবে এবং স্মৃতি সংরক্ষণের জন্য নতুনটি দ্বারা প্রতিস্থাপিত হবে। একটি বাতিল অনুমান আবার ট্রিগার করা যেতে পারে-উদাহরণস্বরূপ সেই লিঙ্কের উপর আবার ঘোরালে-যার ফলে সেই URLটিকে পুনরায় অনুমান করা হবে, প্রাচীনতম অনুমানকে ঠেলে দেবে। এই ক্ষেত্রে পূর্ববর্তী অনুমানটি সেই URL-এর জন্য HTTP ক্যাশে যেকোনও ক্যাশেযোগ্য সংস্থানগুলিকে ক্যাশে করেছে তাই আরও সময় অনুমান করার একটি কম খরচ হওয়া উচিত৷ এই কারণেই সীমাটি 2-এর পরিমিত থ্রেশহোল্ডে সেট করা হয়েছে৷ স্ট্যাটিক তালিকা নিয়মগুলি ব্যবহারকারীর ক্রিয়া দ্বারা ট্রিগার হয় না এবং তাই একটি উচ্চ সীমা থাকে কারণ ব্রাউজারের পক্ষে কোনটি প্রয়োজন এবং কখন সেগুলি প্রয়োজন তা জানা সম্ভব নয়৷

immediate এবং eager সীমাগুলিও গতিশীল, তাই একটি list URL স্ক্রিপ্ট উপাদান সরানো সেই অপসারিত অনুমানগুলি বাতিল করে ক্ষমতা তৈরি করবে৷

ক্রোম কিছু নির্দিষ্ট পরিস্থিতিতে ব্যবহার করা জল্পনাকে প্রতিরোধ করবে যার মধ্যে রয়েছে:

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

সক্রিয় না হওয়া পর্যন্ত ক্রোম প্রি-রেন্ডার করা পৃষ্ঠাগুলিতে ক্রস-অরিজিন iframes রেন্ডার করে না।

এই সমস্ত শর্তগুলির লক্ষ্য হল অতিরিক্ত অনুমানের প্রভাব কমানো যখন এটি ব্যবহারকারীদের জন্য ক্ষতিকর হবে।

একটি পৃষ্ঠায় অনুমানের নিয়মগুলি কীভাবে অন্তর্ভুক্ত করবেন

স্পেকুলেশন নিয়মগুলি পৃষ্ঠার HTML-এ স্থিরভাবে অন্তর্ভুক্ত করা যেতে পারে বা জাভাস্ক্রিপ্ট দ্বারা গতিশীলভাবে পৃষ্ঠায় ঢোকানো যেতে পারে:

• স্থিরভাবে অন্তর্ভুক্ত অনুমানের নিয়ম : উদাহরণস্বরূপ একটি সংবাদ মিডিয়া সাইট, বা একটি ব্লগ নতুন নিবন্ধটি প্রি-রেন্ডার করতে পারে, যদি এটি প্রায়শই ব্যবহারকারীদের একটি বৃহৎ অনুপাতের জন্য পরবর্তী নেভিগেশন হয়, বিকল্পভাবে, ব্যবহারকারীরা লিঙ্কগুলির সাথে ইন্টারঅ্যাক্ট করার সময় একটি moderate বা conservative সহ নথির নিয়মগুলি অনুমান করতে ব্যবহার করা যেতে পারে৷
• গতিশীলভাবে ঢোকানো অনুমান নিয়ম : এটি অ্যাপ্লিকেশন যুক্তির উপর ভিত্তি করে, ব্যবহারকারীর জন্য ব্যক্তিগতকৃত, বা অন্যান্য হিউরিস্টিকসের উপর ভিত্তি করে হতে পারে।

যারা গতিশীল সন্নিবেশকে সমর্থন করে যেমন ক্রিয়াকলাপের উপর ভিত্তি করে হোভার করা, বা লিঙ্কে ক্লিক করা—যেমন অনেক লাইব্রেরি অতীতে <link rel=prefetch> -এর মাধ্যমে করেছে —তাদের নথির নিয়মগুলি দেখার জন্য সুপারিশ করা হয়, কারণ এটি ব্রাউজারকে আপনার ব্যবহারের অনেক ক্ষেত্রে পরিচালনা করতে দেয়।

মূল ফ্রেমে <head> বা <body> -এর মধ্যে অনুমানের নিয়মগুলি যোগ করা যেতে পারে। সাবফ্রেমে অনুমান নিয়মের উপর কাজ করা হয় না, এবং পূর্ব-প্রস্তুত পৃষ্ঠাগুলিতে অনুমান বিধিগুলি শুধুমাত্র একবার সেই পৃষ্ঠাটি সক্রিয় হওয়ার পরেই কাজ করা হয়।

Speculation-Rules HTTP হেডার

নথির এইচটিএমএলে সরাসরি অন্তর্ভুক্ত না করে Speculation-Rules HTTP শিরোনাম ব্যবহার করেও স্পেকুলেশন নিয়মগুলি সরবরাহ করা যেতে পারে। এটি নথির বিষয়বস্তু পরিবর্তন করার প্রয়োজন ছাড়াই CDN দ্বারা সহজ স্থাপনার অনুমতি দেয়।

Speculation-Rules HTTP শিরোনামটি নথির সাথে ফেরত দেওয়া হয়, এবং অনুমান বিধি ধারণকারী একটি JSON ফাইলের অবস্থান নির্দেশ করে:

Speculation-Rules: "/speculationrules.json"

এই সংস্থানটি অবশ্যই সঠিক MIME প্রকার ব্যবহার করতে হবে এবং, যদি এটি একটি ক্রস-অরিজিন রিসোর্স হয়, একটি CORS চেক পাস করুন৷

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

আপনি যদি আপেক্ষিক ইউআরএল ব্যবহার করতে চান তাহলে আপনার অনুমানের নিয়মে "relative_to": "document" কী অন্তর্ভুক্ত করতে পারেন। অন্যথায়, আপেক্ষিক ইউআরএলগুলি জেএসএন ফাইলের ইউআরএলের অনুমান নিয়মের সাথে আপেক্ষিক হবে। এটি বিশেষভাবে উপযোগী হতে পারে যদি আপনি কিছু-বা সমস্ত-একই-অরিজিন লিঙ্ক নির্বাচন করতে চান।

ফটকা নিয়ম ট্যাগ ক্ষেত্র

একটি নিয়ম সেটে সমস্ত অনুমানের নিয়মের জন্য সামগ্রিক স্তরে জল্পনা বিধি JSON সিনট্যাক্সে "ট্যাগ" যোগ করাও সম্ভব:

{
  "tag": "my-rules",
  "prefetch": [
    "urls": ["next.html"]
  ],
  "prerender": [
    "urls": ["next2.html"]
  ],
}

অথবা হয় স্বতন্ত্র নিয়ম স্তরে:

{
  "prefetch": [
    "urls": ["next.html"],
    "tag": "my-prefetch-rules"
  ],
  "prerender": [
    "urls": ["next2.html"],
    "tag": "my-prerender-rules"
  ],
}

এই ট্যাগটি Sec-Speculation-Tags HTTP শিরোনামে প্রতিফলিত হয়, যা সার্ভারে অনুমানের নিয়ম ফিল্টার করতে ব্যবহার করা যেতে পারে। Sec-Speculation-Tags HTTP শিরোনাম একাধিক ট্যাগ অন্তর্ভুক্ত করতে পারে যদি অনুমানটি একাধিক নিয়ম দ্বারা আচ্ছাদিত হয়, নিম্নলিখিত উদাহরণটি দেখায়:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

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

Ruleset ট্যাগগুলি Chrome DevTools-এও প্রদর্শিত হয়।

স্পেকুলেশন নিয়ম target_hint ফিল্ড

অনুমান বিধিতে একটি target_hint ক্ষেত্রও অন্তর্ভুক্ত থাকতে পারে, যেটিতে একটি বৈধ ব্রাউজিং প্রসঙ্গ নাম বা কীওয়ার্ড রয়েছে যা নির্দেশ করে যে পৃষ্ঠাটি পূর্বে উপস্থাপিত বিষয়বস্তু কোথায় সক্রিয় হবে:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

এই ইঙ্গিত target="_blank" লিঙ্কগুলির জন্য প্রি-রেন্ডার অনুমানগুলি পরিচালনা করার অনুমতি দেয়:

<a target="_blank" href="next.html">Open this link in a new tab</a>

আপাতত শুধুমাত্র "target_hint": "_blank" এবং "target_hint": "_self" (নির্দিষ্ট না থাকলে ডিফল্ট) Chrome-এ সমর্থিত এবং শুধুমাত্র প্রি-রেন্ডারের জন্য—প্রিফেচ সমর্থিত নয়।

target_hint শুধুমাত্র urls স্পেকুলেশন নিয়মের জন্য প্রয়োজন, যেমন নথির নিয়মের জন্য target লিঙ্ক থেকেই জানা যায়।

অনুমান নিয়ম এবং SPA

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

পূর্ববর্তী পৃষ্ঠা থেকে অ্যাপ্লিকেশনটি প্রি-রেন্ডার করতে অনুমান বিধি ব্যবহার করা যেতে পারে। এটি কিছু SPA-এর অতিরিক্ত প্রাথমিক লোড খরচ অফসেট করতে সাহায্য করতে পারে। যাইহোক, অ্যাপের মধ্যে রুট পরিবর্তনগুলি প্রি-রেন্ডার করা যাবে না।

ডিবাগ অনুমান নিয়ম

এই নতুন APIটি দেখতে এবং ডিবাগ করতে সহায়তা করার জন্য নতুন Chrome DevTools বৈশিষ্ট্যগুলির জন্য ডিবাগিং অনুমান নিয়মের উপর উত্সর্গীকৃত পোস্টটি দেখুন৷

একাধিক অনুমান নিয়ম

একই পৃষ্ঠায় একাধিক অনুমানের নিয়মও যোগ করা যেতে পারে এবং সেগুলি বিদ্যমান নিয়মের সাথে যুক্ত হয়। অতএব, নিম্নলিখিত বিভিন্ন উপায়ের ফলে one.html এবং two.html উভয়ই প্রিরেন্ডারিং হয়:

URL-এর তালিকা:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

একাধিক speculationrules রুলস স্ক্রিপ্ট:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

speculationrules এক সেটের মধ্যে একাধিক তালিকা

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

No-Vary-Search সমর্থন

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

উদাহরণস্বরূপ, প্রচারাভিযান পরিমাপের জন্য UTM প্যারামিটারগুলি Google Analytics দ্বারা ব্যবহার করা হয়, কিন্তু সাধারণত সার্ভার থেকে বিভিন্ন পৃষ্ঠা বিতরণ করা হয় না। এর মানে হল যে page1.html?utm_content=123 এবং page1.html?utm_content=456 সার্ভার থেকে একই পৃষ্ঠা সরবরাহ করবে, তাই একই পৃষ্ঠাটি ক্যাশে থেকে পুনরায় ব্যবহার করা যেতে পারে।

একইভাবে, অ্যাপ্লিকেশনগুলি অন্য URL প্যারামিটার ব্যবহার করতে পারে যেগুলি শুধুমাত্র ক্লায়েন্ট সাইড পরিচালনা করা হয়।

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

কোন No-Vary-Search HTTP শিরোনামটি কোথায় ফেরত আসবে তা নির্দেশ করার জন্য অনুমান নিয়মগুলি expects_no_vary_search ব্যবহার করে সমর্থন করে। এটি করা প্রতিক্রিয়াগুলি দেখার আগে অপ্রয়োজনীয় ডাউনলোডগুলি এড়াতে সাহায্য করতে পারে।

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

এই উদাহরণে, 123 এবং 124 উভয় পণ্য আইডির জন্য /products প্রাথমিক পৃষ্ঠা HTML একই। যাইহোক, id সার্চ প্যারামিটার ব্যবহার করে পণ্য ডেটা আনার জন্য জাভাস্ক্রিপ্ট ব্যবহার করে ক্লায়েন্ট-সাইড রেন্ডারিংয়ের উপর ভিত্তি করে পৃষ্ঠার বিষয়বস্তু পরিবর্তিত হয়। তাই আমরা সেই URLটি সাগ্রহে প্রিফেচ করি এবং এটি একটি No-Vary-Search HTTP শিরোনাম দেখায় যে পৃষ্ঠাটি যেকোন id অনুসন্ধান প্যারামের জন্য ব্যবহার করা যেতে পারে৷

যাইহোক, যদি ব্যবহারকারী প্রিফেচ সম্পূর্ণ হওয়ার আগে যেকোনও লিঙ্কে ক্লিক করে, ব্রাউজারটি /products পৃষ্ঠা নাও পেতে পারে। এই ক্ষেত্রে, ব্রাউজার জানে না যে এতে No-Vary-Search HTTP হেডার থাকবে কিনা। তারপরে ব্রাউজারটিকে আবার লিঙ্কটি আনতে হবে কিনা বা No-Vary-Search HTTP শিরোনাম রয়েছে কিনা তা দেখার জন্য প্রিফেচ সম্পূর্ণ হওয়ার জন্য অপেক্ষা করুন। expects_no_vary_search সেটিং ব্রাউজারকে জানতে দেয় যে পৃষ্ঠার প্রতিক্রিয়া একটি No-Vary-Search HTTP শিরোনাম থাকবে বলে আশা করা হচ্ছে এবং সেই প্রিফেচ সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে হবে।

এছাড়াও আপনি expects_no_vary_search এ একাধিক প্যারামিটার যোগ করতে পারেন একটি স্পেস দিয়ে আলাদা করে (যেহেতু No-Vary-Search হল একটি HTTP স্ট্রাকচার্ড হেডার):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

অনুমান নিয়ম সীমাবদ্ধতা এবং ভবিষ্যত বর্ধন

অনুমানের নিয়মগুলি একই ট্যাবের মধ্যে খোলা পৃষ্ঠাগুলিতে সীমাবদ্ধ, তবে আমরা সেই সীমাবদ্ধতা কমাতে কাজ করছি ৷

ডিফল্ট অনুমান একই-অরিজিন পৃষ্ঠাগুলিতে সীমাবদ্ধ। অনুমান একই-সাইট ক্রস-অরিজিন পৃষ্ঠাগুলি (উদাহরণস্বরূপ, https://a.example.com https://b.example.com এ একটি পৃষ্ঠা প্রি-রেন্ডার করতে পারে)। এটি ব্যবহার করার জন্য অনুমান করা পৃষ্ঠাটি (এই উদাহরণে https://b.example.com ) একটি Supports-Loading-Mode: credentialed-prerender HTTP হেডার বা Chrome অনুমান বাতিল করবে।

ভবিষ্যত সংস্করণগুলি নন-একই-সাইট, ক্রস-অরিজিন পৃষ্ঠাগুলির জন্যও প্রি-রেন্ডারের অনুমতি দিতে পারে যতক্ষণ না পূর্বে রেন্ডার করা পৃষ্ঠার জন্য কুকিজ বিদ্যমান না থাকে এবং প্রি-রেন্ডার করা পৃষ্ঠাটি অনুরূপ Supports-Loading-Mode: uncredentialed-prerender HTTP হেডারের সাথে নির্বাচন করে।

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

এই বর্তমান সীমাবদ্ধতাগুলির প্রেক্ষিতে, একটি প্যাটার্ন যা অভ্যন্তরীণ লিঙ্ক এবং বাহ্যিক লিঙ্ক উভয়ের জন্য আপনার ব্যবহারকারীদের অভিজ্ঞতা উন্নত করতে পারে যেখানে সম্ভব একই-অরিজিন ইউআরএলগুলিকে প্রি-রেন্ডার করা এবং ক্রস-অরিজিন ইউআরএলগুলি প্রিফেচ করার চেষ্টা করা:

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

ডিফল্টরূপে ক্রস-অরিজিন লিঙ্কগুলির জন্য ক্রস-অরিজিন অনুমান প্রতিরোধ করার সীমাবদ্ধতা নিরাপত্তার জন্য প্রয়োজনীয়। এটি ক্রস-অরিজিন গন্তব্যগুলির জন্য <link rel="prefetch"> একটি উন্নতি যা কুকিও পাঠাবে না কিন্তু তারপরও প্রিফেচ করার চেষ্টা করবে—যার ফলে হয় একটি নষ্ট প্রিফেচ হবে যা পুনরায় পাঠানোর প্রয়োজন হবে বা, আরও খারাপ, ভুল পৃষ্ঠা লোডিং।

স্পেকুলেশন রুলস API সমর্থন সনাক্ত করুন

আপনি স্ট্যান্ডার্ড এইচটিএমএল চেকের সাথে স্পেকুলেশন রুলস API সমর্থন সনাক্ত করতে পারেন:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

জাভাস্ক্রিপ্টের মাধ্যমে গতিশীলভাবে অনুমানের নিয়ম যোগ করুন

এটি জাভাস্ক্রিপ্টের সাথে একটি prerender স্পেকুলেশন নিয়ম যোগ করার একটি উদাহরণ:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

আপনি এই প্রিরেন্ডার ডেমো পৃষ্ঠায় জাভাস্ক্রিপ্ট সন্নিবেশ ব্যবহার করে স্পেকুলেশন রুলস API প্রিরেন্ডারিংয়ের একটি ডেমো দেখতে পারেন।

innerHTML ব্যবহার করে সরাসরি DOM-এ <script type = "speculationrules"> উপাদান ঢোকানো নিরাপত্তার কারণে অনুমান বিধি নিবন্ধন করবে না এবং এটি অবশ্যই পূর্বে দেখানো হিসাবে যোগ করতে হবে। তবে innerHTML ব্যবহার করে গতিশীলভাবে ঢোকানো সামগ্রী যাতে নতুন লিঙ্ক রয়েছে, পৃষ্ঠায় বিদ্যমান নিয়ম দ্বারা বাছাই করা হবে।

একইভাবে, <script type = "speculationrules"> এলিমেন্ট যোগ করার জন্য Chrome DevTools-এ এলিমেন্টস প্যানেল সরাসরি সম্পাদনা করলে তা অনুমানের নিয়ম নিবন্ধন করে না এবং এর পরিবর্তে DOM-এ এটিকে গতিশীলভাবে যুক্ত করার জন্য স্ক্রিপ্টটি অবশ্যই কনসোল থেকে নিয়ম ঢোকানোর জন্য চালাতে হবে।

একটি ট্যাগ ম্যানেজার মাধ্যমে অনুমান নিয়ম যোগ করুন

Google ট্যাগ ম্যানেজার (GTM) এর মতো ট্যাগ ম্যানেজার ব্যবহার করে অনুমানের নিয়মগুলি যোগ করার জন্য এগুলিকে জাভাস্ক্রিপ্টের মাধ্যমে ঢোকানো প্রয়োজন, <script type = "speculationrules"> উপাদান যোগ করার পরিবর্তে GTM সরাসরি একই কারণের জন্য যা আগে উল্লেখ করা হয়েছে:

মনে রাখবেন এই উদাহরণটি var ব্যবহার করে কারণ GTM const সমর্থন করে না।

ফটকা বিধি বাতিল করুন

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

prefetchCache এবং prerenderCache নির্দেশাবলী সহ Clear-Site-Data HTTP হেডার ব্যবহার করে অনুমান বাতিল করা যেতে পারে।

সার্ভারে অবস্থা পরিবর্তন করা হলে এটি কার্যকর হতে পারে। উদাহরণস্বরূপ, যখন একটি "অ্যাড-টু-বাস্কেট" API বা একটি লগইন বা লগআউট API কল করা হয়।

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

অনুমান নিয়ম এবং বিষয়বস্তু নিরাপত্তা নীতি

যেহেতু অনুমানের নিয়মগুলি একটি <script> উপাদান ব্যবহার করে, যদিও তারা শুধুমাত্র JSON ধারণ করে, যদি সাইটটি এটি ব্যবহার করে তবে সেগুলিকে script-src বিষয়বস্তু-নিরাপত্তা-নীতিতে অন্তর্ভুক্ত করতে হবে-হয় হ্যাশ বা ননস ব্যবহার করে।

একটি নতুন inline-speculation-rules script-src এ যোগ করা যেতে পারে যাতে <script type="speculationrules"> হ্যাশ বা ননসড স্ক্রিপ্ট থেকে ইনজেকশন করা উপাদানগুলিকে সমর্থন করা যায়। এটি প্রাথমিক HTML-এ অন্তর্ভুক্ত নিয়মগুলিকে সমর্থন করে না তাই কঠোর CSP ব্যবহার করে এমন সাইটগুলির জন্য জাভাস্ক্রিপ্ট দ্বারা নিয়মগুলি ইনজেকশন করা প্রয়োজন৷

প্রিরেন্ডারিং সনাক্ত করুন এবং অক্ষম করুন

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

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

Chrome এ প্রি-রেন্ডার সক্ষম এবং অক্ষম করুন৷

chrome://settings/performance/ এ "প্রিলোড পৃষ্ঠাগুলি" সেটিং সহ সেই সমস্ত Chrome ব্যবহারকারীদের জন্যই প্রিরেন্ডার সক্ষম করা হয়েছে। অতিরিক্তভাবে, কম-মেমরির ডিভাইসে বা অপারেটিং সিস্টেম সেভ-ডেটা বা এনার্জি সেভার মোডে থাকলে প্রি-রেন্ডারও অক্ষম করা হয়। Chrome সীমা বিভাগ দেখুন।

প্রি-রেন্ডার সার্ভার-সাইড সনাক্ত করুন এবং অক্ষম করুন

প্রি-রেন্ডার করা পৃষ্ঠাগুলি Sec-Purpose HTTP হেডার সহ পাঠানো হবে:

Sec-Purpose: prefetch;prerender

স্পেকুলেশন রুলস API ব্যবহার করে প্রিফেচ করা পৃষ্ঠাগুলিতে এই শিরোনামটি শুধু prefetch জন্য সেট করা থাকবে:

Sec-Purpose: prefetch

সার্ভারগুলি এই শিরোনামের উপর ভিত্তি করে প্রতিক্রিয়া জানাতে পারে, অনুমানের অনুরোধগুলি লগ করতে, বিভিন্ন বিষয়বস্তু ফেরত দিতে, বা প্রি-রেন্ডারকে ঘটতে বাধা দিতে পারে। যদি একটি অ-সফল চূড়ান্ত প্রতিক্রিয়া কোড ফেরত দেওয়া হয়—অর্থাৎ, পুনঃনির্দেশের পরে 200-299 পরিসরে নয়—তাহলে পৃষ্ঠাটি প্রি-রেন্ডার করা হবে না এবং কোনো প্রিফেচ পৃষ্ঠা বাতিল করা হবে। এছাড়াও নোট করুন যে 204 এবং 205 প্রতিক্রিয়াগুলি অতিরিক্তভাবে প্রিরেন্ডারিংয়ের জন্য বৈধ নয় , তবে প্রিফেচের জন্য বৈধ৷

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

জাভাস্ক্রিপ্টে প্রিরেন্ডার সনাক্ত করুন

পৃষ্ঠাটি প্রিরেন্ডারিং করার সময় document.prerendering API true ফিরে আসবে। পৃষ্ঠাটি সক্রিয় না হওয়া পর্যন্ত প্রি-রেন্ডারের সময় কিছু ক্রিয়াকলাপ প্রতিরোধ বা বিলম্ব করতে পৃষ্ঠাগুলি দ্বারা এটি ব্যবহার করা যেতে পারে।

একটি প্রি-রেন্ডার করা ডকুমেন্ট অ্যাক্টিভেট হয়ে গেলে, PerformanceNavigationTiming এর activationStart স্টার্টও একটি নন-জিরো টাইমে সেট করা হবে যা প্রি-রেন্ডার শুরু হওয়ার এবং ডকুমেন্টটি আসলে অ্যাক্টিভেট হওয়ার মধ্যবর্তী সময়ের প্রতিনিধিত্ব করে।

নিম্নলিখিতগুলির মতো প্রিরেন্ডারিং এবং প্রি-রেন্ডার করা পৃষ্ঠাগুলি পরীক্ষা করার জন্য আপনার কাছে একটি ফাংশন থাকতে পারে:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

একটি পৃষ্ঠা প্রি-রেন্ডার করা হয়েছে কিনা তা দেখার সবচেয়ে সহজ উপায় হল পৃষ্ঠাটি সক্রিয় হওয়ার পরে DevTools খুলুন এবং কনসোলে performance.getEntriesByType('navigation')[0].activationStart টাইপ করুন। যদি একটি অ-শূন্য মান ফেরত দেওয়া হয়, আপনি জানেন যে পৃষ্ঠাটি আগে থেকে রেন্ডার করা হয়েছে:

যখন পৃষ্ঠাটি ব্যবহারকারী পৃষ্ঠাটি দেখার দ্বারা সক্রিয় করা হয়, তখন prerenderingchange ইভেন্টটি document প্রেরণ করা হবে, যা তারপরে এমন কার্যকলাপগুলি সক্ষম করতে ব্যবহার করা যেতে পারে যা পূর্বে পৃষ্ঠা লোডের সময় ডিফল্টরূপে শুরু হত কিন্তু আপনি পৃষ্ঠাটি প্রকৃতপক্ষে ব্যবহারকারী দ্বারা দেখা না হওয়া পর্যন্ত বিলম্ব করতে চান৷

এই API গুলি ব্যবহার করে, ফ্রন্টএন্ড জাভাস্ক্রিপ্ট সঠিকভাবে প্রি-রেন্ডার করা পৃষ্ঠাগুলি সনাক্ত করতে এবং কাজ করতে পারে।

বিশ্লেষণের উপর প্রভাব

ওয়েবসাইটের ব্যবহার পরিমাপ করতে অ্যানালিটিক্স ব্যবহার করা হয়, উদাহরণস্বরূপ পৃষ্ঠার দৃশ্য এবং ইভেন্টগুলি পরিমাপ করতে Google Analytics ব্যবহার করে৷ অথবা রিয়েল ইউজার মনিটরিং (RUM) ব্যবহার করে পৃষ্ঠাগুলির পারফরম্যান্স মেট্রিক্স পরিমাপ করে।

পৃষ্ঠাগুলি শুধুমাত্র তখনই প্রি-রেন্ডার করা উচিত যখন ব্যবহারকারীর দ্বারা পৃষ্ঠাটি লোড করার উচ্চ সম্ভাবনা থাকে৷ এই কারণেই ক্রোম অ্যাড্রেস বার প্রিরেন্ডারিং বিকল্পগুলি তখনই ঘটে যখন এত উচ্চ সম্ভাবনা থাকে (সময়ের 80% এর বেশি)।

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

এটি এমন একটি Promise ব্যবহার করে অর্জন করা যেতে পারে যা prerenderingchange ইভেন্টের জন্য অপেক্ষা করে যদি একটি নথি প্রিরেন্ডারিং হয়, অথবা যদি এটি এখন হয় তবে অবিলম্বে সমাধান করে:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

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

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

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

প্রি-রেন্ডারিংয়ের সময় অন্যান্য সামগ্রী আটকে রাখুন

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

উদাহরণস্বরূপ, এই স্ক্রিপ্ট দেওয়া:

<script src="https://example.com/app/script.js" async></script>

আপনি এটিকে একটি গতিশীলভাবে সন্নিবেশিত স্ক্রিপ্ট উপাদানে পরিবর্তন করতে পারেন যা শুধুমাত্র পূর্ববর্তী whenActivated ফাংশনের উপর ভিত্তি করে সন্নিবেশ করা হয়:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

While this is perhaps more likely to happen more often with the use of prerendering, these conditions are also true for pages loaded in background tabs mentioned previously (so the whenFirstVisible function could be used in place of whenActivated ).

In many cases state should ideally also be checked on general visibilitychange changes—for example, when returning to a page that has been background, any shopping basket counters should be updated with the latest number of items in the basket. So this is not a prerender-specific problem but prerender is just making an existing issue more obvious.

One way that Chrome mitigates some of the need for manually wrapping scripts or functions, is that certain APIs are held back as mentioned previously , and also third-party iframes are not rendered, so it's only content on top of this that is required to be manually held back.

কর্মক্ষমতা পরিমাপ

For measuring performance metrics, analytics should consider whether it is better to measure these based upon the activation time rather than the page load time that browser APIs will report.

For Core Web Vitals, measured by Chrome through the Chrome User Experience Report , these are intended to measure the user experience. So these are measured based on activation time. This will often result in a 0 second LCP for example, showing this is great way of improving your Core Web Vitals.

From version 3.1.0, the web-vitals library has been updated to handle prerendered navigations in the same way Chrome measures Core Web Vitals. This version also flags prerendered navigations for those metrics in the Metric.navigationType attribute if the page was fully or partially prerendered.

Measure prerenders

Whether a page is prerendered can be seen with a non-zero activationStart entry of PerformanceNavigationTiming . This can then be logged using a Custom Dimension, or similar when logging the page views, for example using the pagePrerendered function described previously :

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

This will allow your analytics to show how many navigation are prerendered compared to other types of navigation, and also allow you to correlation any performance metrics or business metrics to these different navigation types. Faster pages means happier users, which can often have real impact on business measures as our case studies show.

As you measure the business impact of prerendering pages for instant navigations, you can decide whether it is worth investing more effort in using this technology to allow more navigations to be prerendered, or to investigate why pages are not being prerendered.

Measure hit rates

In addition to measuring the impact of pages that are visited after a prerender, it is also important to measure pages that are prerendered and not subsequently visited. This could imply you are prerendering too much, and using up valuable resources of the user for little benefit.

This can be measured by firing an analytics event when speculation rules are inserted—after checking the browser supports prerendering using HTMLScriptElement.supports('speculationrules') —to indicate that prerender was requested. (Note that just because a prerender was requested, does not indicate that a prerender was started or completed as, as noted previously, a prerender is a hint to the browser and it may choose not to prerender pages on user settings, current memory usage, or other heuristics.)

You can then compare the number of these events, to the actual prerender page views. Or alternatively fire another event on activation if that makes it easier to compare.

The "successful hit rate" can then be approximated by looking at the difference between these two figures. For pages where you are using the Speculation Rules API to prerender the pages, you can adjust the rules appropriately to ensure you keep a high hit rate to maintain the balance between using up the users resources to help them, versus using it needlessly.

Be aware that some prerendering may be taking place due to the address bar prerendering and not just your speculation rules. You can check the document.referrer (which will be blank for address bar navigation including prerendered address bar navigations) if you want to differentiate these.

Remember to also look at pages which have no prerenders, as that could indicate these pages are not eligible for prerendering, even from the address bar. That may mean you are not benefiting from this performance enhancement. The Chrome team is looking to add extra tooling to test for Prerender eligibility perhaps similar to the bfcache testing tool , and also potentially add an API to expose why a prerender failed.

Impact on extensions

See the dedicated post on Chrome Extensions: Extending API to support Instant Navigation which details some additional considerations extension authors may need to think about for prerendered pages.

প্রতিক্রিয়া

Prerendering is in active development by the Chrome team, and there are plenty of plans to expand the scope of what has been made available in the Chrome 108 release. We welcome any feedback on the GitHub repo or using our issue tracker , and look forward to hearing and sharing case studies of this exciting new API.

সম্পর্কিত লিঙ্ক

• Speculation Rules Codelab
• Debugging speculation rules
• Introducing NoState Prefetch
• Speculation Rules API specification
• The Navigational speculation GitHub repo
• Chrome Extensions: Extending API to support Instant Navigation

স্বীকৃতি

Thumbnail image by Marc-Olivier Jodoin on Unsplash