একটি পৃষ্ঠার সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP) উন্নত করতে জটিল হতে পারে, প্রায়ই একাধিক চলমান অংশ এবং ট্রেডঅফ জড়িত। এই পোস্টটি ওয়েব জুড়ে প্রকৃত পৃষ্ঠা লোড থেকে ফিল্ড ডেটা দেখে তা নির্ধারণ করে যে বিকাশকারীদের তাদের অপ্টিমাইজেশন প্রচেষ্টা কোথায় ফোকাস করা উচিত।
ক্লাসিক এলসিপি পরামর্শ: আপনার ছবির আকার কমিয়ে দিন!
ওয়েবে বেশিরভাগ পৃষ্ঠার জন্য, LCP উপাদান হল একটি চিত্র। তাহলে এটা স্বাভাবিক যে LCP উন্নত করার সর্বোত্তম উপায় হল আপনার LCP ইমেজ অপ্টিমাইজ করা।
এলসিপি চালু হওয়ার পাঁচ বছর বা তার পরে, এটি প্রায়শই শিরোনাম পরামর্শ হয়েছে। নিশ্চিত করুন যে আপনার ছবিগুলি যথাযথভাবে মাপ করা হয়েছে এবং পর্যাপ্তভাবে সংকুচিত হয়েছে এবং আপনি সেখানে থাকাকালীন একটি 21 শতকের চিত্র বিন্যাস ব্যবহার করতে পারেন৷ বাতিঘর এমনকি এই পরামর্শগুলি করার জন্য তিনটি ভিন্ন অডিট আছে।
এটি এমন সাধারণ পরামর্শের কারণের একটি অংশ হল যে অত্যধিক বাইট পরিমাপ করা সহজ এবং ইমেজ কম্প্রেশন সরঞ্জামগুলি সুপারিশ করা সহজ। আপনার নির্মাণ এবং স্থাপনার পাইপলাইনের উপর নির্ভর করে, এটি বাস্তবায়ন করাও সহজ হতে পারে।
যদি তাই হয়, এটা করুন! আপনার ব্যবহারকারীদের কম বাইট পাঠানো প্রায় সবসময় একটি জয়. ওয়েবে এমন অনেক সাইট রয়েছে যেগুলি এখনও অপ্রয়োজনীয়ভাবে বড় ছবি পরিবেশন করছে যা এমনকি মৌলিক সংকোচনও ঠিক করবে।
যাইহোক, যখন আমরা LCP-এর সময় সাধারণত কোথায় ব্যয় করা হয় তা দেখার জন্য Chrome-এর ব্যবহারকারীদের জন্য ফিল্ড পারফরম্যান্স ডেটা দেখতে শুরু করি, আমরা দেখতে পেলাম যে চিত্র ডাউনলোডের সময় প্রায় কখনও বাধা হয় না।
পরিবর্তে, LCP এর অন্যান্য অংশগুলি অনেক বড় সমস্যা।
LCP সাব-পার্ট ব্রেকডাউন
এলসিপি উন্নত করার সবচেয়ে বড় সুযোগের ক্ষেত্রগুলি কী তা বোঝার জন্য, আমরা অপ্টিমাইজ এলসিপি- তে বর্ণিত এলসিপি সাব-পার্টস থেকে ডেটা দেখেছি।
যদিও প্রতিটি পৃষ্ঠা এবং প্রতিটি ফ্রেমওয়ার্ক পৃষ্ঠার LCP উপাদান হয়ে ওঠে তা লোড করা এবং প্রদর্শন করার জন্য একটি ভিন্ন পদ্ধতি নিতে পারে, প্রতিটিকে এই উপ-অংশে বিভক্ত করা যেতে পারে:
সেই নিবন্ধ থেকে উদ্ধৃতি , উপ-অংশগুলি হল:
- টাইম টু ফার্স্ট বাইট (TTFB)
- ব্যবহারকারী পৃষ্ঠাটি লোড করা শুরু করার সময় থেকে ব্রাউজার HTML নথির প্রতিক্রিয়ার প্রথম বাইট না পাওয়া পর্যন্ত।
- সম্পদ লোড বিলম্ব
- TTFB এবং ব্রাউজার যখন LCP রিসোর্স লোড করা শুরু করে তার মধ্যে সময়। যদি LCP উপাদানটির রেন্ডার করার জন্য রিসোর্স লোডের প্রয়োজন না হয় তবে এই সময়টি হল
0। - সম্পদ লোড সময়কাল
- LCP রিসোর্স নিজেই লোড করতে যে সময় লাগে। যদি LCP উপাদানটির রেন্ডার করার জন্য রিসোর্স লোডের প্রয়োজন না হয় তবে এই সময়টি হল
0। - উপাদান রেন্ডার বিলম্ব
- LCP রিসোর্স লোড হওয়া এবং LCP উপাদান সম্পূর্ণরূপে রেন্ডারিং শেষ হওয়ার মধ্যে সময়।
বাস্তব নেভিগেশন কর্মক্ষমতা তথ্য
| এলসিপি রেটিং | TTFB (ms) | ইমেজ লোড বিলম্ব (ms) | ছবি লোডের সময়কাল (ms) | রেন্ডার বিলম্ব (মিসে) |
|---|---|---|---|---|
| ভাল | 600 | 350 | 160 | 230 |
| উন্নতি প্রয়োজন | 1,360 | 720 | 270 | 310 |
| দরিদ্র | 2,270 | 1,290 | 350 | 360 |
এই পোস্টের জন্য, আমরা LCP উপ-অংশগুলি দেখতে Chrome-এ একটি সাবরিসোর্স ইমেজ LCP সহ পৃষ্ঠা নেভিগেশন থেকে ডেটা ব্যবহার করেছি। আমরা আগে এই ধরনের ডেটা দেখেছি , কিন্তু পৃষ্ঠার LCP-এর জন্য অপেক্ষা করার সময় প্রকৃত ব্যবহারকারীরা তাদের সময় কোথায় ব্যয় করছে তা দেখার জন্য ফিল্ড ডেটা থেকে কখনও দেখিনি৷
Core Web Vitals-এর মতো, আমরা CrUX ডেটাসেটের প্রতিটি উৎসের জন্য প্রতিটি LCP সাব-পার্টের 75 তম পার্সেন্টাইল (p75) নিয়েছি , যার ফলে p75 মানের চারটি ডিস্ট্রিবিউশন হয়েছে (প্রতিটি সাব-পার্টের জন্য একটি)। এই ডিস্ট্রিবিউশনগুলিকে সংক্ষিপ্ত করার জন্য, আমরা চারটি এলসিপি সাব-পার্টের প্রতিটির জন্য সমস্ত উত্স জুড়ে সেই মানগুলির মধ্যম নিয়েছি।
অবশেষে, 75 তম পার্সেন্টাইলে "ভাল", "উন্নতি প্রয়োজন", বা "দরিদ্র" LCP আছে কিনা তার ভিত্তিতে আমরা মূলগুলিকে বালতিতে বিভক্ত করি। এটি দেখাতে সাহায্য করে যে ভাল এলসিপির সাথে একটি উৎপত্তি এবং দুর্বল এলসিপির সাথে একটি উত্সের পার্থক্য কী।
আপনার LCP ছবির সাইজ কমাবেন? এবার ডাটা নিয়ে
লোডের সময়কাল হল LCP রিসোর্স আনতে কতক্ষণ লাগে তার পরিমাপ, এই ক্ষেত্রে, একটি ছবি। এই সময়টি সাধারণত চিত্রের বাইটের সংখ্যার সমানুপাতিক হয়, তাই বাইটের সংখ্যা কমানোর জন্য সমস্ত কর্মক্ষমতা পরামর্শ।
আগের গ্রাফগুলিতে সময় কোথায় যাচ্ছে তা দেখার সময়, একটি জিনিস যা দাঁড়িয়েছে তা হল যে চিত্র লোডের সময়কালের জন্য খুব বেশি সময় ব্যয় করা হয় না। প্রকৃতপক্ষে, এটি সব এলসিপি বালতিতে সবচেয়ে ছোট এলসিপি সাব-পার্ট। ভাল-এলসিপি উত্সের তুলনায় দুর্বল-এলসিপি উত্সগুলির জন্য লোডের সময়কাল বেশি, তবে এটি এখনও যেখানে বেশিরভাগ সময় ব্যয় করা হয় না৷
দুর্বল এলসিপি সহ বেশিরভাগ উত্স তাদের p75 এলসিপি সময়ের 10% এরও কম সময় এলসিপি ছবি ডাউনলোড করতে ব্যয় করে।
হ্যাঁ, আপনাকে নিশ্চিত করতে হবে যে আপনার ছবিগুলি অপ্টিমাইজ করা হয়েছে, কিন্তু এটি LCP উন্নত করার একটি অংশ মাত্র। এবং এই তথ্য থেকে এটা স্পষ্ট যে ওয়েবে সাধারণ উৎসের জন্য, সামগ্রিকভাবে LCP-এর সম্ভাব্য মিলিসেকেন্ড লাভ কমপ্রেস স্কিম যতই পরিশীলিত হোক না কেন।
একটি চূড়ান্ত বিস্ময়: ধীর লোডের সময়কাল সাধারণত মোবাইল ডিভাইস এবং মোবাইল নেটওয়ার্কের গুণমানকে দায়ী করা হত। আমরা হয়তো একবার আশা করেছিলাম যে একটি সাধারণ ফোন তারযুক্ত সংযোগে ডেস্কটপ মেশিনের মতো একই চিত্র ডাউনলোড করতে একাধিকবার বেশি সময় নেবে। ডেটা প্রস্তাব করে যে এটি আর নেই। দুর্বল LCP এর জন্য, মিডিয়ান p75 ইমেজ লোডের সময়কাল ডেস্কটপের তুলনায় মোবাইলে মাত্র 20% ধীর।
টাইম টু ফার্স্ট বাইট (TTFB)
নেটওয়ার্ক অনুরোধ করে এমন নেভিগেশনের জন্য, TTFB সর্বদা কিছু সময় নেয়। এটি একটি DNS লুকআপ করতে এবং একটি সংযোগ শুরু করতে সময় নেয়৷ এবং আপনি পদার্থবিদ্যাকে হারাতে পারবেন না: একটি সার্ভারে পৌঁছানোর জন্য একটি অনুরোধকে তার এবং অপটিক্যাল তারের মাধ্যমে বাস্তব জগতে ভ্রমণ করতে হবে, তারপর প্রতিক্রিয়াটি ট্রিপটি ফিরিয়ে দিতে হবে। এমনকি ভাল এলসিপি সহ মধ্যম উৎপত্তি TTFB এর 75 তম শতাংশে অর্ধেক সেকেন্ডেরও বেশি সময় ব্যয় করে।
যাইহোক, ভাল এবং দুর্বল LCP উত্সের মধ্যে TTFB বৈষম্য উন্নতির সুযোগ দেখায়। দুর্বল এলসিপির অন্তত অর্ধেক উৎপত্তির জন্য, 2,270 মিলিসেকেন্ডের p75 TTFB একাই প্রায় গ্যারান্টি দেয় যে p75 LCP 2.5 সেকেন্ডের "ভাল" থ্রেশহোল্ডের চেয়ে দ্রুত হতে পারে না। এমনকি সেই সময়ের একটি মাঝারি শতাংশ হ্রাস মানে একটি উল্লেখযোগ্য LCP উন্নতি।
আপনি পদার্থবিদ্যাকে হারাতে পারবেন না, তবে এমন কিছু আছে যা করা যেতে পারে। উদাহরণস্বরূপ, যদি আপনার ব্যবহারকারীরা প্রায়শই আপনার সার্ভারের থেকে খুব আলাদা অবস্থানে থাকে, তাহলে একটি CDN আপনার সামগ্রী তাদের কাছাকাছি নিয়ে যেতে পারে।
আরও জানতে, অপ্টিমাইজিং TTFB গাইড দেখুন।
সম্পদ লোড বিলম্ব, উপেক্ষা ধীর LCP অপরাধী
যদি TTFB উন্নত করা যায় কিন্তু কোনো উন্নতি পদার্থবিদ্যা দ্বারা আবদ্ধ হয়, তাহলে সম্পদ লোড বিলম্ব সম্ভাব্যভাবে দূর করা যেতে পারে, বাস্তবে শুধুমাত্র আপনার পরিবেশন স্থাপত্য দ্বারা আবদ্ধ।
এই উপ-অংশটি HTML প্রতিক্রিয়ার (TTFB) প্রথম বাইটের আগমন থেকে যখন ব্রাউজার LCP চিত্রের জন্য একটি অনুরোধ শুরু করে তখন পর্যন্ত সময় পরিমাপ করে। এলসিপি ছবিগুলি ডাউনলোড করতে কতক্ষণ সময় লাগে তার উপর আমরা কয়েক বছর ধরে ফোকাস করেছি, কিন্তু ব্রাউজারকে ডাউনলোড শুরু করতে বলা হওয়ার আগে আমরা প্রায়ই সময় নষ্ট করে ফেলেছি।
দুর্বল LCP সহ মিডিয়ান সাইটটি LCP ইমেজ ডাউনলোড শুরু করার জন্য অপেক্ষার প্রায় চারগুণ সময় ব্যয় করে, এটি আসলে এটি ডাউনলোড করার জন্য , TTFB এবং ইমেজ অনুরোধের মধ্যে 1.3 সেকেন্ড অপেক্ষা করে। এটি 2.5 সেকেন্ডের LCP বাজেটের অর্ধেকেরও বেশি একটি একক উপ-অংশে চলে গেছে।
নির্ভরতা চেইন দীর্ঘ লোড বিলম্বের একটি সাধারণ কারণ। সহজ প্রান্তে একটি পৃষ্ঠা একটি স্টাইল শীট লোড করছে, যা ব্রাউজার লেআউট করার পরে, একটি পটভূমি চিত্র সেট করে যা শেষ পর্যন্ত LCP হবে। ব্রাউজার LCP ইমেজ ডাউনলোড করা শুরু করার আগেই এই সমস্ত পদক্ষেপগুলি ঘটতে হবে।
এইচটিটিপি আর্কাইভ পাবলিক ক্রল ডেটা ব্যবহার করে, যা এইচটিএমএল ডকুমেন্ট থেকে একটি এলসিপি ইমেজে নেটওয়ার্ক অনুরোধের "ইনিশিয়েটর" চেইন রেকর্ড করে, আপনি ধীর এলসিপির সাথে অনুরোধ চেইন দৈর্ঘ্যের স্পষ্ট সম্পর্ক দেখতে পারেন।
চাবিকাঠি হল যত তাড়াতাড়ি সম্ভব ব্রাউজারকে জানিয়ে দেওয়া যে LCP কী হবে যাতে এটি লোড করা শুরু করতে পারে, এমনকি পৃষ্ঠার লেআউটে এটির জন্য একটি স্থান থাকার আগেই। এটি সম্পন্ন করার জন্য কয়েকটি টুল উপলব্ধ রয়েছে, যেমন HTML এ একটি ক্লাসিক <img> ট্যাগ যাতে প্রিলোড স্ক্যানার দ্রুত এটি খুঁজে পেতে এবং ডাউনলোড করা শুরু করতে পারে , অথবা একটি <link rel="preload"> ট্যাগ (বা HTTP হেডার) ছবি যা <img> s হবে না।
কোন সংস্থানগুলিকে অগ্রাধিকার দিতে হবে তা নির্ধারণ করতে ব্রাউজারকে সাহায্য করাও গুরুত্বপূর্ণ৷ এটি বিশেষভাবে সত্য যদি আপনার পৃষ্ঠাটি পৃষ্ঠা লোড করার সময় প্রচুর অনুরোধ করে, কারণ ব্রাউজার প্রায়শই জানে না যে LCP উপাদানটি কী হবে যতক্ষণ না এই রিসোর্সগুলির অনেকগুলি লোড হয় এবং লেআউট ঘটে। একটি fetchpriority="high" অ্যাট্রিবিউটের সাথে সম্ভাব্য LCP উপাদানটি টীকা করা (এবং loading="lazy" এড়াতে নিশ্চিত করা) তা অবিলম্বে সংস্থান লোড করা শুরু করার জন্য ব্রাউজারকে স্পষ্ট করে দেয়।
লোড বিলম্ব অপ্টিমাইজ করার বিষয়ে আরও পরামর্শ পড়ুন।
রেন্ডার বিলম্ব
রেন্ডার বিলম্ব সেই সময়কে পরিমাপ করে যখন ব্রাউজারে LCP ইমেজ লোড এবং রেডি হয়, কিন্তু কিছু কারণে এটি স্ক্রিনে দেখানোর আগে একটি বিলম্ব হয়। কখনও কখনও এটি একটি দীর্ঘ কাজ যা মূল থ্রেডটিকে ব্লক করে দেয় যখন ছবিটি প্রস্তুত থাকে, অন্য ক্ষেত্রে এটি একটি লুকানো উপাদান প্রকাশ করার জন্য একটি UI পছন্দ হতে পারে।
ওয়েবে সাধারণ উত্সের জন্য একটি বিশাল রেন্ডার বিলম্বের সুযোগ বলে মনে হয় না, তবে অপ্টিমাইজেশনের সময় আপনি কখনও কখনও অন্যান্য উপ-অংশগুলিতে পূর্বে ব্যয় করা সময়ের বাইরে রেন্ডার বিলম্ব তৈরি করতে পারেন। উদাহরণস্বরূপ, যদি একটি পৃষ্ঠা এলসিপি চিত্রটি প্রিলোড করা শুরু করে যাতে এটি দ্রুত উপলব্ধ হয় তবে লোড করতে আর দীর্ঘ বিলম্ব হবে না, তবে যদি পৃষ্ঠাটি নিজেই ছবিটি প্রদর্শনের জন্য প্রস্তুত না হয় - যেমন একটি বড় রেন্ডার-ব্লকিং স্টাইল শীট বা একটি ক্লায়েন্ট-সাইড রেন্ডারিং অ্যাপ যা কিছু দেখানোর আগে তার সমস্ত জাভাস্ক্রিপ্ট লোড করা শেষ করতে হবে—এলসিপি এখনও তার চেয়ে ধীর হবে, এবং অপেক্ষা করা সময় এখন রেন্ডার বিলম্ব হিসাবে প্রদর্শিত হবে। এই কারণে সার্ভার সাইড রেন্ডারিং বা স্ট্যাটিক এইচটিএমএল প্রায়শই এলসিপির ক্ষেত্রে একটি সুবিধা থাকে।
আপনার নিজের বিষয়বস্তু প্রভাবিত হলে, রেন্ডার বিলম্ব অপ্টিমাইজ করার বিষয়ে আরও পরামর্শ পড়ুন।
ঐ সব সাব-পার্টস চেক করুন
এটা স্পষ্ট যে কার্যকরভাবে LCP অপ্টিমাইজ করার জন্য, ডেভেলপারদের পৃষ্ঠা লোডকে সামগ্রিকভাবে দেখতে হবে, এবং শুধুমাত্র ছবি অপ্টিমাইজ করার উপর ফোকাস করতে হবে না। LCP-তে সময়ের প্রতিটি অংশ পরীক্ষা করুন, কারণ উন্নতির জন্য সম্ভবত অনেক বড় সুযোগ রয়েছে।
ক্ষেত্রটিতে এই ডেটা সংগ্রহের জন্য, ওয়েব-ভাইটাল লাইব্রেরির অ্যাট্রিবিউশন বিল্ডে LCP সাব-পার্টসের সময় অন্তর্ভুক্ত রয়েছে। ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট (CrUX) এখনও এই সমস্ত ডেটা অন্তর্ভুক্ত করে না, তবে এটিতে TTFB এবং LCP-এর জন্য এন্ট্রি রয়েছে, তাই এটি একটি শুরু। আমরা আশা করি ভবিষ্যতে এই পোস্টের জন্য ব্যবহৃত ডেটা CrUX-এ অন্তর্ভুক্ত করব, তাই এই বিষয়ে আরও খবরের জন্য আমাদের সাথে থাকুন।
স্থানীয়ভাবে এলসিপি সাব-পার্টস পরীক্ষা করার জন্য, এই নিবন্ধে ওয়েব ভাইটালস এক্সটেনশন বা জাভাস্ক্রিপ্ট স্নিপেট চেষ্টা করুন। লাইটহাউস এর "লার্জেস্ট কনটেন্টফুল পেইন্ট এলিমেন্ট" নিরীক্ষাতে ভাঙ্গনও অন্তর্ভুক্ত করে । DevTools পারফরম্যান্স প্যানেলে আরও LCP সাব-পার্ট পরামর্শ দেখুন, শীঘ্রই আসছে ।