পারফর্ম্যান্স সংক্রান্ত মূল সমস্যা

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

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

ছবির অনুরোধ স্থগিত করা হচ্ছে

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

<img src="image.jpg" loading=&quo>t;lazy" alt="…"

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

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

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

ফেচ করার অগ্রাধিকার

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

আপনি সম্ভবত ব্রাউজারের অগ্রাধিকার আনার প্রাথমিক পদ্ধতি সম্পর্কে জানেন: যেমন, কোনও ডকুমেন্টের <head>-এ এক্সটার্নাল CSS ফাইলের জন্য করা অনুরোধকে রেন্ডার ব্লক করার জন্য যথেষ্ট গুরুত্বপূর্ণ বলে মনে করা হয়, যেখানে </body>-এর ঠিক উপরে এক্সটার্নাল JavaScript ফাইলের জন্য করা অনুরোধ রেন্ডার সম্পূর্ণ না হওয়া পর্যন্ত স্থগিত রাখা হবে। <img>-এ loading অ্যাট্রিবিউটের ভ্যালু 'lazy' হলে, ব্রাউজার যতক্ষণ না নির্ধারণ করছে যে এটি ব্যবহারকারীকে দেখানো হবে, ততক্ষণ সংশ্লিষ্ট ছবির অনুরোধ স্থগিত রাখা হবে। অন্যথায়, পৃষ্ঠার অন্যান্য ছবির মতোই সেই ছবির অগ্রাধিকার একই থাকবে।

fetchpriority অ্যাট্রিবিউট ডেভেলপারদের অ্যাসেটের অগ্রাধিকারের উপর আরও সূক্ষ্ম নিয়ন্ত্রণ প্রদান করার জন্য ডিজাইন করা হয়েছে, যা আপনাকে একই ধরনের রিসোর্সের তুলনায় রিসোর্সগুলিকে 'উচ্চ' এবং 'নিম্ন' অগ্রাধিকার হিসেবে ফ্ল্যাগ করার অনুমতি দেয়। fetchpriority-এর ব্যবহারের ক্ষেত্র loading অ্যাট্রিবিউটের মতোই, তবে অনেক বেশি বিস্তৃত। যেমন, আপনি কোনও ছবিতে fetchpriority="low" ব্যবহার করতে পারেন যা শুধুমাত্র ব্যবহারকারীর ইন্টার‍্যাকশনের পরে প্রকাশ করা হয় (সেই ছবিটি ব্যবহারকারীর ভিউপোর্টের মধ্যে পড়ে কিনা তা নির্বিশেষে) যাতে পৃষ্ঠার অন্য কোথাও দৃশ্যমান ছবিগুলিকে অগ্রাধিকার দেওয়া যায়, অথবা fetchpriority="high" এমন একটি ছবিকে অগ্রাধিকার দিতে যা আপনি জানেন যে পৃষ্ঠাটি রেন্ডার হওয়ার সাথে সাথেই ভিউপোর্টে অবিলম্বে দৃশ্যমান হবে।

মনে রাখবেন যে fetchpriority, loading-এর থেকে আলাদা কারণ এটি ব্রাউজারের আচরণে কোনও মৌলিক পরিবর্তন করে না। এটি ব্রাউজারকে নির্দেশ দেয় না যে কিছু অ্যাসেট অন্যদের আগে লোড করতে হবে, পরিবর্তে এটি অ্যাসেটের অনুরোধ করার বিষয়ে সিদ্ধান্ত নেওয়ার জন্য গুরুত্বপূর্ণ প্রসঙ্গ প্রদান করে।

ছবির প্রভাব পরিমাপ করা

ইমেজ অ্যাসেট অপ্টিমাইজ করার সময়, মোট ট্রান্সফার সাইজের চেয়ে অনুভূত পারফর্ম্যান্স প্রায়শই বেশি গুরুত্বপূর্ণ এবং পরিমাপ করা আরও কঠিন।

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

কিউমুলেটিভ লেআউট শিফ্ট

