অলস লোড ছবি এবং <iframe> উপাদান

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

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

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

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

loading বৈশিষ্ট্য সহ অলস লোড চিত্র

loading অ্যাট্রিবিউটটি <img> উপাদানগুলিতে যোগ করা যেতে পারে যাতে ব্রাউজারগুলিকে কীভাবে লোড করা উচিত তা বলা যায়:

  • "eager" ব্রাউজারকে জানায় যে ছবিটি অবিলম্বে লোড করা উচিত, এমনকি যদি এটি প্রাথমিক ভিউপোর্টের বাইরে থাকে। এটি loading বৈশিষ্ট্যের জন্যও ডিফল্ট মান।
  • দৃশ্যমান ভিউপোর্ট থেকে একটি নির্দিষ্ট দূরত্বের মধ্যে না হওয়া পর্যন্ত "lazy" একটি চিত্র লোড করা পিছিয়ে দেয়। এই দূরত্বটি ব্রাউজার অনুসারে পরিবর্তিত হয়, তবে প্রায়শই এটি যথেষ্ট বড় হতে সেট করা হয় যে ব্যবহারকারী যখন এটিতে স্ক্রোল করে তখন ছবিটি লোড হয়।

এটাও লক্ষণীয় যে আপনি যদি <picture> এলিমেন্ট ব্যবহার করেন, তাহলে loading এট্রিবিউটটি তার চাইল্ড <img> এলিমেন্টে প্রয়োগ করা উচিত, <picture> এলিমেন্টে নয় । এর কারণ হল <picture> এলিমেন্ট হল একটি কন্টেইনার যাতে অতিরিক্ত <source> উপাদান থাকে যা বিভিন্ন ইমেজ প্রার্থীর দিকে নির্দেশ করে এবং ব্রাউজার যে প্রার্থীকে বেছে নেয় সেটি সরাসরি তার চাইল্ড <img> এলিমেন্টে প্রয়োগ করা হয়।

প্রাথমিক ভিউপোর্টে থাকা ছবি লোড করতে অলস করবেন না

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

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

যাইহোক, এমন কিছু ক্ষেত্রে রয়েছে যেখানে এটি মোটামুটি পরিষ্কার যে আপনার loading="lazy" প্রয়োগ করা এড়ানো উচিত। উদাহরণস্বরূপ, হিরো ইমেজের ক্ষেত্রে আপনার <img> উপাদানগুলি থেকে loading="lazy" বৈশিষ্ট্যটি অবশ্যই বাদ দেওয়া উচিত, বা অন্যান্য চিত্র ব্যবহারের ক্ষেত্রে যেখানে <img> উপাদানগুলি ভাঁজের উপরে বা লেআউটের শীর্ষের কাছাকাছি প্রদর্শিত হতে পারে যেকোনো ডিভাইসে। LCP প্রার্থী হতে পারে এমন চিত্রগুলির জন্য এটি আরও গুরুত্বপূর্ণ ।

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

যেহেতু <img> এলিমেন্টের loading অ্যাট্রিবিউটটি সমস্ত প্রধান ব্রাউজারে সমর্থিত , তাই অলস লোড ইমেজগুলির জন্য জাভাস্ক্রিপ্ট ব্যবহার করার কোন প্রয়োজন নেই, কারণ ব্রাউজার ইতিমধ্যে প্রদান করে এমন ক্ষমতা প্রদানের জন্য একটি পৃষ্ঠায় অতিরিক্ত জাভাস্ক্রিপ্ট যোগ করা পৃষ্ঠার কর্মক্ষমতার অন্যান্য দিকগুলিকে প্রভাবিত করে, যেমন INP হিসাবে।

চিত্র অলস লোডিং ডেমো

অলস লোড <iframe> উপাদান

ভিউপোর্টে দৃশ্যমান না হওয়া পর্যন্ত অলস লোডিং <iframe> উপাদানগুলি উল্লেখযোগ্য ডেটা সংরক্ষণ করতে পারে এবং শীর্ষ-স্তরের পৃষ্ঠা লোড করার জন্য প্রয়োজনীয় গুরুত্বপূর্ণ সংস্থানগুলির লোডিং উন্নত করতে পারে। অতিরিক্তভাবে, যেহেতু <iframe> উপাদানগুলি মূলত একটি শীর্ষ-স্তরের নথির মধ্যে লোড করা সম্পূর্ণ HTML নথি, সেগুলি উল্লেখযোগ্য সংখ্যক উপ-সম্পদ-বিশেষ করে জাভাস্ক্রিপ্ট-কে অন্তর্ভুক্ত করতে পারে যা একটি পৃষ্ঠার INP-কে উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে যদি সেই ফ্রেমের মধ্যে কাজগুলির জন্য উল্লেখযোগ্য প্রক্রিয়াকরণ সময়ের প্রয়োজন হয়।

