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

Barry Pollard

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

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

অতীতে, ক্রোম <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 সেটিং ব্যবহার করা হয়, যা নথির নিয়মগুলির জন্য বিশেষভাবে কার্যকর:

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

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>

ক্রোম সীমাবদ্ধতা

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

অনুমান নিয়ম এবং 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 শিরোনাম থাকবে বলে আশা করা হচ্ছে এবং সেই প্রিফেচ সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে হবে।

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

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

ডিফল্ট অনুমান একই-অরিজিন পৃষ্ঠাগুলিতে সীমাবদ্ধ। অনুমান একই-সাইট ক্রস-অরিজিন পৃষ্ঠাগুলি (উদাহরণস্বরূপ, 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 সমর্থন করে না।

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

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

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

যেহেতু অনুমানের নিয়মগুলি একটি <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');

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

যদিও এটি প্রি-রেন্ডারিং ব্যবহার করে প্রায়শই ঘটতে পারে, এই শর্তগুলি পূর্বে উল্লেখিত পটভূমি ট্যাবে লোড করা পৃষ্ঠাগুলির জন্যও সত্য (তাই whenFirstVisible ফাংশন whenActivated এর জায়গায় ব্যবহার করা যেতে পারে)।

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

একটি উপায় যে Chrome স্ক্রিপ্ট বা ফাংশনগুলিকে ম্যানুয়ালি মোড়ানোর কিছু প্রয়োজনীয়তা কমিয়ে দেয়, তা হল নির্দিষ্ট APIগুলিকে পূর্বে উল্লিখিত হিসাবে আটকে রাখা হয় , এবং তৃতীয় পক্ষের আইফ্রেমগুলিও রেন্ডার করা হয় না, তাই এটি শুধুমাত্র এটির উপরে বিষয়বস্তু যা ম্যানুয়ালি আটকে রাখা প্রয়োজন৷

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

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

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

সংস্করণ 3.1.0 থেকে, web-vitals লাইব্রেরিটি পূর্ব-প্রস্তুত ন্যাভিগেশনগুলি পরিচালনা করার জন্য আপডেট করা হয়েছে যেভাবে Chrome মূল ওয়েব ভাইটালগুলিকে পরিমাপ করে৷ পৃষ্ঠাটি সম্পূর্ণ বা আংশিকভাবে প্রি-রেন্ডার করা থাকলে এই সংস্করণটি Metric.navigationType অ্যাট্রিবিউটে সেই মেট্রিকগুলির জন্য পূর্ব-প্রস্তুত ন্যাভিগেশনগুলিকেও ফ্ল্যাগ করে৷

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

একটি পৃষ্ঠা প্রি-রেন্ডার করা হয়েছে কিনা তা PerformanceNavigationTiming টাইমিং-এর নন-জিরো activationStart স্টার্ট এন্ট্রি দিয়ে দেখা যাবে। এটি তারপর একটি কাস্টম মাত্রা ব্যবহার করে লগ করা যেতে পারে, বা পৃষ্ঠা দর্শন লগ করার সময় অনুরূপ, উদাহরণস্বরূপ পূর্বে বর্ণিত pagePrerendered ফাংশন ব্যবহার করে:

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

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

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

হিট হার পরিমাপ

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

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

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

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

সচেতন থাকুন যে কেবল আপনার অনুমানের নিয়ম নয়, ঠিকানা বার প্রেরেন্ডারিংয়ের কারণে কিছু প্রেরেন্ডারিং হতে পারে। আপনি document.referrer পরীক্ষা করতে পারেন re

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

এক্সটেনশনের উপর প্রভাব

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

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

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

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

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

স্বীকৃতি

মার্ক-অলিভিয়ার জোডোইন দ্বারা থাম্বনেইল চিত্রটি আনস্প্ল্যাশে

Barry Pollard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

প্রথম ব্যবহারের ক্ষেত্রে, আপনি chrome://predictors পৃষ্ঠায় URL এর জন্য ক্রোমের ভবিষ্যদ্বাণীগুলি দেখতে পারেন:

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

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

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

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

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

অনুমানের বিধি API

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

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

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

<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 সেটিং ব্যবহার করা হয়, যা ডকুমেন্ট বিধিগুলির জন্য বিশেষভাবে কার্যকর:

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

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

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

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

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

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

প্রিফেচ

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

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

ক্রোম সীমা

অনুমানের নিয়মের অতিরিক্ত ব্যবহার রোধ করতে ক্রোমের সীমাবদ্ধতা রয়েছে:

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

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

ক্রোম কিছু শর্তে জল্পনা -কল্পনাও রোধ করবে:

• সেভ-ডেটা ।
• সক্ষম যখন সক্ষম এবং কম ব্যাটারিতে শক্তি সেভার ।
• স্মৃতির সীমাবদ্ধতা।
• যখন "প্রিলোড পৃষ্ঠাগুলি" সেটিংসটি বন্ধ করা হয় (যা উব্লক উত্সের মতো ক্রোম এক্সটেনশন দ্বারা স্পষ্টভাবে বন্ধ করা হয়)।
• পটভূমি ট্যাবে খোলা পৃষ্ঠাগুলি।

ক্রোম সক্রিয়করণ না হওয়া পর্যন্ত প্রেরেন্ডারড পৃষ্ঠাগুলিতে ক্রস-উত্স আইফ্রেমগুলিও সরবরাহ করে না।

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

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

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

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

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

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

Speculation-Rules এইচটিটিপি শিরোনাম

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

Speculation-Rules এইচটিটিপি শিরোনামটি দস্তাবেজটি দিয়ে ফিরে আসে এবং অনুমানের বিধিগুলি সম্বলিত একটি জেএসওএন ফাইলের অবস্থানের দিকে নির্দেশ করে:

Speculation-Rules: "/speculationrules.json"

এই সংস্থানটি অবশ্যই সঠিক মাইম টাইপটি ব্যবহার করতে হবে এবং এটি যদি ক্রস-উত্সের সংস্থান হয় তবে একটি কর্স চেক পাস করুন।

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

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

অনুমানের নিয়ম এবং স্পা

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

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

অনুমানের নিয়মগুলি ডিবাগ করুন

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

একাধিক জল্পনা বিধি

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

ইউআরএলগুলির তালিকা:

<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 পরামিতিগুলি (প্রযুক্তিগতভাবে অনুসন্ধান পরামিতি হিসাবে পরিচিত) সার্ভার দ্বারা সরবরাহ করা পৃষ্ঠায় গুরুত্বহীন হতে পারে এবং কেবল ক্লায়েন্ট সাইড জাভাস্ক্রিপ্ট দ্বারা ব্যবহৃত হয়।

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

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

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

অনুমানের বিধিগুলি expects_no_vary_search ব্যবহার করে সমর্থন করে যেখানে কোনও 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>

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

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

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

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

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

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

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

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

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

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

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

অনুমানের বিধিগুলি এপিআই সমর্থন সনাক্ত করুন

আপনি স্ট্যান্ডার্ড এইচটিএমএল চেকগুলির সাথে অনুমানের বিধিগুলি এপিআই সমর্থন সনাক্ত করতে পারেন:

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);
}

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

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

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

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

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

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

