অত্যধিক অলস লোডিং কর্মক্ষমতা প্রভাব

কোর ওয়েব ভাইটালগুলিকে মাথায় রেখে অলস লোডিং চিত্রগুলির জন্য ডেটা-চালিত পরামর্শ৷

Felix Arntz

Rick Viscomi

অলস লোডিং এমন একটি কৌশল যা ডেটা সংরক্ষণ করতে এবং গুরুত্বপূর্ণ সম্পদের জন্য নেটওয়ার্ক বিরোধ কমাতে প্রয়োজন না হওয়া পর্যন্ত কোনও সংস্থান ডাউনলোড করা পিছিয়ে দেয়। এটি 2019 সালে একটি ওয়েব স্ট্যান্ডার্ড হয়ে ওঠে এবং আজকে ছবির জন্য loading="lazy" বেশিরভাগ প্রধান ব্রাউজার দ্বারা সমর্থিত ।

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

দত্তক

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

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

দত্তক নেওয়ার হারও লক্ষণীয়। এক বছর আগে 2020 সালের জুলাই মাসে, ওয়ার্ডপ্রেস সাইটগুলি যেগুলি অলস লোডিং ব্যবহার করে প্রায় 6 মিলিয়ন (মোট 1%) এর মধ্যে কয়েক হাজার ওয়েবসাইট তৈরি করেছিল। শুধুমাত্র ওয়ার্ডপ্রেসে অলস লোডিং গ্রহণের পর থেকে 1 মিলিয়নেরও বেশি ওয়েবসাইট (মোট 14%) বেড়েছে।

পারস্পরিক পারফরম্যান্স

HTTP আর্কাইভের আরও গভীরে খনন করে , ব্রাউজার-লেভেল ইমেজ অলস লোডিং সহ এবং ব্যতীত পৃষ্ঠাগুলি কীভাবে সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP) মেট্রিকের সাথে কাজ করে তা তুলনা করা যেতে পারে। LCP ডেটা ল্যাবে কৃত্রিম পরীক্ষার বিপরীতে Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX) থেকে বাস্তব-ব্যবহারকারীর অভিজ্ঞতা থেকে আসে। নিম্নলিখিত চার্টটি প্রতিটি পৃষ্ঠার 75 তম পার্সেন্টাইল এলসিপির ডিস্ট্রিবিউশনগুলি কল্পনা করার জন্য একটি বাক্স-এবং-হুইস্কার প্লট ব্যবহার করে: লাইনগুলি 10 তম এবং 90 তম পার্সেন্টাইল এবং বাক্সগুলি 25 তম এবং 75 তম পার্সেন্টাইল প্রতিনিধিত্ব করে৷

অলস লোডিং ছাড়া মধ্যমা পৃষ্ঠাটির 2,922 মিলিসেকেন্ডের 75 তম পার্সেন্টাইল LCP রয়েছে, অলস লোডিং সহ মিডিয়ান পৃষ্ঠাটির জন্য 3,546 মিলিসেকেন্ডের তুলনায়। সামগ্রিকভাবে, যে ওয়েবসাইটগুলি অলস লোডিং ব্যবহার করে সেগুলির LCP কার্যক্ষমতা আরও খারাপ হয়৷

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

দুর্ভাগ্যবশত, ওয়ার্ডপ্রেস পৃষ্ঠাগুলিতে ড্রিল করার সময় একই প্যাটার্ন আবির্ভূত হয়; যারা অলস লোডিং ব্যবহার করে তাদের LCP কর্মক্ষমতা কম থাকে। অলস লোডিং ছাড়া মিডিয়ান ওয়ার্ডপ্রেস পৃষ্ঠায় 3,495 মিলিসেকেন্ডের 75তম পার্সেন্টাইল LCP রয়েছে, যেখানে অলস লোডিং সহ মিডিয়ান পৃষ্ঠার জন্য 3,768 মিলিসেকেন্ডের তুলনায়।

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

কার্যকারণ কর্মক্ষমতা

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

এই ফলাফলগুলি ডেস্কটপ এবং মোবাইলের জন্য সংরক্ষণাগার এবং একক পৃষ্ঠাগুলির পরীক্ষার জন্য মিলিসেকেন্ডে মধ্যম LCP তুলনা করে। যখন সংরক্ষণাগার পৃষ্ঠাগুলিতে অলস লোডিং অক্ষম করা হয়েছিল, তখন LCP একটি উল্লেখযোগ্য ব্যবধানে উন্নত হয়েছিল৷ একক পৃষ্ঠায়, তবে, এটি একটি পার্থক্য কম করেছে।

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

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

A/B পরীক্ষার ফলাফল সংক্ষিপ্ত করার জন্য, WordPress দ্বারা ব্যবহৃত অলস লোডিং কৌশলটি খুব স্পষ্টভাবে বিলম্বিত LCP-এর খরচে ইমেজ বাইট কমাতে সাহায্য করে।

একটি ফিক্স পরীক্ষা

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

এই নতুন ডেটা প্রদত্ত, একটি পরীক্ষামূলক সমাধান তৈরি করা হয়েছিল যা ভাঁজের উপরে থাকা অলস লোডিং চিত্রগুলি এড়ায় এবং প্রথম A/B পরীক্ষার মতো একই অবস্থার অধীনে ফিক্সটি পরীক্ষা করা হয়েছিল।

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

ইমেজ বাইটের পরিপ্রেক্ষিতে, ডিফল্ট আচরণের তুলনায় ফিক্সের একেবারে কোন পরিবর্তন নেই। এটি দুর্দান্ত কারণ এটি বর্তমান পদ্ধতির অন্যতম শক্তি ছিল।

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

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

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

বাস্তবায়ন

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

যেহেতু এই সর্বোত্তম অনুশীলনগুলি সমস্ত ওয়েব বিকাশকারীদের জন্য প্রযোজ্য, এটি লাইটহাউসের মতো সরঞ্জামগুলিতে অলস লোডিং অ্যান্টিপ্যাটার্নগুলিকে ফ্ল্যাগ করাও মূল্যবান হতে পারে৷ আপনি যদি সেই অডিটের অগ্রগতি সহ অনুসরণ করতে আগ্রহী হন তবে 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});

পূর্ববর্তী জাভাস্ক্রিপ্ট স্নিপেট সাম্প্রতিকতম এলসিপি উপাদানটির মূল্যায়ন করবে এবং এটি অলস-লোড হলে একটি সতর্কতা লগ করবে।

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

উপসংহার

যদি আপনার সাইট ব্রাউজার-লেভেল ইমেজ অলস লোডিং ব্যবহার করে, তাহলে এটি কীভাবে বাস্তবায়িত হয়েছে তা পরীক্ষা করে দেখুন এবং এর পারফরম্যান্সের খরচ ভালোভাবে বুঝতে A/B পরীক্ষা চালান। এটি ভাঁজের উপরে আরও আগ্রহের সাথে লোড করা ছবি থেকে উপকৃত হতে পারে। আপনার যদি একটি ওয়ার্ডপ্রেস সাইট থাকে, আশা করি শীঘ্রই ওয়ার্ডপ্রেস কোরে একটি প্যাচ ল্যান্ডিং হবে। এবং আপনি যদি অন্য CMS ব্যবহার করেন তবে নিশ্চিত করুন যে তারা এখানে বর্ণিত সম্ভাব্য পারফরম্যান্স সমস্যা সম্পর্কে সচেতন।

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

আনস্প্ল্যাশে ফ্রাঙ্কি লোপেজের ছবি