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

ব্যারি পোলার্ড

প্রকাশিত: ২ ডিসেম্বর, ২০২২, সর্বশেষ হালনাগাদ: ২৩ জানুয়ারি, ২০২৬

Browser Support

  • ক্রোম: ১০৯।
  • প্রান্ত: ১০৯।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি: একটি পতাকার আড়ালে।

Source

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

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

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

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

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

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

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

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

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

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

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

নিচের ভিডিওতে দেখানো হয়েছে যে, প্রি-রেন্ডারিংয়ের ফলে পেজ প্রায় সঙ্গে সঙ্গেই লোড হয়।

প্রি-রেন্ডারিংয়ের প্রভাবের উদাহরণ।

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

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

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

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

ক্রোমের অ্যাড্রেস বারের পূর্বাভাস দেখুন

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

প্রবেশ করানো টেক্সটের উপর ভিত্তি করে ক্রোম প্রেডিক্টরস পেজটি নিম্ন (ধূসর), মাঝারি (হলুদ) এবং উচ্চ (সবুজ) প্রেডিকশন দেখানোর জন্য ফিল্টার করা হয়েছে।
ক্রোম প্রেডিক্টরস পৃষ্ঠা।

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

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

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

ক্রোম অ্যাড্রেস বারের 'টাইপহেড' বৈশিষ্ট্য
অ্যাড্রেস বারের 'টাইপহেড' বৈশিষ্ট্য।

আপনার টাইপিং এবং নির্বাচনের উপর ভিত্তি করে ক্রোম ক্রমাগত তার পূর্বাভাসগুলো আপডেট করবে।

  • ৩০%-এর বেশি কনফিডেন্স লেভেলের ক্ষেত্রে (যা অ্যাম্বার রঙে দেখানো হয়), ক্রোম সক্রিয়ভাবে ডোমেইনের সাথে আগে থেকেই সংযোগ স্থাপন করে, কিন্তু পেজটি আগে থেকে রেন্ডার করে না।
  • ৫০% এর বেশি কনফিডেন্স লেভেলের জন্য (সবুজ রঙে দেখানো), ক্রোম ইউআরএলটি প্রি-রেন্ডার করবে।

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

Speculation Rules API-এর প্রি-রেন্ডার অপশনের মাধ্যমে, ওয়েব ডেভেলপাররা তাদের পেজে JSON নির্দেশনা যোগ করতে পারেন, যা ব্রাউজারকে জানিয়ে দেয় কোন URL-গুলো প্রি-রেন্ডার করতে হবে।

ইউআরএল তালিকা

অনুমানের নিয়মগুলো ইউআরএল-এর তালিকার উপর ভিত্তি করে তৈরি করা যেতে পারে:

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

নথির নিয়মাবলী

