ঝটপট পৃষ্ঠা নেভিগেট করার জন্য Chrome-এ পৃষ্ঠা প্রিরেন্ডার করা

Barry Pollard

প্রকাশিত: ২ ডিসেম্বর, ২০২২, শেষবার আপডেট করা হয়েছে: ২৯ অক্টোবর, ২০২৬

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

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

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

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

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

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

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

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

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

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

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

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

প্রিরেন্ডারিংয়ের মাধ্যমে প্রায় সঙ্গে সঙ্গে পৃষ্ঠা লোড করা যায়, যেমনটি নিম্নলিখিত ভিডিওতে দেখানো হয়েছে:

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

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

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

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

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

Chrome-এর অ্যাড্রেস বার সংক্রান্ত অনুমান দেখুন

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

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

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

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

এইসব প্রেডিক্টর অ্যাড্রেস বারে সাজেস্ট করা বিকল্পও দেখায়, যা আপনি হয়ত লক্ষ্য করেছেন:

Chrome অ্যাড্রেস বারের 'টাইপঅ্যাহেড' ফিচার
অ্যাড্রেস বারের 'টাইপঅ্যাহেড' ফিচার।

আপনার টাইপ করা ও বেছে নেওয়া বিকল্পের উপর ভিত্তি করে Chrome ক্রমাগত তার প্রেডিক্টর আপডেট করবে।

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

Speculation Rules API

Speculation Rules API প্রিরেন্ডার বিকল্পের জন্য, ওয়েব ডেভেলপাররা তাদের পৃষ্ঠায় JSON নির্দেশাবলী যোগ করতে পারেন যাতে কোন URL প্রিরেন্ডার করতে হবে তা ব্রাউজারকে জানানো যায়।

URL তালিকা

স্পেকুলেশন রুল URL-এর তালিকার উপর ভিত্তি করে হতে পারে:

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

ডকুমেন্ট সংক্রান্ত নিয়ম

