এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

ক্লায়েন্ট ইঙ্গিত সহ ব্যবহারকারীদের মানিয়ে নেওয়া

Jeremy Wagner

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

ক্লায়েন্ট হিন্টস হলো কিছু ঐচ্ছিক HTTP রিকোয়েস্ট হেডার, যা ব্যবহারকারীর ডিভাইস এবং তিনি যে নেটওয়ার্কের সাথে সংযুক্ত আছেন, সে সম্পর্কিত বিভিন্ন দিক সম্পর্কে আমাদের ধারণা দেয়। সার্ভার সাইডে এই তথ্য ব্যবহার করে, আমরা ডিভাইস এবং/অথবা নেটওয়ার্কের অবস্থার উপর ভিত্তি করে কন্টেন্ট সরবরাহের পদ্ধতি পরিবর্তন করতে পারি। এটি আমাদের আরও অন্তর্ভুক্তিমূলক ব্যবহারকারী অভিজ্ঞতা তৈরি করতে সাহায্য করতে পারে।

পুরোটাই বিষয়বস্তু আলোচনার উপর নির্ভরশীল

ক্লায়েন্ট হিন্টস হলো কন্টেন্ট নেগোসিয়েশনের আরেকটি পদ্ধতি, যার অর্থ হলো ব্রাউজার রিকোয়েস্ট হেডারের উপর ভিত্তি করে কন্টেন্ট রেসপন্স পরিবর্তন করা।

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

Accept: image/webp,image/apng,image/*,*/*;q=0.8

যদিও সব ব্রাউজারই JPEG, PNG, এবং GIF-এর মতো ইমেজ ফরম্যাট সমর্থন করে, Accept এক্ষেত্রে জানাচ্ছে যে ব্রাউজারটি WebP এবং APNG- ও সমর্থন করে। এই তথ্য ব্যবহার করে, আমরা প্রতিটি ব্রাউজারের জন্য সেরা ইমেজ টাইপগুলো নিয়ে আলোচনা করে নিতে পারি:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

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

অংশগ্রহণ করা

Accept হেডারের মতো নয়, ক্লায়েন্ট হিন্টগুলো এমনি এমনি চলে আসে না ( Save-Data এর ব্যতিক্রম, যা নিয়ে আমরা পরে আলোচনা করব)। রিকোয়েস্ট হেডার ন্যূনতম রাখার স্বার্থে, যখন কোনো ব্যবহারকারী কোনো রিসোর্সের জন্য অনুরোধ করে, তখন একটি Accept-CH হেডার পাঠিয়ে আপনাকে বেছে নিতে হবে যে আপনি কোন কোন ক্লায়েন্ট হিন্ট গ্রহণ করতে চান।

Accept-CH: Viewport-Width, Downlink

Accept-CH এর ভ্যালুটি হলো অনুরোধ করা হিন্টগুলোর একটি কমা-দ্বারা-বিভক্ত তালিকা, যা সাইটটি পরবর্তী রিসোর্স অনুরোধের ফলাফল নির্ধারণ করতে ব্যবহার করবে। যখন ক্লায়েন্ট এই হেডারটি পড়ে, তখন তাকে বলা হয়, “এই সাইটটি Viewport-Width এবং Downlink ক্লায়েন্ট হিন্টগুলো চায়।” নির্দিষ্ট হিন্টগুলো নিয়ে এখনই চিন্তা করবেন না। আমরা একটু পরেই সেগুলোতে আসব।

আপনি যেকোনো ব্যাক-এন্ড ল্যাঙ্গুয়েজে এই অপ্ট-ইন হেডারগুলো সেট করতে পারেন। উদাহরণস্বরূপ, PHP-এর header ফাংশন ব্যবহার করা যেতে পারে। এমনকি আপনি একটি <meta> ট্যাগে http-equiv অ্যাট্রিবিউট ব্যবহার করেও এই অপ্ট-ইন হেডারগুলো সেট করতে পারেন:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

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

ক্লায়েন্টের সব পরামর্শ!

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

ডিভাইসের ইঙ্গিত

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

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

অন্তর্নিহিত আকার: কোনো মিডিয়া রিসোর্সের আসল মাপ। উদাহরণস্বরূপ, আপনি যদি ফটোশপে একটি ছবি খোলেন, তাহলে ছবির আকারের ডায়ালগ বক্সে দেখানো মাপটিই এর অন্তর্নিহিত আকার বর্ণনা করে।

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

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