Cumulative Layout Shift (CLS) হল ভিজ্যুয়াল স্থিতিশীলতার পরিমাপ। অ্যাসেট লোড হওয়ার সময় এবং পৃষ্ঠা রেন্ডার করার সময়, পৃষ্ঠার কন্টেন্টের লেআউট কতটা শিফট করে তা পরিমাপ করার জন্য এটি একটি মেট্রিক। ওয়েব ব্যবহার করে অনেক সময় কাটিয়েছেন এমন যেকেউ কোনও দীর্ঘ টেক্সট পড়ার সময় নিজের জায়গা হারিয়ে ফেলেছেন কারণ দেরিতে লোড হওয়া ওয়েবফন্ট বা ছবির সোর্স হঠাৎ রেন্ডার হওয়ার কারণে পৃষ্ঠা "জাম্প" করেছে—অথবা কোনও ইন্টার‍্যাক্টিভ এলিমেন্ট হঠাৎ আপনার পয়েন্টার থেকে দূরে সরে গেছে। CLS বেশি হলে তা ব্যবহারকারীর পক্ষে বিরক্তিকর হতে পারে এবং এর ফলে ব্যবহারকারী ভুলও করতে পারেন—যেমন, ব্যবহারকারী ক্লিক করার ঠিক আগে "বাতিল করুন" বোতামটি সরে গিয়ে "কনফার্ম করুন" বোতামের জায়গায় চলে আসা।

লোড হতে বেশি সময় লাগা এবং লেআউটে বেশি জায়গা নেওয়ার কারণে, ছবিই যে CLS স্কোর বেশি হওয়ার সাধারণ কারণ, তা সহজেই বোঝা যায়।

আধুনিক ব্রাউজারে তুলনামূলকভাবে সাম্প্রতিক পরিবর্তনের জন্য, ছবির কারণে বেশি CLS স্কোর এড়ানো আপনার ভাবনার চেয়ে সহজ।

আপনি যদি কয়েক বছর ধরে ফ্রন্টএন্ডে কাজ করে থাকেন, তাহলে <img>-এ width এবং height অ্যাট্রিবিউট সম্পর্কে আপনি জানবেন: CSS-এর ব্যাপক ব্যবহারের আগে, ছবির সাইজ নিয়ন্ত্রণ করার জন্য এগুলিই ছিল একমাত্র উপায়।

<img src="image.jpg" height="200"> width="400" alt="…"

আমাদের মার্ক-আপ থেকে স্টাইলিং সংক্রান্ত বিষয় আলাদা রাখার প্রচেষ্টায় এই অ্যাট্রিবিউটগুলি ব্যবহার করা বন্ধ হয়ে গেছে, বিশেষ করে রেসপন্সিভ ওয়েব ডিজাইন CSS-এর মাধ্যমে শতাংশ-ভিত্তিক সাইজ নির্দিষ্ট করা প্রয়োজনীয় করে তুলেছে। প্রতিক্রিয়াশীল ওয়েব ডিজাইনের প্রথম দিকে, "অব্যবহৃত width এবং height অ্যাট্রিবিউট সরিয়ে দিন" পরামর্শটি সাধারণ ছিল, কারণ আমাদের CSS-এ নির্দিষ্ট করা ভ্যালু—max-width: 100% এবং height: auto—সেগুলিকে ওভাররাইড করবে।

<img src="image.jpg&quo>t; alt="…"

img {
  max-width: 100%;
  height: auto;
}

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

২০১৯ থেকে শুরু করে, width এবং height অ্যাট্রিবিউট আলাদাভাবে ম্যানেজ করার জন্য ব্রাউজারের আচরণ আপডেট করা হয়েছে। লেআউটে img এলিমেন্টের নির্দিষ্ট, পিক্সেল-ভিত্তিক সাইজ নির্ধারণ করতে এইসব অ্যাট্রিবিউটের মান ব্যবহার করার পরিবর্তে, এইসব অ্যাট্রিবিউটকে ছবির অ্যাস্পেক্ট রেশিও হিসেবে বিবেচনা করা যেতে পারে, যদিও সিনট্যাক্স একই থাকে। আধুনিক ব্রাউজারগুলি এই মানগুলিকে একে অপরের বিরুদ্ধে ভাগ করবে যাতে পৃষ্ঠাটি রেন্ডার করার আগে একটি img উপাদানের অন্তর্নিহিত অ্যাস্পেক্ট রেশিও নির্ধারণ করা যায়, যা লেআউট রেন্ডার করার সাথে সাথে ছবিটি যে স্থান দখল করবে তা রিজার্ভ করার অনুমতি দেয়।

নিয়ম অনুযায়ী, আপনার সবসময় <img>-এ height ও width অ্যাট্রিবিউট ব্যবহার করা উচিত, যার ভ্যালু আপনার ইমেজ সোর্সের অন্তর্নিহিত সাইজের সাথে ম্যাচ করে—যতক্ষণ আপনি নিশ্চিত করছেন যে HTML অ্যাট্রিবিউট থেকে উচ্চতা ওভাররাইড করার জন্য max-width: 100%-এর পাশাপাশি height: auto নির্দিষ্ট করেছেন।

