সবচেয়ে বড় বিষয়বস্তু পেইন্ট অপ্টিমাইজ করুন

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

Philip Walton

Barry Pollard

প্রকাশিত: 30 এপ্রিল, 2020

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

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

ব্রাউজার কত দ্রুত একটি ওয়েব পৃষ্ঠা লোড এবং রেন্ডার করতে পারে তা অনেকগুলি কারণের উপর প্রভাব ফেলতে পারে এবং তাদের যেকোনটি জুড়ে বিলম্ব এলসিপিতে উল্লেখযোগ্য প্রভাব ফেলতে পারে।

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

আপনার LCP মেট্রিক বোঝা

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

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

বাস্তব ব্যবহারকারীদের উপর ভিত্তি করে এলসিপি ডেটা একটি সাইটে ইনস্টল করা রিয়েল ইউজার মনিটরিং (RUM) টুল থেকে বা Chrome ব্যবহারকারীর অভিজ্ঞতা প্রতিবেদন (CrUX) ব্যবহার করে দেখা যেতে পারে যা লক্ষ লক্ষ ওয়েবসাইটের জন্য প্রকৃত Chrome ব্যবহারকারীদের থেকে বেনামী ডেটা সংগ্রহ করে।

Chrome DevTools CrUX LCP ডেটা ব্যবহার করা

Chrome DevTools-এর পারফরম্যান্স প্যানেল লাইভ মেট্রিক্স ভিউতে পৃষ্ঠার পাশে আপনার স্থানীয় LCP অভিজ্ঞতা বা মূলের CrUX LCP দেখায়।

পারফরম্যান্স প্যানেলে ফিল্ড ডেটা লেয়ারিং করে, আপনি একটি পৃষ্ঠায় বাস্তব-ব্যবহারকারীর LCP সমস্যা আছে কিনা তা মূল্যায়ন করতে পারেন এবং সেই সমস্যাগুলি আরও ভালভাবে পুনরুত্পাদন এবং ডিবাগ করার জন্য আপনার স্থানীয় পরিবেশ সেটিংস মানিয়ে নিতে পারেন৷

PageSpeed ​​Insights CrUX LCP ডেটা ব্যবহার করা

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

PageSpeed ​​অন্তর্দৃষ্টি চারটি ভিন্ন CrUX ডেটা দেখায়:

• এই URL এর জন্য মোবাইল ডেটা
• এই URL- এর জন্য ডেস্কটপ ডেটা
• পুরো মূলের জন্য মোবাইল ডেটা
• সমগ্র অরিজিনের জন্য ডেস্কটপ ডেটা

আপনি এই বিভাগের উপরের এবং উপরের ডানদিকে নিয়ন্ত্রণগুলিতে এগুলি টগল করতে পারেন। যদি একটি URL-এর URL স্তরে দেখানোর জন্য পর্যাপ্ত ডেটা না থাকে, কিন্তু উৎপত্তির ডেটা থাকে, তাহলে PageSpeed ​​Insights সর্বদা মূল ডেটা দেখায়৷

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

CrUX ডেটার চারটি আলাদা বিভাগ দেখে আপনাকে বুঝতে সাহায্য করতে পারে যে LCP সমস্যা এই পৃষ্ঠার জন্য নির্দিষ্ট, নাকি আরও সাধারণ সাইট-ব্যাপী সমস্যা। একইভাবে, এটি কোন ডিভাইসের প্রকারের LCP সমস্যা আছে তা দেখাতে পারে।

PageSpeed ​​Insights CrUX সম্পূরক মেট্রিক্স ব্যবহার করে

যারা এলসিপি অপ্টিমাইজ করতে চান তাদের ফার্স্ট কনটেন্টফুল পেইন্ট (এফসিপি) এবং টাইম টু ফার্স্ট বাইট (টিটিএফবি) সময় ব্যবহার করা উচিত, যা ভাল ডায়াগনস্টিক মেট্রিক যা এলসিপি সম্পর্কে মূল্যবান অন্তর্দৃষ্টি প্রদান করতে পারে।

