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

Barry Pollard

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

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

অতিরিক্ত বৈশিষ্ট্য

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

নথির নিয়ম

পূর্বে, স্পেকুলেশন রুলস API প্রিফেচ বা প্রি-রেন্ডার করার জন্য ইউআরএলগুলির একটি তালিকা নির্দিষ্ট করে কাজ করত:

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

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

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

একটি বিকল্প হিসাবে, নথির নিয়মগুলি ব্যবহার করে স্বয়ংক্রিয় লিঙ্ক অনুসন্ধানের জন্য একটি নতুন বিকল্প অফার করতে আমরা উত্তেজিত৷ এটি একটি where শর্তের উপর ভিত্তি করে ডকুমেন্ট থেকে ইউআরএল সোর্স করে কাজ করে। এটি লিঙ্কগুলির উপর ভিত্তি করে করা যেতে পারে:

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

CSS নির্বাচকদের একটি বিকল্প হিসাবে ব্যবহার করা যেতে পারে, বা বর্তমান পৃষ্ঠায় লিঙ্কগুলি খুঁজতে href মিলের সাথে একত্রে ব্যবহার করা যেতে পারে:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

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

অবশ্যই, একটি পৃষ্ঠায় সমস্ত লিঙ্ক প্রি-রেন্ডার করা অবশ্যই অপব্যয় হবে, তাই এই নতুন ক্ষমতার সাথে, আমরা একটি eagerness সেটিং চালু করেছি।

আকুলতা

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

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

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

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

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

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

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

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

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

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

এমনকি eagerness পছন্দের সাথেও, এই API-এর অতিরিক্ত ব্যবহার রোধ করার জন্য Chrome-এর সীমাবদ্ধতা রয়েছে:

moderate এবং conservative সেটিংস—যা ব্যবহারকারীর ইন্টারঅ্যাকশনের উপর নির্ভর করে—একটি ফার্স্ট ইন, ফার্স্ট আউট (FIFO) পদ্ধতিতে কাজ করে। সীমাতে পৌঁছানোর পরে, একটি নতুন অনুমান বাতিল হয়ে যাবে এবং স্মৃতি সংরক্ষণের জন্য নতুনটি দ্বারা প্রতিস্থাপিত হবে।

ব্যবহারকারীদের দ্বারা moderate এবং conservative অনুমানগুলি ট্রিগার করা হয় তা আমাদের মেমরি সংরক্ষণের জন্য 2 এর আরও বিনয়ী থ্রেশহোল্ড ব্যবহার করতে দেয়। immediate এবং eager সেটিংসগুলি ব্যবহারকারীর ক্রিয়া দ্বারা ট্রিগার হয় না এবং তাই একটি উচ্চ সীমা থাকে কারণ কোনটি প্রয়োজন এবং কখন সেগুলি প্রয়োজন তা ব্রাউজারের পক্ষে জানা সম্ভব নয়৷

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

immediate এবং eager সীমাও গতিশীল। এই আগ্রহের মাত্রাগুলি ব্যবহার করে একটি অনুমান নিয়মের স্ক্রিপ্ট উপাদানগুলি সরানো সেই অপসারিত অনুমানগুলি বাতিল করে ক্ষমতা তৈরি করবে। এই URLগুলিকে আবার অনুমান করা যেতে পারে যদি সেগুলি একটি নতুন URL স্ক্রিপ্টে অন্তর্ভুক্ত করা হয় এবং সীমাতে পৌঁছানো না হয়৷

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

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

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

ঐচ্ছিক source

Chrome 122 source কীটিকে ঐচ্ছিক করে তোলে কারণ এটি url বা where কী আছে তা থেকে অনুমান করা যেতে পারে। এই দুটি অনুমান নিয়ম তাই অভিন্ন:

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

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

Speculation-Rules HTTP হেডার

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

আরও ভাল ক্যাশে পুনঃব্যবহার

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

এটি পুনরায় অনুমান করা (উদাহরণস্বরূপ, একটি moderate আগ্রহের সেটিং সহ নথির নিয়মগুলির জন্য) যথেষ্ট সস্তা করে তোলে, কারণ ক্রোম ক্যাশেযোগ্য সংস্থানগুলির জন্য HTTP ক্যাশে ব্যবহার করবে।