অনুমানের বিধি বাতিল করুন

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

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

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

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

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

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

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

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

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

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

প্রিরেন্ডারড পৃষ্ঠাগুলি Sec-Purpose এইচটিটিপি শিরোনাম সহ প্রেরণ করা হবে:

Sec-Purpose: prefetch;prerender

অনুমানের নিয়মগুলি ব্যবহার করে প্রিফেচড পৃষ্ঠাগুলি এপিআইয়ের এই শিরোনামটি কেবল prefetch সেট করবে:

Sec-Purpose: prefetch

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

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

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

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

একবার কোনও প্রেরেন্ডারড ডকুমেন্টটি সক্রিয় হয়ে গেলে, PerformanceNavigationTiming activationStart প্রেরেন্ডার শুরু হওয়ার সময় এবং নথিটি আসলে সক্রিয় করা হয়েছিল এমন সময়ের মধ্যে সময়ের প্রতিনিধিত্ব করে একটি শূন্য সময়ও সেট করা হবে।

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

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

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

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

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

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

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

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

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

এটি এমন একটি 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 ব্যবহার করতে চাইতে পারেন PRE প্রেরেন্ডারিং এবং prerenderingchange বিশেষভাবে প্রেরেন্ডারিং পৃষ্ঠাগুলি লক্ষ্য করার জন্য।