TTFB হল সেই সময় যখন ভিজিটর একটি পৃষ্ঠায় নেভিগেট করতে শুরু করে (উদাহরণস্বরূপ, একটি লিঙ্কে ক্লিক করা), যতক্ষণ না HTML ডকুমেন্টের প্রথম বাইট পাওয়া যায়। একটি উচ্চ TTFB একটি 2.5 সেকেন্ডের LCP অর্জনকে চ্যালেঞ্জিং বা এমনকি অসম্ভব করে তুলতে পারে।

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

একবার একটি পৃষ্ঠা রেন্ডারিং শুরু করলে, একটি প্রাথমিক পেইন্ট (উদাহরণস্বরূপ, পটভূমির রঙ) হতে পারে, তারপরে কিছু বিষয়বস্তু প্রদর্শিত হবে (উদাহরণস্বরূপ, সাইট হেডার)। প্রাথমিক বিষয়বস্তুর চেহারা FCP দ্বারা পরিমাপ করা হয়। FCP এবং অন্যান্য মেট্রিক্সের মধ্যে ডেল্টা খুব বলা যেতে পারে।

TTFB এবং FCP-এর মধ্যে একটি বড় ডেল্টা নির্দেশ করতে পারে যে ব্রাউজারটিকে প্রচুর রেন্ডার-ব্লকিং সম্পদ ডাউনলোড করতে হবে। এটি একটি চিহ্নও হতে পারে যেকোন অর্থপূর্ণ বিষয়বস্তু রেন্ডার করার জন্য এটিকে অবশ্যই অনেক কাজ সম্পূর্ণ করতে হবে—একটি সাইটের একটি ক্লাসিক চিহ্ন যা ক্লায়েন্ট-সাইড রেন্ডারিংয়ের উপর অনেক বেশি নির্ভর করে।

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

PageSpeed ​​Insights Lighthouse ডেটা ব্যবহার করা

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

যদি লাইটহাউস এবং CrUX উভয়ই LCP মানগুলি দেখায় যেগুলির উন্নতির প্রয়োজন, তাহলে LCP উন্নত করার উপায়গুলি সম্পর্কে LCP বিভাগটি মূল্যবান নির্দেশনা প্রদান করতে পারে৷ LCP ফিল্টার ব্যবহার করুন শুধুমাত্র LCP এর সাথে প্রাসঙ্গিক অডিট দেখানোর জন্য নিম্নরূপ:

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

আমরা পরবর্তীতে এই উপ-অংশগুলি নিয়ে আলোচনা করব।

LCP ভাঙ্গন

LCP-এর জন্য অপ্টিমাইজ করা আরও জটিল কাজ হতে পারে যখন PageSpeed ​​Insights আপনাকে এই মেট্রিকটি কীভাবে উন্নত করা যায় তার উত্তর দেয় না। জটিল কাজগুলির সাথে সাধারণত সেগুলিকে ছোট, আরও পরিচালনাযোগ্য কাজগুলিতে ভাগ করা এবং প্রতিটিকে আলাদাভাবে সম্বোধন করা ভাল।

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

বেশিরভাগ পৃষ্ঠা লোডের মধ্যে সাধারণত অনেকগুলি নেটওয়ার্ক অনুরোধ থাকে, কিন্তু LCP উন্নত করার সুযোগগুলি সনাক্ত করার উদ্দেশ্যে, আপনার শুধুমাত্র দুটি দেখে শুরু করা উচিত:

1. প্রাথমিক HTML নথি
2. LCP সম্পদ (যদি প্রযোজ্য হয়)

যদিও পৃষ্ঠার অন্যান্য অনুরোধগুলি LCP-কে প্রভাবিত করতে পারে, এই দুটি অনুরোধ - বিশেষ করে যখন LCP সংস্থান শুরু হয় এবং শেষ হয় - আপনার পৃষ্ঠা LCP-এর জন্য অপ্টিমাইজ করা হয়েছে কিনা তা প্রকাশ করে৷

