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

Barry Pollard

ব্রাউজার সমর্থন

• 109
• 109
• এক্স
• এক্স

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 বা CSS নির্বাচকদের উপর ভিত্তি করে নথিতে পাওয়া লিঙ্কগুলিকে প্রি-রেন্ডার করে:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

দ্রষ্টব্য: স্পেকুলেশন রুলস এপিআই একটি source কী অন্তর্ভুক্ত করতে ব্যবহৃত হয় যা তালিকা ইউআরএল বা ডকুমেন্ট ইউআরএলগুলির জন্য document জন্য list সেট করা হয়েছিল কিন্তু যেহেতু এটি একটি urls বা where কী (যা পারস্পরিকভাবে একচেটিয়া) এর উপস্থিতি থেকে বোঝানো যেতে পারে, এই প্রয়োজনীয়তা ছিল Chrome 121 থেকে সরানো হয়েছে। আপনি এখনও কিছু সাইট বা উদাহরণ কোডে এই source কী ব্যবহার করা দেখতে পারেন।

আকুলতা

ব্রাউজার সমর্থন

• 121
• 121
• এক্স
• এক্স

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

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

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

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

প্রিফেচ

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

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

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

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

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

আগ্রহ	প্রিফেচ	প্রি-রেন্ডার
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

ক্রোমে জল্পনা সীমা।

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

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

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

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

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

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

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

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

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

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

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

Speculation-Rules HTTP হেডার

ব্রাউজার সমর্থন

• 121
• 121
• এক্স
• এক্স

উৎস

নথির এইচটিএমএলে সরাসরি অন্তর্ভুক্ত না করে 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 সমর্থন

ব্রাউজার সমর্থন

• 121
• 121
• এক্স
• এক্স

উৎস

একটি পৃষ্ঠা প্রিফেচ বা প্রি-রেন্ডার করার সময়, নির্দিষ্ট 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 শিরোনাম সহ নির্বাচন করে), এবং নতুন ট্যাবে প্রিরেন্ডারিং সক্ষম করে ।

স্পেকুলেশন রুলস 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 প্রিরেন্ডারিংয়ের একটি ডেমো দেখতে পারেন।

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

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

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

যেহেতু অনুমানের নিয়মগুলি একটি <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 বা একটি 304 নয়), তাহলে পৃষ্ঠাটি প্রি-রেন্ডার করা হবে না এবং যেকোনো প্রিফেচ পৃষ্ঠা বাতিল করা হবে।

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

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

পৃষ্ঠাটি প্রিরেন্ডারিং করার সময় 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 ডিবাগিং বৈশিষ্ট্যগুলি প্রিফেচ করা এবং প্রি-রেন্ডার করা পৃষ্ঠাগুলি ডিবাগ করার জন্য উপলব্ধ৷ আরো বিস্তারিত জানার জন্য ডিবাগিং অনুমান নিয়ম পোস্ট দেখুন.

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

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

সতর্কতা: PerformanceNavigationTiming.type prerender মান ব্যবহার করে না, যা পুরোনো, আসল <link rel="prerender"...> নেভিগেশন টাইপের জন্য ছিল। এটি ভবিষ্যতে পরিবর্তিত হতে পারে তবে আপাতত, ক্লায়েন্টদের প্রিরেন্ডারিং পৃষ্ঠাগুলি সনাক্ত করতে document.prerendering API ব্যবহার করা উচিত এবং একটি নন-জিরো PerformanceNavigationTiming.activationStart ফিল্ড ব্যবহার করা উচিত প্রি-রেন্ডার করা পৃষ্ঠাগুলি সনাক্ত করতে যা সক্রিয় করা হয়েছে৷

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

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

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

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

দ্রষ্টব্য: Google Analytics ডিফল্টরূপে সক্রিয় হওয়া পর্যন্ত বিলম্ব করে প্রি-রেন্ডার পরিচালনা করে। Google প্রকাশক ট্যাগ (GPT), এবং Google Adsense একইভাবে সক্রিয় হওয়া পর্যন্ত বিলম্ব করে।

এটি এমন একটি 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);
  } else {
    resolve();
  }
});

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

initAnalytics();

কর্মক্ষমতা যাচাই

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

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

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

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

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

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

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

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

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

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

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

স্বীকৃতি

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