Lazy loading আসলে আপনার largest contentful paint-এ কী করে

Lazy loading একটি scheduling decision, speed spell নয়

Lazy loading-কে প্রায়ই performance improvement হিসেবে বর্ণনা করা হয়, যা ঠিক ততটাই সত্য যতটা suitcase না ভরাকে weight reduction বলা যায়। এটি সাহায্য করে কারণ browser শুরুতে কম কাজ করে।

এই পার্থক্যটি Largest Contentful Paint-এর জন্য গুরুত্বপূর্ণ, যাকে সাধারণত LCP বলা হয়। LCP মাপে viewport-এর মধ্যে সবচেয়ে বড় meaningful element কখন render হয়। অনেক page-এ সেই element একটি hero image। অন্য page-এ এটি বড় heading, poster image, product photo, বা content block হতে পারে।

Lazy loading resource কখন request করা হবে তা বদলে দেয়। এটি image decode দ্রুত করে না, server response দ্রুত করে না, বা font আগে render করায় না। আপনি যদি ভুল জিনিস lazy load করেন, বিশেষ করে যে elementটি LCP হয়, তাহলে আপনি browser-কে বলছেন Core Web Vitals পাস করতে যে জিনিসটি দেখানো জরুরি, সেটি fetch করার আগে অপেক্ষা করতে।

এই কারণেই lazy loading অতিরিক্ত ব্যবহৃত হয় এবং যথেষ্ট বোঝা হয় না।

আপনি image lazy load করলে browser কী করে

Native image lazy loading সাধারণত এভাবে যোগ করা হয়:

<img src='hero.jpg' loading='lazy' alt='...'>

loading='lazy' থাকলে browser image fetch করা পিছিয়ে দিতে পারে, যতক্ষণ না তার মনে হয় imageটি সম্ভবত দরকার হবে। বাস্তবে, browser viewport থেকে দূরত্ব, network conditions, image dimensions, এবং অন্যান্য heuristics ব্যবহার করে। নির্দিষ্ট নিয়মগুলো implementation details এবং বদলাতে পারে।

loading='eager' থাকলে, বা বেশিরভাগ ক্ষেত্রে lazy attribute না থাকলে, browser imageটিকে normal loading process-এর অংশ হিসেবে ধরে। তাকে এখনও CSS, JavaScript, fonts, images, এবং অন্যান্য requests-এর মধ্যে prioritize করতে হয়, কিন্তু imageটি সঙ্গে সঙ্গে discoverable হয়।

এর অর্থ, lazy loading মূলত তিনটি phase-কে প্রভাবিত করে:

• Discovery: browser কখন resourceটি খেয়াল করে।
• Request start: network fetch কখন শুরু হয়।
• Render timing: resourceটি শেষ পর্যন্ত কখন decode ও paint করা যায়।

LCP-এর জন্য বিপজ্জনকটি হলো request start। LCP image request দেরিতে শুরু হলে, তার পরের সবকিছুই দেরিতে সরে যায়।

সহজ নিয়ম: LCP candidate কখনও lazy load করবেন না

কোনো image যদি initial viewport-এ visible হয় এবং largest contentful element হওয়ার সম্ভাবনা থাকে, সেটি lazy load করবেন না।

এর মধ্যে রয়েছে:

• hero images
• fold-এর উপরে থাকা primary product photos
• বড় article lead images
• <img> হিসেবে implement করা বড় background-like images
• video poster images, যখন poster-টিই প্রধান visual element

LCP image request, transfer, decode, এবং paint না হওয়া পর্যন্ত browser সেটি render করতে পারে না। Lazy loading প্রথম ধাপের আগেই অনিশ্চয়তা ঢুকিয়ে দেয়। ধীর connection-এ সামান্য delay-ও LCP-কে acceptable থেকে poor-এ নিয়ে যেতে যথেষ্ট হতে পারে।

একটি common failure pattern এমন:

1. Server HTML পাঠায়।
2. Browser above-the-fold image parse করে।
3. Image-এ loading='lazy' থাকে।
4. Lazy-loading heuristic বলছে অপেক্ষা করা যায়, তাই browser অপেক্ষা করে।
5. CSS এবং JavaScript load হতে থাকে।
6. Image request যতটা আগে শুরু হওয়া উচিত ছিল, তার চেয়ে দেরিতে শুরু হয়।
7. Image file নিজে reasonably optimized হলেও LCP দেরিতে হয়।

এটি হতাশাজনক, কারণ code review-তে pageটি পরিপাটি দেখাতে পারে। সমস্যা শুধু file size নয়। এটি priority।