ক্যাশে পুনঃব্যবহার আরও উন্নত করতে আমরা নতুন No-Vary-Search প্রস্তাবকে সমর্থন করি।

No-Vary-Search সমর্থন

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

উদাহরণস্বরূপ, প্রচারাভিযান পরিমাপের জন্য ইউটিএম প্যারামিটারগুলি গুগল অ্যানালিটিক্স দ্বারা ব্যবহার করা হয়, তবে সাধারণত সার্ভার থেকে বিভিন্ন পৃষ্ঠা বিতরণ করা হয় না। এর মানে হল যে 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://speculative-rules.glitch.me/common-fruits.html- এ একটি ডেমো তৈরি করেছি যা নথির নিয়মগুলি দেখতে ব্যবহার করা যেতে পারে একটি moderate আগ্রহের সাথে কাজ করার জন্য:

DevTools খুলুন, অ্যাপ্লিকেশন প্যানেলে ক্লিক করুন। তারপরে, পটভূমি পরিষেবা বিভাগে, অনুমানমূলক লোডগুলিতে ক্লিক করুন, তারপরে স্পেকুলেশন প্যানে, এবং স্থিতি কলাম অনুসারে সাজান।

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

আপনি পূর্ববর্তী ডিবাগিং স্পেকুলেশন নিয়মগুলিকে ডিবাগ করার জন্য কীভাবে DevTools ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য ব্লগ পোস্টটি দেখতে পারেন৷

অনুমান বিধি জন্য প্ল্যাটফর্ম সমর্থন

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

আমরা ওয়েব ইনকিউবেটর কমিউনিটি গ্রুপ (WICG) এর মাধ্যমে API-কে মানসম্মত করার জন্য কঠোর পরিশ্রম করছি যাতে অন্য ব্রাউজারগুলিও এই উত্তেজনাপূর্ণ API বাস্তবায়ন করতে পারে যদি তারা পছন্দ করে।

ওয়ার্ডপ্রেস

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

সেটিংসের দুটি গ্রুপ উপলব্ধ: অনুমান মোড এবং আগ্রহ সেটিং:

আরও জটিল সেটআপের জন্য—উদাহরণস্বরূপ, নির্দিষ্ট ইউআরএলগুলিকে প্রিফেচ করা বা প্রি-রেন্ডার করা থেকে বাদ দেওয়া— ডকুমেন্টেশন পড়ুন।

আকামই

Akamai হল বিশ্বের অন্যতম প্রধান CDN প্রদানকারী, এবং তারা কিছু সময়ের জন্য সক্রিয়ভাবে Speculation Rules API নিয়ে পরীক্ষা-নিরীক্ষা করছে। আকামাই কীভাবে গ্রাহকরা তাদের CDN সেটিংসে এই API সক্ষম করতে পারে তার ডকুমেন্টেশন প্রকাশ করেছে। তারা পূর্বে এই নতুন API এর সাথে সম্ভাব্য চিত্তাকর্ষক ফলাফলগুলি ভাগ করেছে।

নাইট্রোপ্যাক

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

Chrome টিম NitroPack-এর সাথে Speculation Rules API-এর একটি ওয়েবিনারে যারা আরও তথ্যের সন্ধান করছে, যার মধ্যে প্রাথমিক এবং প্রায়শই অনুমান করার পাশাপাশি দেরীতে এবং কম ঘন ঘন করার মধ্যে প্রয়োজনীয় বিবেচ্য বিষয়গুলির উপর একটি ভাল আলোচনা সহ কাজ করেছে৷

অ্যাস্ট্রো

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

উপসংহার

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

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

আমরা 2024 জুড়ে স্পেকুলেশন রুলস API-এর আরও গ্রহণের জন্য উন্মুখ, এবং আমরা API-তে যে কোনও উন্নতির বিষয়ে আপনাকে আপডেট রাখব।

স্বীকৃতি

আনস্প্ল্যাশে রবি ডাউনের থাম্বনেইল