এলসিপি (LCP) বিশ্লেষণ করে উন্নতির মূল ক্ষেত্রগুলো চিহ্নিত করার একটি ধাপে ধাপে নির্দেশিকা।
প্রকাশিত: ৩০ এপ্রিল, ২০২০, সর্বশেষ হালনাগাদ: ৩১ মার্চ, ২০২৫
লার্জেস্ট কন্টেন্টফুল পেইন্ট (LCP) হলো তিনটি কোর ওয়েব ভাইটালস মেট্রিকের মধ্যে একটি, এবং এটি নির্দেশ করে একটি ওয়েব পেজের মূল কন্টেন্ট কত দ্রুত লোড হয়। নির্দিষ্টভাবে বলতে গেলে, ব্যবহারকারী যখন পেজটি লোড করা শুরু করেন, তখন থেকে ভিউপোর্টের মধ্যে সবচেয়ে বড় ছবি বা টেক্সট ব্লকটি রেন্ডার হওয়া পর্যন্ত সময়কে LCP পরিমাপ করে।
ব্যবহারকারীদের ভালো অভিজ্ঞতা দেওয়ার জন্য, সাইটগুলোর উচিত পেজ ভিজিটের অন্তত ৭৫% ক্ষেত্রে LCP ২.৫ সেকেন্ড বা তার কম রাখার চেষ্টা করা।
ব্রাউজার কত দ্রুত একটি ওয়েব পেজ লোড ও রেন্ডার করতে পারে, তা বেশ কিছু বিষয়ের উপর নির্ভর করে, এবং এগুলোর যেকোনো একটিতে বিলম্ব হলে তা LCP-এর উপর উল্লেখযোগ্য প্রভাব ফেলতে পারে।
পেজের কোনো একটি অংশে দ্রুত কোনো সমাধান করলে LCP-তে অর্থপূর্ণ উন্নতি হওয়ার ঘটনা বিরল। LCP উন্নত করতে হলে, আপনাকে সম্পূর্ণ লোডিং প্রক্রিয়াটি খতিয়ে দেখতে হবে এবং এর প্রতিটি ধাপ অপ্টিমাইজ করা হয়েছে কিনা তা নিশ্চিত করতে হবে।
আপনার LCP মেট্রিক বোঝা
LCP অপ্টিমাইজ করার আগে, ডেভেলপারদের এটা বোঝার চেষ্টা করা উচিত যে তাদের আদৌ কোনো LCP সমস্যা আছে কিনা, এবং সেই সমস্যার মাত্রা কতটা।
এলসিপি বিভিন্ন টুলের মাধ্যমে পরিমাপ করা যায় এবং এগুলোর সবকটি একই পদ্ধতিতে এলসিপি পরিমাপ করে না। প্রকৃত ব্যবহারকারীদের এলসিপি বোঝার জন্য, লাইটহাউসের মতো ল্যাব-ভিত্তিক টুল বা স্থানীয় পরীক্ষার ফলাফলের পরিবর্তে, প্রকৃত ব্যবহারকারীরা কী অভিজ্ঞতা লাভ করছেন তা আমাদের দেখা উচিত। এই ল্যাব-ভিত্তিক টুলগুলো এলসিপি ব্যাখ্যা করতে এবং তা উন্নত করতে প্রচুর তথ্য দিতে পারে, কিন্তু মনে রাখবেন যে শুধুমাত্র ল্যাবের পরীক্ষাগুলো আপনার প্রকৃত ব্যবহারকারীদের অভিজ্ঞতার সম্পূর্ণ প্রতিনিধিত্ব নাও করতে পারে।
কোনো সাইটে ইনস্টল করা রিয়েল ইউজার মনিটরিং (RUM) টুল থেকে, অথবা ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্ট (CrUX) ব্যবহার করে প্রকৃত ব্যবহারকারীদের উপর ভিত্তি করে LCP ডেটা পাওয়া যেতে পারে, যা লক্ষ লক্ষ ওয়েবসাইটের জন্য প্রকৃত ক্রোম ব্যবহারকারীদের কাছ থেকে বেনামী ডেটা সংগ্রহ করে।
Chrome DevTools CrUX LCP ডেটা ব্যবহার করে
ক্রোম ডেভটুলস-এর পারফরম্যান্স প্যানেলটি লাইভ মেট্রিক্স ভিউতে পেজ বা অরিজিনের CrUX LCP-এর পাশে আপনার লোকাল LCP অভিজ্ঞতা দেখায়, এবং একটি পারফরম্যান্স ট্রেসের ইনসাইটস -এ LCP সাবপার্ট টাইমিং-এর বিস্তারিত বিশ্লেষণ অন্তর্ভুক্ত করে (যা আমরা শীঘ্রই ব্যাখ্যা করব)।
পারফরম্যান্স প্যানেলে ফিল্ড ডেটা যুক্ত করার মাধ্যমে, আপনি মূল্যায়ন করতে পারেন যে কোনো পৃষ্ঠায় বাস্তব ব্যবহারকারীর LCP সংক্রান্ত কোনো সমস্যা আছে কিনা এবং সেই সমস্যাগুলো আরও ভালোভাবে পুনরুৎপাদন ও ডিবাগ করার জন্য আপনার স্থানীয় পরিবেশের সেটিংস পরিবর্তন করতে পারেন।
PageSpeed Insights CrUX LCP ডেটা ব্যবহার করে
PageSpeed Insights-এর উপরের অংশে 'আপনার আসল ব্যবহারকারীরা কী অভিজ্ঞতা লাভ করছেন তা আবিষ্কার করুন ' লেবেলযুক্ত অংশে CrUX ডেটা পাওয়া যায়। আরও বিস্তারিত ল্যাব-ভিত্তিক ডেটা নিচের অংশে ' পারফরম্যান্স সমস্যা নির্ণয় করুন ' লেবেলযুক্ত অংশে পাওয়া যায়। যদি আপনার ওয়েবসাইটের জন্য CrUX ডেটা উপলব্ধ থাকে, তবে সর্বদা প্রথমে আসল ব্যবহারকারীর ডেটার উপর মনোযোগ দিন।
PageSpeed Insights সর্বোচ্চ চারটি ভিন্ন CrUX ডেটা দেখায়:
- এই URL-এর জন্য মোবাইল ডেটা
- এই URL-এর জন্য ডেস্কটপ ডেটা
- পুরো অরিজিনের জন্য মোবাইল ডেটা
- সম্পূর্ণ অরিজিনের জন্য ডেস্কটপ ডেটা
আপনি এই বিভাগের উপরে এবং উপরের ডানদিকের কন্ট্রোলগুলিতে এগুলি টগল করতে পারেন। যদি কোনো URL-এ URL লেভেলে দেখানোর জন্য যথেষ্ট ডেটা না থাকে, কিন্তু অরিজিনের জন্য ডেটা থাকে, তাহলে PageSpeed Insights সর্বদা অরিজিনের ডেটা দেখায়।
পুরো অরিজিনের LCP, একটি নির্দিষ্ট পেজের LCP থেকে অনেকটাই ভিন্ন হতে পারে, যা নির্ভর করে সেই অরিজিনের অন্যান্য পেজের তুলনায় পেজটিতে LCP কীভাবে লোড হয় তার উপর। ভিজিটররা কীভাবে এই পেজগুলোতে নেভিগেট করেন, তার দ্বারাও এটি প্রভাবিত হতে পারে। হোম পেজগুলোতে সাধারণত নতুন ব্যবহারকারীরাই যান এবং তাই এগুলো প্রায়শই কোনো ক্যাশ করা কন্টেন্ট ছাড়াই "কোল্ড" লোড হয়, ফলে এগুলো প্রায়শই একটি ওয়েবসাইটের সবচেয়ে ধীরগতির পেজ হয়ে থাকে।
CrUX ডেটার চারটি ভিন্ন বিভাগ পর্যালোচনা করলে আপনি বুঝতে পারবেন যে LCP সমস্যাটি শুধুমাত্র এই পৃষ্ঠার জন্য নির্দিষ্ট, নাকি এটি একটি সাধারণ সাইট-ব্যাপী সমস্যা। একইভাবে, এটি দেখাতে পারে কোন ধরনের ডিভাইসে LCP সমস্যা রয়েছে।
PageSpeed Insights CrUX সম্পূরক মেট্রিক ব্যবহার করে
যারা LCP অপ্টিমাইজ করতে চান, তাদের ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) এবং টাইম টু ফার্স্ট বাইট (TTFB) টাইমিংগুলোও ব্যবহার করা উচিত, যেগুলো ভালো ডায়াগনস্টিক মেট্রিক এবং LCP সম্পর্কে মূল্যবান অন্তর্দৃষ্টি প্রদান করতে পারে।
TTFB হলো সেই সময়, যখন কোনো পরিদর্শক একটি পৃষ্ঠায় নেভিগেট করা শুরু করেন (উদাহরণস্বরূপ, একটি লিঙ্কে ক্লিক করার পর থেকে HTML ডকুমেন্টের প্রথম বাইটগুলো গৃহীত হওয়া পর্যন্ত। একটি উচ্চ TTFB ২.৫ সেকেন্ডের LCP অর্জন করাকে কঠিন, এমনকি অসম্ভব করে তুলতে পারে।
উচ্চ TTFB-এর কারণ হতে পারে একাধিক সার্ভার রিডাইরেক্ট, নিকটতম সাইট সার্ভার থেকে দূরে অবস্থিত ভিজিটর, দুর্বল নেটওয়ার্ক পরিস্থিতি, অথবা কোয়েরি প্যারামিটারের কারণে ক্যাশ করা কন্টেন্ট ব্যবহার করতে না পারা।
একটি পৃষ্ঠা রেন্ডার হওয়া শুরু করলে, প্রথমে একটি প্রাথমিক প্রলেপ (যেমন, ব্যাকগ্রাউন্ডের রঙ) থাকতে পারে, যার পরে কিছু বিষয়বস্তু (যেমন, সাইট হেডার) প্রদর্শিত হয়। এই প্রাথমিক বিষয়বস্তুর উপস্থিতি FCP দ্বারা পরিমাপ করা হয়। FCP এবং অন্যান্য মেট্রিকের মধ্যেকার পার্থক্য অনেক গুরুত্বপূর্ণ তথ্য দিতে পারে।
TTFB এবং FCP-এর মধ্যে বড় পার্থক্য ইঙ্গিত দিতে পারে যে ব্রাউজারকে প্রচুর পরিমাণে রেন্ডার-ব্লকিং অ্যাসেট ডাউনলোড করতে হবে। এটি এমনও একটি লক্ষণ হতে পারে যে, কোনো অর্থবহ কন্টেন্ট রেন্ডার করার জন্য ব্রাউজারকে অনেক কাজ সম্পন্ন করতে হয়—যা ক্লায়েন্ট-সাইড রেন্ডারিংয়ের ওপর ব্যাপকভাবে নির্ভরশীল কোনো সাইটের একটি চিরায়ত লক্ষণ।
FCP এবং LCP-এর মধ্যে একটি বড় পার্থক্য নির্দেশ করে যে, LCP রিসোর্সটি হয় ব্রাউজারের অগ্রাধিকার দেওয়ার জন্য তাৎক্ষণিকভাবে উপলব্ধ নয় (উদাহরণস্বরূপ, টেক্সট বা ছবি যা প্রাথমিক HTML-এ উপলব্ধ না থেকে জাভাস্ক্রিপ্ট দ্বারা পরিচালিত হয়), অথবা ব্রাউজারটি LCP কন্টেন্ট প্রদর্শন করার আগে অন্য কাজ সম্পন্ন করছে।
PageSpeed Insights Lighthouse ডেটা ব্যবহার করে
PageSpeed Insights-এর Lighthouse বিভাগটি LCP উন্নত করার জন্য কিছু নির্দেশনা দেয়, কিন্তু প্রথমে আপনার যাচাই করে দেখা উচিত যে প্রদত্ত LCP, CrUX দ্বারা সরবরাহ করা প্রকৃত ব্যবহারকারীর ডেটার সাথে মোটামুটিভাবে সামঞ্জস্যপূর্ণ কিনা। যদি Lighthouse এবং CrUX-এর মধ্যে অমিল থাকে, তাহলে সম্ভবত CrUX আপনার ব্যবহারকারীর অভিজ্ঞতার একটি আরও সঠিক চিত্র প্রদান করে। এর উপর ভিত্তি করে কোনো পদক্ষেপ নেওয়ার আগে নিশ্চিত হয়ে নিন যে আপনার CrUX ডেটা শুধুমাত্র আপনার পেজের জন্য, সম্পূর্ণ অরিজিনের জন্য নয়।
যদি লাইটহাউস এবং ক্রাক্স উভয়ই উন্নতির প্রয়োজন এমন LCP মান দেখায়, তবে লাইটহাউস বিভাগটি LCP উন্নত করার উপায় সম্পর্কে মূল্যবান নির্দেশনা প্রদান করতে পারে। শুধুমাত্র LCP-এর সাথে প্রাসঙ্গিক অডিটগুলি দেখানোর জন্য নিম্নলিখিতভাবে LCP ফিল্টারটি ব্যবহার করুন:
উন্নতির সুযোগগুলোর পাশাপাশি, এমন ডায়াগনস্টিক তথ্যও রয়েছে যা সমস্যাটি নির্ণয়ে আরও সাহায্য করতে পারে। লার্জেস্ট কন্টেন্টফুল পেইন্ট এলিমেন্ট ডায়াগনস্টিকটি LCP গঠনকারী বিভিন্ন টাইমিংগুলোর একটি কার্যকর বিভাজন দেখায়:
LCP রিসোর্স টাইপ এবং সাবপার্টগুলো CrUX-এও পাওয়া যায় ।
আমরা পরবর্তীতে এই উপবিভাগগুলো নিয়ে বিস্তারিত আলোচনা করব।
এলসিপি বিভাজন
যখন PageSpeed Insights এই মেট্রিকটি কীভাবে উন্নত করা যায় তার উত্তর দেয় না, তখন LCP অপ্টিমাইজ করা একটি আরও জটিল কাজ হতে পারে। জটিল কাজগুলোকে সাধারণত ছোট ছোট ও সহজে পরিচালনাযোগ্য অংশে ভাগ করে নিয়ে প্রতিটি আলাদাভাবে সমাধান করা শ্রেয়।
এই অংশে এলসিপি-কে এর সবচেয়ে গুরুত্বপূর্ণ উপ-অংশগুলোতে বিভক্ত করার একটি পদ্ধতি উপস্থাপন করা হয়েছে এবং তারপর প্রতিটি অংশকে অপ্টিমাইজ করার জন্য নির্দিষ্ট সুপারিশ ও সর্বোত্তম অনুশীলন তুলে ধরা হয়েছে।
বেশিরভাগ পেজ লোডের সময় সাধারণত বেশ কিছু নেটওয়ার্ক রিকোয়েস্ট অন্তর্ভুক্ত থাকে, কিন্তু LCP উন্নত করার সুযোগ শনাক্ত করার উদ্দেশ্যে, আপনার কেবল দুটি বিষয় দিয়ে শুরু করা উচিত:
- প্রাথমিক HTML ডকুমেন্ট
- এলসিপি রিসোর্স (যদি প্রযোজ্য হয়)
যদিও পেজের অন্যান্য অনুরোধ LCP-কে প্রভাবিত করতে পারে, এই দুটি অনুরোধ—বিশেষ করে LCP রিসোর্সটি কখন শুরু ও শেষ হয়—তা থেকে জানা যায় আপনার পেজটি LCP-এর জন্য অপ্টিমাইজ করা হয়েছে কি না।
LCP রিসোর্সটি শনাক্ত করতে, আপনি ডেভেলপার টুলস (যেমন পূর্বে আলোচিত PageSpeed Insights, Chrome DevTools , বা WebPageTest ) ব্যবহার করে LCP এলিমেন্টটি নির্ধারণ করতে পারেন। সেখান থেকে, আপনি পেজ দ্বারা লোড হওয়া সমস্ত রিসোর্সের একটি নেটওয়ার্ক ওয়াটারফলে এলিমেন্টটি দ্বারা লোড হওয়া URL-টি (প্রযোজ্য হলে, আবারও) মেলাতে পারেন।
উদাহরণস্বরূপ, নিম্নলিখিত ভিজ্যুয়ালাইজেশনটি একটি সাধারণ পেজ লোডের নেটওয়ার্ক ওয়াটারফল ডায়াগ্রামে এই রিসোর্সগুলিকে হাইলাইট করে দেখায়, যেখানে LCP এলিমেন্টটি রেন্ডার করার জন্য একটি ইমেজ রিকোয়েস্টের প্রয়োজন হয়।
একটি ভালোভাবে অপ্টিমাইজ করা পেজের জন্য, আপনি চাইবেন আপনার LCP রিসোর্স রিকোয়েস্টটি যত তাড়াতাড়ি সম্ভব লোড হওয়া শুরু করুক, এবং LCP রিসোর্সটি লোড হওয়া শেষ হওয়ার পর LCP এলিমেন্টটি যত দ্রুত সম্ভব রেন্ডার হোক। কোনো নির্দিষ্ট পেজ এই নীতিটি অনুসরণ করছে কি না, তা সহজে বোঝার জন্য, আপনি মোট LCP সময়কে নিম্নলিখিত উপভাগগুলিতে ভাগ করতে পারেন:
- প্রথম বাইটের সময় (TTFB)
- ব্যবহারকারী যখন পৃষ্ঠাটি লোড করা শুরু করেন, সেই সময় থেকে ব্রাউজার এইচটিএমএল ডকুমেন্ট প্রতিক্রিয়ার প্রথম বাইটটি গ্রহণ করা পর্যন্ত সময়কাল।
- রিসোর্স লোড বিলম্ব
- TTFB এবং ব্রাউজার যখন LCP রিসোর্স লোড করা শুরু করে, তার মধ্যবর্তী সময়। যদি LCP এলিমেন্টটি রেন্ডার করার জন্য কোনো রিসোর্স লোডের প্রয়োজন না হয় (উদাহরণস্বরূপ, যদি এলিমেন্টটি একটি সিস্টেম ফন্ট দিয়ে রেন্ডার করা টেক্সট নোড হয়), তাহলে এই সময়টি ০ হয়।
- রিসোর্স লোডের সময়কাল
- এলসিপি রিসোর্সটি লোড হতে যে সময় লাগে। যদি এলসিপি এলিমেন্টটি রেন্ডার করার জন্য কোনো রিসোর্স লোডের প্রয়োজন না হয়, তবে এই সময় ০ হয়।
- এলিমেন্ট রেন্ডার বিলম্ব
- LCP রিসোর্স লোড হওয়া শেষ হওয়ার পর থেকে LCP এলিমেন্টটি সম্পূর্ণরূপে রেন্ডার হওয়া পর্যন্ত সময়।
প্রতিটি পৃষ্ঠার LCP মানকে এই চারটি উপভাগে বিভক্ত করা যায়। এদের মধ্যে কোনো উপরিপাতন বা ফাঁক নেই। সম্মিলিতভাবে, এগুলোই সম্পূর্ণ LCP সময়ের সমান।
LCP অপ্টিমাইজ করার সময়, এই উপাংশগুলোকে আলাদাভাবে অপ্টিমাইজ করার চেষ্টা করা সহায়ক। কিন্তু এটাও মনে রাখা জরুরি যে, আপনাকে সবগুলোই অপ্টিমাইজ করতে হবে। কিছু ক্ষেত্রে, একটি অংশে অপ্টিমাইজেশন প্রয়োগ করলে তা LCP-এর উন্নতি ঘটায় না, বরং সাশ্রয় হওয়া সময়কে অন্য অংশে স্থানান্তরিত করে।
উদাহরণস্বরূপ, আগের নেটওয়ার্ক ওয়াটারফলে, যদি আপনি আমাদের ইমেজকে আরও বেশি কম্প্রেস করে বা আরও উপযুক্ত কোনো ফরম্যাটে (যেমন AVIF বা WebP) পরিবর্তন করে এর ফাইলের আকার কমাতেন, তাহলে রিসোর্স লোডের সময়কাল কমে যেত, কিন্তু এটি আসলে LCP-এর কোনো উন্নতি করত না, কারণ সময়টা তখন এলিমেন্ট রেন্ডার ডিলে সাবপার্টে স্থানান্তরিত হতো:
এর কারণ হলো, এই পেজে জাভাস্ক্রিপ্ট কোড লোড হওয়া শেষ না হওয়া পর্যন্ত LCP এলিমেন্টটি লুকানো থাকে এবং লোড হওয়ার পর সবকিছু একবারে প্রকাশ হয়ে যায়।
এই উদাহরণটি এই বিষয়টি স্পষ্ট করতে সাহায্য করে যে, সর্বোত্তম LCP ফলাফল অর্জনের জন্য আপনাকে এই সমস্ত উপাংশগুলোকে অপ্টিমাইজ করতে হবে।
সর্বোত্তম উপাংশ সময়
LCP-এর প্রতিটি উপাংশকে অপ্টিমাইজ করার জন্য, একটি ভালোভাবে অপ্টিমাইজ করা পেজে এই উপাংশগুলোর আদর্শ বিভাজন কেমন হওয়া উচিত, তা বোঝা জরুরি।
চারটি উপাংশের মধ্যে দুটির নামে 'ডিলে' (delay) শব্দটি রয়েছে। এটি একটি ইঙ্গিত যে, আপনি এই সময়গুলোকে যতটা সম্ভব শূন্যের কাছাকাছি আনতে চাইবেন। অন্য দুটি অংশে নেটওয়ার্ক রিকোয়েস্ট জড়িত, যা স্বভাবতই সময় নেয়।
মনে রাখবেন যে এই সময়ের বিভাজনগুলো নির্দেশিকা মাত্র, কোনো কঠোর নিয়ম নয়। যদি আপনার পেজগুলোর LCP টাইম ধারাবাহিকভাবে ২.৫ সেকেন্ডের মধ্যে থাকে, তাহলে আপেক্ষিক অনুপাতগুলো কী তা তেমন গুরুত্বপূর্ণ নয়। কিন্তু যদি আপনি 'ডিলে' অংশগুলোর কোনো একটিতে অনেক অপ্রয়োজনীয় সময় ব্যয় করেন, তাহলে ধারাবাহিকভাবে ২.৫ সেকেন্ডের লক্ষ্যমাত্রা অর্জন করা খুব কঠিন হবে।
এলসিপি সময়ের বিভাজন সম্পর্কে ভাবার একটি ভালো উপায় হলো:
- LCP-এর সময়ের সিংহভাগ HTML ডকুমেন্ট এবং LCP সোর্স লোড করতে ব্যয় করা উচিত।
- LCP-এর আগে যেকোনো সময় যখন এই দুটি রিসোর্সের মধ্যে একটি লোড হচ্ছে না , তখন তা উন্নতির একটি সুযোগ ।
প্রতিটি অংশকে কীভাবে অপ্টিমাইজ করবেন
এখন যেহেতু আপনি বুঝতে পেরেছেন যে একটি ভালোভাবে অপ্টিমাইজ করা পেজে LCP-এর প্রতিটি উপভাগের সময় কীভাবে বিভক্ত হওয়া উচিত, আপনি আপনার নিজের পেজগুলো অপ্টিমাইজ করা শুরু করতে পারেন।
পরবর্তী চারটি বিভাগে প্রতিটি অংশকে কীভাবে অপ্টিমাইজ করা যায়, সে বিষয়ে সুপারিশ এবং সেরা অনুশীলনগুলো উপস্থাপন করা হবে। এগুলো ক্রমানুসারে সাজানো হয়েছে, এবং শুরু হয়েছে সেই অপ্টিমাইজেশনগুলো দিয়ে যেগুলোর প্রভাব সবচেয়ে বেশি পড়ার সম্ভাবনা রয়েছে।
১. রিসোর্স লোড বিলম্ব দূর করুন
এই ধাপের লক্ষ্য হলো LCP রিসোর্সটি যত তাড়াতাড়ি সম্ভব লোড হওয়া শুরু করে তা নিশ্চিত করা। যদিও তাত্ত্বিকভাবে একটি রিসোর্স TTFB-এর ঠিক পরেই লোড হওয়া শুরু করতে পারে , বাস্তবে ব্রাউজারগুলো রিসোর্স লোড করা শুরু করার আগে সবসময়ই কিছুটা বিলম্ব হয়।
একটি সাধারণ নিয়ম হলো, আপনার LCP রিসোর্সটি সেই পেজ দ্বারা লোড হওয়া প্রথম রিসোর্সের সাথে একই সময়ে লোড হওয়া শুরু করবে। অথবা, অন্যভাবে বলতে গেলে, যদি LCP রিসোর্সটি প্রথম রিসোর্সের পরে লোড হওয়া শুরু করে, তাহলে উন্নতির সুযোগ রয়েছে।
সাধারণভাবে বলতে গেলে, দুটি বিষয় একটি LCP রিসোর্স কত দ্রুত লোড হতে পারে তা প্রভাবিত করে:
- যখন সম্পদটি আবিষ্কৃত হয়।
- সম্পদটিকে কী অগ্রাধিকার দেওয়া হয়।
সম্পদটি আবিষ্কৃত হলে অপ্টিমাইজ করুন।
আপনার LCP রিসোর্সটি যাতে যত তাড়াতাড়ি সম্ভব লোড হওয়া শুরু করে, তা নিশ্চিত করার জন্য ব্রাউজারের প্রিলোড স্ক্যানার দ্বারা প্রাথমিক HTML ডকুমেন্ট রেসপন্সে রিসোর্সটি শনাক্তযোগ্য হওয়া অত্যন্ত গুরুত্বপূর্ণ। উদাহরণস্বরূপ, নিম্নলিখিত ক্ষেত্রে, ব্রাউজার HTML ডকুমেন্ট রেসপন্স স্ক্যান করে LCP রিসোর্সটি খুঁজে পেতে পারে:
- LCP এলিমেন্টটি একটি
<img>এলিমেন্ট, এবং এরsrcবাsrcsetঅ্যাট্রিবিউটগুলো প্রাথমিক HTML মার্কআপে উপস্থিত থাকে। - LCP এলিমেন্টের জন্য একটি CSS ব্যাকগ্রাউন্ড ইমেজ প্রয়োজন, কিন্তু সেই ইমেজটি HTML মার্কআপে
<link rel="preload">ব্যবহার করে (অথবা একটিLinkহেডার ব্যবহার করে) আগে থেকেই লোড করা থাকে। - LCP এলিমেন্টটি একটি টেক্সট নোড যা রেন্ডার করার জন্য একটি ওয়েব ফন্টের প্রয়োজন হয়, এবং ফন্টটি HTML মার্কআপে
<link rel="preload">ব্যবহার করে (অথবা একটিLinkহেডার ব্যবহার করে) লোড করা হয়।
এখানে এমন কিছু উদাহরণ দেওয়া হল যেখানে HTML ডকুমেন্ট প্রতিক্রিয়া স্ক্যান করে LCP রিসোর্সটি খুঁজে পাওয়া যায় না:
- LCP এলিমেন্টটি হলো একটি
<img>যা জাভাস্ক্রিপ্ট ব্যবহার করে পেজে গতিশীলভাবে যুক্ত করা হয়। - LCP এলিমেন্টটি একটি জাভাস্ক্রিপ্ট লাইব্রেরির সাহায্যে লেজিলি লোড করা হয়, যা এর
srcবাsrcsetঅ্যাট্রিবিউটগুলোকে (প্রায়শইdata-srcবাdata-srcsetহিসেবে) আড়াল করে রাখে। - LCP এলিমেন্টের জন্য একটি CSS ব্যাকগ্রাউন্ড ইমেজ প্রয়োজন।
এই প্রতিটি ক্ষেত্রে, ব্রাউজারকে LCP রিসোর্সটি খুঁজে বের করে লোড করা শুরু করার আগে স্ক্রিপ্টটি চালাতে বা স্টাইলশিটটি প্রয়োগ করতে হয়—যার জন্য সাধারণত নেটওয়ার্ক রিকোয়েস্ট শেষ হওয়ার অপেক্ষা করতে হয়। এটি কখনোই সর্বোত্তম পদ্ধতি নয়।
অপ্রয়োজনীয় রিসোর্স লোড বিলম্ব দূর করতে, আপনার LCP রিসোর্সটি HTML সোর্স থেকে সহজে খুঁজে পাওয়ার যোগ্য হওয়া উচিত। যেসব ক্ষেত্রে রিসোর্সটি শুধুমাত্র একটি বাহ্যিক CSS বা জাভাস্ক্রিপ্ট ফাইল থেকে রেফারেন্স করা হয়, সেক্ষেত্রে 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">
সম্পদকে দেওয়া অগ্রাধিকার অপ্টিমাইজ করুন।
এইচটিএমএল মার্কআপ থেকে এলসিপি রিসোর্সটি খুঁজে পাওয়া গেলেও, এটি প্রথম রিসোর্সের মতো দ্রুত লোড হওয়া শুরু নাও করতে পারে। এমনটা হতে পারে যদি ব্রাউজারের প্রিলোড স্ক্যানারের প্রায়োরিটি হিউরিস্টিকস রিসোর্সটিকে গুরুত্বপূর্ণ হিসেবে শনাক্ত করতে না পারে, অথবা যদি এটি নির্ধারণ করে যে অন্য রিসোর্সগুলো বেশি গুরুত্বপূর্ণ।
উদাহরণস্বরূপ, আপনি আপনার <img> এলিমেন্টে loading="lazy" সেট করে HTML ব্যবহার করে আপনার LCP ইমেজের লোড হওয়া বিলম্বিত করতে পারেন। লেজি লোডিং ব্যবহার করার অর্থ হলো, লেআউট যখন নিশ্চিত করবে যে ইমেজটি ভিউপোর্টে আছে, তার আগে রিসোর্সটি লোড হবে না এবং তাই এটি স্বাভাবিকের চেয়ে দেরিতে লোড হওয়া শুরু করতে পারে।
লেজি লোডিং ছাড়াও, ব্রাউজারগুলো প্রাথমিকভাবে ছবিগুলোকে সর্বোচ্চ অগ্রাধিকার দিয়ে লোড করে না, কারণ এগুলো রেন্ডার-ব্লকিং রিসোর্স নয়। যেসব রিসোর্সের উচ্চতর অগ্রাধিকার প্রয়োজন, সেগুলোর জন্য আপনি fetchpriority অ্যাট্রিবিউট ব্যবহার করে ব্রাউজারকে ইঙ্গিত দিতে পারেন যে কোন রিসোর্সগুলো সবচেয়ে গুরুত্বপূর্ণ।
<img fetchpriority="high" src="/path/to/hero-image.webp">
যদি আপনি মনে করেন যে একটি <img> এলিমেন্ট আপনার পেজের LCP এলিমেন্ট হতে পারে, তবে সেটিতে fetchpriority="high" সেট করা একটি ভালো উপায়। তবে, এক বা দুটি ছবির বেশিতে উচ্চ প্রায়োরিটি সেট করলে, LCP কমানোর ক্ষেত্রে প্রায়োরিটি সেটিং আর সহায়ক থাকে না।
আপনি এমন ছবিগুলির অগ্রাধিকারও কমাতে পারেন যেগুলি ডকুমেন্ট রেসপন্সের শুরুতে থাকতে পারে কিন্তু স্টাইলিংয়ের কারণে দৃশ্যমান হয় না, যেমন ক্যারোসেল স্লাইডের ছবি যা স্টার্টআপের সময় দেখা যায় না:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
কিছু রিসোর্সের অগ্রাধিকার কমিয়ে দিলে যে রিসোর্সগুলোর বেশি প্রয়োজন, সেগুলোতে আরও বেশি ব্যান্ডউইথ দেওয়া যেতে পারে—কিন্তু সতর্ক থাকুন। সবসময় DevTools-এ রিসোর্সের অগ্রাধিকার পরীক্ষা করুন এবং ল্যাব ও ফিল্ড টুল দিয়ে পরিবর্তনগুলো যাচাই করুন।
আপনার LCP রিসোর্সের অগ্রাধিকার এবং আবিষ্কারের সময় অপ্টিমাইজ করার পরে, আপনার নেটওয়ার্ক ওয়াটারফলটি দেখতে এইরকম হবে (যেখানে LCP রিসোর্সটি প্রথম রিসোর্সের সাথে একই সময়ে শুরু হবে):
২. এলিমেন্ট রেন্ডার বিলম্ব দূর করুন
এই ধাপের লক্ষ্য হলো, এলসিপি (LCP) এলিমেন্টটি যেন তার রিসোর্স লোড হওয়ার সাথে সাথেই রেন্ডার হতে পারে, তা যখনই ঘটুক না কেন।
রিসোর্স লোড হওয়া শেষ হওয়ার সাথে সাথেই LCP এলিমেন্টটি রেন্ডার হতে না পারার প্রধান কারণ হলো, যদি অন্য কোনো কারণে রেন্ডারিং ব্লক হয়ে থাকে:
-
<head>এর মধ্যে থাকা স্টাইলশীট বা সিনক্রোনাস স্ক্রিপ্টগুলো এখনও লোড হতে থাকায় পুরো পৃষ্ঠাটি রেন্ডার হওয়া আটকে আছে। - LCP রিসোর্সটি লোড হওয়া শেষ হয়েছে, কিন্তু LCP এলিমেন্টটি এখনও DOM-এ যুক্ত হয়নি (এটি কিছু জাভাস্ক্রিপ্ট কোড লোড হওয়ার জন্য অপেক্ষা করছে)।
- এলিমেন্টটি অন্য কোনো কোড দ্বারা লুকানো হচ্ছে, যেমন একটি A/B টেস্টিং লাইব্রেরি যা এখনও নির্ধারণ করছে যে ব্যবহারকারীকে কোন এক্সপেরিমেন্টে রাখা উচিত।
- দীর্ঘ কাজগুলোর কারণে প্রধান থ্রেডটি আটকে গেছে, এবং সেই দীর্ঘ কাজগুলো সম্পন্ন না হওয়া পর্যন্ত রেন্ডারিংয়ের কাজকে অপেক্ষা করতে হচ্ছে।
নিম্নলিখিত বিভাগগুলিতে অপ্রয়োজনীয় এলিমেন্ট রেন্ডার বিলম্বের সবচেয়ে সাধারণ কারণগুলি কীভাবে সমাধান করা যায় তা ব্যাখ্যা করা হয়েছে।
রেন্ডার-ব্লকিং স্টাইলশীটগুলি হ্রাস করুন বা ইনলাইন করুন
এইচটিএমএল মার্কআপ থেকে লোড করা স্টাইল শীটগুলো তাদের পরবর্তী সমস্ত কন্টেন্টের রেন্ডারিং আটকে দেয়, যা একটি ভালো দিক, কারণ আপনি সাধারণত স্টাইলবিহীন এইচটিএমএল রেন্ডার করতে চাইবেন না। তবে, যদি স্টাইল শীটটি এতটাই বড় হয় যে এটি লোড হতে এলসিপি রিসোর্সের চেয়ে উল্লেখযোগ্যভাবে বেশি সময় নেয়, তাহলে এটি এলসিপি এলিমেন্টটিকে রেন্ডার হতে বাধা দেবে—এমনকি এর রিসোর্স লোড হয়ে যাওয়ার পরেও, যেমনটি এই উদাহরণে দেখানো হয়েছে:
এটি ঠিক করতে আপনার কাছে নিম্নলিখিত বিকল্পগুলো রয়েছে:
- অতিরিক্ত নেটওয়ার্ক অনুরোধ এড়াতে স্টাইল শীটটি HTML-এর মধ্যে ইনলাইন করুন; অথবা,
- স্টাইল শীটের আকার কমান।
সাধারণত, আপনার স্টাইল শীট ইনলাইন করার পরামর্শ তখনই দেওয়া হয় যখন সেটির আকার ছোট হয়, কারণ HTML-এর ইনলাইন করা কন্টেন্ট পরবর্তী পেজ লোডের সময় ক্যাশিংয়ের সুবিধা নিতে পারে না। যদি কোনো স্টাইল শীট এতটাই বড় হয় যে সেটি লোড হতে LCP রিসোর্সের চেয়েও বেশি সময় নেয়, তাহলে সেটিকে ইনলাইন করার জন্য উপযুক্ত মনে হওয়ার সম্ভাবনা কম।
বেশিরভাগ ক্ষেত্রে, স্টাইল শীটটি যাতে LCP এলিমেন্টের রেন্ডারিংয়ে বাধা না দেয়, তা নিশ্চিত করার সেরা উপায় হলো এর আকার কমিয়ে LCP রিসোর্সের চেয়ে ছোট করে ফেলা। এতে করে এটি বেশিরভাগ ভিজিটের ক্ষেত্রে কোনো প্রতিবন্ধকতা সৃষ্টি করবে না।
স্টাইল শীটের আকার কমানোর জন্য কিছু পরামর্শ হলো:
- অব্যবহৃত CSS অপসারণ করুন : Chrome DevTools ব্যবহার করে এমন CSS রুলগুলো খুঁজুন যেগুলো ব্যবহৃত হচ্ছে না এবং অপসারণ (বা স্থগিত) করা যেতে পারে।
- অপ্রয়োজনীয় 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>সার্ভার সাইড রেন্ডারিং ব্যবহার করুন
সার্ভার-সাইড রেন্ডারিং (এসএসআর) হলো আপনার ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন লজিক সার্ভারে চালানো এবং এইচটিএমএল ডকুমেন্ট অনুরোধের জবাবে সম্পূর্ণ এইচটিএমএল মার্কআপ ব্যবহার করার প্রক্রিয়া।
LCP অপ্টিমাইজ করার দৃষ্টিকোণ থেকে, SSR-এর দুটি প্রধান সুবিধা রয়েছে:
- আপনার ইমেজ রিসোর্সগুলো HTML সোর্স থেকে খুঁজে পাওয়া যাবে (যেমনটি আগে ধাপ ১- এ আলোচনা করা হয়েছে)।
- আপনার পৃষ্ঠার বিষয়বস্তু রেন্ডার হওয়ার আগে তা শেষ হওয়ার জন্য অতিরিক্ত জাভাস্ক্রিপ্ট অনুরোধের প্রয়োজন হবে না।
এসএসআর-এর প্রধান অসুবিধা হলো এর জন্য অতিরিক্ত সার্ভার প্রসেসিং সময়ের প্রয়োজন হয়, যা আপনার টিটিএফবি (TTFB) কমিয়ে দিতে পারে। তবে এই আপসটি সাধারণত লাভজনক, কারণ সার্ভার প্রসেসিং সময় আপনার নিয়ন্ত্রণে থাকে, কিন্তু আপনার ব্যবহারকারীদের নেটওয়ার্ক এবং ডিভাইসের সক্ষমতা আপনার নিয়ন্ত্রণে থাকে না।
SSR-এর মতো একটি বিকল্পকে স্ট্যাটিক সাইট জেনারেশন (SSG) বা প্রি-রেন্ডারিং বলা হয়। এটি হলো অন-ডিমান্ডের পরিবর্তে একটি বিল্ড স্টেপে আপনার HTML পেজ তৈরি করার প্রক্রিয়া। যদি আপনার আর্কিটেকচারে প্রি-রেন্ডারিং সম্ভব হয়, তবে পারফরম্যান্সের জন্য এটি সাধারণত একটি ভালো বিকল্প।
দীর্ঘ কাজগুলোকে ছোট ছোট অংশে ভাগ করুন
আপনি আগের পরামর্শ অনুসরণ করলেও, এবং আপনার জাভাস্ক্রিপ্ট কোড রেন্ডার-ব্লকিং না হলেও বা আপনার এলিমেন্টগুলো রেন্ডার করার দায়িত্বে না থাকলেও, এটি LCP-কে বিলম্বিত করতে পারে।
এর সবচেয়ে সাধারণ কারণ হলো যখন পেজগুলো বড় জাভাস্ক্রিপ্ট ফাইল লোড করে, যেগুলোকে ব্রাউজারের প্রধান থ্রেডে পার্স ও এক্সিকিউট করতে হয়। এর মানে হলো, আপনার ইমেজ রিসোর্সটি সম্পূর্ণ ডাউনলোড হয়ে গেলেও, রেন্ডার হওয়ার আগে এটিকে একটি সম্পর্কহীন স্ক্রিপ্টের এক্সিকিউশন শেষ হওয়া পর্যন্ত অপেক্ষা করতে হতে পারে।
আজকাল সব ব্রাউজারই মেইন থ্রেডে ছবি রেন্ডার করে, যার মানে হলো, যা কিছুই মেইন থ্রেডকে ব্লক করে, তা অপ্রয়োজনীয় এলিমেন্ট রেন্ডার বিলম্বের কারণ হতে পারে।
৩. রিসোর্স লোডের সময়কাল হ্রাস করুন
এই ধাপের উদ্দেশ্য হলো নেটওয়ার্কের মাধ্যমে ব্যবহারকারীর ডিভাইসে রিসোর্সের বাইট স্থানান্তরের জন্য ব্যয়িত সময় কমানো। সাধারণত, এটি করার চারটি উপায় রয়েছে:
- রিসোর্সের আকার হ্রাস করুন।
- সম্পদের ভ্রমণপথের দূরত্ব কমান।
- নেটওয়ার্ক ব্যান্ডউইথের জন্য প্রতিযোগিতা হ্রাস করুন।
- নেটওয়ার্ক সময় সম্পূর্ণরূপে বাদ দিন।
সম্পদের আকার হ্রাস করুন
একটি পৃষ্ঠার LCP রিসোর্স (যদি থাকে) হয় একটি ছবি অথবা একটি ওয়েব ফন্ট। উভয়ের আকার কীভাবে কমানো যায়, সে সম্পর্কে নিম্নলিখিত নির্দেশিকাগুলিতে বিস্তারিত আলোচনা করা হয়েছে:
- সর্বোত্তম ছবির আকার পরিবেশন করুন
- আধুনিক ইমেজ ফরম্যাট ব্যবহার করুন
- ছবি সংকুচিত করুন
- ওয়েব ফন্টের আকার কমান
সম্পদের ভ্রমণ দূরত্ব হ্রাস করুন
রিসোর্সের আকার কমানোর পাশাপাশি, আপনার সার্ভারগুলোকে ব্যবহারকারীদের ভৌগোলিকভাবে যতটা সম্ভব কাছাকাছি এনে আপনি লোড টাইমও কমাতে পারেন। আর তা করার সেরা উপায় হলো কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) ব্যবহার করা।
বিশেষ করে ইমেজ সিডিএনগুলো খুবই সহায়ক, কারণ এগুলো শুধু রিসোর্সের যাতায়াতের দূরত্বই কমায় না, বরং সাধারণত রিসোর্সের আকারও হ্রাস করে—আপনার জন্য পূর্বের আকার-হ্রাসের সমস্ত সুপারিশগুলো স্বয়ংক্রিয়ভাবে বাস্তবায়ন করে।
নেটওয়ার্ক ব্যান্ডউইথের জন্য প্রতিযোগিতা হ্রাস করুন
এমনকি আপনি আপনার রিসোর্সের আকার এবং এর অতিক্রম করার দূরত্ব কমিয়ে আনলেও, একই সময়ে আরও অনেক রিসোর্স লোড করার কারণে একটি রিসোর্স লোড হতে অনেক সময় লাগতে পারে। এই সমস্যাটি নেটওয়ার্ক কনটেনশন নামে পরিচিত।
যদি আপনি আপনার LCP রিসোর্সকে একটি উচ্চ fetchpriority দিয়ে থাকেন এবং যত তাড়াতাড়ি সম্ভব এটি লোড করা শুরু করেন, তাহলে ব্রাউজার নিম্ন-প্রায়োরিটির রিসোর্সগুলোকে এর সাথে প্রতিযোগিতা করা থেকে বিরত রাখতে যথাসাধ্য চেষ্টা করবে। তবে, যদি আপনি উচ্চ fetchpriority সহ অনেক রিসোর্স লোড করেন, অথবা সাধারণভাবে অনেক রিসোর্স লোড করেন, তাহলে এটি LCP রিসোর্সটি কত দ্রুত লোড হবে তার উপর প্রভাব ফেলতে পারে।
নেটওয়ার্কের সময় সম্পূর্ণরূপে বাদ দিন।
রিসোর্স লোডের সময়কাল কমানোর সবচেয়ে ভালো উপায় হলো প্রক্রিয়াটি থেকে নেটওয়ার্ককে পুরোপুরি বাদ দেওয়া। আপনি যদি একটি কার্যকর ক্যাশ-কন্ট্রোল পলিসির মাধ্যমে আপনার রিসোর্সগুলো পরিবেশন করেন, তাহলে যে ভিজিটররা দ্বিতীয়বার সেই রিসোর্সগুলোর জন্য অনুরোধ করবে, তারা সেগুলো ক্যাশ থেকে পাবে—যার ফলে রিসোর্স লোডের সময়কাল কার্যত শূন্যে নেমে আসবে!
আপনার LCP রিসোর্সটি যদি একটি ওয়েব ফন্ট হয়, তবে ওয়েব ফন্টের আকার কমানোর পাশাপাশি, ওয়েব ফন্ট রিসোর্স লোড হওয়ার সময় রেন্ডারিং ব্লক করার প্রয়োজন আছে কিনা, সেটাও আপনার বিবেচনা করা উচিত। আপনি যদি font-display মান auto বা block ছাড়া অন্য কিছু সেট করেন, তাহলে লোড হওয়ার সময় টেক্সট সবসময় দৃশ্যমান থাকবে এবং অতিরিক্ত কোনো নেটওয়ার্ক অনুরোধের জন্য LCP ব্লক হবে না।
অবশেষে, যদি আপনার LCP রিসোর্সটি ছোট হয়, তবে রিসোর্সগুলোকে একটি ডেটা ইউআরএল (data URL) হিসেবে ইনলাইন করা যুক্তিযুক্ত হতে পারে, যা অতিরিক্ত নেটওয়ার্ক রিকোয়েস্টও দূর করবে। তবে, ডেটা ইউআরএল ব্যবহারের কিছু সীমাবদ্ধতা রয়েছে, কারণ সেক্ষেত্রে রিসোর্সগুলো ক্যাশ করা যায় না এবং কিছু ক্ষেত্রে অতিরিক্ত ডিকোড খরচের কারণে রেন্ডার হতে বেশি দেরি হতে পারে।
৪. প্রথম বাইটের সময় হ্রাস করুন
এই ধাপের লক্ষ্য হলো যত দ্রুত সম্ভব প্রাথমিক HTML সরবরাহ করা। এই ধাপটি শেষে তালিকাভুক্ত করা হয়েছে কারণ এটি এমন একটি ধাপ যার উপর ডেভেলপারদের নিয়ন্ত্রণ সবচেয়ে কম থাকে। তবে, এটি সবচেয়ে গুরুত্বপূর্ণ ধাপগুলোর মধ্যে একটি, কারণ এটি এর পরবর্তী প্রতিটি ধাপকে সরাসরি প্রভাবিত করে। ব্যাকএন্ড কন্টেন্টের প্রথম বাইটটি সরবরাহ না করা পর্যন্ত ফ্রন্টএন্ডে কিছুই হতে পারে না, তাই আপনার TTFB (টাইম টু ফার্স্ট ব্যাক) এর গতি বাড়ানোর জন্য আপনি যা কিছুই করুন না কেন, তা অন্যান্য সমস্ত লোড মেট্রিককেও উন্নত করবে।
অন্যথায় দ্রুতগতির কোনো সাইটের TTFB (টাইম টু ফেস) ধীর হওয়ার একটি সাধারণ কারণ হলো, ভিজিটরদের একাধিক রিডাইরেক্টের মাধ্যমে সাইটে আসা, যেমন বিজ্ঞাপন বা সংক্ষিপ্ত লিঙ্ক থেকে। একজন ভিজিটরকে যতগুলো রিডাইরেক্টের জন্য অপেক্ষা করতে হয়, তার সংখ্যা সর্বদা কমিয়ে আনুন।
এর আরেকটি সাধারণ কারণ হলো, যখন কোনো সিডিএন এজ সার্ভার থেকে ক্যাশ করা কন্টেন্ট ব্যবহার করা যায় না এবং সমস্ত অনুরোধকে সরাসরি অরিজিন সার্ভারে ফেরত পাঠাতে হয়। এমনটা হতে পারে যদি ভিজিটররা অ্যানালিটিক্সের জন্য স্বতন্ত্র ইউআরএল প্যারামিটার ব্যবহার করেন—এমনকি যদি সেগুলোর ফলে ভিন্ন কোনো পেজ না-ও দেখা যায়।
TTFB অপ্টিমাইজ করার বিষয়ে নির্দিষ্ট নির্দেশনার জন্য, অপ্টিমাইজ TTFB গাইডটি দেখুন।
জাভাস্ক্রিপ্টে LCP বিভাজন নিরীক্ষণ করুন
পূর্বে আলোচিত LCP-এর সমস্ত উপাংশের টাইমিং সংক্রান্ত তথ্য জাভাস্ক্রিপ্টে নিম্নলিখিত পারফরম্যান্স API-গুলোর সমন্বয়ের মাধ্যমে আপনার কাছে উপলব্ধ হবে:
অনেক RUM প্রোডাক্ট ইতিমধ্যেই এই API-গুলো ব্যবহার করে সাবপার্টগুলো গণনা করে। web-vitals লাইব্রেরিটিও তার অ্যাট্রিবিউশন বিল্ডে এই LCP সাবপার্ট টাইমিংগুলো অন্তর্ভুক্ত করে এবং জাভাস্ক্রিপ্টে এগুলো কীভাবে গণনা করতে হয়, তার জন্য এর কোডটি রেফারেন্স হিসেবে ব্যবহার করা যেতে পারে।
পূর্ববর্তী স্ক্রিনশটগুলিতে দেখানো অনুযায়ী Chrome DevTools এবং Lighthouse-ও এই উপাংশগুলি পরিমাপ করে, ফলে ঐ টুলগুলি ব্যবহার করার সময় জাভাস্ক্রিপ্টে এগুলি ম্যানুয়ালি গণনা করার প্রয়োজন হয় না।
সারসংক্ষেপ
এলসিপি একটি জটিল বিষয়, এবং এর সময় বিভিন্ন কারণের দ্বারা প্রভাবিত হতে পারে। কিন্তু যদি আপনি বিবেচনা করেন যে এলসিপি অপ্টিমাইজ করার মূল উদ্দেশ্য হলো এলসিপি রিসোর্সের লোড অপ্টিমাইজ করা, তবে এটি বিষয়টিকে উল্লেখযোগ্যভাবে সহজ করে তুলতে পারে।
উচ্চস্তরে, LCP অপ্টিমাইজ করার প্রক্রিয়াকে চারটি ধাপে সংক্ষিপ্ত করা যায়:
- এলসিপি রিসোর্সটি যাতে যত তাড়াতাড়ি সম্ভব লোড হওয়া শুরু করে, তা নিশ্চিত করুন।
- নিশ্চিত করুন যেন LCP এলিমেন্টটি তার রিসোর্স লোড হওয়া শেষ হওয়ার সাথে সাথেই রেন্ডার হতে পারে।
- গুণমান বজায় রেখে LCP রিসোর্সের লোড টাইম যতটা সম্ভব কমিয়ে আনুন।
- প্রাথমিক HTML ডকুমেন্টটি যত দ্রুত সম্ভব সরবরাহ করুন।
যদি আপনি আপনার পেজগুলোতে এই ধাপগুলো অনুসরণ করতে পারেন, তাহলে আপনি নিশ্চিত থাকতে পারেন যে আপনি আপনার ব্যবহারকারীদের একটি সর্বোত্তম লোডিং অভিজ্ঞতা প্রদান করছেন, এবং এর প্রতিফলন আপনার বাস্তব LCP স্কোরেও দেখতে পাবেন।