LCP রিসোর্স শনাক্ত করতে, আপনি LCP উপাদান নির্ধারণ করতে ডেভেলপার টুল (যেমন PageSpeed ​​Insights আগে আলোচনা করা হয়েছে, Chrome DevTools বা WebPageTest ) ব্যবহার করতে পারেন। সেখান থেকে আপনি পৃষ্ঠা দ্বারা লোড করা সমস্ত সংস্থানগুলির নেটওয়ার্ক জলপ্রপাতের উপাদান দ্বারা লোড করা URL (আবার, যদি প্রযোজ্য হয়) মেলাতে পারেন৷

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

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

টাইম টু ফার্স্ট বাইট (TTFB)

ব্যবহারকারী পৃষ্ঠাটি লোড করা শুরু করার সময় থেকে ব্রাউজার HTML নথির প্রতিক্রিয়ার প্রথম বাইট না পাওয়া পর্যন্ত।

সম্পদ লোড বিলম্ব

TTFB এবং ব্রাউজার যখন LCP রিসোর্স লোড করা শুরু করে তার মধ্যে সময়। যদি LCP উপাদানটির রেন্ডার করার জন্য রিসোর্স লোডের প্রয়োজন না হয় (উদাহরণস্বরূপ, যদি উপাদানটি একটি সিস্টেম ফন্টের সাথে রেন্ডার করা একটি পাঠ্য নোড হয়), এই সময়টি 0।

সম্পদ লোড সময়কাল

LCP রিসোর্স নিজেই লোড করতে যে সময় লাগে। যদি LCP উপাদানটির রেন্ডার করার জন্য রিসোর্স লোডের প্রয়োজন না হয় তবে এই সময়টি 0।

উপাদান রেন্ডার বিলম্ব

LCP রিসোর্স লোড হওয়া এবং LCP উপাদান সম্পূর্ণরূপে রেন্ডারিং শেষ হওয়ার মধ্যে সময়।

প্রতিটি পৃষ্ঠার LCP এই চারটি উপশ্রেণী নিয়ে গঠিত। তাদের মধ্যে কোন ফাঁক বা ওভারল্যাপ নেই এবং তারা সম্পূর্ণ LCP সময় পর্যন্ত যোগ করে।

প্রতিটি একক পৃষ্ঠার LCP মান এই চারটি উপ-অংশে বিভক্ত হতে পারে। তাদের মধ্যে কোন ওভারল্যাপ বা ফাঁক নেই। সম্মিলিতভাবে, তারা সম্পূর্ণ LCP সময় পর্যন্ত যোগ করে।

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

উদাহরণস্বরূপ, পূর্ববর্তী নেটওয়ার্ক জলপ্রপাতে, আপনি যদি আমাদের চিত্রের ফাইলের আকারকে আরও সংকুচিত করে বা আরও অনুকূল বিন্যাসে (যেমন AVIF বা WebP) স্যুইচ করে কমিয়ে দেন, তবে এটি রিসোর্স লোডের সময়কাল হ্রাস করবে, কিন্তু তা হবে না আসলে এলসিপি উন্নত করুন কারণ সময়টি কেবল উপাদান রেন্ডার বিলম্ব সাব-পার্টে স্থানান্তরিত হবে:

এটি হওয়ার কারণ হল, এই পৃষ্ঠায়, জাভাস্ক্রিপ্ট কোড লোডিং শেষ না হওয়া পর্যন্ত LCP উপাদানটি লুকানো থাকে এবং তারপরে সবকিছু একবারে প্রকাশ করা হয়।

এই উদাহরণটি এই বিন্দুটিকে ব্যাখ্যা করতে সাহায্য করে যে আপনাকে সর্বোত্তম LCP ফলাফল অর্জনের জন্য এই সমস্ত উপ-অংশগুলিকে অপ্টিমাইজ করতে হবে।

সর্বোত্তম উপ-অংশের সময়

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