তৃতীয় পক্ষের এম্বেডগুলি <iframe> উপাদানগুলির জন্য একটি সাধারণ ব্যবহারের ক্ষেত্রে। উদাহরণস্বরূপ, এম্বেড করা ভিডিও প্লেয়ার বা সোশ্যাল মিডিয়া পোস্টগুলি সাধারণত <iframe> উপাদানগুলি ব্যবহার করে এবং তাদের প্রায়শই উল্লেখযোগ্য সংখ্যক সাবরিসোর্সের প্রয়োজন হয় যার ফলে শীর্ষ-স্তরের পৃষ্ঠার সংস্থানগুলির জন্য ব্যান্ডউইথ বিতর্কও হতে পারে। উদাহরণ স্বরূপ, অলসভাবে একটি YouTube ভিডিওর এম্বেড লোড করা প্রাথমিক পৃষ্ঠা লোডের সময় 500 KiB-এর বেশি সাশ্রয় করে, যখন অলসভাবে Facebook লাইক বোতাম প্লাগইন লোড করা 200 KiB-এর বেশি সংরক্ষণ করে—যার বেশিরভাগই জাভাস্ক্রিপ্ট।

যেভাবেই হোক, যখনই আপনার কোনো পৃষ্ঠায় ভাঁজের নিচে <iframe> থাকে, তখন এটিকে সামনে লোড করা গুরুত্বপূর্ণ না হলে অলসভাবে লোড করার বিষয়টি আপনার দৃঢ়ভাবে বিবেচনা করা উচিত, কারণ এটি ব্যবহারকারীর অভিজ্ঞতাকে উল্লেখযোগ্যভাবে উন্নত করতে পারে।

<iframe> উপাদানগুলির জন্য loading বৈশিষ্ট্য

<iframe> উপাদানগুলিতে loading বৈশিষ্ট্য সমস্ত প্রধান ব্রাউজারে সমর্থিত। loading অ্যাট্রিবিউটের মান এবং তাদের আচরণগুলি <img> উপাদানগুলির সাথে একই যা loading বৈশিষ্ট্য ব্যবহার করে:

  • "eager" হল ডিফল্ট মান। এটি ব্রাউজারকে <iframe> উপাদানের এইচটিএমএল এবং এর সাবরিসোর্স অবিলম্বে লোড করতে জানায়।
  • "lazy" <iframe> উপাদানের HTML এবং এর সাবরিসোর্স লোড করা পিছিয়ে দেয় যতক্ষণ না এটি ভিউপোর্ট থেকে পূর্বনির্ধারিত দূরত্বের মধ্যে থাকে।

অলস লোডিং iframes ডেমো

সম্মুখভাগ

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

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

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

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

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

অন্যদিকে একটি সম্মুখভাগ দিয়ে, তৃতীয় পক্ষের "স্টার্ট চ্যাট" বোতামটিকে একটি জাল বোতাম দিয়ে প্রতিস্থাপন করা সম্ভব৷ একবার ব্যবহারকারী অর্থপূর্ণভাবে এটির সাথে ইন্টারঅ্যাক্ট করে - যেমন একটি যুক্তিসঙ্গত সময়ের জন্য এটির উপর একটি পয়েন্টার ধরে রাখা, বা একটি ক্লিকের সাথে - ব্যবহারকারীর প্রয়োজন হলে প্রকৃত, কার্যকরী চ্যাট উইজেটটি স্লট করা হয়৷

যদিও আপনার নিজের সম্মুখভাগগুলি তৈরি করা অবশ্যই সম্ভব, সেখানে আরও জনপ্রিয় তৃতীয় পক্ষের জন্য ওপেন সোর্স বিকল্প রয়েছে, যেমন YouTube ভিডিওগুলির জন্য lite-youtube-embed , ভিমিও ভিডিওগুলির জন্য lite-vimeo-embed এবং চ্যাট উইজেটের জন্য প্রতিক্রিয়া লাইভ চ্যাট লোডার .

জাভাস্ক্রিপ্ট অলস লোডিং লাইব্রেরি

আপনার যদি অলস লোড <video> উপাদান, <video> উপাদান poster ছবি, সিএসএস background-image প্রপার্টি দ্বারা লোড করা ছবি, বা অন্যান্য অসমর্থিত উপাদানগুলির প্রয়োজন হয়, তাহলে আপনি জাভাস্ক্রিপ্ট-ভিত্তিক অলস লোডিং সমাধানের সাথে তা করতে পারেন, যেমন ল্যাজিসাইজ বা yall.js , অলসভাবে এই ধরনের সম্পদ লোড করা ব্রাউজার-স্তরের বৈশিষ্ট্য নয়।

