Core Web Vitals-এর কথা মাথায় রেখে ধীরে ধীরে লোড করা ছবির জন্য ডেটা-চালিত পরামর্শ।
ধীরে ধীরে লোড করা হল এমন একটি টেকনিক যা ডেটা সংরক্ষণ করতে এবং গুরুত্বপূর্ণ অ্যাসেটের জন্য নেটওয়ার্কের বিরোধ কমাতে, প্রয়োজন না হওয়া পর্যন্ত রিসোর্স ডাউনলোড করা স্থগিত রাখে। এটি ২০১৯ সালে একটি ওয়েব স্ট্যান্ডার্ডে পরিণত হয়েছে এবং আজ ছবির জন্য loading="lazy" বেশিরভাগ প্রধান ব্রাউজার দ্বারা সমর্থিত।
ব্রাউজার-লেভেল ইমেজ ধীরে ধীরে লোড করার অ্যাডপশন ও পারফর্ম্যান্সের বৈশিষ্ট্য বুঝতে, সর্বজনীনভাবে উপলভ্য ওয়েব ট্রান্সপারেন্সি ডেটা ও অ্যাড হক A/B টেস্টিং কীভাবে বিশ্লেষণ করা হয়েছে তা এই নির্দেশিকায় সংক্ষেপে বলা হয়েছে। ফলাফলে দেখা গেছে যে ধীরে ধীরে লোড করা অপ্রয়োজনীয় ইমেজ বাইট কমানোর জন্য একটি অত্যন্ত কার্যকর টুল হতে পারে, তবে অতিরিক্ত ব্যবহার পারফর্ম্যান্সের উপর নেতিবাচক প্রভাব ফেলতে পারে। নির্দিষ্টভাবে, এই বিশ্লেষণ দেখায় যে প্রাথমিক ভিউপোর্টের মধ্যে আরও বেশি ছবি লোড করা—বাকিগুলি ধীরে ধীরে লোড করার সময়—আমাদের দুটি ক্ষেত্রেই সেরা ফলাফল দিতে পারে: কম বাইট লোড করা এবং উন্নত Core Web Vitals।
দত্তকগ্রহণ
HTTP আর্কাইভে থাকা সবচেয়ে সাম্প্রতিক ডেটা অনুযায়ী, ২৯% ওয়েবসাইটে বিল্ট-ইন ইমেজ ধীরে ধীরে লোড করার সুবিধা ব্যবহার করা হয় এবং এটি দ্রুত জনপ্রিয় হয়ে উঠছে।
HTTP আর্কাইভ প্রোজেক্টে র ডেটা কোয়েরি করলে, কোন ধরনের ওয়েবসাইট এই পদ্ধতি গ্রহণ করছে তা আমরা আরও স্পষ্টভাবে বুঝতে পারি: ব্রাউজার-লেভেল ইমেজ ধীরে ধীরে লোড করার পদ্ধতি ব্যবহার করে এমন সাইটের ৮৪% WordPress ব্যবহার করে, ২% অন্য CMS ব্যবহার করে এবং বাকি ১৪% কোনও পরিচিত CMS ব্যবহার করে না। এই ফলাফল থেকে স্পষ্ট বোঝা যায় যে, WordPress কীভাবে এই প্রযুক্তি গ্রহণ করার ক্ষেত্রে নেতৃত্ব দিচ্ছে।
অ্যাডপশনের হারও লক্ষ্য করার মতো। এক বছর আগে, ২০২০ সালের জুলাই মাসে, ধীরে ধীরে লোড করা ব্যবহার করে এমন WordPress সাইটগুলি প্রায় ৬০ লক্ষ (মোটের ১%) কর্পাসে হাজার হাজার ওয়েবসাইট তৈরি করেছে। শুধু WordPress-এ ধীরে ধীরে লোড করার পদ্ধতি গ্রহণ করার পর থেকে ১ মিলিয়নেরও বেশি ওয়েবসাইটে (মোটের ১৪%) এটি ব্যবহার করা হচ্ছে।
পারস্পরিক সম্পর্কযুক্ত পারফর্ম্যান্স
HTTP আর্কাইভ আরও গভীরভাবে বিশ্লেষণ করে, ব্রাউজার-লেভেল ইমেজ ধীরে ধীরে লোড করার সুবিধা সহ এবং ছাড়া পৃষ্ঠাগুলি লার্জেস্ট কন্টেন্টফুল পেইন্ট (LCP) মেট্রিক-এর সাথে কীভাবে পারফর্ম করে তা তুলনা করা যেতে পারে। ল্যাবে সিন্থেটিক টেস্টিংয়ের পরিবর্তে Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX) থেকে পাওয়া আসল ব্যবহারকারীর অভিজ্ঞতা থেকে LCP ডেটা পাওয়া যায়। নিম্নলিখিত চার্টটি প্রতিটি পৃষ্ঠার ৭৫তম পার্সেন্টাইল LCP-এর ডিস্ট্রিবিউশন ভিজ্যুয়ালাইজ করতে বক্স-অ্যান্ড-হুইস্কার প্লট ব্যবহার করে: লাইনগুলি ১০তম এবং ৯০তম পার্সেন্টাইল এবং বক্সগুলি ২৫তম এবং ৭৫তম পার্সেন্টাইলকে উপস্থাপন করে।
ধীরে ধীরে লোড করা হয় না এমন মিডিয়ান পৃষ্ঠার ৭৫তম পার্সেন্টাইল LCP হল ২,৯২২ মিলিসেকেন্ড, যেখানে ধীরে ধীরে লোড করা হয় এমন মিডিয়ান পৃষ্ঠার ক্ষেত্রে এটি হল ৩,৫৪৬ মিলিসেকেন্ড। সাধারণত, যেসব ওয়েবসাইট ধীরে ধীরে লোড করার পদ্ধতি ব্যবহার করে, সেগুলির LCP পারফর্ম্যান্স খারাপ হয়।
এটি উল্লেখ করা গুরুত্বপূর্ণ যে এগুলি হল পারস্পরিক সম্পর্কযুক্ত ফলাফল এবং এগুলি থেকে এটি বোঝা যায় না যে ধীরে ধীরে লোড করার কারণেই পারফর্ম্যান্স ধীর হয়ে গেছে। অনুমান করা যায় যে, WordPress সাইটগুলি যদি কিছুটা ধীরগতির হয় এবং তারা কতটা ধীরে ধীরে লোড করা কোহর্ট তৈরি করে, তা থেকে পার্থক্যের কারণ বোঝা যেতে পারে। সেই পরিবর্তনশীলতা দূর করতে, ফোকাসটি বিশেষভাবে WordPress সাইটে সীমাবদ্ধ করা যেতে পারে।
দুর্ভাগ্যবশত, WordPress পৃষ্ঠার ক্ষেত্রেও একই প্যাটার্ন দেখা যায়; যেগুলি ধীরে ধীরে লোড হয়, সেগুলির LCP পারফর্ম্যান্সও ধীরগতির হয়। ধীরে ধীরে লোড করা হয় না এমন মিডিয়ান WordPress পৃষ্ঠার ৭৫তম পার্সেন্টাইল LCP হল ৩,৪৯৫ মিলিসেকেন্ড, যেখানে ধীরে ধীরে লোড করা হয় এমন মিডিয়ান পৃষ্ঠার ক্ষেত্রে এটি হল ৩,৭৬৮ মিলিসেকেন্ড।
তবে, এর থেকে এখনও প্রমাণিত হয় না যে ধীরে ধীরে লোড করার কারণে পৃষ্ঠা ধীরে লোড হয়, তবে এটি ব্যবহার করলে পারফর্ম্যান্সের গতি কমে যায়। কারণ-ফলাফল সংক্রান্ত প্রশ্নের উত্তর দেওয়ার জন্য, ল্যাব-ভিত্তিক A/B টেস্ট সেট-আপ করা হয়েছিল।
কারণগত পারফর্ম্যান্স
A/B টেস্টের লক্ষ্য ছিল এই হাইপোথিসিস প্রমাণ বা অপ্রমাণ করা যে, WordPress কোরে প্রয়োগ করা বিল্ট-ইন ইমেজ ধীরে ধীরে লোড করার ফলে LCP পারফর্ম্যান্স ধীরগতির হয় এবং কম ইমেজ বাইট হয়। twentytwentyone থিম সহ একটি ডেমো WordPress ওয়েবসাইট পরীক্ষা করার জন্য এই পদ্ধতি ব্যবহার করা হয়েছে। WebPageTest ব্যবহার করে ডেস্কটপ এবং এমুলেট করা মোবাইল ডিভাইসে হোম এবং নিবন্ধ পৃষ্ঠার মতো আর্কাইভ এবং একক পৃষ্ঠার ধরন পরীক্ষা করা হয়েছে। ধীরে ধীরে লোড করার সুবিধা চালু থাকা ও না থাকা পৃষ্ঠার প্রতিটি কম্বিনেশন পরীক্ষা করা হয়েছে এবং প্রতিটি পরীক্ষা নয় বার করে চালানো হয়েছে যাতে মধ্যক LCP ভ্যালু ও ইমেজ বাইটের সংখ্যা পাওয়া যায়।
| সিরিজ | ডিফল্ট | অক্ষম | ডিফল্ট থেকে পার্থক্য |
|---|---|---|---|
| twentytwentyone-archive-desktop | ২,০২৯ | ১,৭৫৯ | -১৩% |
| twentytwentyone-archive-mobile | ১,৬৫৭ | ১,৪০৩ | -১৫% |
| twentytwentyone-single-desktop | ১,৬৫৫ | ১,৭২৬ | ৪% |
| twentytwentyone-single-mobile | ১,৩৫২ | ১,৩৮৪ | ২% |
এই ফলাফলগুলি ডেস্কটপ এবং মোবাইলের জন্য আর্কাইভ এবং একক পৃষ্ঠায় পরীক্ষার জন্য মিলিসেকেন্ডে মিডিয়ান LCP তুলনা করে। আর্কাইভ পৃষ্ঠায় ধীরে ধীরে লোড করার সুবিধা বন্ধ করে দেওয়ার পরে, LCP-তে উল্লেখযোগ্য উন্নতি দেখা গেছে। তবে, একটি পৃষ্ঠার ক্ষেত্রে, এটি খুব বেশি পার্থক্য তৈরি করেনি।
ধীরে ধীরে লোড করার সুবিধা বন্ধ করে দিলে, সিঙ্গেল পৃষ্ঠাগুলি একটু দ্রুত লোড হয় বলে মনে হচ্ছে। তবে, ডেস্কটপ ও মোবাইল, উভয় পরীক্ষার ক্ষেত্রেই LCP-এর পার্থক্য একটি স্ট্যান্ডার্ড ডেভিয়েশনের চেয়ে কম, তাই এটি পার্থক্যের কারণে হতে পারে এবং সামগ্রিকভাবে পরিবর্তনটি নিরপেক্ষ বলে বিবেচনা করা যেতে পারে। তুলনামূলকভাবে, আর্কাইভ পৃষ্ঠার ক্ষেত্রে পার্থক্য দুই থেকে তিন স্ট্যান্ডার্ড ডেভিয়েশনের কাছাকাছি।
| সিরিজ | ডিফল্ট | অক্ষম | ডিফল্ট থেকে পার্থক্য |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | ১০৩% |
| twentytwentyone-archive-mobile | 172 | 378 | ১২০% |
| twentytwentyone-single-desktop | 301 | 850 | ১৮৩% |
| twentytwentyone-single-mobile | 114 | 378 | ২৩৩% |
এই ফলাফল প্রতিটি পরীক্ষার জন্য ইমেজ বাইটের (কেবি-তে) মধ্যক সংখ্যার তুলনা করে। যেমনটি আশা করা হয়েছিল, ধীরে ধীরে লোড করার ফলে ইমেজ বাইটের সংখ্যা কমানোর ক্ষেত্রে খুব স্পষ্ট ইতিবাচক প্রভাব দেখা যায়। কোনও আসল ব্যবহারকারী পুরো পৃষ্ঠা স্ক্রল করলে, ভিউপোর্ট অতিক্রম করার সময় সব ছবি লোড হয়ে যাবে, তবে এই ফলাফল থেকে প্রাথমিক পৃষ্ঠা লোড হওয়ার সময় উন্নত পারফর্ম্যান্সের বিষয়টি বোঝা যায়।
A/B Test-এর ফলাফল সংক্ষেপে বলতে গেলে, WordPress-এর ব্যবহার করা ধীরে ধীরে লোড করার টেকনিক, LCP-তে দেরি হওয়ার বিনিময়ে ছবির বাইট কমাতে খুব স্পষ্টভাবে সাহায্য করে।
সমাধান পরীক্ষা করা হচ্ছে
এই এক্সপেরিমেন্টের জন্য WordPress-এর বর্তমান ধীরে ধীরে লোড করার ইমপ্লিমেন্টেশনের সবচেয়ে গুরুত্বপূর্ণ দিক হল এটি ভিউপোর্টের মধ্যে ছবি ধীরে ধীরে লোড করে (স্ক্রল না করে দেখা যায় এমন অংশ)। CMS ব্লগ পোস্টে এটিকে এড়িয়ে চলার মতো প্যাটার্ন হিসেবে স্বীকার করা হয়েছে, তবে সেই সময়কার পরীক্ষামূলক ডেটা থেকে বোঝা যায় যে LCP-এর উপর এর প্রভাব ছিল ন্যূনতম এবং WordPress কোরে ইমপ্লিমেন্টেশন সহজ করার জন্য এটি উপযুক্ত।
এই নতুন ডেটার ভিত্তিতে, একটি পরীক্ষামূলক সমাধান তৈরি করা হয়েছিল যা ফোল্ডের উপরে থাকা ছবিগুলি ধীরে ধীরে লোড করা এড়িয়ে যায় এবং প্রথম A/B টেস্টের মতো একই পরিস্থিতিতে সমাধানটি পরীক্ষা করা হয়েছিল।
| সিরিজ | ডিফল্ট | অক্ষম | ঠিক করুন | ডিফল্ট থেকে পার্থক্য | বন্ধ করা থেকে পার্থক্য |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | ২,০২৯ | ১,৭৫৯ | ১,৭৪৯ | -১৪% | -১% |
| twentytwentyone-archive-mobile | ১,৬৫৭ | ১,৪০৩ | ১,৩৫২ | -১৮% | -৪% |
| twentytwentyone-single-desktop | ১,৬৫৫ | ১,৭২৬ | ১,৬৭৬ | ১% | -৩% |
| twentytwentyone-single-mobile | ১,৩৫২ | ১,৩৮৪ | ১,৩৪২ | -১% | -৩% |
এইসব ফলাফল অনেক বেশি আশাব্যঞ্জক। শুধুমাত্র বিলো-দ্য-ফোল্ড ছবি ধীরে ধীরে লোড করার ফলে LCP রিগ্রেশন সম্পূর্ণভাবে রিভার্স হয়ে যায় এবং ধীরে ধীরে লোড করার সুবিধা সম্পূর্ণভাবে বন্ধ করার তুলনায় সামান্য উন্নতিও হতে পারে। ধীরে ধীরে লোড না করার চেয়ে এটি কীভাবে দ্রুত হতে পারে? একটি ব্যাখ্যা হল, বিলো-দ্য-ফোল্ড ছবি লোড না করার মাধ্যমে, LCP ছবির সাথে নেটওয়ার্কের কম প্রতিযোগিতা হয়, যা এটিকে আরও দ্রুত লোড করতে সক্ষম করে।
| সিরিজ | ডিফল্ট | অক্ষম | ঠিক করুন | ডিফল্ট থেকে পার্থক্য | বন্ধ করা থেকে পার্থক্য |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | ০% | -৫১% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | ০% | -৫৪% |
| twentytwentyone-single-desktop | 301 | 850 | 301 | ০% | ৬৫% কম |
| twentytwentyone-single-mobile | 114 | 378 | 114 | ০% | -৭০% |
ইমেজ বাইটের ক্ষেত্রে, ডিফল্ট অ্যাকশনের তুলনায় এই সমাধানে কোনও পরিবর্তন নেই। এটি খুব ভালো কারণ এটি বর্তমান পদ্ধতির অন্যতম শক্তিশালী দিক।
এই সমাধানের সাথে কিছু সতর্কতাও রয়েছে। সার্ভার সাইডে কোন ছবি ধীরে ধীরে লোড করা হবে তা WordPress নির্ধারণ করে, যার অর্থ হল এটি ব্যবহারকারীর ভিউপোর্ট সাইজ বা ছবি প্রাথমিকভাবে এর মধ্যে লোড হয় কিনা সে সম্পর্কে কিছুই জানে না। তাই, ভিউপোর্টে এটি লোড হয় কিনা তা অনুমান করতে, মার্কআপে ছবির আপেক্ষিক লোকেশন সম্পর্কে হিউরিস্টিক ব্যবহার করে এই সমস্যার সমাধান করা হয়। বিশেষ করে, ছবিটি যদি পৃষ্ঠার প্রথম ফিচার করা ছবি বা মূল কন্টেন্টের প্রথম ছবি হয়, তাহলে ধরে নেওয়া হয় যে এটি ভাঁজের উপরে বা তার কাছাকাছি আছে এবং এটি ধীরে ধীরে লোড করা হবে না।
পৃষ্ঠা-লেভেল শর্ত যেমন শিরোনামে শব্দের সংখ্যা বা মূল কন্টেন্টের শুরুতে প্যারাগ্রাফ টেক্সটের পরিমাণ, ভিউপোর্টের মধ্যে ছবি আছে কিনা তা প্রভাবিত করতে পারে। এছাড়াও, ব্যবহারকারী-লেভেলের শর্ত আছে যা হিউরিস্টিক্সের নির্ভুলতাকে প্রভাবিত করতে পারে, বিশেষ করে ভিউপোর্ট সাইজ এবং অ্যাঙ্কর লিঙ্কের ব্যবহার যা পৃষ্ঠার স্ক্রল পজিশন পরিবর্তন করে।
এইসব কারণে, এটি স্বীকার করা গুরুত্বপূর্ণ যে সমাধানটি শুধুমাত্র সাধারণ ক্ষেত্রে ভালো পারফর্ম্যান্স প্রদান করার জন্য ক্যালিব্রেট করা হয়েছে এবং এই ফলাফলগুলি সমস্ত বাস্তব-জগতের পরিস্থিতিতে প্রযোজ্য করার জন্য ফাইন-টিউন করার প্রয়োজন হতে পারে।
প্রয়োগ
এখন যেহেতু ধীরে ধীরে লোড করা ছবির আরও ভালো উপায় চিহ্নিত করা হয়েছে, সমস্ত ছবি সেভ করা এবং দ্রুত LCP পারফর্ম্যান্স, সাইটগুলি কীভাবে এটি ব্যবহার করা শুরু করতে পারে? সবচেয়ে বেশি অগ্রাধিকার দিয়ে যে পরিবর্তনটি করতে হবে তা হল, পরীক্ষামূলক সমাধান প্রয়োগ করার জন্য WordPress কোরে একটি প্যাচ জমা দেওয়া। CMS-এর জন্য ব্রাউজার-লেভেল ধীরে ধীরে লোড করা ব্লগ পোস্টে দেওয়া নির্দেশিকাও আপডেট করা হবে যাতে উপরে-ভাঁজ করা ধীরে ধীরে লোড করার নেতিবাচক প্রভাব এবং CMS কীভাবে হিউরিস্টিক ব্যবহার করে এটি এড়াতে পারে তা স্পষ্ট করা যায়।
এই পেশাদার পদ্ধতিগুলি সব ওয়েব ডেভেলপারের ক্ষেত্রে প্রযোজ্য, তাই Lighthouse-এর মতো টুলে ধীরে ধীরে লোড করার অ্যান্টিপ্যাটার্ন ফ্ল্যাগ করাও গুরুত্বপূর্ণ হতে পারে। আপনি যদি সেই অডিটের অগ্রগতি অনুসরণ করতে আগ্রহী হন, তাহলে GitHub-এ ফিচার রিকোয়েস্ট দেখুন। ততক্ষণ পর্যন্ত, LCP এলিমেন্ট ধীরে ধীরে লোড হওয়ার উদাহরণ খুঁজে পেতে ডেভেলপাররা একটি কাজ করতে পারেন, তা হল ফিল্ড ডেটাতে আরও বিস্তারিত লগিং যোগ করা।
new PerformanceObserver((list) => {
const latestEntry = list.getEntries().at(-1);
if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
console.warn('Warning: LCP element was lazy loaded', latestEntry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
পূর্ববর্তী জাভাস্ক্রিপ্ট স্নিপেট সবচেয়ে সাম্প্রতিক LCP এলিমেন্ট মূল্যায়ন করবে এবং এটি ধীরে ধীরে লোড করা হলে একটি সতর্কতা লগ করবে।
এটি ধীরে ধীরে লোড করার টেকনিকের একটি তীক্ষ্ণ প্রান্ত এবং প্ল্যাটফর্ম লেভেলে API উন্নতির সম্ভাবনাকেও হাইলাইট করে। যেমন, Chromium-এ একটি সমস্যা এখনও সমাধান করা হয়নি, যেখানে loading অ্যাট্রিবিউট থাকা সত্ত্বেও, প্রথম কয়েকটি ছবি নেটিভভাবে লোড করার জন্য পরীক্ষা করা হচ্ছে, যা এই সমস্যার সমাধানের মতোই।
উপসংহার
আপনার সাইট যদি ব্রাউজার-লেভেল ইমেজ ধীরে ধীরে লোড করার পদ্ধতি ব্যবহার করে, তাহলে এটি কীভাবে প্রয়োগ করা হয়েছে তা চেক করুন এবং এর পারফর্ম্যান্স খরচ আরও ভালোভাবে বুঝতে A/B টেস্ট চালান। এটি আরও বেশি আগ্রহের সাথে উপরের ফোল্ডে ছবি লোড করার মাধ্যমে উপকৃত হতে পারে। আপনার WordPress সাইট থাকলে, আশা করা যায় যে শীঘ্রই WordPress কোরে একটি প্যাচ ল্যান্ডিং হবে। আপনি অন্য কোনও CMS ব্যবহার করলে, এখানে উল্লেখ করা পারফর্ম্যান্স সংক্রান্ত সম্ভাব্য সমস্যা সম্পর্কে তারা অবগত কিনা তা নিশ্চিত করুন।
তুলনামূলকভাবে নতুন ওয়েব প্ল্যাটফর্ম API ব্যবহার করে দেখার মধ্যে ঝুঁকি ও পুরস্কার দুই-ই আছে—এগুলিকে অত্যাধুনিক ফিচার বলা হয়। ব্রাউজার-লেভেল ইমেজ ধীরে ধীরে লোড করার জটিলতা আমরা বুঝতে শুরু করেছি, তবে আরও ভালো পারফর্ম্যান্সের জন্য এটি কীভাবে ব্যবহার করা যায় তাও আমরা দেখছি।