প্রেরেন্ডারিংয়ের সময় অন্যান্য সামগ্রী ধরে রাখুন

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

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

<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');

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

যদিও এটি সম্ভবত প্রেরেন্ডারিংয়ের ব্যবহারের সাথে প্রায়শই ঘটে যাওয়ার সম্ভাবনা বেশি থাকে তবে পূর্বে উল্লিখিত ব্যাকগ্রাউন্ড ট্যাবগুলিতে লোড হওয়া পৃষ্ঠাগুলির ক্ষেত্রেও এই শর্তগুলিও সত্য (সুতরাং যখন whenFirstVisible ফাংশনটি whenActivated জায়গায় ব্যবহার করা যেতে পারে)।

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

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
• ডিবাগিং স্পেকুলেশন নিয়ম
• 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

Barry Pollard

The Chrome team has brought back full prerendering of future pages that a user is likely to navigate to.

A brief history of prerender

In the past, Chrome supported the <link rel="prerender" href="/next-page"> resource hint, however it was not broadly supported beyond Chrome, and it wasn't a very expressive API.

This legacy prerendering using the link rel=prerender hint was deprecated in favor of NoState Prefetch , which instead fetched the resources needed by the future page, but did not fully prerender the page nor execute JavaScript. NoState Prefetch does help improve page performance by improving the resource loading, but won't deliver an instant page load like a full prerender would.

The Chrome team has now reintroduced full prerendering back into Chrome. To avoid complications with existing usage, and to allow for future expansion of prerendering, this new prerender mechanism won't use the <link rel="prerender"...> syntax, which remains in place for NoState Prefetch, with a view of retiring this at some point in the future.

How is a page prerendered?

A page can be prerendered in one of four ways, all of which aim to make navigations quicker:

1. When you type a URL into the Chrome address bar (also known as "the omnibox"), Chrome may automatically prerender the page for you, if it has high confidence you will visit that page, based on your previous browsing history.
2. When you use the bookmarks bar, Chrome may automatically prerender the page for you on holding the pointer over one of the bookmark buttons.
3. When you type a search term into the Chrome address bar, Chrome may automatically prerender the search results page, when instructed to do so by the search engine.
4. Sites can use the Speculation Rules API , to programmatically tell Chrome which pages to prerender. This replaces what <link rel="prerender"...> used to do and allows sites to proactively prerender a page based on speculation rules on the page. These can statically exist on the pages, or be dynamically injected by JavaScript as the page owner sees fit.

In each of these cases, a prerender behaves as if the page has been opened in an invisible background tab, and then is "activated" by replacing the foreground tab with that prerendered page. If a page is activated before it has fully prerendered, then its current state is "foregrounded" and continues to load, which means you can still get a good head start.

As the prerendered page is opened in a hidden state, a number of APIs that cause intrusive behaviors (for example, prompts) are not activated in this state, and are instead delayed until the page is activated. In the small number of cases where this is not yet possible, the prerender is canceled. The Chrome team is working on exposing prerender cancellation reasons as an API, and also enhancing DevTools capabilities to make identifying such edge cases easier.

Impact of prerendering

Prerendering allows a near-instant page load as shown in the following video:

