এখন যেমন দাঁড়িয়েছে, প্রতি পৃষ্ঠায় মোট স্থানান্তর আকার এবং অনুরোধের সংখ্যা উভয়ের ক্ষেত্রেই ছবিগুলি ওয়েবের সবচেয়ে বড় সম্পদ। মিডিয়ান ওয়েবপেজের মোট স্থানান্তর আকার প্রায় 2MB, জুন 2022 অনুযায়ী , শুধুমাত্র ছবিই এর প্রায় অর্ধেক। ইমেজ অনুরোধ অপ্টিমাইজ করা একটি একক বৃহত্তম কর্মক্ষমতা অপ্টিমাইজেশান হতে পারে যে বলতে কোন অতিরঞ্জিত হয় না.
পরে, আপনি শিখবেন কিভাবে প্রতিক্রিয়াশীল চিত্রগুলি সমস্ত ঘটনার জন্য একটি চিত্র পরিবেশন করার চেষ্টা করে তৈরি সমস্যাগুলির সাথে সাহায্য করার জন্য বিকশিত হয়েছে৷ এই বিভাগে, চিত্রগুলির সাথে সম্পর্কিত মূল কর্মক্ষমতা মেট্রিক্স এবং কীভাবে সেগুলি উন্নত করা যায় তা আবিষ্কার করুন৷
ইমেজ অনুরোধ deferring
আপনি যখন আপনার ছবির অনুরোধগুলি যতটা সম্ভব ছোট এবং দক্ষ তা নিশ্চিত করার জন্য অনেকগুলি উপায় শিখতে চলেছেন, সবচেয়ে দ্রুত চিত্র অনুরোধটি সর্বদা এমন একটি হবে যা কখনও করা হয় না। তাই, সামনের দিকে, আমি শেয়ার করতে চাই যে আপনি আপনার ব্যবহারকারীদের কাছে ইমেজ সম্পদ সরবরাহ করার পদ্ধতিতে সবচেয়ে প্রভাবশালী পরিবর্তন কি করতে পারেন: loading="lazy" বৈশিষ্ট্য।
<img src="image.jpg" loading="lazy" alt="…">
এই বৈশিষ্ট্যটি নিশ্চিত করে যে ছবিগুলির জন্য অনুরোধগুলি ব্যবহারকারীর ভিউপোর্টের কাছাকাছি না আসা পর্যন্ত করা হবে না, প্রাথমিক পৃষ্ঠার লোড থেকে সেগুলিকে পিছিয়ে দেয়—যে সময় ব্রাউজারটি সবচেয়ে ব্যস্ত থাকে—এবং সেই অনুরোধগুলিকে সমালোচনামূলক রেন্ডারিং পাথ থেকে সরিয়ে দেয়৷
বাস্তবে যতটা সহজ, এই বৈশিষ্ট্যটি ব্যবহার করলে কর্মক্ষমতার উপর বিশাল ইতিবাচক প্রভাব পড়তে পারে: এমন একটি চিত্র যা ব্যবহারকারীর ভিউপোর্টের মধ্যে পড়ে না তার জন্য কখনই অনুরোধ করা হবে না, এবং ব্যবহারকারী কখনই দেখতে পাবে না এমন চিত্রগুলিতে কোনও ব্যান্ডউইথ নষ্ট হবে না।
তবে একটি ধরা আছে: এই অনুরোধগুলিকে পিছিয়ে দেওয়ার অর্থ হল যত তাড়াতাড়ি সম্ভব ছবিগুলির অনুরোধ করার জন্য ব্রাউজারের হাইপার-অপ্টিমাইজড প্রক্রিয়াগুলির সুবিধা না নেওয়া৷ যদি লেআউটের উপরের দিকে img উপাদানগুলিতে loading="lazy" ব্যবহার করা হয়—এবং এইভাবে পৃষ্ঠাটি প্রথম লোড করার সময় ব্যবহারকারীর ভিউপোর্টে থাকার সম্ভাবনা বেশি থাকে—এই চিত্রগুলি শেষ ব্যবহারকারীর কাছে উল্লেখযোগ্যভাবে ধীর অনুভব করতে পারে।
অগ্রাধিকার আনুন
loading অ্যাট্রিবিউট হল একটি বৃহত্তর ওয়েব স্ট্যান্ডার্ড প্রচেষ্টার একটি উদাহরণ যাতে ওয়েব ব্রাউজারগুলি কীভাবে অনুরোধগুলিকে অগ্রাধিকার দেয় তার উপর ডেভেলপারদের আরও ক্ষমতা দেয়৷
আপনি সম্ভবত অগ্রাধিকার আনার জন্য ব্রাউজারগুলির মৌলিক পদ্ধতি সম্পর্কে সচেতন: উদাহরণস্বরূপ, একটি নথির <head> এ একটি বহিরাগত CSS ফাইলের জন্য একটি অনুরোধ রেন্ডারকে ব্লক করার জন্য যথেষ্ট প্রয়োজনীয় বলে বিবেচিত হয়, যখন ঠিক উপরে একটি বহিরাগত জাভাস্ক্রিপ্ট ফাইলের জন্য একটি অনুরোধ রেন্ডার সম্পূর্ণ না হওয়া পর্যন্ত </body> পিছিয়ে যাবে। যদি একটি <img> এ একটি loading বৈশিষ্ট্যের মান 'অলস' হয়, তাহলে ব্রাউজার এটি ব্যবহারকারীকে দেখানো হবে তা নির্ধারণ না করা পর্যন্ত সংশ্লিষ্ট চিত্র অনুরোধটি স্থগিত করা হবে। অন্যথায়, সেই ছবিটি পৃষ্ঠার অন্য যেকোনো ছবির মতোই অগ্রাধিকার পাবে।
fetchpriority অ্যাট্রিবিউটটি ডেভেলপারদের সম্পদের অগ্রাধিকারের উপর আরও সূক্ষ্ম নিয়ন্ত্রণ দেওয়ার উদ্দেশ্যে তৈরি করা হয়েছে, যা আপনাকে একই ধরনের সম্পদের সাপেক্ষে সম্পদকে 'উচ্চ' এবং 'নিম্ন' অগ্রাধিকার হিসাবে ফ্ল্যাগ করতে দেয়। fetchpriority ব্যবহারের ক্ষেত্রে loading অ্যাট্রিবিউটের মতো, যদিও অনেক বেশি বিস্তৃত। উদাহরণস্বরূপ, আপনি পৃষ্ঠার অন্য কোথাও দৃশ্যমান ছবিগুলিকে অগ্রাধিকার দেওয়ার জন্য শুধুমাত্র ব্যবহারকারীর ইন্টারঅ্যাকশনের পরে প্রকাশিত একটি ছবিতে fetchpriority="low" ব্যবহার করতে পারেন (সেটি ছবিটি ব্যবহারকারীর ভিউপোর্টের মধ্যে পড়ে বা না হয়) বা অগ্রাধিকার দিতে fetchpriority="high" ব্যবহার করতে পারেন পৃষ্ঠাটি রেন্ডার হওয়ার সাথে সাথে আপনার পরিচিত একটি চিত্র ভিউপোর্টে অবিলম্বে দৃশ্যমান হবে৷
মনে রাখবেন যে fetchpriority loading থেকে আলাদা যে এটি ব্রাউজারের আচরণকে মৌলিকভাবে পরিবর্তন করে না। এটি ব্রাউজারকে অন্যদের আগে নির্দিষ্ট সম্পদ লোড করার নির্দেশ দেয় না, পরিবর্তে এটি সম্পদের অনুরোধের বিষয়ে সিদ্ধান্ত নেওয়ার জন্য গুরুত্বপূর্ণ প্রসঙ্গ দেয়।
ইমেজ প্রভাব পরিমাপ
ইমেজ সম্পদ অপ্টিমাইজ করার সময়, অনুভূত কর্মক্ষমতা প্রায়ই বেশি গুরুত্বপূর্ণ, এবং পরিমাপ করা আরও কঠিন, একা মোট স্থানান্তর আকারের চেয়ে।
ওয়েব ভাইটালগুলি পরিমাপযোগ্য, কর্মযোগ্য মেট্রিক্স এবং ওয়েবের ব্যবহারকারীদের অভিজ্ঞতা উন্নত করার জন্য নির্দেশিকা প্রদান করে, ওয়েব সার্ভার থেকে ধীর প্রতিক্রিয়ার সময়, রেন্ডারিং সমস্যা এবং ইন্টারঅ্যাক্টিভিটি বিলম্বের মতো সমস্যাগুলি হাইলাইট করে। কোর ওয়েব ভাইটাল হল এই লক্ষ্যগুলির একটি উপসেট, একটি পৃথক পৃষ্ঠার ব্যবহারকারীর প্রত্যক্ষ অভিজ্ঞতার উপর লেজার-কেন্দ্রিক-প্রযুক্তিগত পরিমাপের একটি সেট যা একসাথে, একটি অভিজ্ঞতা ব্যবহারকারীর কাছে কতটা দ্রুত অনুভব করে তা নির্ধারণ করে।
ক্রমবর্ধমান লেআউট শিফট
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" alt="…">
img {
max-width: 100%;
height: auto;
}
পূর্ববর্তী উদাহরণের মতো height এবং width বৈশিষ্ট্যগুলি সরিয়ে ফেলার পরে, এই পরিস্থিতিতে চিত্রের উচ্চতা নির্ধারণের জন্য ব্রাউজারটির একমাত্র পদ্ধতিটি হল উত্সের জন্য অনুরোধ করা, এটিকে পার্স করা এবং এটির অন্তর্নিহিত অনুপাতের উপর ভিত্তি করে রেন্ডার করা। স্টাইলশীট প্রয়োগ করা হলে লেআউটে এটি যে স্থান দখল করে তার প্রস্থ। এই প্রক্রিয়াটির বেশিরভাগই পৃষ্ঠাটি রেন্ডার হওয়ার পরে সঞ্চালিত হয়, নতুন গণনা করা উচ্চতা অতিরিক্ত লেআউট স্থানান্তর ঘটায়।
2019 থেকে শুরু করে , width এবং height বৈশিষ্ট্যগুলিকে ভিন্নভাবে পরিচালনা করতে ব্রাউজারের আচরণ আপডেট করা হয়েছিল। বিন্যাসে একটি img উপাদানের স্থির, পিক্সেল-ভিত্তিক আকার নির্ধারণের জন্য এই বৈশিষ্ট্যগুলির মানগুলি ব্যবহার করার পরিবর্তে, এই বৈশিষ্ট্যগুলিকে চিত্রের আকৃতির অনুপাতের প্রতিনিধিত্ব করার কথা ভাবা যেতে পারে, যদিও সিনট্যাক্স একই। আধুনিক ব্রাউজারগুলি পৃষ্ঠাটি রেন্ডার হওয়ার আগে একটি img উপাদানের অন্তর্নিহিত আকৃতির অনুপাত নির্ধারণ করার জন্য এই মানগুলিকে একে অপরের বিরুদ্ধে বিভক্ত করবে, যাতে লেআউটটি রেন্ডার হওয়ার সাথে সাথে চিত্রটি যে স্থান দখল করবে তা সংরক্ষণ করতে দেয়৷
একটি নিয়ম হিসাবে, আপনার সর্বদা <img> এ height এবং width বৈশিষ্ট্যগুলি ব্যবহার করা উচিত, মানগুলি আপনার চিত্রের উত্সের অন্তর্নিহিত আকারের সাথে মেলে—যতক্ষণ আপনি নিশ্চিত হন যে আপনি উচ্চতা নির্দিষ্ট করেছেন: max-width: 100% পাশাপাশি height: auto : 100% থেকে HTML অ্যাট্রিবিউট থেকে উচ্চতা ওভাররাইড করুন।
<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 সমস্যাগুলি এড়াতে পারে, ব্যবহারকারীরা একটি খালি ফাঁক বা নিম্ন-মানের স্থানধারক সহ উপস্থাপন করে যখন তারা একটি চিত্র স্থানান্তর এবং রেন্ডার করার জন্য অপেক্ষা করে তখনও আদর্শ নয়। যদিও ধীর-থেকে-লোড চিত্রগুলির পরিমাপযোগ্য এবং উপলব্ধিযোগ্য প্রভাবকে প্রশমিত করার জন্য আপনি কিছু করতে পারেন, তবে ব্যবহারকারীর কাছে একটি সম্পূর্ণ-রেন্ডার করা চিত্রটি আরও দ্রুত উপস্থাপন করার একমাত্র উপায় হল এর স্থানান্তর আকার হ্রাস করা।
সবচেয়ে বড় বিষয়বস্তু পেইন্ট
লার্জেস্ট কনটেন্টফুল পেইন্ট (LCP) ব্যবহারকারীর ভিউপোর্টে দৃশ্যমান সবচেয়ে বড় "কন্টেন্টফুল" উপাদানটিকে রেন্ডার করতে যে সময় লাগে তা পরিমাপ করে—যে বিষয়বস্তু উপাদানটি দৃশ্যমান পৃষ্ঠার বৃহত্তম শতাংশ দখল করে। এটি পৃষ্ঠায় একটি অতিমাত্রায় নির্দিষ্ট মেট্রিকের মতো মনে হতে পারে, কিন্তু সেই উপাদানটি ব্যবহারকারীর দৃষ্টিকোণ থেকে, পৃষ্ঠার বেশিরভাগ অংশ রেন্ডার করা হয়েছে এমন বিন্দুর জন্য একটি ব্যবহারিক প্রক্সি হিসাবে কাজ করে৷ LCP হল (অনুভূত) কর্মক্ষমতার একটি গুরুত্বপূর্ণ পরিমাপ।
DOMContentLoaded বা window.onload ইভেন্টের মতো মেট্রিকগুলি বর্তমান পৃষ্ঠাটি লোড করার প্রক্রিয়া কখন টেকনিক্যালভাবে সম্পূর্ণ হয়েছে তা নির্ধারণের জন্য উপযোগী হতে পারে, কিন্তু সেগুলি অবশ্যই পৃষ্ঠাটির ব্যবহারকারীর অভিজ্ঞতার সাথে সঙ্গতিপূর্ণ নয়৷ ব্যবহারকারীর ভিউপোর্টের বাইরে একটি উপাদান রেন্ডার করতে সামান্য বিলম্ব এই মেট্রিকগুলির মধ্যে একটিতে ফ্যাক্টর করা হবে, তবে সম্ভবত একজন বাস্তব-বিশ্ব ব্যবহারকারীর দ্বারা সম্পূর্ণরূপে সনাক্ত করা যাবে না। একটি দীর্ঘ LCP মানে হল একটি পৃষ্ঠার ব্যবহারকারীর প্রথম ইম্প্রেশন—বর্তমান ভিউপোর্টের মধ্যে সবচেয়ে গুরুত্বপূর্ণ বিষয়বস্তু—হল পৃষ্ঠাটি ধীর, বা একেবারে ভেঙে গেছে।
LCP দ্বারা ক্যাপচার করা ব্যবহারকারীর উপলব্ধি ব্যবহারকারীর অভিজ্ঞতার উপর সরাসরি প্রভাব ফেলে। গত বছর ভোডাফোনের করা একটি পরীক্ষায় দেখা গেছে যে এলসিপি-তে 31% উন্নতি শুধুমাত্র 8% বেশি বিক্রির দিকে পরিচালিত করে-নিজেই একটি শক্তিশালী ফলাফল—কিন্তু তাদের মোট ব্যবহারকারীর সংখ্যার মধ্যে, দর্শকের সংখ্যায় 15% উন্নতি হয়েছে। যারা সম্ভাব্য গ্রাহক হয়েছেন ("ভিজিটর-টু-লিড রেট") এবং তাদের কার্ট পরিদর্শনকারী ব্যবহারকারীর সংখ্যায় 11% উন্নতি হয়েছে ("কার্ট টু ভিজিট রেট")।
70% এরও বেশি ওয়েবপেজে, প্রাথমিক ভিউপোর্টের সবচেয়ে বড় উপাদানটি একটি চিত্রকে জড়িত করে, হয় একটি স্বতন্ত্র <img> উপাদান বা একটি পটভূমি চিত্র সহ একটি উপাদান। অন্য কথায়, পৃষ্ঠাগুলির LCP স্কোরগুলির 70% চিত্র কর্মক্ষমতার উপর ভিত্তি করে। এটি দেখতে খুব বেশি কল্পনা লাগে না কেন: বড়, মনোযোগ আকর্ষণকারী ছবি এবং লোগোগুলি "ভাঁজের উপরে" পাওয়া যাওয়ার সম্ভাবনা খুব বেশি।
এলসিপি বিলম্ব এড়াতে আপনি কিছু পদক্ষেপ নিতে পারেন: প্রথমত, "ভাঁজের উপরে" ছবিতে কখনই loading="lazy" উল্লেখ করবেন না, কারণ পৃষ্ঠাটি রেন্ডার না হওয়া পর্যন্ত অনুরোধটি বিলম্বিত করা সম্ভবত একটি বিশাল নেতিবাচক প্রভাব ফেলবে আপনার LCP স্কোর। দ্বিতীয়ত, fetchpriority="high" ব্যবহার করে ব্রাউজারকে জানাতে পারে যে এই ছবির স্থানান্তরকে পৃষ্ঠার অন্য কোথাও চিত্রগুলির উপরে অগ্রাধিকার দেওয়া উচিত।
এই নিয়মগুলি বর্ধিতভাবে মাথায় রেখে, একটি পৃষ্ঠার LCP স্কোর উন্নত করার জন্য আপনি সবচেয়ে গুরুত্বপূর্ণ যে কাজটি করতে পারেন তা হল সেই ছবিগুলি স্থানান্তর এবং রেন্ডার করতে কতটা সময় লাগে তা হ্রাস করুন৷ এটি করার জন্য, আপনাকে আপনার ছবির উত্স যতটা সম্ভব ছোট এবং দক্ষ রাখতে হবে (অবশ্যই তাদের গুণমান বিসর্জন না করে) এবং নিশ্চিত করতে হবে যে ব্যবহারকারীরা কেবলমাত্র তাদের ব্রাউজিং প্রসঙ্গগুলির জন্য সবচেয়ে অর্থপূর্ণ চিত্র সম্পদগুলি পাচ্ছেন৷
উপসংহার
ইমেজ সম্পদ হল আপনার ব্যবহারকারীদের ব্যান্ডউইথের সবচেয়ে বড় ড্রেন—একটি পৃষ্ঠা রেন্ডার করার জন্য প্রয়োজনীয় অন্যান্য সম্পদ স্থানান্তর থেকে ব্যান্ডউইথ কেড়ে নেওয়া হয়। চিত্রগুলি আশেপাশের পৃষ্ঠার বিন্যাস রেন্ডার হওয়ার সময় এবং পরে উভয়ই অনুভূত কার্যক্ষমতার ক্ষেত্রে উল্লেখযোগ্য সমস্যাগুলি উপস্থাপন করে৷ সংক্ষেপে: ছবির সম্পদ ক্ষতি করে।
এটি ভয়ঙ্কর হতে পারে, যদিও "ওয়েবটি কম চিত্রের সাথে আরও ভাল হবে" অবশ্যই একা পারফরম্যান্সের ক্ষেত্রে সত্য হবে, এটি এর ব্যবহারকারীদের একটি দুর্দান্ত ক্ষতিও করবে৷ ছবিগুলি ওয়েবের একটি অত্যাবশ্যক অংশ, এবং শুধুমাত্র কর্মক্ষমতার জন্য অর্থপূর্ণ সামগ্রীর মানের সাথে আপনার আপস করা উচিত নয়৷
এই কোর্সের বাকি অংশে, আপনি সেই প্রযুক্তিগুলি সম্পর্কে শিখবেন যা আমাদের চিত্র সম্পদগুলিকে শক্তিশালী করে এবং গুণমানের সাথে আপস না করে তাদের কার্যক্ষমতার প্রভাবগুলি হ্রাস করার কৌশলগুলি।