Client Hints-এর মাধ্যমে ব্যবহারকারীর সাথে মানিয়ে নেওয়া

Jeremy Wagner

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

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

কন্টেন্ট নেগোসিয়েশন সম্পর্কে সব কিছু

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

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

নির্বাচন করা হচ্ছে

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

Accept-CH: Viewport-Width, Downlink

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

মনে রাখবেন: Client Hints যাতে কাজ করে, তার জন্য আপনার সাইট অবশ্যই HTTPS-এ খুলতে হবে!

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

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

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

সব Client Hints!

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

ডিভাইস সংক্রান্ত ইঙ্গিত

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

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

আসল সাইজ: মিডিয়া রিসোর্সের আসল ডাইমেনশন। যেমন, আপনি Photoshop-এ কোনও ছবি খুললে, ছবির সাইজ সংক্রান্ত ডায়ালগে দেখানো ডাইমেনশন তার ইন্ট্রিনসিক সাইজ বর্ণনা করে।

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

<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 ছবির অন্তর্নিহিত সাইজ হল ৩২০x২৪০ এবং 2x ছবির অন্তর্নিহিত সাইজ হল ৬৪০x৪৮০। এই মার্কআপ যদি ২ ডিভাইস পিক্সেল অনুপাত (যেমন, Retina স্ক্রিন) সহ স্ক্রিন ডিভাইসে ইনস্টল করা কোনও ক্লায়েন্ট পার্স করে, তাহলে 2x ছবির জন্য অনুরোধ করা হয়। 2x ছবির ঘনত্ব-সংশোধিত অন্তর্নিহিত সাইজ হল ৩২০x২৪০, কারণ ৬৪০x৪৮০-কে ২ দিয়ে ভাগ করলে ৩২০x২৪০ হয়।

এক্সট্রিনসিক সাইজ: CSS এবং অন্যান্য লেআউট ফ্যাক্টর (যেমন width এবং height অ্যাট্রিবিউট) প্রয়োগ করার পরে মিডিয়া রিসোর্সের সাইজ। ধরা যাক, আপনার কাছে একটি <img> এলিমেন্ট আছে যা ৩২০x২৪০-এর ডেনসিটি-কারেক্টেড ইন্ট্রিনসিক সাইজ সহ একটি ছবি লোড করে, তবে এতে CSS width এবং height প্রপার্টিও আছে যার মান যথাক্রমে 256px এবং 192px। এই উদাহরণে, সেই <img> এলিমেন্টের এক্সট্রিনসিক সাইজ ২৫৬x১৯২ হয়ে যায়।

ছবি ১. আসল বনাম বাহ্যিক সাইজের একটি ইলাস্ট্রেশন। লে-আউট ফ্যাক্টর প্রয়োগ করার পরে কোনও ছবি তার বাহ্যিক সাইজ অর্জন করে। এই ক্ষেত্রে, width: 256px; এবং height: 192px;-এর CSS নিয়ম প্রয়োগ করলে ৩২০x২৪০ সাইজের একটি ছবি ২৫৬x১৯২ সাইজে পরিবর্তিত হয়।

কিছু পরিভাষা সম্পর্কে জানার পরে, আপনার জন্য উপলভ্য ডিভাইস-নির্দিষ্ট Client Hints-এর তালিকা দেখে নেওয়া যাক।

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

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

Viewport-Width: 320

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

DPR

DPR, ডিভাইস পিক্সেল অনুপাতের সংক্ষিপ্ত রূপ, ব্যবহারকারীর স্ক্রিনের ফিজিক্যাল পিক্সেল থেকে CSS পিক্সেলের অনুপাত রিপোর্ট করে:

DPR: 2

স্ক্রিনের পিক্সেল ডেনসিটি (যেমন srcset অ্যাট্রিবিউটে x ডেসক্রিপ্টর করে) অনুযায়ী ছবির সোর্স বেছে নেওয়ার সময় এই ইঙ্গিত কাজে লাগে।

প্রস্থ

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