<img src="image.jpg" height="200"> width="400" alt="…"

img {
  max-width: 100%;
  height: auto;
}

আপনার <img> এলিমেন্টে width এবং height অ্যাট্রিবিউট ব্যবহার করে, আপনি ছবির কারণে হওয়া উচ্চ CLS স্কোর এড়াতে পারবেন।

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

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

লার্জেস্ট কন্টেন্টফুল পেন্ট

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

বর্তমান পৃষ্ঠা লোড করার প্রসেস কখন টেকনিক্যালি সম্পূর্ণ হয়েছে তা নির্ধারণ করার জন্য DOMContentLoaded বা window.onload ইভেন্টের মতো মেট্রিক উপযোগী হতে পারে, তবে পৃষ্ঠায় ব্যবহারকারীর অভিজ্ঞতার সাথে সেগুলি সবসময় মেলে না। ব্যবহারকারীর ভিউপোর্টের বাইরে কোনও এলিমেন্ট রেন্ডার করতে সামান্য দেরি হলে, তা এই দুটি মেট্রিকের মধ্যে যেকোনও একটিতে ফ্যাক্টর করা হবে, তবে সম্ভবত বাস্তব-জগতের ব্যবহারকারীর দ্বারা সম্পূর্ণভাবে শনাক্ত করা যাবে না। LCP-এর সময় বেশি হওয়ার অর্থ হল, কোনও পৃষ্ঠা সম্পর্কে ব্যবহারকারীর প্রথম ইম্প্রেশন—বর্তমান ভিউপোর্টের মধ্যে সবচেয়ে গুরুত্বপূর্ণ কন্টেন্ট—হল, পৃষ্ঠাটি স্লো, অথবা একেবারেই কাজ করছে না।

LCP-এর মাধ্যমে ক্যাপচার করা ব্যবহারকারীর ধারণার সরাসরি প্রভাব ব্যবহারকারীর অভিজ্ঞতার উপর পড়ে। Vodafone-এর করা একটি পরীক্ষা থেকে গত বছরই দেখা গেছে যে LCP-তে ৩১% উন্নতি শুধু যে ৮% বেশি বিক্রি এনে দিয়েছে তাই নয়—এটি নিজেই একটি শক্তিশালী ফলাফল—বরং তাদের মোট ব্যবহারকারীর সংখ্যার মধ্যে, সম্ভাব্য গ্রাহক হয়ে ওঠা দর্শকের সংখ্যায় ১৫% উন্নতি ("দর্শক-থেকে-লিড রেট") এবং তাদের কার্ট ভিজিট করা ব্যবহারকারীর সংখ্যায় ১১% উন্নতি ("কার্ট-থেকে-ভিজিট রেট") দেখা গেছে।

৭০%-এর বেশি ওয়েবপেজে, প্রাথমিক ভিউপোর্টের সবচেয়ে বড় এলিমেন্টে একটি ছবি থাকে, হয় সেটি একটি স্বতন্ত্র <img> এলিমেন্ট অথবা ব্যাকগ্রাউন্ড ছবি সহ একটি এলিমেন্ট। অন্যভাবে বলতে গেলে, ৭০% পৃষ্ঠার LCP স্কোর ছবির পারফর্ম্যান্সের উপর নির্ভর করে। এর কারণ বোঝা খুব একটা কঠিন নয়: বড়, দৃষ্টি আকর্ষণকারী ছবি এবং লোগো "স্ক্রল না করেই" দেখতে পাওয়ার সম্ভাবনা অনেক বেশি।

LCP-র প্রসেস ডিলে হওয়া এড়াতে আপনি কয়েকটি পদক্ষেপ নিতে পারেন: প্রথমত, "অ্যাবাভ দ্য ফোল্ড" ইমেজে কখনও loading="lazy" নির্দিষ্ট করবেন না, কারণ পৃষ্ঠা রেন্ডার না হওয়া পর্যন্ত অনুরোধ ডিলে করলে, আপনার LCP স্কোরের উপর ব্যাপক নেতিবাচক প্রভাব পড়তে পারে। দ্বিতীয়ত, fetchpriority="high" ব্যবহার করে ব্রাউজারকে জানানো যেতে পারে যে পৃষ্ঠার অন্য যেকোনও ছবির তুলনায় এই ছবি ট্রান্সফার করার কাজকে অগ্রাধিকার দিতে হবে।

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

উপসংহার

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

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

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