এছাড়াও, where সিনট্যাক্স ব্যবহার করে স্পেকুলেশন রুল "ডকুমেন্ট রুল" হতে পারে। এটি href সিলেক্টর (URL প্যাটার্ন 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

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

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

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

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

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

কোন 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

এছাড়াও, Chrome টিম Speculation Rules API-তে prerender_until_script যোগ করার জন্য কাজ করছে (দেখুন: ইমপ্লিমেন্টেশন সংক্রান্ত সমস্যা)। এটি প্রিফেচ ও প্রিরেন্ডারের মধ্যবর্তী একটি ধাপ এবং একই পদ্ধতিতে ব্যবহার করা হবে:

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

NoState prefetch-এর মতো এটিও HTML ডকুমেন্ট এবং সেই HTML-এ উপলভ্য সাবরিসোর্স প্রিফেচ করবে। তবে, এটি তার থেকেও বেশি কিছু করবে এবং প্রথম স্ক্রিপ্ট না পাওয়া পর্যন্ত পৃষ্ঠা প্রিরেন্ডার করা শুরু করবে।

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

এটি JavaScript এক্সিকিউট করার ফলে অনিচ্ছাকৃত পার্শ্বপ্রতিক্রিয়ার ঝুঁকি এড়াবে, তবে শুধু prefetch-এর চেয়ে অনেক বেশি পারফর্ম্যান্সের সুবিধা দেবে।

Chrome-এর সীমা

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

আগ্রহ আগে থেকে লোড করা প্রিরেন্ডার
immediate 50 10
মোবাইলে eager / moderate 6 (FIFO) ২ (FIFO)
ডেস্কটপে eager / moderate ২ (FIFO) ২ (FIFO)
conservative ২ (FIFO) ২ (FIFO)
Chrome-এ স্পেকুলেশন সংক্রান্ত সীমা।

eager, moderate ও conservative সেটিংস—যা ব্যবহারকারীর ইন্টার‍্যাকশনের উপর নির্ভর করে—ফার্স্ট ইন, ফার্স্ট আউট (FIFO) পদ্ধতিতে কাজ করে: সীমায় পৌঁছে যাওয়ার পরে, নতুন স্পেকুলেশন হলে, মেমরি বাঁচানোর জন্য সবচেয়ে পুরনো স্পেকুলেশন বাতিল করে নতুনটি দিয়ে রিপ্লেস করা হবে।

বাতিল করা অনুমান আবার ট্রিগার করা যেতে পারে—যেমন, সেই লিঙ্কের উপর আবার মাউস নিয়ে গেলে—যার ফলে সেই URL আবার অনুমান করা হবে এবং সবচেয়ে পুরনো অনুমানটি সরিয়ে দেওয়া হবে। এই ক্ষেত্রে, আগের স্পেকুলেশন সেই URL-এর জন্য HTTP ক্যাশেতে যেকোনও ক্যাশে করা যায় এমন রিসোর্স ক্যাশে করবে, তাই আরও একবার স্পেকুলেশন করলে খরচ কম হবে। এই কারণেই ডিফল্ট হিসেবে থ্রেশহোল্ড ২-এ সেট করা থাকে। মোবাইলে প্রিফেচ করার জন্য আমরা ৬-এর বেশি থ্রেশহোল্ড ব্যবহার করি কারণ সেখানে কোনও "হোভার" নেই, বিকল্প মোবাইল ভিউপোর্ট হিউরিস্টিক কম সঠিক এবং প্রিরেন্ডারের চেয়ে প্রিফেচ কম ব্যয়বহুল (মোবাইলে প্রিরেন্ডারের জন্য আমরা ২-এর সীমা রাখি)।

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

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

immediate-এর সীমাও ডায়নামিক, তাই list URL স্ক্রিপ্ট এলিমেন্ট সরিয়ে দিলে, সেই সরানো অনুমান বাতিল করে ক্যাপাসিটি তৈরি করা হবে।

এছাড়াও, Chrome নির্দিষ্ট কিছু পরিস্থিতিতে স্পেকুলেশন ব্যবহার করা আটকাবে, যার মধ্যে রয়েছে:

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

এছাড়াও, অ্যাক্টিভেশন না হওয়া পর্যন্ত Chrome প্রিরেন্ডার করা পৃষ্ঠায় ক্রস-অরিজিন iframe রেন্ডার করে না।

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

কোনও পৃষ্ঠায় কীভাবে স্পেকুলেশন রুল অন্তর্ভুক্ত করবেন

অনুমান সংক্রান্ত নিয়ম পৃষ্ঠার HTML-এ স্ট্যাটিক হিসেবে অন্তর্ভুক্ত করা যেতে পারে অথবা JavaScript-এর মাধ্যমে পৃষ্ঠায় ডায়নামিক হিসেবে যোগ করা যেতে পারে:

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

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

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

Speculation-Rules HTTP হেডার

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

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

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

স্পেকুলেশন রুল ট্যাগ ফিল্ড

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

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

এছাড়াও, রুলসেট ট্যাগ Chrome DevTools-এ দেখানো হয়।

স্পেকুলেশন রুল target_hint ফিল্ড

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

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>

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

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

স্পেকুলেশন রুল ও SPA

ব্রাউজার দ্বারা ম্যানেজ করা সম্পূর্ণ পৃষ্ঠা নেভিগেশনের জন্য স্পেকুলেশন রুল কাজ করে, তবে সিঙ্গেল পেজ অ্যাপ (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>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

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

যেমন, ক্যাম্পেন পরিমাপের জন্য Google Analytics-এর মাধ্যমে UTM প্যারামিটার ব্যবহার করা হয়, তবে সাধারণত সার্ভার থেকে বিভিন্ন পৃষ্ঠা ডেলিভার করার ক্ষেত্রে এর কোনও ভূমিকা থাকে না। এর অর্থ হল, page1.html?utm_content=123 এবং page1.html?utm_content=456 সার্ভার থেকে একই পৃষ্ঠা ডেলিভার করবে, তাই একই পৃষ্ঠা ক্যাশে থেকে আবার ব্যবহার করা যাবে।

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

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

স্পেকুলেশন রুল 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>

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

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

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

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

স্পেকুলেশন রুল সংক্রান্ত বিধিনিষেধ ও ভবিষ্যতে আরও উন্নত করা

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

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

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

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

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

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

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

Speculation Rules API সাপোর্ট শনাক্ত করা

আপনি স্ট্যান্ডার্ড HTML চেকের মাধ্যমে Speculation Rules 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 Tag Manager (GTM)-এর মতো ট্যাগ ম্যানেজার ব্যবহার করে স্পেকুলেশন রুল যোগ করতে হলে, এগুলি JavaScript-এর মাধ্যমে যোগ করতে হবে। আগে উল্লেখ করা একই কারণে GTM-এর মাধ্যমে সরাসরি <script type = "speculationrules"> এলিমেন্ট যোগ করলে চলবে না:

Google Tag Manager-এ কাস্টম HTML ট্যাগ কনফিগার করা
Google Tag Manager-এর মাধ্যমে স্পেকুলেশন রুল যোগ করা।

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

স্পেকুলেশন রুল বাতিল করুন

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

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

সার্ভারে স্ট্যাটাস পরিবর্তন করা হলে এটি কাজে লাগতে পারে। যেমন, "add-to-basket" API বা লগ-ইন বা লগ-আউট API কল করার সময়।

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

স্পেকুলেশন রুল ও কন্টেন্ট নিরাপত্তা নীতি

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

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

প্রিরেন্ডারিং শনাক্ত ও বন্ধ করা

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

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

Chrome-এ প্রিরেন্ডার চালু ও বন্ধ করা

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

সার্ভার-সাইডে প্রিরেন্ডার শনাক্ত ও বন্ধ করা

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

Sec-Purpose: prefetch;prerender

Speculation Rules API ব্যবহার করে প্রিফেচ করা পৃষ্ঠার ক্ষেত্রে এই হেডার শুধু prefetch-এ সেট করা থাকবে:

Sec-Purpose: prefetch

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

আপনি যদি কোনও নির্দিষ্ট পৃষ্ঠা প্রিরেন্ডার করতে না চান, তাহলে এটি যাতে না ঘটে তা নিশ্চিত করার সবচেয়ে ভালো উপায় হল নন-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 টাইপ করা। শূন্য নয় এমন ভ্যালু রিটার্ন করা হলে, আপনি জানতে পারবেন যে পৃষ্ঠাটি প্রিরেন্ডার করা হয়েছে:

Chrome DevTools-এ কনসোল একটি পজিটিভ activationStart দেখাচ্ছে যা ইঙ্গিত করে যে পৃষ্ঠাটি প্রিরেন্ডার করা হয়েছে
কনসোলে প্রিরেন্ডার টেস্ট করা।

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

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

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

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

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

তবে—বিশেষ করে Speculation Rules 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 ব্যবহার করা যেতে পারে। এটি JavaScript-এর নির্দিষ্ট অংশ বা সম্পূর্ণ স্ক্রিপ্ট এলিমেন্ট হতে পারে যা আপনি প্রিরেন্ডার স্টেজে চালাতে চান না।

যেমন, এই স্ক্রিপ্টটি দেখুন:

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

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

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

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

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

পারফরম্যান্স পরিমাপ করতে

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

Core Web Vitals-এর ক্ষেত্রে, Chrome User Experience Report-এর মাধ্যমে Chrome-এর দ্বারা পরিমাপ করা হয়, এগুলি ব্যবহারকারীর অভিজ্ঞতা পরিমাপ করার উদ্দেশ্যে করা হয়। তাই, অ্যাক্টিভেশন সময়ের উপর ভিত্তি করে এগুলি পরিমাপ করা হয়। এর ফলে প্রায়ই ০ সেকেন্ডের LCP পাওয়া যায়, যা আপনার Core Web Vitals উন্নত করার একটি দুর্দান্ত উপায়।

3.1.0 ভার্সন থেকে, web-vitals লাইব্রেরি আপডেট করা হয়েছে যাতে Chrome যেভাবে Core Web Vitals পরিমাপ করে ঠিক সেইভাবেই প্রিরেন্ডার করা নেভিগেশন ম্যানেজ করা যায়। পৃষ্ঠাটি সম্পূর্ণ বা আংশিকভাবে প্রিরেন্ডার করা হলে, এই ভার্সনটি 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') ব্যবহার করে প্রিরেন্ডারিং সাপোর্ট করে কিনা তা চেক করার পরে—প্রিরেন্ডারের অনুরোধ করা হয়েছে কিনা তা বোঝাতে। (মনে রাখবেন, প্রিরেন্ডারের অনুরোধ করা হয়েছে মানেই যে প্রিরেন্ডার শুরু বা সম্পূর্ণ হয়েছে তা নয়। আগে যেমন বলা হয়েছে, প্রিরেন্ডার হল ব্রাউজারের জন্য একটি ইঙ্গিত এবং এটি ব্যবহারকারীর সেটিংস, বর্তমান মেমরির ব্যবহার বা অন্যান্য হিউরিস্টিকসের উপর ভিত্তি করে পৃষ্ঠাগুলি প্রিরেন্ডার না করার সিদ্ধান্ত নিতে পারে।)

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

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

মনে রাখবেন, অ্যাড্রেস বার প্রিরেন্ডারিংয়ের কারণে কিছু প্রিরেন্ডারিং হতে পারে এবং শুধু আপনার স্পেকুলেশন রুল নয়। আপনি যদি এগুলি আলাদা করতে চান, তাহলে document.referrer (যা প্রিরেন্ডার করা অ্যাড্রেস বার নেভিগেশন সহ অ্যাড্রেস বার নেভিগেশনের জন্য ফাঁকা থাকবে) চেক করতে পারেন।

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

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

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

মতামত

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

স্বীকৃতি

Unsplash-এ Marc-Olivier Jodoin-এর তোলা থাম্বনেল ছবি