The example site is already a fast site, but even with this you can see how prerendering improves the user experience. This can therefore also have a direct impact on a site's Core Web Vitals , with near zero LCP, reduced CLS (since any load CLS happens before the initial view), and improved INP (since the load should be completed before the user interacts).

Even when a page activates before it is fully loaded, having a head start to the page load, should improve the loading experience. When a link is activated while prerendering is still happening, the prerendering page will move to the main frame and continue loading.

However, prerendering does use additional memory and network bandwidth. Be careful not to over-prerender, at a cost of user resources. Only prerender when there is a high likelihood of the page being navigated to.

See the Measuring performance section for more information on how to measure the actual performance impact in your analytics.

View Chrome's address bar predictions

For the first use case, you can view Chrome's predictions for URLs in the chrome://predictors page:

Green lines indicate enough confidence to trigger prerendering. In this example typing "s" gives a reasonable confidence (amber), but once you type "sh" then Chrome has enough confidence that you nearly always navigate to https://sheets.google.com .

This screenshot was taken in a relatively fresh Chrome install, and filtering out zero confidence predictions, but if you view your own predictors you will likely see considerably more entries, and potentially more characters required to reach a high enough confidence level.

These predictors are also what drive the address bar suggested options you may have noticed:

Chrome will continually update its predictors based on your typing and selections.

• For a greater than 50% confidence level (shown in amber), Chrome proactively preconnects to the domain, but does not prerender the page.
• For a greater than 80% confidence level (shown in green), Chrome will prerender the URL.

The Speculation Rules API

For the Speculation Rules API prerender option, web developers can insert JSON instructions onto their pages to inform the browser about which URLs to prerender:

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

Or by document rules (available from Chrome 121), which prerenders links found in the document based on href selectors (based on the URL Pattern API ) or CSS selectors:

<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>

The Chrome team have prepared a Speculation Rules Codelab which will walk you through adding Speculation Rules to a site.

আকুলতা

An eagerness setting is used to indicate when the speculations should fire, which is particularly useful for document rules:

• immediate : This is used to speculate as soon as possible, that is, as soon as the speculation rules are observed.
• eager : This behaves identically to the immediate setting, but in future, we are looking to place this somewhere between immediate and moderate .
• moderate : This performs speculations if you hold the pointer over a link for 200 milliseconds (or on the pointerdown event if that is sooner, and on mobile where there is no hover event).
• conservative : This speculates on pointer or touch down.

The default eagerness for list rules is immediate . The moderate and conservative options can be used to limit list rules to URLs that a user interacts with to a specific list. Though in many cases, document rules with an appropriate where condition may be more appropriate.

The default eagerness for document rules is conservative . Given a document can consist of many URLs, use of immediate or eager for document rules should be used with caution (see also the Chrome limits section next).

Which eagerness setting to use depends on your site. For a lightweight, static site, speculating more eagerly may have little cost and be beneficial for users. Sites with more complex architectures and heavier page payloads may prefer to reduce waste by speculating less often until you get more positive signal of intent from users to limit waste.

The moderate option is a middle ground, and many sites could benefit from the following speculation rule that would prerender a link when holding the pointer over the link for 200 milliseconds or on the pointerdown event as a basic—yet powerful—implementation of speculation rules:

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

প্রিফেচ

Speculation rules can also be used to just prefetch pages, without a full prerender. This can often be a good first step on the road to prerendering:

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

Chrome limits

Chrome has limits in place to prevent overuse of the Speculation Rules API:

The moderate and conservative settings—which depend on user interaction—work in a First In, First Out (FIFO) manner : after reaching the limit, a new speculation will cause the oldest speculation to be canceled and replaced by the newer one to conserve memory. A canceled speculation can be triggered again—for example by hovering over that link again—which will result in that URL being re-speculated, pushing out the oldest speculation. In this case the previous speculation will have cached any cacheable resources in the HTTP Cache for that URL so speculationing a further time should have a reduced cost. This is why the limit is set to the modest threshold of 2. Static list rules are not triggered by a user action and so have a higher limit as it is not possible for the browser to know which are needed and when they are needed.