চারটি উপ-অংশের মধ্যে দুটির নামে "বিলম্ব" শব্দটি রয়েছে। এটি একটি সংকেত যে আপনি এই বার যতটা সম্ভব শূন্যের কাছাকাছি পেতে চান। অন্য দুটি অংশে নেটওয়ার্ক অনুরোধ জড়িত, যা তাদের স্বভাবগতভাবে সময় নেয়।

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

LCP সময়ের ভাঙ্গন সম্পর্কে চিন্তা করার একটি ভাল উপায় হল:

• এইচটিএমএল ডকুমেন্ট এবং এলসিপি সোর্স লোড করার জন্য LCP সময়ের বেশিরভাগ সময় ব্যয় করা উচিত।
• যেকোন সময় এলসিপির আগে যেখানে এই দুটি রিসোর্স লোড হচ্ছে না সেখানে উন্নতি করার সুযোগ রয়েছে।

প্রতিটি অংশ অপ্টিমাইজ কিভাবে

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

পরবর্তী চারটি বিভাগ প্রতিটি অংশকে কীভাবে অপ্টিমাইজ করা যায় তার জন্য সুপারিশ এবং সর্বোত্তম অনুশীলন উপস্থাপন করবে। সেগুলিকে ক্রমানুসারে উপস্থাপন করা হয়েছে, অপ্টিমাইজেশানগুলি দিয়ে শুরু করে যা সম্ভবত সবচেয়ে বড় প্রভাব ফেলতে পারে৷

1. রিসোর্স লোড বিলম্ব দূর করুন

এই ধাপে লক্ষ্য হল LCP রিসোর্স যত তাড়াতাড়ি সম্ভব লোড করা শুরু করে তা নিশ্চিত করা। যদিও তাত্ত্বিকভাবে একটি রিসোর্স লোড হওয়া শুরু হতে পারে তা TTFB-এর পরপরই, বাস্তবে ব্রাউজারগুলি আসলে রিসোর্স লোড করা শুরু করার আগে সবসময় কিছু বিলম্ব হয়।

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

সাধারণভাবে বলতে গেলে, LCP রিসোর্স কত দ্রুত লোড হতে পারে তা প্রভাবিত করে এমন দুটি কারণ রয়েছে:

• যখন সম্পদ আবিষ্কৃত হয়।
• সম্পদ কি অগ্রাধিকার দেওয়া হয়.

সম্পদ আবিষ্কৃত হলে অপ্টিমাইজ করুন

আপনার LCP রিসোর্স যত তাড়াতাড়ি সম্ভব লোড করা শুরু করে তা নিশ্চিত করার জন্য, ব্রাউজারের প্রিলোড স্ক্যানার দ্বারা প্রাথমিক HTML নথির প্রতিক্রিয়ায় সংস্থানটি আবিষ্কার করা গুরুত্বপূর্ণ। উদাহরণস্বরূপ, নিম্নলিখিত ক্ষেত্রে, ব্রাউজার HTML নথির প্রতিক্রিয়া স্ক্যান করে LCP সংস্থান আবিষ্কার করতে পারে:

• LCP উপাদান হল একটি <img> উপাদান, এবং এর src বা srcset বৈশিষ্ট্যগুলি প্রাথমিক HTML মার্কআপে উপস্থিত থাকে।
• LCP উপাদানটির জন্য একটি CSS ব্যাকগ্রাউন্ড ইমেজ প্রয়োজন, কিন্তু সেই ইমেজটি HTML মার্কআপে (বা একটি Link হেডার ব্যবহার করে) <link rel="preload"> ব্যবহার করে প্রিলোড করা হয়।
• LCP উপাদান হল একটি টেক্সট নোড যা রেন্ডার করার জন্য একটি ওয়েব ফন্টের প্রয়োজন হয় এবং ফন্টটি HTML মার্কআপে (অথবা একটি Link হেডার ব্যবহার করে) <link rel="preload"> ব্যবহার করে লোড করা হয়।

এখানে কিছু উদাহরণ রয়েছে যেখানে HTML নথির প্রতিক্রিয়া স্ক্যান করে LCP সংস্থান আবিষ্কার করা যাবে না:

• LCP উপাদান হল একটি <img> যা জাভাস্ক্রিপ্ট ব্যবহার করে পৃষ্ঠায় গতিশীলভাবে যোগ করা হয়।
• LCP উপাদানটি একটি জাভাস্ক্রিপ্ট লাইব্রেরির সাথে অলসভাবে লোড করা হয় যা এর src বা srcset বৈশিষ্ট্যগুলি লুকিয়ে রাখে (প্রায়শই data-src বা data-srcset হিসাবে)।
• LCP উপাদানটির জন্য একটি CSS ব্যাকগ্রাউন্ড ইমেজ প্রয়োজন।

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

অপ্রয়োজনীয় রিসোর্স লোড বিলম্ব দূর করতে, আপনার LCP রিসোর্স HTML সোর্স থেকে আবিষ্কার করা উচিত। যে ক্ষেত্রে সম্পদ শুধুমাত্র একটি বাহ্যিক CSS বা JavaScript ফাইল থেকে উল্লেখ করা হয়, LCP রিসোর্স একটি উচ্চ আনয়ন অগ্রাধিকার সহ প্রিলোড করা উচিত, উদাহরণস্বরূপ:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

সম্পদ দেওয়া অগ্রাধিকার অপ্টিমাইজ করুন

এমনকি যদি LCP রিসোর্সটি HTML মার্কআপ থেকে আবিষ্কৃত হয়, তবুও এটি প্রথম রিসোর্সের মতো লোড হওয়া শুরু নাও হতে পারে। এটি ঘটতে পারে যদি ব্রাউজার প্রিলোড স্ক্যানারের অগ্রাধিকার হিউরিস্টিকগুলি সংস্থানটি গুরুত্বপূর্ণ বলে স্বীকৃতি না দেয়, বা যদি এটি নির্ধারণ করে যে অন্যান্য সংস্থানগুলি আরও গুরুত্বপূর্ণ৷

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

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

<img fetchpriority="high" src="/path/to/hero-image.webp">

আপনি যদি মনে করেন যে এটি আপনার পৃষ্ঠার LCP উপাদান হতে পারে তাহলে একটি <img> উপাদানে fetchpriority="high" সেট করা একটি ভাল ধারণা। যাইহোক, এক বা দুটির বেশি ছবিতে একটি উচ্চ অগ্রাধিকার সেট করা অগ্রাধিকার সেটিংকে LCP কমাতে অসহায় করে তোলে।

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

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

নির্দিষ্ট সংস্থানগুলিকে অগ্রাহ্য করা সংস্থানগুলির জন্য আরও ব্যান্ডউইথ বহন করতে পারে যেগুলির জন্য এটি আরও বেশি প্রয়োজন — তবে সতর্ক থাকুন৷ DevTools-এ সর্বদা রিসোর্স অগ্রাধিকার চেক করুন এবং ল্যাব ও ফিল্ড টুলের মাধ্যমে পরিবর্তনগুলি পরীক্ষা করুন।

আপনি আপনার LCP রিসোর্স অগ্রাধিকার এবং আবিষ্কারের সময় অপ্টিমাইজ করার পরে, আপনার নেটওয়ার্ক জলপ্রপাতটি এইরকম হওয়া উচিত (LCP রিসোর্সটি প্রথম রিসোর্সের মতো একই সময়ে শুরু হয়):

2. উপাদান রেন্ডার বিলম্ব দূর করুন

এই ধাপে লক্ষ্য হল এলসিপি উপাদানটি তার রিসোর্স লোডিং শেষ হওয়ার সাথে সাথেই রেন্ডার করতে পারে তা নিশ্চিত করা, তা যখনই ঘটবে না কেন।

LCP উপাদানটি তার রিসোর্স লোডিং শেষ হওয়ার সাথে সাথে রেন্ডার করতে সক্ষম হবে না তার প্রাথমিক কারণ হল যদি রেন্ডারিং অন্য কোনো কারণে ব্লক করা হয়:

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