যেমন, ধরা যাক, কোনও ব্যবহারকারী ৩২০ CSS পিক্সেল চওড়া স্ক্রিন ও ২ DPR সহ একটি পৃষ্ঠার অনুরোধ করেছেন। ডিভাইসটি এমন একটি ডকুমেন্ট লোড করে যাতে <img> এলিমেন্ট আছে এবং sizes অ্যাট্রিবিউটের ভ্যালু হল 85vw (অর্থাৎ, সব স্ক্রিন সাইজের জন্য ভিউপোর্ট প্রস্থের ৮৫%)। Width হিন্ট অপ্ট-ইন করা থাকলে, ক্লায়েন্ট <img>-এর src-এর জন্য অনুরোধ সহ সার্ভারে এই Width হিন্ট পাঠাবে:

Width: 544

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

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

Content-DPR

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

অন্যান্য Client Hints-এর মতো, Content-DPR কোনও অনুরোধ হেডার নয় যা সার্ভার ব্যবহার করবে, বরং এটি একটি রেসপন্স হেডার যা সার্ভারকে অবশ্যই পাঠাতে হবে যখনই DPR এবং Width ইঙ্গিত কোনও রিসোর্স বেছে নিতে ব্যবহার করা হয়। Content-DPR-এর ভ্যালু এই সমীকরণের ফলাফল হতে হবে:

Content-DPR = [বেছে নেওয়া ছবির রিসোর্স সাইজ] / ([Width] / [DPR])

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

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

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

Device-Memory: 2

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

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

নেটওয়ার্ক হিন্ট

Network Information API অন্য ধরনের Client Hints প্রদান করে যা ব্যবহারকারীর নেটওয়ার্ক কানেকশনের পারফর্ম্যান্স বর্ণনা করে। আমার মতে, এগুলি হল সবচেয়ে উপযোগী হিন্টের সেট। এগুলির সাহায্যে, স্লো কানেকশনে ক্লায়েন্টদের রিসোর্স ডেলিভার করার পদ্ধতি পরিবর্তন করে আমরা ব্যবহারকারীদের অভিজ্ঞতা কাস্টমাইজ করতে পারি।

মনে রাখবেন: নেটওয়ার্ক হিন্ট ভ্যালু হল পূর্ববর্তী লেটেন্সি ও ব্যান্ডউইথ রিডিংয়ের উপর ভিত্তি করে করা অনুমান। তাই, এগুলি ১০০% সঠিক নয়, তবে ক্লায়েন্ট হিন্ট ব্যবহারের ক্ষেত্রে যথেষ্ট ভালো বলে ধরে নেওয়া হয়।

RTT

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

RTT: 125

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

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

ডাউনলিঙ্ক

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

Downlink: 2.5

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

RTT-এর সাথে Downlink ব্যবহার করলে, নেটওয়ার্ক কানেকশনের কোয়ালিটির উপর নির্ভর করে ব্যবহারকারীদের কীভাবে কন্টেন্ট ডেলিভার করা হবে তা পরিবর্তন করার ক্ষেত্রে সহায়ক হতে পারে।

ECT

ECT ইঙ্গিতটি কার্যকর কানেকশনের ধরন-এর জন্য ব্যবহার করা হয়। এর ভ্যালু হল কানেকশনের ধরনের একটি তালিকা, যার প্রতিটি RTT এবং Downlink ভ্যালুর নির্দিষ্ট রেঞ্জের মধ্যে একটি কানেকশন বর্ণনা করে।

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

ECT: 2g

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

Save-Data

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

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

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

Save-Data: on

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

সবকিছু একসাথে করা হচ্ছে

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

রেসপন্সিভ ছবি

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

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

Client hints এটি সহজ করতে পারে। ক্লায়েন্ট হিন্টসের সাথে ছবির উত্তর নিয়ে আলোচনা করা এইরকম দেখতে হতে পারে:

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

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