where সিনট্যাক্স ব্যবহার করে স্পেকুলেশন রুলগুলো 'ডকুমেন্ট রুল' হিসেবেও কাজ করতে পারে। এটি href সিলেক্টর ( URL Pattern 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>

আগ্রহ

Browser Support

  • ক্রোম: ১২১।
  • প্রান্ত: ১২১।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি: একটি পতাকার আড়ালে।

Source

স্পেকুলেশনগুলো কখন সক্রিয় হবে তা নির্দেশ করতে একটি eagerness সেটিং ব্যবহার করা হয়, যা বিশেষত ডকুমেন্ট রুলগুলোর জন্য উপযোগী:

  • conservative : এটি পয়েন্টার বা টাচ ডাউন নিয়ে অনুমান করে।
  • moderate : ডেস্কটপে, আপনি যদি কোনো লিঙ্কের উপর ২০০ মিলিসেকেন্ডের জন্য পয়েন্টার ধরে রাখেন (অথবা তার আগেই যদি pointerdown ইভেন্ট ঘটে, এবং মোবাইলে যেখানে hover ইভেন্ট নেই), তাহলে এটি স্পেকুলেশন সম্পাদন করে। মোবাইলে, আমরা আগস্ট ২০২৫ থেকে এটিকে জটিল ভিউপোর্ট হিউরিস্টিকসের উপর ভিত্তি করে পরিবর্তন করেছি। জটিল ভিউপোর্ট হিউরিস্টিকস ব্যবহারকারী স্ক্রোলিং বন্ধ করার ৫০০ মিলিসেকেন্ড পরে ট্রিগার হয়, পূর্ববর্তী পয়েন্টার ডাউন থেকে উল্লম্ব দূরত্বের ৩০% এর মধ্যে থাকা অ্যাঙ্করগুলির জন্য, যেখানে অ্যাঙ্করগুলি ভিউপোর্টের বৃহত্তম অ্যাঙ্করের চেয়ে কমপক্ষে ০.৫ গুণ বড়। যেমনটি এই ডকুমেন্টে বর্ণনা করা হয়েছে ।
  • eager : এই eagerness আগে immediate এর মতোই কাজ করত, কিন্তু Chrome 143 থেকে এটি পরিবর্তিত হয়েছে। ডেস্কটপে, আপনি যদি কোনো লিঙ্কের উপর ১০ মিলিসেকেন্ডের জন্য পয়েন্টার ধরে রাখেন, তবে এটি কিছু অনুমানমূলক কাজ করে। মোবাইলের জন্য, জানুয়ারি ২০২৬ থেকে আমরা এটিকে simple viewport heuristics-এর উপর ভিত্তি করে পরিবর্তন করেছি। অ্যাঙ্করটি ভিউপোর্টে প্রবেশ করার ৫০ মিলিসেকেন্ড পরে simple viewport heuristics সক্রিয় হয়।
  • immediate : এটি যত তাড়াতাড়ি সম্ভব অনুমান করার জন্য ব্যবহৃত হয়, অর্থাৎ, অনুমানের নিয়মগুলি পালন করার সাথে সাথেই।

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

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

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

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

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

প্রিফেচ

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

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

Prerender until script

ক্রোম টিম স্পেকুলেশন রুলস এপিআই-তে prerender_until_script যোগ করার জন্যও কাজ করছে (দেখুন: ইমপ্লিমেন্টেশন বাগ )। এটি prefetch এবং prerender-এর মধ্যবর্তী একটি ধাপ হবে এবং একই পদ্ধতিতে ব্যবহৃত হবে:

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

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

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

এর ফলে জাভাস্ক্রিপ্ট কার্যকর হওয়ার ফলে সৃষ্ট অনাকাঙ্ক্ষিত পার্শ্বপ্রতিক্রিয়ার ঝুঁকি এড়ানো যাবে, কিন্তু শুধু prefetch চেয়ে অনেক বেশি পারফরম্যান্সের উন্নতি ঘটবে।

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

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

আগ্রহ প্রিফেচ প্রি-রেন্ডার
immediate ৫০ ১০
eager / moderate / conservative ২ (FIFO) ২ (FIFO)
ক্রোমে অনুমানের সীমাবদ্ধতা।

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

যেহেতু এটি একটি কম সুনির্দিষ্ট হিউরিস্টিক, তাই ক্রোম মোবাইলের জন্য eager এবং moderate সীমা অন্তত প্রিফেচের ক্ষেত্রে ৫ পর্যন্ত বাড়ানোর কথাও বিবেচনা করছে । যেসব ডেভেলপার eager ব্যবহার করেন, তারা ভিউপোর্টে একাধিক লিঙ্ক উপলব্ধ থাকলে এর পাশাপাশি conservative নিয়ম ব্যবহার করার কথা ভাবতে পারেন, যাতে প্রথম দুটি লিঙ্কের একটি হিসেবে নির্বাচিত না হলেও সেগুলো স্পেকুলেট করতে পারে।

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

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

  • ডেটা সংরক্ষণ করুন ।
  • চালু থাকলে এবং ব্যাটারি কম থাকলে এনার্জি সেভার মোড চালু থাকে।
  • মেমরির সীমাবদ্ধতা।
  • যখন "Preload pages" সেটিংটি বন্ধ করা থাকে (যা uBlock Origin-এর মতো Chrome এক্সটেনশনগুলো দ্বারাও স্পষ্টভাবে বন্ধ করা থাকে)।
  • পেজগুলো ব্যাকগ্রাউন্ড ট্যাবে খোলা হয়েছে।

ক্রোম অ্যাক্টিভেশনের আগ পর্যন্ত প্রি-রেন্ডার করা পেজগুলিতে ক্রস-অরিজিন আইফ্রেমও রেন্ডার করে না।

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

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

স্পেকুলেশন রুলগুলো পেজের HTML-এ স্ট্যাটিক্যালি অন্তর্ভুক্ত করা যেতে পারে অথবা জাভাস্ক্রিপ্টের মাধ্যমে পেজে ডাইনামিক্যালি সন্নিবেশ করা যেতে পারে:

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

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

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

Speculation-Rules HTTP হেডার

Browser Support

  • ক্রোম: ১২১।
  • প্রান্ত: ১২১।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি: একটি পতাকার আড়ালে।

Source

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

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

Browser Support

  • ক্রোম: ১৩৬।
  • প্রান্ত: ১৩৬।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি: একটি পতাকার আড়ালে।

Source

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

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

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

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

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

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

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

রুলসেট ট্যাগগুলি ক্রোম ডেভটুলস-এও প্রদর্শিত হয়।

অনুমান নিয়ম target_hint ক্ষেত্র

Browser Support

  • ক্রোম: ১৩৮।
  • প্রান্ত: ১৩৮।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি সমর্থিত নয়।

Source

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

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

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

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

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

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

জল্পনা-কল্পনার নিয়ম এবং এসপিএ

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

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

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

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

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

একই পৃষ্ঠায় একাধিক স্পেকুলেশন নিয়মও যোগ করা যেতে পারে, এবং সেগুলি বিদ্যমান নিয়মগুলির সাথে যুক্ত হয়। অতএব, নিম্নলিখিত বিভিন্ন উপায়গুলির সবকটির ফলেই 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>

Browser Support

  • ক্রোম: ১৪১।
  • প্রান্ত: ১৪১।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি সমর্থিত নয়।

Source

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

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

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

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

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

<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 No-Vary-Search HTTP হেডার আছে কি না। expects_no_vary_search সেটিংটি ব্রাউজারকে বুঝতে সাহায্য করে যে পেজ রেসপন্সে একটি No-Vary-Search HTTP হেডার থাকার কথা, এবং সেই প্রিফেচটি সম্পূর্ণ হওয়া পর্যন্ত অপেক্ষা করতে বলে।

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

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

জল্পনা-কল্পনার নিয়মকানুন, সীমাবদ্ধতা এবং ভবিষ্যৎ উন্নয়ন

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

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

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

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

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

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

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

অনুমান নিয়ম সনাক্তকরণ এপিআই সমর্থন

আপনি সাধারণ HTML চেকের মাধ্যমে স্পেকুলেশন রুলস 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);
}

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

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

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

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

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