ধরা যাক, এক্ষেত্রে 1x ইমেজের ইন্ট্রিনসিক সাইজ হলো 320x240 এবং 2x ইমেজের ইন্ট্রিনসিক সাইজ হলো 640x480। যদি এই মার্কআপটি এমন কোনো ডিভাইসে ইনস্টল করা ক্লায়েন্ট দ্বারা পার্স করা হয় যার স্ক্রিন ডিভাইস পিক্সেল রেশিও ২ (যেমন, একটি রেটিনা স্ক্রিন), তবে 2x ইমেজটির জন্য অনুরোধ করা হয়। 2x ইমেজটির ডেনসিটি-সংশোধিত ইন্ট্রিনসিক সাইজ হলো 320x240, কারণ 640x480-কে 2 দিয়ে ভাগ করলে 320x240 হয়।

এক্সট্রিনসিক সাইজ: কোনো মিডিয়া রিসোর্সের উপর CSS এবং অন্যান্য লেআউট ফ্যাক্টর (যেমন width ও height অ্যাট্রিবিউট) প্রয়োগ করার পরের আকার। ধরা যাক, আপনার কাছে একটি <img> এলিমেন্ট আছে যা 320x240 ডেনসিটি-সংশোধিত ইন্ট্রিনসিক সাইজের একটি ছবি লোড করে, কিন্তু এর সাথে CSS-এ যথাক্রমে 256px ও 192px মানের width এবং height প্রপার্টিও প্রয়োগ করা আছে। এই উদাহরণে, ঐ <img> এলিমেন্টটির এক্সট্রিনসিক সাইজ হবে 256x192।

অভ্যন্তরীণ আকার বনাম বাহ্যিক আকারের একটি উদাহরণ। ৩২০x২৪০ পিক্সেল আকারের একটি বাক্স দেখানো হয়েছে যার লেবেল ‘অভ্যন্তরীণ আকার’। এর ভিতরে ২৫৬x১৯২ পিক্সেল আকারের একটি ছোট বাক্স রয়েছে, যা CSS প্রয়োগ করা একটি HTML img এলিমেন্টকে প্রতিনিধিত্ব করে। এই বাক্সটির লেবেল ‘বাহ্যিক আকার’। ডানদিকে একটি বাক্স রয়েছে যেখানে এলিমেন্টটিতে CSS প্রয়োগ করা হয়েছে, যা img এলিমেন্টের লেআউটকে এমনভাবে পরিবর্তন করে যাতে এর বাহ্যিক আকার এর অভ্যন্তরীণ আকার থেকে ভিন্ন হয়। — **চিত্র ১।** ইন্ট্রিনসিক বনাম এক্সট্রিনসিক আকারের একটি দৃষ্টান্ত। একটি ছবিতে লেআউট ফ্যাক্টর প্রয়োগ করার পর সেটি তার এক্সট্রিনসিক আকার লাভ করে। এক্ষেত্রে, `width: 256px;` এবং `height: 192px;` এই CSS নিয়মগুলো প্রয়োগ করার ফলে একটি 320x240 ইন্ট্রিনসিক আকারের ছবি একটি 256x192 এক্সট্রিনসিক আকারের ছবিতে রূপান্তরিত হয়।

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

ভিউপোর্ট-প্রস্থ

Viewport-Width হলো ব্যবহারকারীর ভিউপোর্টের প্রস্থ, যা CSS পিক্সেলে পরিমাপ করা হয়:

Viewport-Width: 320

এই ইঙ্গিতটি অন্যান্য স্ক্রিন-নির্দিষ্ট ইঙ্গিতের সাথে ব্যবহার করা যেতে পারে, যাতে কোনো ছবির ভিন্ন ভিন্ন রূপ (যেমন, ক্রপ) প্রদান করা যায় যা নির্দিষ্ট স্ক্রিন আকারের জন্য সর্বোত্তম (যেমন, আর্ট ডিরেকশন ), অথবা বর্তমান স্ক্রিনের প্রস্থের জন্য অপ্রয়োজনীয় রিসোর্স বাদ দেওয়া যায়।

ডিপিআর

DPR , যার পূর্ণরূপ ডিভাইস পিক্সেল রেশিও, ব্যবহারকারীর স্ক্রিনের ফিজিক্যাল পিক্সেল এবং সিএসএস (CSS) পিক্সেলের অনুপাত প্রকাশ করে।