<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 URL হল একটি PHP স্ক্রিপ্ট যার পরে প্যারামিটারগুলি mod_rewrite দ্বারা পুনরায় লেখা হয়। এটি ব্যাক-এন্ড স্ক্রিপ্টকে সাহায্য করার জন্য একটি ছবির ফাইলের নাম এবং অতিরিক্ত প্যারামিটার নেয় প্রদত্ত শর্তে সেরা ছবি বেছে নিন।

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

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

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

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

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

স্লো নেটওয়ার্কে ব্যবহারকারীদের সাহায্য করা

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

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

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

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

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

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

এই উদাহরণে, আমরা দেখতে পাচ্ছি যে স্লো নেটওয়ার্কে সাইটের পারফর্ম্যান্স উন্নত করার ক্ষেত্রে Client Hints-এর কী প্রভাব রয়েছে। নিচে স্লো নেটওয়ার্কে থাকা সাইটের WebPagetest ওয়াটারফল দেওয়া হল যা Client Hints-এর সাথে মানানসই নয়:

ছবি ৩. স্লো কানেকশনে ছবি, স্ক্রিপ্ট ও ফন্ট লোড করার জন্য রিসোর্স-হেভি সাইট।

আর এখন একই সাইটের জন্য একই স্লো কানেকশনে ওয়াটারফল, তবে এইবার, সাইটটি অপ্রয়োজনীয় পৃষ্ঠা রিসোর্স বাদ দিতে Client Hints ব্যবহার করে:

ছবি ৪। একই কানেকশনে একই সাইট, শুধুমাত্র "থাকলে ভালো হয়" রিসোর্সগুলি দ্রুত লোড করার জন্য বাদ দেওয়া হয়েছে।

Client hints-এর ফলে পৃষ্ঠা লোড হওয়ার সময় ৪৫ সেকেন্ড থেকে কমে তার এক দশমাংশেরও কম হয়ে গেছে। এই পরিস্থিতিতে Client Hints-এর সুবিধা যথেষ্ট জোর দিয়ে বলা যায় না এবং স্লো নেটওয়ার্কে গুরুত্বপূর্ণ তথ্য খুঁজছেন এমন ব্যবহারকারীদের জন্য এটি একটি গুরুতর আশীর্বাদ হতে পারে।

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

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

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

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

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

Vary: DPR, Width

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

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

সার্ভিস ওয়ার্কারে Client hints

কন্টেন্ট নেগোসিয়েশন এখন আর শুধু সার্ভারের জন্য নয়! যেহেতু সার্ভিস ওয়ার্কার ক্লায়েন্ট ও সার্ভারের মধ্যে প্রক্সি হিসেবে কাজ করে, তাই জাভাস্ক্রিপ্টের মাধ্যমে রিসোর্স কীভাবে ডেলিভার করা হবে তা আপনি নিয়ন্ত্রণ করতে পারবেন। এর মধ্যে Client Hints অন্তর্ভুক্ত। সার্ভিস ওয়ার্কার 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!
    })(),
  );
});

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

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

ফাইলের ধরনের জন্য Imagemin প্লাগ-ইন।

Client hint	JS-এর সমতুল্য
`ECT`	`navigator.connection.effectiveType`
`RTT`	`navigator.connection.rtt`
`Save-Data`	`navigator.connection.saveData`
ডাউনলিঙ্ক	`navigator.connection.downlink`
`Device-Memory`	`navigator.deviceMemory`

এইসব API সব জায়গায় উপলভ্য নয় বলে আপনাকে in অপারেটর ব্যবহার করে ফিচার চেক করতে হবে:

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

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

শেষ করা হচ্ছে

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

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

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

রিসোর্স

• Client Hints-এর সাহায্যে অটোমেটিক রেসপন্সিভ ছবি
• Client Hints and Responsive Images—What Changed in Chrome 67
• (Client) Hint নিন! (Slides)
• Save-Data-এর মাধ্যমে দ্রুত ও লাইট অ্যাপ্লিকেশন ডেলিভার করা

এই নিবন্ধে মূল্যবান মতামত ও এডিট করার জন্য Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss এবং Estelle Weyl-কে ধন্যবাদ।