নিম্নলিখিত বিভাগগুলি ব্যাখ্যা করে কিভাবে অপ্রয়োজনীয় উপাদান রেন্ডার বিলম্বের সবচেয়ে সাধারণ কারণগুলিকে মোকাবেলা করতে হয়৷

কমানো বা ইনলাইন রেন্ডার-ব্লকিং স্টাইলশীট

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

এটি ঠিক করতে, আপনার বিকল্পগুলি হল:

• অতিরিক্ত নেটওয়ার্ক অনুরোধ এড়াতে এইচটিএমএল-এ স্টাইল শীট ইনলাইন করুন; অথবা,
• স্টাইল শীটের আকার কমিয়ে দিন।

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

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

স্টাইল শীটের আকার কমাতে কিছু সুপারিশ হল:

• অব্যবহৃত CSS সরান : CSS নিয়মগুলি খুঁজে পেতে Chrome DevTools ব্যবহার করুন যা ব্যবহার করা হচ্ছে না এবং সম্ভাব্যভাবে সরানো যেতে পারে (বা স্থগিত)।
• অ-সমালোচনামূলক CSS স্থগিত করুন : আপনার স্টাইল শীটকে এমন স্টাইলগুলিতে বিভক্ত করুন যা প্রাথমিক পৃষ্ঠা লোডের জন্য প্রয়োজনীয় এবং তারপরে অলসভাবে লোড করা যেতে পারে এমন শৈলীগুলি।
• CSS ছোট করুন এবং সংকুচিত করুন : যে শৈলীগুলি সমালোচনামূলক, নিশ্চিত করুন যে আপনি তাদের স্থানান্তরের আকার যতটা সম্ভব কম করছেন।

ডিফার বা ইনলাইন রেন্ডার-ব্লকিং জাভাস্ক্রিপ্ট

আপনার পৃষ্ঠাগুলির <head> -এ সিঙ্ক্রোনাস স্ক্রিপ্টগুলি ( async বা defer অ্যাট্রিবিউট ছাড়া স্ক্রিপ্টগুলি) যোগ করার প্রয়োজন হয় না এবং এটি করা প্রায় সর্বদা কর্মক্ষমতার উপর নেতিবাচক প্রভাব ফেলবে।

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

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

সার্ভার-সাইড রেন্ডারিং ব্যবহার করুন

সার্ভার-সাইড রেন্ডারিং (SSR) হল সার্ভারে আপনার ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন লজিক চালানোর এবং সম্পূর্ণ HTML মার্কআপের সাথে HTML নথির অনুরোধে সাড়া দেওয়ার প্রক্রিয়া।

LCP অপ্টিমাইজ করার দৃষ্টিকোণ থেকে, SSR এর দুটি প্রাথমিক সুবিধা রয়েছে:

• আপনার ইমেজ রিসোর্স এইচটিএমএল সোর্স থেকে আবিষ্কৃত হবে (যেমন ধাপ 1 এ আগে আলোচনা করা হয়েছে)।
• আপনার পৃষ্ঠার সামগ্রী রেন্ডার করার আগে শেষ করার জন্য অতিরিক্ত জাভাস্ক্রিপ্ট অনুরোধের প্রয়োজন হবে না।

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

SSR-এর অনুরূপ বিকল্পটিকে স্ট্যাটিক সাইট জেনারেশন (SSG) বা প্রিরেন্ডারিং বলা হয়। এটি চাহিদার পরিবর্তে একটি বিল্ড ধাপে আপনার HTML পৃষ্ঠাগুলি তৈরি করার প্রক্রিয়া। যদি আপনার আর্কিটেকচারের সাথে প্রি-রেন্ডারিং সম্ভব হয় তবে এটি সাধারণত পারফরম্যান্সের জন্য একটি ভাল পছন্দ।

দীর্ঘ কাজগুলি ভেঙে ফেলুন