DPR: 2

এই ইঙ্গিতটি তখন কাজে আসে যখন স্ক্রিনের পিক্সেল ঘনত্বের সাথে সামঞ্জস্যপূর্ণ ছবির উৎস নির্বাচন করা হয় (যেমন srcset অ্যাট্রিবিউটে x ডেসক্রিপ্টরগুলো করে থাকে)।

প্রস্থ

<img> বা <source> ট্যাগের মাধ্যমে sizes অ্যাট্রিবিউট ব্যবহার করে পাঠানো ইমেজ রিসোর্সের অনুরোধে Width হিন্টটি দেখা যায়। sizes অ্যাট্রিবিউট ব্রাউজারকে বলে দেয় যে রিসোর্সটির এক্সট্রিনসিক সাইজ কত হবে; Width সেই এক্সট্রিনসিক সাইজ ব্যবহার করে বর্তমান লেআউটের জন্য সর্বোত্তম ইন্ট্রিনসিক সাইজের একটি ইমেজের অনুরোধ করে।

উদাহরণস্বরূপ, ধরা যাক একজন ব্যবহারকারী 320 CSS পিক্সেল চওড়া স্ক্রিন এবং 2 DPR সহ একটি পেজের জন্য অনুরোধ করেছেন। ডিভাইসটি এমন একটি ডকুমেন্ট লোড করে যেখানে একটি <img> এলিমেন্ট আছে এবং সেই sizes অ্যাট্রিবিউটের মান 85vw (অর্থাৎ, সমস্ত স্ক্রিন সাইজের জন্য ভিউপোর্ট প্রস্থের 85%)। যদি Width hint-টি বেছে নেওয়া হয়ে থাকে, তাহলে ক্লায়েন্ট <img> -এর src এর অনুরোধের সাথে এই Width hint-টি সার্ভারে পাঠাবে।

Width: 544

এই ক্ষেত্রে, ক্লায়েন্ট সার্ভারকে ইঙ্গিত দিচ্ছে যে অনুরোধ করা ছবির জন্য সর্বোত্তম অন্তর্নিহিত প্রস্থ হবে ভিউপোর্ট প্রস্থের (272 পিক্সেল) 85% কে স্ক্রিনের DPR (2) দ্বারা গুণ করে, যার সমান 544 পিক্সেল।

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

কন্টেন্ট-ডিপিআর

আপনি ইতিমধ্যেই জানেন যে স্ক্রিনের একটি ডিভাইস পিক্সেল রেশিও থাকে, কিন্তু রিসোর্সগুলোরও নিজস্ব পিক্সেল রেশিও থাকে। সবচেয়ে সহজ রিসোর্স নির্বাচনের ক্ষেত্রে, ডিভাইস এবং রিসোর্সের মধ্যে পিক্সেল রেশিও একই হতে পারে। কিন্তু! যেসব ক্ষেত্রে DPR এবং Width উভয় হেডারই ব্যবহৃত হয়, সেখানে একটি রিসোর্সের এক্সট্রিনসিক সাইজ এমন পরিস্থিতি তৈরি করতে পারে যেখানে এই দুটি ভিন্ন হয়। এখানেই Content-DPR হিন্টটি কাজে আসে।

অন্যান্য ক্লায়েন্ট হিন্টের মতো নয়, Content-DPR সার্ভার দ্বারা ব্যবহৃত কোনো রিকোয়েস্ট হেডার নয়, বরং এটি একটি রেসপন্স হেডার যা সার্ভারকে অবশ্যই পাঠাতে হয় যখনই কোনো রিসোর্স নির্বাচন করার জন্য DPR এবং Width হিন্ট ব্যবহার করা হয়। Content-DPR এর মান এই সমীকরণের ফলাফল হওয়া উচিত:

Content-DPR = [নির্বাচিত ইমেজ রিসোর্সের আকার] / ([ Width ] / [ DPR ])

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

ডিভাইস-মেমরি

প্রযুক্তিগতভাবে ডিভাইস মেমরি এপিআই- এর একটি অংশ, Device-Memory বর্তমান ডিভাইসটিতে থাকা মেমরির আনুমানিক পরিমাণ GiB-তে প্রকাশ করে:

Device-Memory: 2