আপনি যদি lab output পড়ে বোঝার চেষ্টা করেন LCP সত্যিই issue কি না, তাহলে আতঙ্কিত না হয়ে Lighthouse report পড়ার বিষয়ে আমাদের guide ইচ্ছাকৃতভাবে practical: code বদলানো শুরু করার আগে field data, lab hints, এবং fixes আলাদা করুন। (Note: আপনার routing case-sensitive হলে, CMS থেকে exact URL ব্যবহার করুন।)

Correction: actual internal URL ব্যবহার করুন

সঠিক Wux article URL হলো How to read a Lighthouse report without panicking। মূল কথা একই: loading behavior বদলানোর আগে LCP element identify করুন।

কখন lazy loading LCP উন্নত করতে পারে

Lazy loading indirectভাবে LCP উন্নত করতে পারে, যখন এটি non-critical resources-কে browser-এর পথ থেকে সরিয়ে রাখে।

ধরুন একটি product page আছে, উপরে hero product image এবং fold-এর নিচে বারোটি recommendation image-এর carousel। যদি তেরোটি image-ই eagerly load হয়, browser এমন image-এর জন্য bandwidth এবং connection slots খরচ করতে পারে যা user এখনও দেখতে পাচ্ছে না। constrained network-এ এটি hero image, CSS, বা font files-এর সঙ্গে compete করতে পারে।

Below-fold carousel images lazy load করলে LCP image আগে load হতে সাহায্য করতে পারে, কারণ initial page load-এর সময় কম non-critical requests compete করে।

Lazy loading-এর legitimate performance case হলো এটি:

• above-the-fold LCP candidate eager load করুন
• initial viewport-এর নিচের images lazy load করুন
• গুরুত্বপূর্ণ images দেরিতে inject করে এমন heavy scripts এড়িয়ে চলুন
• layout shifts এড়াতে HTML-এ image dimensions রাখুন

Lazy loading নিজে LCP optimization নয়। এটি resource prioritization tool। Critical path-কে protect করলে এটি সাহায্য করে।

LCP images-এর জন্য ভালো pattern

Above-the-fold LCP image-এর ক্ষেত্রে লক্ষ্য হলো browser যেন সেটি দ্রুত discover করে, দ্রুত request করে, এবং layout instability ছাড়া render করে।

একটি solid baseline এমন:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

গুরুত্বপূর্ণ অংশগুলো decorative নয়:

• loading='eager' lazy-loading delay প্রতিরোধ করে।
• fetchpriority='high' browser-কে জানায় এই image গুরুত্বপূর্ণ।
• width এবং height space reserve করে এবং layout shift কমায়।
• srcset এবং sizes oversized downloads প্রতিরোধ করে।
• Modern format সতর্কভাবে ব্যবহার করলে transfer time কমাতে পারে।

আপনি যদি এখনও প্রতিটি screen-এ একটি বড় JPEG serve করেন, তাহলে image format এবং responsive sizing lazy-loading attribute-এর চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে। Practical decision tree-এর জন্য দেখুন when AVIF beats WebP and when it does not।

Background images-এর জন্য extra care দরকার

CSS background images সাধারণ HTML images-এর মতো দ্রুত discover হয় না। Browser-কে CSS fetch এবং parse করতে হয়, তারপর সে এগুলো সম্পর্কে জানতে পারে। আপনার LCP element যদি CSS background image হয়, তাহলে আপনি discovery ইতিমধ্যেই কঠিন করে ফেলেছেন।

এর অর্থ এই নয় যে background images নিষিদ্ধ। এর অর্থ হলো আপনাকে deliberate হতে হবে।

Decorative images-এর জন্য CSS backgrounds ঠিক আছে। Meaningful hero imagery-এর জন্য <img> বা <picture> element সাধারণত ভালো, কারণ এটি HTML parser-এর কাছে visible, alt text support করে, এবং responsive image attributes-এর সঙ্গে ভালো কাজ করে।

LCP image-এর জন্য CSS background ব্যবহার করতেই হলে, সেটি preload করার কথা ভাবুন:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload-ও magic wand নয়। অনেক বেশি images preload করলে একই priority problem অন্য পোশাকে তৈরি হয়। Design system-এর প্রতিটি image-এর জন্য নয়, সত্যিই গুরুত্বপূর্ণ একটিমাত্র image-এর জন্য ব্যবহার করুন।

JavaScript lazy loading প্রায়ই পরিস্থিতি খারাপ করে

Native lazy loading ব্যাপকভাবে supported হওয়ার আগে, অনেক site JavaScript libraries ব্যবহার করত, যা page load-এর পরে বা intersection observer fire করার পরে data-src-কে src-এ swap করত। কিছু site এখনও করে।

Long article pages বা image-heavy galleries-এর জন্য এটি reasonable হতে পারে। Above-the-fold content-এর জন্য এটি খারাপ choice।