এমনকি যদি আপনি আগে থেকে দেওয়া পরামর্শ অনুসরণ করে থাকেন, এবং আপনার জাভাস্ক্রিপ্ট কোড রেন্ডার-ব্লকিং নয় বা আপনার উপাদানগুলি রেন্ডার করার জন্য দায়ী নয়, তবুও এটি LCP বিলম্বিত করতে পারে।

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

সমস্ত ব্রাউজার আজ প্রধান থ্রেডে চিত্রগুলি রেন্ডার করে, যার অর্থ মূল থ্রেডকে ব্লক করে এমন কিছু অপ্রয়োজনীয় উপাদান রেন্ডার বিলম্বের দিকে নিয়ে যেতে পারে।

3. সম্পদ লোড সময়কাল হ্রাস

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

• সম্পদের আকার হ্রাস করুন।
• সম্পদ ভ্রমণ করতে হবে দূরত্ব কমিয়ে.
• নেটওয়ার্ক ব্যান্ডউইথের জন্য বিরোধ হ্রাস করুন।
• নেটওয়ার্কের সময় সম্পূর্ণভাবে বাদ দিন।

সম্পদের আকার হ্রাস করুন

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

• সর্বোত্তম ছবির আকার পরিবেশন করুন
• আধুনিক চিত্র বিন্যাস ব্যবহার করুন
• ইমেজ কম্প্রেস
• ওয়েব ফন্টের আকার হ্রাস করুন

সম্পদ ভ্রমণ করতে হবে দূরত্ব কমিয়ে

সম্পদের আকার কমানোর পাশাপাশি, আপনি আপনার সার্ভারগুলিকে ভৌগলিকভাবে যতটা সম্ভব আপনার ব্যবহারকারীদের কাছাকাছি নিয়ে লোডের সময় কমাতে পারেন। এবং এটি করার সর্বোত্তম উপায় হল একটি সামগ্রী বিতরণ নেটওয়ার্ক (CDN) ব্যবহার করা।

বিশেষ করে ইমেজ CDNগুলি বিশেষভাবে সহায়ক কারণ তারা শুধুমাত্র সম্পদের দূরত্ব কমায় না, তবে তারা সাধারণত সম্পদের আকারও কমিয়ে দেয়—আপনার জন্য আগের থেকে সমস্ত আকার-হ্রাস সুপারিশ স্বয়ংক্রিয়ভাবে বাস্তবায়ন করে।

নেটওয়ার্ক ব্যান্ডউইথের জন্য বিরোধ হ্রাস করুন

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

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

নেটওয়ার্কের সময় সম্পূর্ণভাবে বাদ দিন

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

যদি আপনার LCP রিসোর্স একটি ওয়েব ফন্ট হয়, তাহলে ওয়েব ফন্টের আকার কমানোর পাশাপাশি, আপনাকে ওয়েব ফন্ট রিসোর্স লোডে রেন্ডারিং ব্লক করতে হবে কিনা তাও বিবেচনা করা উচিত। আপনি যদি auto বা block ছাড়া অন্য কিছুর একটি font-display মান সেট করেন, তাহলে লোডের সময় পাঠ্য সর্বদা দৃশ্যমান হবে , এবং অতিরিক্ত নেটওয়ার্ক অনুরোধে LCP ব্লক করা হবে না।

অবশেষে, আপনার LCP রিসোর্স যদি ছোট হয়, তাহলে রিসোর্সগুলিকে ডেটা URL হিসেবে ইনলাইন করাটা বোধগম্য হতে পারে, যা অতিরিক্ত নেটওয়ার্ক অনুরোধও বাদ দেবে। যাইহোক, ডেটা URL ব্যবহার করা সতর্কতার সাথে আসে কারণ তখন সংস্থানগুলি ক্যাশে করা যায় না এবং কিছু ক্ষেত্রে অতিরিক্ত ডিকোড খরচের কারণে রেন্ডার বিলম্ব হতে পারে।

4. প্রথম বাইটে সময় কমিয়ে দিন

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