দ্রষ্টব্য: যেহেতু এই তথ্য ব্যবহারকারীদের ফিঙ্গারপ্রিন্ট করতে ব্যবহার করা যেতে পারে , তাই Device-Memory মান ইচ্ছাকৃতভাবে স্থূল রাখা হয়েছে। বৈধ মানগুলো হলো 0.25 , 0.5 , 1 , 2 , 4 এবং 8 ।

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

নেটওয়ার্ক ইঙ্গিত

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

আরটিটি

RTT হিন্ট অ্যাপ্লিকেশন লেয়ারে আনুমানিক রাউন্ড ট্রিপ টাইম (Round Trip Time) মিলিসেকেন্ডে প্রদান করে। ট্রান্সপোর্ট লেয়ারের RTT এর বিপরীতে, RTT হিন্টে সার্ভার প্রসেসিং টাইম অন্তর্ভুক্ত থাকে।

RTT: 125

দ্রষ্টব্য: ফিঙ্গারপ্রিন্টিং প্রতিরোধ করার জন্য RTT এর মান নিকটতম ২৫ মিলিসেকেন্ডে রাউন্ড করা হয়।

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

ডাউনলিঙ্ক

লোডিং পারফরম্যান্সের ক্ষেত্রে ল্যাটেন্সি গুরুত্বপূর্ণ হলেও, ব্যান্ডউইথও প্রভাবশালী। মেগাবিটস প্রতি সেকেন্ড (Mbps)-এ প্রকাশিত Downlink হিন্টটি ব্যবহারকারীর সংযোগের আনুমানিক ডাউনস্ট্রিম গতি প্রকাশ করে:

Downlink: 2.5

দ্রষ্টব্য: Downlink মান ২৫ কিলোবিট প্রতি সেকেন্ডের নিকটতম গুণিতকে রাউন্ড করা হয়েছে। কারণ, ফিঙ্গারপ্রিন্টিং।

RTT সাথে একত্রে, নেটওয়ার্ক সংযোগের মানের উপর ভিত্তি করে ব্যবহারকারীদের কাছে কন্টেন্ট পৌঁছে দেওয়ার পদ্ধতি পরিবর্তনে Downlink সহায়ক হতে পারে।

ইসিটি

ECT হিন্ট-এর পূর্ণরূপ হলো Effective Connection Type (কার্যকরী সংযোগের ধরন )। এর মান হলো সংযোগের ধরনগুলোর একটি তালিকাভুক্ত প্রকার, যার প্রতিটি RTT এবং Downlink উভয় মানের নির্দিষ্ট পরিসরের মধ্যে একটি সংযোগকে বর্ণনা করে।

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

ECT: 2g

ECT জন্য বৈধ মানগুলি হলো 4g , 3g , 2g এবং slow-2g । এই ইঙ্গিতটি সংযোগের মান মূল্যায়নের জন্য একটি প্রাথমিক ধাপ হিসেবে ব্যবহার করা যেতে পারে এবং পরবর্তীতে RTT ও Downlink ইঙ্গিত ব্যবহার করে এটিকে আরও পরিমার্জন করা যায়।

ডেটা সংরক্ষণ করুন

Save-Data ঠিক নেটওয়ার্কের অবস্থা বর্ণনা করার মতো কোনো ইঙ্গিত নয়, বরং এটি একটি ব্যবহারকারীর পছন্দ যা নির্দেশ করে যে পেজগুলো যেন কম ডেটা পাঠায়।

দ্রষ্টব্য: সমস্ত ক্লায়েন্ট হিন্টগুলোর মধ্যে, Save-Data হলো একমাত্র হিন্ট যা আপনি Accept-CH দিয়ে চালু করতে পারবেন না । শুধুমাত্র ব্যবহারকারীই অ্যান্ড্রয়েড ডিভাইসে ক্রোমের ডেটা সেভার ফিচারটি টগল করার মাধ্যমে এই হিন্টটি পাঠানো হবে কিনা তা নিয়ন্ত্রণ করতে পারেন।

আমি Save-Data একটি নেটওয়ার্ক হিন্ট হিসেবে শ্রেণীবদ্ধ করতে পছন্দ করি, কারণ এটি দিয়ে করা যায় এমন অনেক কাজই অন্যান্য নেটওয়ার্ক হিন্টের মতোই। ব্যবহারকারীরা উচ্চ ল্যাটেন্সি/নিম্ন ব্যান্ডউইথের পরিবেশে এটি চালু করতে পারেন। এই হিন্টটি, যখন উপস্থিত থাকে, তখন সবসময় এইরকম দেখায়:

Save-Data: on

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

সবকিছু একসাথে বেঁধে

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

প্রতিক্রিয়াশীল ছবি

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

যদিও <picture> এবং srcset নিঃসন্দেহে চমৎকার টুল, জটিল ব্যবহারের ক্ষেত্রে এগুলোর উন্নয়ন ও রক্ষণাবেক্ষণ সময়সাপেক্ষ হতে পারে। আমরা মার্কআপ তৈরি স্বয়ংক্রিয় করতে পারি, কিন্তু সেটাও কঠিন, কারণ <picture> এবং srcset যে কার্যকারিতা প্রদান করে তা যথেষ্ট জটিল এবং এগুলোর স্বয়ংক্রিয়করণ এমনভাবে করতে হয় যাতে এদের দেওয়া নমনীয়তা বজায় থাকে।

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

আপনার ওয়ার্কফ্লোর জন্য প্রযোজ্য হলে, প্রথমে Viewport-Width হিন্টটি চেক করে একটি ইমেজ ট্রিটমেন্ট (যেমন, আর্ট-ডিরেক্টেড ইমেজেরি) নির্বাচন করুন।
Width hint এবং DPR hint চেক করে, এবং ছবির লেআউট সাইজ ও স্ক্রিন ডেনসিটির সাথে মানানসই একটি সোর্স বেছে নিয়ে ছবির রেজোলিউশন নির্বাচন করুন ( srcset এ x এবং w ডেসক্রিপ্টর যেভাবে কাজ করে, তার অনুরূপ)।
ব্রাউজার যে ফাইল ফরম্যাটটি সমর্থন করে, তার মধ্যে সবচেয়ে উপযুক্তটি নির্বাচন করুন (বেশিরভাগ ব্রাউজারে Accept এই কাজটি করতে আমাদের সাহায্য করে)।

আমার কাল্পনিক কাঠ কোম্পানি ক্লায়েন্টের ক্ষেত্রে, আমি পিএইচপি-তে একটি সরল রেসপন্সিভ ইমেজ সিলেকশন রুটিন তৈরি করেছিলাম যা ক্লায়েন্ট হিন্ট ব্যবহার করে। এর মানে হলো, সমস্ত ব্যবহারকারীকে এই মার্কআপটি পাঠানোর পরিবর্তে:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

স্বতন্ত্র ব্রাউজার সমর্থনের উপর ভিত্তি করে আমি এটিকে নিম্নলিখিতভাবে কমিয়ে আনতে পেরেছি:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

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

আমার মনে হচ্ছে, আপনার প্রথম প্রশ্নটি হলো, “কিন্তু এটা কি শুধু ব্যাক-এন্ডে <picture> এবং srcset পুনরায় প্রয়োগ করা নয়?”

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

ক্লায়েন্ট হিন্টস একটি লসলেস, উচ্চ-রেজোলিউশনের ছবি দিয়ে কাজ শুরু করা সম্ভব করে, যা পরবর্তীতে যেকোনো স্ক্রিন ও লেআউটের সমন্বয়ের জন্য সর্বোত্তম করে তোলার জন্য ডায়নামিকভাবে রিসাইজ করা যায়। srcset মতো নয়, যেখানে ব্রাউজারের বেছে নেওয়ার জন্য সম্ভাব্য ছবির একটি নির্দিষ্ট তালিকা তৈরি করতে হয়, এই পদ্ধতিটি আরও বেশি নমনীয় হতে পারে। যেখানে srcset আপনাকে ব্রাউজারগুলোকে কিছু নির্দিষ্ট ভ্যারিয়েন্ট—যেমন, 256w , 512w , 768w , এবং 1024w দেওয়ার জন্য বাধ্য করে, সেখানে ক্লায়েন্ট-হিন্টস চালিত একটি সমাধান বিশাল পরিমাণ মার্কআপ ছাড়াই সমস্ত প্রস্থের ছবি সরবরাহ করতে পারে।

অবশ্যই, আপনাকে নিজে থেকে ইমেজ সিলেকশন লজিক লিখতে হবে না। আপনি যখন w_auto প্যারামিটারটি ব্যবহার করেন, তখন Cloudinary ক্লায়েন্ট হিন্ট ব্যবহার করে ইমেজ রেসপন্স তৈরি করে , এবং দেখা গেছে যে ক্লায়েন্ট হিন্ট সমর্থনকারী ব্রাউজার ব্যবহার করার সময় গড় ব্যবহারকারীরা ৪২% কম বাইট ডাউনলোড করেছেন।

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