বিশেষ করে, অটোপ্লেয়িং এবং লুপিং <video> উপাদানগুলি একটি অডিও ট্র্যাক ছাড়াই অ্যানিমেটেড GIF ব্যবহার করার চেয়ে অনেক বেশি কার্যকর বিকল্প , যা প্রায়শই সমতুল্য ভিজ্যুয়াল মানের ভিডিও সংস্থানের চেয়ে কয়েকগুণ বড় হতে পারে। তবুও, এই ভিডিওগুলি এখনও ব্যান্ডউইথের পরিপ্রেক্ষিতে তাৎপর্যপূর্ণ হতে পারে, তাই অলসভাবে সেগুলি লোড করা একটি অতিরিক্ত অপ্টিমাইজেশান যা নষ্ট ব্যান্ডউইথ কমাতে অনেক দূর যেতে পারে৷

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

বলুন আপনার কাছে একটি ভিডিও আছে যা একটি অ্যানিমেটেড GIF প্রতিস্থাপন করে, কিন্তু আপনি এটি একটি জাভাস্ক্রিপ্ট সমাধান দিয়ে অলসভাবে লোড করতে চান৷ নিম্নলিখিত মার্কআপ প্যাটার্ন সহ yall.js এর সাথে এটি সম্ভব :

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

ডিফল্টরূপে, yall.js "lazy" শ্রেণীর সমস্ত যোগ্যতা সম্পন্ন এইচটিএমএল উপাদান পর্যবেক্ষণ করে। একবার yall.js লোড এবং পৃষ্ঠায় কার্যকর করা হলে, ব্যবহারকারী ভিউপোর্টে স্ক্রোল না করা পর্যন্ত ভিডিওটি লোড হয় না। সেই সময়ে, <video> এলিমেন্টের চাইল্ড <source> এলিমেন্টের data-src অ্যাট্রিবিউটগুলিকে src অ্যাট্রিবিউটে অদলবদল করা হয়, যা ভিডিওটি ডাউনলোড করার জন্য অনুরোধ পাঠায় এবং স্বয়ংক্রিয়ভাবে এটি চালানো শুরু করে।

নিজের জ্ঞান যাচাই করুন

<img> এবং <iframe> উভয় উপাদানের জন্য loading বৈশিষ্ট্যের ডিফল্ট মান কোনটি?

"eager"
সঠিক!
"lazy"
আবার চেষ্টা কর.

জাভাস্ক্রিপ্ট-ভিত্তিক অলস লোডিং সমাধান কখন ব্যবহার করা যুক্তিসঙ্গত?

অলস লোড হতে পারে যে কোনো সম্পদ জন্য.
আবার চেষ্টা কর.
যে সমস্ত সংস্থানগুলিতে loading বৈশিষ্ট্য সমর্থিত নয়, যেমন অ্যানিমেটেড চিত্রগুলি প্রতিস্থাপন করার উদ্দেশ্যে অটোপ্লেয়িং ভিডিওগুলির ক্ষেত্রে, অথবা একটি <video> উপাদানের পোস্টার ছবি অলসভাবে লোড করার ক্ষেত্রে।
সঠিক!

যখন একটি সম্মুখভাগ একটি দরকারী কৌশল?

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

পরবর্তী: প্রিফেচিং এবং প্রিরেন্ডারিং

এখন যেহেতু আপনার অলস লোডিং ইমেজ এবং <iframe> উপাদানগুলির একটি হ্যান্ডেল রয়েছে, আপনি আপনার ব্যবহারকারীদের চাহিদার প্রতি সম্মান জানিয়ে পৃষ্ঠাগুলি আরও দ্রুত লোড করতে পারে তা নিশ্চিত করার জন্য একটি ভাল অবস্থানে আছেন৷ যাইহোক, এমন কিছু ক্ষেত্রে রয়েছে যেখানে সম্পদের অনুমানমূলক লোডিং বাঞ্ছনীয় হতে পারে। পরবর্তী মডিউলে , প্রিফেচিং এবং প্রি-রেন্ডারিং সম্পর্কে জানুন, এবং কীভাবে এই কৌশলগুলি-যখন সাবধানে ব্যবহার করা হয়-সেগুলিকে সময়ের আগে লোড করে পরবর্তী পৃষ্ঠাগুলিতে নেভিগেশনের গতি বাড়াতে পারে।