The immediate and eager limits are also dynamic, so removing a list URL script element will create capacity by canceling those removed speculations.

Chrome will also prevent speculations being used in certain conditions including:

• Save-Data .
• Energy saver when enabled and on low battery.
• স্মৃতির সীমাবদ্ধতা।
• When the "Preload pages" setting is turned off (which is also explicitly turned off by Chrome extensions such as uBlock Origin).
• Pages opened in background tabs.

Chrome also does not render cross-origin iframes on prerendered pages until activation.

All of these conditions aim to reduce the impact of over-speculation when it would be detrimental to users.

How to include speculation rules on a page

Speculation rules can be statically included in the page's HTML or dynamically inserted into the page by JavaScript:

• Statically included speculation rules : For example a news media site, or a blog may prerender the newest article, if that is often the next navigation for a large proportion of users, Alternatively, document rules with a moderate or conservative can be used to speculate as users interact with links.
• Dynamically inserted speculation rules : This could be based on application logic, personalized to the user, or based on other heuristics.

Those favoring dynamic insertion based on actions such as hovering over, or clicking down on a link—as many libraries have done in the past with <link rel=prefetch> —are recommended to look at document rules, as these allow the browser to handle many of your use cases.

Speculation rules can be added in either the <head> or the <body> of in the main frame. Speculation rules in subframes are not acted upon, and speculation rules in prerendered pages are only acted upon once that page is activated.

The Speculation-Rules HTTP header

Speculation rules can also be delivered by using a Speculation-Rules HTTP header, rather than including them directly in the document's HTML. This allows easier deployment by CDNs without the need to alter document contents themselves.

The Speculation-Rules HTTP header is returned with the document, and points to a location of a JSON file containing the speculation rules:

Speculation-Rules: "/speculationrules.json"

This resource must use the correct MIME type and, if it is a cross-origin resource, pass a CORS check.

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

If you want to use relative URLs you may want to include the "relative_to": "document" key in your speculation rules. Otherwise, relative URLs will be relative to the speculation rules JSON file's URL. This may be particularly useful if you need to select some—or all—same-origin links.

Speculation rules and SPAs

Speculation rules are only supported for full page navigations managed by the browser, and not for Single Page Apps (SPA) or app shell pages. These architecture don't use document fetches, but instead make API or partial fetches of data or pages—which are then processed and presented in the current page. The data needed for these so called "soft navigations" can be prefetched by the app outside of speculation rules, but they cannot be prerendered.

Speculation Rules can be used to prerender the application itself from a previous page. This can help offset some of the extra initial load costs some SPAs have. However, route changes within the app cannot be prerendered.

Debug speculation rules

See the dedicated post on debugging speculation rules , for new Chrome DevTools features to assist with viewing and debugging this new API.

Multiple speculation rules

Multiple speculation rules can also be added to the same page, and they append to the existing rules. Therefore, the following different ways all result in both one.html and two.html prerendering:

List of URLs:

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

Multiple speculationrules scripts:

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

Multiple lists within one set of speculationrules

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

No-Vary-Search support

When prefetching or prerendering a page, certain URL parameters (technically known as search parameters ) may be unimportant to the page actually delivered by the server, and only used by client side JavaScript.

For example, UTM parameters are used by Google Analytics for campaign measurement, but usually don't result in different pages being delivered from the server. This means that page1.html?utm_content=123 and page1.html?utm_content=456 will deliver the same page from the server, so the same page can be reused from the cache.

Similarly, applications may use other URL parameters that are only handled client side.

The No-Vary-Search proposal allows a server to specify parameters that don't result in a difference to the resource delivered, and therefore allow a browser to reuse previously cached versions of a document which only differ by these parameters. This is supported in Chrome (and Chromium-based browsers) for navigation speculations for both prefetch and prerender.

Speculation rules support using expects_no_vary_search to indicate where a No-Vary-Search HTTP header is expected to be returned. Doing so can help further avoid unnecessary downloads.