ধীরগতির নেটওয়ার্কে ব্যবহারকারীদের সাহায্য করা

অভিযোজিত কর্মক্ষমতা হলো এই ধারণা যে, ক্লায়েন্টের ইঙ্গিত থেকে প্রাপ্ত তথ্যের ভিত্তিতে আমরা রিসোর্স সরবরাহের পদ্ধতি সামঞ্জস্য করতে পারি; বিশেষত ব্যবহারকারীর নেটওয়ার্ক সংযোগের বর্তমান অবস্থা সম্পর্কিত তথ্যের ওপর ভিত্তি করে।

স্কনি টিম্বারের সাইটের ক্ষেত্রে, নেটওয়ার্ক ধীরগতির হলে আমরা লোড কমানোর জন্য পদক্ষেপ নিই এবং এর জন্য আমাদের ব্যাক-এন্ড কোডে Save-Data , ECT , RTT , ও Downlink হেডারগুলো পরীক্ষা করা হয়। এটি সম্পন্ন হলে, আমরা একটি নেটওয়ার্ক কোয়ালিটি স্কোর তৈরি করি, যা ব্যবহার করে আমরা নির্ধারণ করি যে ব্যবহারকারীর উন্নত অভিজ্ঞতার জন্য আমাদের কোনো হস্তক্ষেপ করা উচিত কিনা। এই নেটওয়ার্ক স্কোরটি 0 থেকে 1 মধ্যে থাকে, যেখানে 0 হলো সম্ভাব্য সবচেয়ে খারাপ নেটওয়ার্ক কোয়ালিটি এবং 1 হলো সবচেয়ে ভালো।

শুরুতে, আমরা পরীক্ষা করে দেখি যে Save-Data আছে কি না। যদি থাকে, তাহলে স্কোর 0 সেট করা হয়, কারণ আমরা ধরে নিচ্ছি যে ব্যবহারকারী চান আমরা অভিজ্ঞতাটিকে আরও সহজ ও দ্রুত করার জন্য যা যা করা দরকার, তা-ই করি।

তবে, যদি Save-Data অনুপস্থিত থাকে, তাহলে আমরা নেটওয়ার্ক সংযোগের মান বর্ণনা করে এমন একটি স্কোর গণনা করার জন্য ECT , RTT এবং Downlink হিন্টস-এর মানগুলো বিবেচনা করি। নেটওয়ার্ক স্কোর তৈরির সোর্স কোড গিটহাবে (Github) পাওয়া যায়। মূল কথা হলো, যদি আমরা কোনোভাবে নেটওয়ার্ক-সম্পর্কিত হিন্টসগুলো ব্যবহার করি, তাহলে যারা ধীরগতির নেটওয়ার্কে আছেন তাদের অভিজ্ঞতা আরও উন্নত করতে পারি।

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

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

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

একটি ধীরগতির নেটওয়ার্ক সংযোগে স্কনি টিম্বার সাইটের সমস্ত রিসোর্স লোড হওয়ার একটি ওয়েবপেজটেস্ট ওয়াটারফল। — **চিত্র ৩।** একটি ধীরগতির সংযোগে রিসোর্স-হেভি সাইট কর্তৃক ছবি, স্ক্রিপ্ট এবং ফন্ট লোড হওয়া।

এবং এখন একই ধীরগতির সংযোগে একই সাইটের জন্য একটি ওয়াটারফল, তবে এবার সাইটটি পেজের অপ্রয়োজনীয় রিসোর্সগুলো বাদ দিতে ক্লায়েন্ট হিন্টস ব্যবহার করে:

ধীরগতির নেটওয়ার্ক সংযোগে অ-গুরুত্বপূর্ণ রিসোর্স লোড না করার সিদ্ধান্ত নিতে ক্লায়েন্টের ইঙ্গিত ব্যবহার করে স্কনি টিম্বার সাইটের একটি ওয়েবপেজটেস্ট ওয়াটারফল। — **চিত্র ৪।** একই সংযোগে একই সাইট, যেখানে দ্রুত লোডিংয়ের স্বার্থে শুধুমাত্র ঐচ্ছিক রিসোর্সগুলো বাদ দেওয়া হয়েছে।

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

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

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