গুগল ট্যাগ ম্যানেজারে কাস্টম এইচটিএমএল ট্যাগ কনফিগারেশন
গুগল ট্যাগ ম্যানেজারের মাধ্যমে স্পেকুলেশন রুল যোগ করা।

উল্লেখ্য, এই উদাহরণে var ব্যবহার করা হয়েছে, কারণ GTM const সমর্থন করে না।

জল্পনা বাতিলের নিয়ম

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

Browser Support

  • ক্রোম: ১৩৮।
  • প্রান্ত: ১৩৮।
  • ফায়ারফক্স সমর্থিত নয়।
  • সাফারি সমর্থিত নয়।

Source

Clear-Site-Data HTTP হেডার এবং prefetchCache ও prerenderCache ডিরেক্টিভ ব্যবহার করেও স্পেকুলেশন বাতিল করা যায়।

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

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

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

যেহেতু স্পেকুলেশন রুলগুলিতে একটি <script> এলিমেন্ট ব্যবহৃত হয়, যদিও সেগুলিতে শুধুমাত্র JSON থাকে, তাই সাইটটি যদি Content-Security-Policy ব্যবহার করে, তবে সেগুলিকে অবশ্যই script-src মধ্যে অন্তর্ভুক্ত করতে হবে—হয় হ্যাশ অথবা ননস ব্যবহার করে।

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

প্রি-রেন্ডারিং সনাক্ত করুন এবং নিষ্ক্রিয় করুন

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

তবে, এমন পরিস্থিতিও আসতে পারে যখন আপনি পেজের প্রি-রেন্ডারিং চান না , যেমন—প্রাথমিক অনুরোধের ভিত্তিতে অথবা পেজে জাভাস্ক্রিপ্ট চলার কারণে পেজের অবস্থার পরিবর্তন হলে।

ক্রোমে প্রি-রেন্ডার চালু এবং বন্ধ করুন

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

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

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

Sec-Purpose: prefetch;prerender

Speculation Rules API ব্যবহার করে প্রিফেচ করা পেজগুলিতে এই হেডারটি শুধু prefetch জন্য সেট করা থাকবে: 

Sec-Purpose: prefetch

সার্ভারগুলো এই হেডারের উপর ভিত্তি করে সাড়া দিতে পারে, যেমন—স্পেকুলেশন রিকোয়েস্ট লগ করতে, ভিন্ন কন্টেন্ট ফেরত দিতে, অথবা প্রি-রেন্ডার হওয়া থেকে বিরত রাখতে। যদি একটি অসফল চূড়ান্ত রেসপন্স কোড ফেরত আসে—অর্থাৎ, রিডাইরেক্টের পর কোডটি ২০০-২৯৯ রেঞ্জের মধ্যে না থাকে—তাহলে পেজটি প্রি-রেন্ডার হবে না এবং যেকোনো প্রিফেচ পেজ বাতিল হয়ে যাবে। আরও উল্লেখ্য যে, ২০৪ এবং ২০৫ রেসপন্সগুলো প্রি-রেন্ডারিংয়ের জন্য বৈধ নয় , কিন্তু প্রিফেচের জন্য বৈধ।

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

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

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

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

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

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

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

ক্রোম ডেভটুলসের কনসোলে একটি ইতিবাচক activationStart দেখাচ্ছে, যা নির্দেশ করে যে পৃষ্ঠাটি প্রি-রেন্ডার করা হয়েছে।
কনসোলে প্রি-রেন্ডার পরীক্ষা করা হচ্ছে।

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

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

অ্যানালিটিক্সের উপর প্রভাব

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.

কৃতজ্ঞতা স্বীকার

Thumbnail image by Marc-Olivier Jodoin on Unsplash