Browser preload scanner দ্রুত, কিন্তু JavaScript run না করা পর্যন্ত custom attribute-এ লুকানো URL-এর image request করতে পারে না। আপনার hero image যদি data-src='hero.jpg' হিসেবে শুরু হয়, তাহলে আপনি discovery-কে script download, parsing, execution, এবং framework hydration-এর পেছনে delayed করেছেন।

LCP-এর জন্য এটি খারাপ trade। Critical image URLs real HTML-এ রাখুন। Browser-কে তার কাজ করতে দিন।

LCP সব সময় image problem নয়

কিছু page-এ LCP element text। সে ক্ষেত্রে lazy loading images-এর direct effect খুব কম হতে পারে। আপনার bottleneck হতে পারে render-blocking CSS, slow server response, client-side rendering, বা web fonts।

Fonts আলাদা করে বলার মতো, কারণ এগুলো late text rendering-এর frequent hidden cause। বড় heading LCP হতে পারে, এবং font loading behavior সেই heading কখন paint হবে তা delay বা alter করতে পারে। আপনার image work যদি metric না বদলায়, assumption না করে সরাসরি LCP element inspect করুন। web fonts as a performance win নিয়ে আমাদের article-এ প্রায়ই কাজ করে এমন boring fixes রয়েছে: fewer weights, modern formats, sensible fallbacks।

নিজেকে ভুল না বুঝিয়ে lazy loading changes কীভাবে test করবেন

Office Wi-Fi-তে page-এর দিকে তাকিয়ে test করবেন না। আপনাকে request timing দেখতে হবে।

এই workflow ব্যবহার করুন:

1. Chrome DevTools খুলে Performance trace record করুন।
2. Network throttling enable করুন, যেমন Fast 4G বা Slow 4G।
3. Cache disabled রেখে page reload করুন।
4. LCP marker খুঁজুন।
5. LCP element identify করুন।
6. Network panel-এ resourceটি কখন loading শুরু করেছে check করুন।

LCP resource দেরিতে শুরু হলে, কেন তা জিজ্ঞেস করুন:

• এটি কি lazy loaded ছিল?
• এটি কি JavaScript দিয়ে injected ছিল?
• এটি কি CSS-এ hidden ছিল?
• এটি কি অন্য images-এর পেছনে deprioritized ছিল?
• Server response কি slow ছিল?

তারপর একটি change করুন এবং retest করুন। Teams একই deployment-এ image format, lazy loading, preloading, JavaScript bundles, এবং CDN settings বদলালে performance work messy হয়ে যায়। আপনি page improve করতে পারেন, কিন্তু কোন change গুরুত্বপূর্ণ ছিল তা জানতে পারবেন না।

Field data-ও গুরুত্বপূর্ণ। Lab tools diagnosis-এর জন্য useful, কিন্তু LCP device, network, viewport, cache state, এবং geography অনুযায়ী vary করে। সম্ভব হলে real-user monitoring বা Chrome User Experience Report data ব্যবহার করুন।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: আপনার LCP ছবিটি ছোট এবং তাৎক্ষণিকভাবে লোড হওয়া রাখুন Image Compressor দিয়ে সেটি প্রক্রিয়া করে, যাতে লেজি লোডিংয়ের প্রয়োজন ছাড়াই এটি দ্রুত রেন্ডার হয়।

<!-- tool-cta:end -->

বেশিরভাগ website-এর জন্য practical policy

বেশিরভাগ marketing sites, ecommerce pages, documentation sites, এবং publisher pages-এর জন্য এই policy যথেষ্ট:

• Above-the-fold primary image: eager load করুন, high fetch priority বিবেচনা করুন।
• Below-the-fold content images: lazy load করুন।
• Icons এবং tiny UI assets: সাধারণত আলাদাভাবে ভাবার দরকার নেই।
• CSS background hero: HTML image হিসেবে reconsider করুন বা carefully preload করুন।
• JavaScript-injected hero image: সম্ভব হলে rendering architecture ঠিক করুন।
• Carousels: শুধু প্রথম visible slide eager load করুন; বাকি lazy load করুন।

Edge cases আছে। Browser heuristics improve করে। Frameworks automatic image components যোগ করে। কিছু platform এখন viewport-এর কাছাকাছি detected images lazy load করা এড়িয়ে যায়। তবু principle বদলায় না: critical resources early এবং obvious হওয়া উচিত; non-critical resources অপেক্ষা করবে।

Lazy loading মূল্যবান, যখন এটি এই পার্থক্য প্রকাশ করে। এটি ক্ষতিকর, যখন page ইতিমধ্যেই LCP race হারাতে শুরু করার পর পর্যন্ত browser-এর কাছ থেকে সবচেয়ে গুরুত্বপূর্ণ content লুকিয়ে রাখে।