অন্যথায় দ্রুত সাইটের জন্য ধীর TTFB এর একটি সাধারণ কারণ হল একাধিক পুনঃনির্দেশের মাধ্যমে আসা দর্শকরা, যেমন বিজ্ঞাপন বা সংক্ষিপ্ত লিঙ্কগুলি থেকে। সর্বদা একটি ভিজিটর অপেক্ষা করতে হবে পুনঃনির্দেশের সংখ্যা কমিয়ে.

আরেকটি সাধারণ কারণ হল যখন একটি CDN প্রান্ত সার্ভার থেকে ক্যাশে করা সামগ্রী ব্যবহার করা যায় না এবং সমস্ত অনুরোধগুলিকে মূল সার্ভারে ফিরে যেতে হবে। এটি ঘটতে পারে যদি অনন্য URL প্যারামিটারগুলি দর্শকদের দ্বারা বিশ্লেষণের জন্য ব্যবহার করা হয়—এমনকি যদি সেগুলি ভিন্ন পৃষ্ঠায় না আসে।

TTFB অপ্টিমাইজ করার বিষয়ে সুনির্দিষ্ট নির্দেশনার জন্য, অপ্টিমাইজ TTFB গাইড দেখুন৷

জাভাস্ক্রিপ্টে এলসিপি ব্রেকডাউন মনিটর করুন

পূর্বে আলোচনা করা সমস্ত LCP উপ-অংশগুলির জন্য সময় সংক্রান্ত তথ্য নিম্নলিখিত পারফরম্যান্স APIগুলির সংমিশ্রণের মাধ্যমে জাভাস্ক্রিপ্টে আপনার কাছে উপলব্ধ:

• সবচেয়ে বড় বিষয়বস্তু পেইন্ট API
• নেভিগেশন টাইমিং API
• রিসোর্স টাইমিং API

জাভাস্ক্রিপ্টে এই সময়ের মানগুলি গণনা করার সুবিধা হল এটি আপনাকে একটি বিশ্লেষণ প্রদানকারীর কাছে পাঠাতে বা ডিবাগিং এবং অপ্টিমাইজে সহায়তা করার জন্য আপনার বিকাশকারী সরঞ্জামগুলিতে লগ করতে দেয়৷

উদাহরণস্বরূপ, Chrome DevTools পারফরম্যান্স প্যানেলে টাইমিং ট্র্যাকে বার যোগ করতে নিম্নলিখিত স্ক্রিনশটটি ব্যবহারকারী টাইমিং API থেকে performance.measure() পদ্ধতি ব্যবহার করে।

টাইমিংস ট্র্যাকের ভিজ্যুয়ালাইজেশনগুলি বিশেষভাবে সহায়ক যখন নেটওয়ার্ক এবং প্রধান থ্রেড ট্র্যাকগুলির পাশাপাশি দেখা হয়, কারণ আপনি এক নজরে দেখতে পারেন যে এই সময়সীমার সময় পৃষ্ঠায় আর কী ঘটছে৷

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

এই স্ক্রিনশটটি একটি উদাহরণ দেখায় যা প্রতিটি LCP সাব-পার্টের মোট সময় লগ করে, সেইসাথে কনসোলে মোট LCP সময়ের শতাংশ।

এই দুটি ভিজ্যুয়ালাইজেশন নিম্নলিখিত কোড দিয়ে তৈরি করা হয়েছিল:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

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

সারাংশ

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

উচ্চ স্তরে, LCP অপ্টিমাইজ করা চারটি ধাপে সংক্ষিপ্ত করা যেতে পারে:

1. LCP রিসোর্স যত তাড়াতাড়ি সম্ভব লোড করা শুরু করে তা নিশ্চিত করুন।
2. নিশ্চিত করুন যে LCP উপাদানটি তার রিসোর্স লোডিং শেষ হওয়ার সাথে সাথে রেন্ডার করতে পারে।
3. LCP রিসোর্সের লোড টাইম যতটা সম্ভব কমিয়ে দিন গুণমানকে ত্যাগ না করে।
4. যত দ্রুত সম্ভব প্রাথমিক HTML ডকুমেন্ট ডেলিভার করুন।

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