<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>

In this example, the /products initial page HTML is the same for both product IDs 123 and 124 . However, the page contents eventually differ based on client-side rendering using JavaScript to fetch product data using the id search parameter. So we prefetch that URL eagerly and it should return a No-Vary-Search HTTP header showing the page can be used for any id search param.

However, if the user clicks on any of the links before the prefetch has completed, the browser may not have received the /products page. In this case, the browser does not know if it will contain the No-Vary-Search HTTP header. The browser is then left with a choice of whether to fetch the link again, or wait for the prefetch to complete to see if it contains a No-Vary-Search HTTP header. The expects_no_vary_search setting allows the browser to know the page response is expected to contain a No-Vary-Search HTTP header, and to wait for that prefetch to complete.

Speculation rules restrictions and future enhancements

Speculation rules are restricted to pages opened within the same tab, but we are working to reduce that restriction .

By default speculations are restricted to same-origin pages. Speculation same-site cross-origin pages (for example, https://a.example.com could prerender a page on https://b.example.com ). To use this the speculated page ( https://b.example.com in this example) needs to opt-in by including a Supports-Loading-Mode: credentialed-prerender HTTP header or Chrome will cancel the speculation.

Future versions may also allow prerender for non-same-site, cross-origin pages as long as cookies don't exist for the prerendered page and the prerendered page opts in with a similar Supports-Loading-Mode: uncredentialed-prerender HTTP header.

Speculation rules do already support cross-origin prefetches, but again only when cookies for the cross-origin domain don't exist. If cookies exist from the user having visited that site before, then the speculation won't be triggered and will show a failure in DevTools.

Given those current limitations, one pattern that can improve your users experiences for both internal links and external links where possible is to prerender same-origin URLs and attempt to prefetch cross-origin URLs:

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

The restriction to prevent cross-origin speculations for cross-origin links by default is necessary for security. It is an improvement over <link rel="prefetch"> for cross-origin destinations which will also not send cookies but still attempt the prefetch—which will be either result in a wasted prefetch that needs to be resent or, worse still, the incorrect page loading.

Speculation rules are not supported for prefetch for pages controlled by service workers. We are working to add this support. Follow this Support service worker issue for updates. Prerender is supported for service worker-controlled pages.

Detect Speculation Rules API support

You can feature detect Speculation Rules API support with standard HTML checks:

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

Add speculation rules dynamically through JavaScript

This is an example of adding a prerender speculation rule with JavaScript:

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);
}

You can view a demo of Speculation Rules API prerendering, using JavaScript insertion, on this prerender demo page .

Inserting a <script type = "speculationrules"> element directly into the DOM using innerHTML won't register the speculation rules for security reasons and this must be added as shown previously. However content inserted dynamically using innerHTML which contains new links, will be picked up by existing rules on the page.

Similarly, direct editing the Elements panel in Chrome DevTools to add the <script type = "speculationrules"> element does not register the speculation rules and instead the script to dynamically add this to the DOM must be run from the Console to insert the rules.

Add speculation rules through a tag manager

To add speculation rules using a tag manager like Google Tag Manager (GTM) requires these to be inserted through JavaScript, rather than adding the <script type = "speculationrules"> element though GTM directly for the same reasons as mentioned previously:

Note this example uses var as GTM does not support const .

Cancel speculation rules

Removing speculation rules will result in the prerender being cancelled but, by the time this has happened, resources will likely have already been spent to initiate the prerender, so it is recommended not to prerender if there is a likelihood of needing to cancel the prerender.

Speculation rules and Content Security Policy

As speculation rules use a <script> element, even though they only contain JSON, they need to be included in the script-src Content-Security-Policy if the site uses this—either using a hash or nonce.

A new inline-speculation-rules can be added to script-src allowing <script type="speculationrules"> elements injected from hash or nonced scripts to be supported. This does not support rules included in the initial HTML so rules need to be injected by JavaScript for sites that use a strict CSP.