এখানে, "4g" হলো ECT হেডার দ্বারা বর্ণিত সর্বোচ্চ মানের নেটওয়ার্ক সংযোগ। যদি আমরা $ect "4g" দিয়ে ইনিশিয়ালাইজ করি, তাহলে যেসব ব্রাউজার ক্লায়েন্ট হিন্টস সাপোর্ট করে না, সেগুলোর উপর কোনো প্রভাব পড়বে না। অপ্ট-ইনই সেরা!

ওই ক্যাশগুলোর দিকে খেয়াল রেখো!

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

Vary: DPR, Width

তবে, এর একটি বড় সীমাবদ্ধতা আছে: আপনি কখনোই ঘন ঘন পরিবর্তনশীল কোনো হেডারের (যেমন Cookie ) উপর ভিত্তি করে ক্যাশেযোগ্য রেসপন্সগুলোকে Vary করতে চাইবেন না, কারণ সেক্ষেত্রে সেই রিসোর্সগুলো কার্যত আনক্যাশেযোগ্য হয়ে পড়ে। এই বিষয়টি জেনে, আপনি RTT বা Downlink মতো ক্লায়েন্ট হিন্ট হেডারগুলোর উপর Vary করা এড়িয়ে চলতে পারেন, কারণ এগুলো এমন কানেকশন ফ্যাক্টর যা প্রায়শই পরিবর্তিত হতে পারে। যদি আপনি এই হেডারগুলোর উপর ভিত্তি করে রেসপন্স পরিবর্তন করতে চান, তবে শুধুমাত্র ECT হেডারটি কী (key) করার কথা বিবেচনা করুন, যা ক্যাশে মিসের সম্ভাবনা কমিয়ে আনবে।

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

পরিষেবা কর্মীদের মধ্যে ক্লায়েন্টের ইঙ্গিত

কন্টেন্ট নেগোসিয়েশন এখন আর শুধু সার্ভারের জন্য নয়! যেহেতু সার্ভিস ওয়ার্কাররা ক্লায়েন্ট এবং সার্ভারের মধ্যে প্রক্সি হিসেবে কাজ করে, তাই জাভাস্ক্রিপ্টের মাধ্যমে রিসোর্সগুলো কীভাবে ডেলিভার করা হবে তার উপর আপনার নিয়ন্ত্রণ থাকে। এর মধ্যে ক্লায়েন্ট হিন্টসও অন্তর্ভুক্ত। সার্ভিস ওয়ার্কারের fetch ইভেন্টে, আপনি event অবজেক্টের request.headers.get মেথড ব্যবহার করে একটি রিসোর্সের রিকোয়েস্ট হেডারগুলো এভাবে পড়তে পারেন:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

সতর্কীকরণ: যেহেতু সব ব্রাউজার ক্লায়েন্ট হিন্টস সমর্থন করে না, তাই event.request.headers.get কী মান ফেরত দেয় তা আপনাকে যাচাই করতে হবে। একটি সম্ভাব্য বিকল্প পদ্ধতি হলো window.devicePixelRatio বা window.innerWidth এর মতো JS সমতুল্য মানগুলোকে IndexedDB তে রেকর্ড করা, যা সার্ভিস ওয়ার্কার স্কোপে অ্যাক্সেসযোগ্য।

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

ফাইল টাইপের জন্য ইমেজমিন প্লাগইন।
ক্লায়েন্টের ইঙ্গিত	জেএস সমতুল্য
`ECT`	`navigator.connection.effectiveType`
`RTT`	`navigator.connection.rtt`
ডেটা সংরক্ষণ করুন	`navigator.connection.saveData`
`ডাউনলিঙ্ক`	`navigator.connection.downlink`
`ডিভাইস-মেমরি`	`navigator.deviceMemory`

যেহেতু এই API-গুলো সব জায়গায় পাওয়া যায় না, তাই আপনার ফিচার চেক করার জন্য in অপারেটরটি ব্যবহার করতে হবে:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

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

উপসংহার

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

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

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

সম্পদ

এই নিবন্ধটিতে তাদের মূল্যবান মতামত ও সম্পাদনার জন্য ইলিয়া গ্রিগোরিক , এরিক পোর্টিস , জেফ পসনিক , ইয়োভ ওয়েইস এবং এস্টেল ওয়েলকে ধন্যবাদ।