Detect and disable prerendering

Prerender is usually a positive experience for users as it allows fast page rendering—often instant. This benefits both the user, and the site owner, since prerendered pages allow a better user experience that may be difficult to achieve otherwise.

However, there may be instances when you don't want prerendering of pages to happen , for example when pages change state—either based on the initial request, or based on JavaScript executing on the page.

Enable and disable prerender in Chrome

Prerender is only enabled for those Chrome users with the "Preload pages" setting in chrome://settings/performance/ . Additionally, prerender is also disabled on low-memory devices, or if the operating system is in Save-data or Energy saver modes. See the Chrome limits section.

Detect and disable prerender server-side

Prerendered pages will be sent with the Sec-Purpose HTTP header:

Sec-Purpose: prefetch;prerender

Prefetched pages using the Speculation Rules API will have this header set to just prefetch :

Sec-Purpose: prefetch

Servers can respond based on this header, to log speculation requests, return different content, or prevent a prerender from happening. If a non-success final response code is returned—that is, not in the 200-299 range after redirects—then the page won't be prerendered and any prefetch page will be discarded. Note also that 204 and 205 responses are additionally not valid for prerendering , but are valid for prefetch.

If you don't want a particular page to be prerendered, returning a non-2XX response code (such as 503) is the best way to ensure it won't happen. However, to deliver the best experience, it is recommended to instead allow prerendering, but delay any actions that should only happen then the page is actually viewed, using JavaScript.

Detect prerender in JavaScript

The document.prerendering API will return true while the page is prerendering. This can be used by pages to prevent—or delay—certain activities during the prerender until the page is actually activated.

Once a prerendered document is activated, PerformanceNavigationTiming 's activationStart will also be set to a non-zero time representing the time between when the prerender was started and the document was actually activated.

You can have a function to check for prerendering and prerendered pages like the following:

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

The easiest way to see if a page was prerendered (either in full or partially) is to open DevTools after the page is activated and type performance.getEntriesByType('navigation')[0].activationStart in the console. If a non-zero value is returned, you know the page was prerendered:

When the page is activated by the user viewing the page, the prerenderingchange event will be dispatched on the document , which can then be used to enable activities that previously would be started by default on page load but which you want to delay until the page is actually viewed by the user.

Using these APIs, frontend JavaScript can detect and act upon prerendered pages appropriately.

Impact on analytics

Analytics are used to measure website usage, for example using Google Analytics to measure page views, and events. Or by measuring performance metrics of pages using Real User Monitoring (RUM) .

Pages should only be prerendered when there is a high probability the page will be loaded by the user. This is why the Chrome address bar prerendering options only happen when there is such a high probability (greater than 80% of the time).

However—particularly when using the Speculation Rules API—prerendered pages may have an impact on analytics and site owners may need to add extra code to only enable analytics for prerendered pages on activation, as not all analytics providers may do this by default.

This could be achieved by using a Promise which waits for the prerenderingchange event if a document is prerendering, or resolves immediately if it is now:

// 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();

An alternative approach is to delay analytic activities until the page is first made visible, which would cover both the prerendering case, and also when tabs are opened in the background (for example, with right-click and open in new tab):

// 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();

While this may make sense for analytics and similar use cases, in other cases you may want more content loaded for those cases, and so may want to use document.prerendering and prerenderingchange to specifically target prerendering pages.

Hold back other content during prerendering

The same APIs discussed previously can be used to hold back other content during the prerender phase. This can be specific parts of JavaScript or whole script elements that you would prefer not to run during the prerender stage.

For example, given this script:

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

You can change this to a dynamically inserted script element which only inserts based on the previous whenActivated function:

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');

This can be useful to hold back distinct scripts that include analytics, or render content based on state or other variables that can change during the span of a visit. For example, recommendations, or login state, or shopping basket icons could all be held back to ensure the most up to date information is presented.

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
• ডিবাগিং স্পেকুলেশন নিয়ম
• 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