Web Performance

আতঙ্কিত না হয়ে Lighthouse রিপোর্ট পড়ার উপায়

আপনার পারফরম্যান্স অডিটে কোন বিষয়গুলো সত্যিই গুরুত্বপূর্ণ—আর কোনগুলো নিরাপদে উপেক্ষা করা যায়—তা বোঝার একটি ব্যবহারিক গাইড

The Wux Webtools Team The Wux Webtools Team 2 মিনিট পড়া এআই-সহায়ক, মানব-পর্যালোচিত
Stylized lighthouse beam illuminating a clear path through fog, representing clarity in performance diagnostics
সুচিপত্র
  1. প্রথম নিয়ম: আপনার স্কোর আপনার সাইট নয়
  2. প্রথমে কী পড়বেন: Core Web Vitals
  3. Opportunities বনাম Diagnostics: পার্থক্য জানুন
  4. যেসব অডিট সাধারণত উপেক্ষা করতে পারেন
  5. সবকিছু লাল হলে কী করবেন
  6. Lab data বনাম field data: বাস্তবতা যাচাই
  7. কখন Lighthouse আবার চালাবেন
  8. Lighthouse ফলাফলের ভিত্তিতে কাজ করতে সহায়ক টুলগুলো
  9. মূল বিষয়গুলো
  10. FAQ
  11. Sources

প্রথম নিয়ম: আপনার স্কোর আপনার সাইট নয়

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

সম্ভবত তা নয়। Lighthouse একটি ডায়াগনস্টিক টুল, রিপোর্ট কার্ড নয়। স্কোরটি হলো ল্যাব-পরিস্থিতিতে চালানো একটি সিনথেটিক বেঞ্চমার্ক—প্রায়ই থ্রটল করা কানেকশনে, 2017 সালের একটি মাঝারি মানের ফোন অনুকরণ করে। এটি বলে ওই নির্দিষ্ট পরিস্থিতিতে আপনার সাইট কীভাবে কাজ করে, বাস্তব জগতে ব্যবহারকারীরা কীভাবে অভিজ্ঞতা পান তা নয়।

এটি গুরুত্বপূর্ণ, কারণ অধিকাংশ দল স্কোরে আটকে যায় এবং প্রেক্ষাপট হারিয়ে ফেলে। রিয়েল-টাইম ডেটাসহ জটিল web app-এর জন্য 65 স্কোর ঠিকই হতে পারে। আবার ভুল বিষয়গুলো অপ্টিমাইজ করা হলে 95 স্কোরের সাইটও খারাপ অভিজ্ঞতা দিতে পারে। স্কোর হলো অনুসন্ধানের সূচনা, সফলতার মেট্রিক নয়।

প্রথমে কী পড়বেন: Core Web Vitals

সামগ্রিক পারফরম্যান্স স্কোর এড়িয়ে যান। নিচে Metrics বিভাগে যান এবং তিনটি সংখ্যা দেখুন: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), এবং Interaction to Next Paint (INP)। এগুলোই Core Web Vitals, এবং Google র‍্যাঙ্কিং সংকেত হিসেবে যে পারফরম্যান্স মেট্রিক ব্যবহার করে সেগুলোই।

  • LCP মাপে সবচেয়ে বড় দৃশ্যমান এলিমেন্ট রেন্ডার হতে কত সময় লাগে। লক্ষ্য: 2.5 সেকেন্ডের কম। আপনি যদি 4 সেকেন্ডের বেশি হন, ব্যবহারকারীরা অর্থবহ কনটেন্ট দেখতে খুব বেশি অপেক্ষা করছেন।
  • CLS ভিজ্যুয়াল স্থিতিশীলতা মাপে—লোড হওয়ার সময় পেজ কতটা লাফায়। লক্ষ্য: 0.1-এর কম। আপনি যদি 0.25-এর বেশি হন, বাটন সরে যাওয়ার কারণে ব্যবহারকারীরা ভুল জায়গায় ক্লিক করছেন।
  • INP রেসপনসিভনেস মাপে—ক্লিক, ট্যাপ এবং কীস্ট্রোকের প্রতিক্রিয়া পেজ কত দ্রুত দেয়। লক্ষ্য: 200ms-এর কম। আপনি যদি 500ms-এর বেশি হন, সাইটটি ধীর মনে হয়।

এই তিনটি মেট্রিক বাস্তব ব্যবহারকারীর বিরক্তির সঙ্গে সম্পর্কিত। অন্য কিছু নিয়ে চিন্তা করার আগে এগুলো ঠিক করুন।

Opportunities বনাম Diagnostics: পার্থক্য জানুন

Lighthouse তার ফলাফল দুই ভাগে ভাগ করে: Opportunities এবং Diagnostics। Opportunities আনুমানিক সময় সাশ্রয়ের ভিত্তিতে র‍্যাঙ্ক করা হয়। Diagnostics হলো অতিরিক্ত প্রেক্ষাপট—যেগুলো সমস্যা হতে পারে, আবার নাও হতে পারে।

Opportunities দিয়ে শুরু করুন। Lighthouse যদি বলে "Eliminate render-blocking resources" 1.2 সেকেন্ড বাঁচাতে পারে, সেটি একটি স্পষ্ট লাভ। যদি বলে "Reduce unused JavaScript" 0.1 সেকেন্ড বাঁচাতে পারে, সেটির জন্য বড় রিফ্যাক্টর সম্ভবত প্রয়োজন নেই।

Diagnostics একটু জটিল। "Avoid an excessive DOM size" শুনতে খারাপ লাগে, কিন্তু আপনার CLS যদি ভালো হয় এবং INP দ্রুত হয়, তাহলে বড় DOM হয়তো কাউকে ক্ষতি করছে না। Diagnostics হলো সূত্র, নির্দেশ নয়। যেগুলো আপনার বাস্তব মেট্রিকের সঙ্গে মেলে, সেগুলো তদন্ত করুন।

যেসব অডিট সাধারণত উপেক্ষা করতে পারেন

কিছু Lighthouse সতর্কবার্তা পুরনো বা অতিরিক্ত আক্রমণাত্মক। যেগুলো সবচেয়ে বেশি অপ্রয়োজনীয় আতঙ্ক তৈরি করে, সেগুলো হলো:

  • "Does not use passive listeners to improve scrolling performance" — এটি একটি মাইক্রো-অপ্টিমাইজেশন, যা খুব কম ক্ষেত্রেই বড় পরিবর্তন আনে। স্ক্রলিং ঝাঁকুনি দিচ্ছে এমন প্রমাণ না থাকলে, এটি এড়িয়ে যান।
  • "Image elements do not have explicit width and height" — CLS-এর জন্য এটি গুরুত্বপূর্ণ, তবে শুধুমাত্র তখনই যখন ছবিগুলো layout shift ঘটাচ্ছে। আপনার CLS যদি ইতিমধ্যেই ভালো হয়, অডিটের খাতিরে রিফ্যাক্টর করবেন না।
  • "Serve images in next-gen formats" — হ্যাঁ, WebP এবং AVIF ছোট। কিন্তু আপনার ছবি যদি ইতিমধ্যেই অপ্টিমাইজ করা থাকে এবং LCP দ্রুত হয়, এটি ভালো হলে ভালো, সংকট নয়।
  • "Avoid enormous network payloads" — Lighthouse 1.6 MB-এর বেশি যেকোনো কিছু ফ্ল্যাগ করে। কিন্তু দ্রুত লোড হওয়া 2 MB পেজ, রেন্ডারিং আটকে দেওয়া 500 KB পেজের চেয়ে ভালো। শুধু মোট বাইট নয়, বাইটগুলো কীভাবে ডেলিভার হচ্ছে তাতে মনোযোগ দিন।

সবকিছু লাল হলে কী করবেন

আপনার Lighthouse স্কোর যদি 50-এর নিচে হয় এবং বেশিরভাগ অডিট ব্যর্থ হয়, তাহলে সম্ভবত তিনটি মূল কারণের একটি নিয়ে কাজ করছেন:

  1. অপ্টিমাইজ না করা ফন্ট। বেশিরভাগ সাইটে Web fonts এখনো সবচেয়ে সহজ পারফরম্যান্স জয়। আপনি কি দুইটি ব্যবহার করেও ছয়টি font weight লোড করছেন, অথবা WOFF2-এর বদলে WOFF ফাইল পাঠাচ্ছেন—তা পরীক্ষা করুন।
  2. Render-blocking CSS এবং JavaScript। আপনার First Contentful Paint (FCP) যদি 3 সেকেন্ডের বেশি হয়, কিছু একটা ব্রাউজারকে পেইন্ট করা থেকে আটকে দিচ্ছে। <head>-এ বড় CSS ফাইল বা synchronous script খুঁজুন।
  3. অতিরিক্ত বড় ছবি। আপনার LCP এলিমেন্ট যদি ছবি হয় এবং সেটি 4 MB হয়, সমস্যাটি সেখানেই। এটি কমপ্রেস করুন, below-the-fold ছবিগুলো lazy-load করুন, এবং responsive image syntax ব্যবহার করুন।

এগুলোর একটি ঠিক করুন এবং Lighthouse আবার চালান। প্রায়ই 20-30 পয়েন্টের লাফ দেখতে পাবেন। এরপর পরেরটি ধরুন।

Lab data বনাম field data: বাস্তবতা যাচাই

Lighthouse ল্যাবে চলে। এটি ধীর কানেকশন এবং ধীর ডিভাইস অনুকরণ করে, কিন্তু বাস্তব ব্যবহারকারীর আচরণ অনুকরণ করতে পারে না—মানুষ কীভাবে স্ক্রল করে, কী ক্লিক করে, তারা অস্থির Wi-Fi-এ আছে কি না।

বাস্তবতা যাচাই করতে, আপনার Lighthouse ফলাফল field data-র সঙ্গে তুলনা করুন Chrome User Experience Report (CrUX) থেকে। গত 28 দিনে বাস্তব Chrome ব্যবহারকারীরা আপনার সাইট কীভাবে অভিজ্ঞতা করেছেন CrUX তা দেখায়। Lighthouse যদি বলে আপনার LCP 4 সেকেন্ড কিন্তু CrUX দেখায় 2 সেকেন্ড, CrUX-কে বিশ্বাস করুন। দুটোই খারাপ হলে, আপনার সত্যিই সমস্যা আছে।

PageSpeed Insights-এ (Lighthouse-এর web version) অথবা Google Search Console-এর "Core Web Vitals"-এর অধীনে CrUX ডেটা পাবেন। অমিল থাকলে কারণ খুঁজুন। হয়তো আপনার বাস্তব ব্যবহারকারীরা দ্রুত নেটওয়ার্কে আছেন। হয়তো Lighthouse অপ্টিমাইজ না করা dev build পরীক্ষা করছে।

কখন Lighthouse আবার চালাবেন

Lighthouse-এ শোরগোল থাকে। একই পেজে পরপর তিনবার চালালেও তিনটি আলাদা স্কোর পাবেন। কারণ পারফরম্যান্স পরিবর্তনশীল—background process, network jitter, এবং browser heuristics সবই ফলাফল প্রভাবিত করে।

স্থিতিশীল baseline পেতে, সব extensions disabled রেখে incognito mode-এ Lighthouse চালান, অথবা আরও ধারাবাহিক ফলাফলের জন্য --preset=desktop flag সহ CLI ব্যবহার করুন। তিনবার চালিয়ে স্কোরের গড় নিন। যদি বড় ওঠানামা দেখেন (10 পয়েন্টের বেশি), অন্য কিছু ভুল আছে—হয়তো server ধীর, অথবা প্রতিবার পেজ ভিন্ন resource লোড করছে।

প্রতিটি গুরুত্বপূর্ণ পরিবর্তনের পরে Lighthouse আবার চালান। নতুন font strategy deploy করেছেন? LCP পরীক্ষা করুন। ছবি lazy-load করেছেন? CLS পরীক্ষা করুন। third-party script যোগ করেছেন? INP পরীক্ষা করুন। পারফরম্যান্স একবারের সমাধান নয়; এটি এমন একটি বাজেট যা আপনাকে রক্ষা করতে হয়।

Lighthouse ফলাফলের ভিত্তিতে কাজ করতে সহায়ক টুলগুলো

Lighthouse আপনাকে বলে কী ধীর। এটি সবসময় বলে না কীভাবে ঠিক করবেন। তার জন্য অতিরিক্ত টুল দরকার:

  • WebPageTest পেজ কীভাবে লোড হয় তার filmstrip view দেয়, frame by frame। LCP এবং CLS সমস্যা নির্ণয়ের জন্য অপরিহার্য।
  • Chrome DevTools Performance panel ঠিক কোন JavaScript main thread আটকে দিচ্ছে তা দেখায়। খারাপ INP স্কোরের উৎস খুঁজতে এটি ব্যবহার করুন।
  • Image compressor tools ব্রাউজারেই সরাসরি ছবি অপ্টিমাইজ করতে দেয়, যা third-party service-এ upload করার চেয়ে দ্রুত এবং বেশি private। Client-side image processing গোপনীয়তার জন্য লাভজনক, কারণ আপনার ছবিগুলো কখনো আপনার মেশিন ছাড়ে না।

Lighthouse হলো সূচনা বিন্দু। এই টুলগুলো কাজ শেষ করতে সাহায্য করে।

মূল বিষয়গুলো

  • আপনার Lighthouse স্কোর একটি lab benchmark, বাস্তব ব্যবহারকারীর অভিজ্ঞতার মাপ নয়। আতঙ্কিত হওয়ার আগে CrUX-এর field data-র সঙ্গে তুলনা করুন।
  • প্রথমে Core Web Vitals (LCP, CLS, INP)-এ মনোযোগ দিন। এগুলোই ব্যবহারকারীর বিরক্তি এবং SEO প্রভাবের সঙ্গে সম্পর্কিত মেট্রিক।
  • আনুমানিক সময় সাশ্রয়ের ভিত্তিতে Opportunities অগ্রাধিকার দিন। আপনার বাস্তব পারফরম্যান্স সমস্যার সঙ্গে না মেললে Diagnostics উপেক্ষা করুন।
  • কিছু অডিট—যেমন passive listeners বা next-gen image formats—মাইক্রো-অপ্টিমাইজেশন। আগে বড় বিষয়গুলো ঠিক করুন।
  • Lighthouse তিনবার চালিয়ে ফলাফলের গড় নিন। পারফরম্যান্স পরিবর্তনশীল, এবং একবারের রান বিভ্রান্তিকর হতে পারে।

FAQ

Q: Lighthouse চালালে প্রতিবার আমার স্কোর বদলে যায় কেন?
A: Lighthouse পরিবর্তনশীল পরিস্থিতিতে পারফরম্যান্স মাপে—network speed, CPU load, এবং browser heuristics সবই ফলাফল প্রভাবিত করে। আরও স্থিতিশীল baseline-এর জন্য incognito mode-এ তিনবার চালিয়ে স্কোরের গড় নিন।

Q: আগে mobile নাকি desktop অপ্টিমাইজ করব?
A: Mobile। Lighthouse ডিফল্টভাবে mobile simulation ব্যবহার করে, কারণ বেশিরভাগ web traffic mobile এবং mobile device তুলনামূলক ধীর। আপনার mobile score ভালো হলে, desktop score সাধারণত ঠিকই থাকবে।

Q: আমার Lighthouse স্কোর 95, কিন্তু সাইট এখনো ধীর লাগে। সমস্যা কোথায়?
A: Lighthouse page load মাপে, load-এর পর interactivity নয়। আপনার INP স্কোর দেখুন এবং ব্যবহারকারীরা click বা scroll করলে কী ঘটে তা profile করতে Chrome DevTools Performance panel ব্যবহার করুন। আপনার JavaScript সমস্যা থাকতে পারে যা Lighthouse ধরতে পারে না।

Q: নিখুঁত 100 স্কোর কি দরকার?
A: না। 90+ স্কোর চমৎকার। 100-এর পেছনে ছোটা প্রায়ই এমন জিনিস অপ্টিমাইজ করা বোঝায় যা ব্যবহারকারীর কাছে গুরুত্বপূর্ণ নয়। বাস্তব মেট্রিক—LCP, CLS, INP—এ মনোযোগ দিন এবং স্কোর উপেক্ষা করুন।

Q: অনেক third-party script ব্যবহার করলে Lighthouse-কে কি বিশ্বাস করতে পারি?
A: Lighthouse third-party script-গুলোকে সমস্যা হিসেবে ফ্ল্যাগ করবে, কিন্তু প্রয়োজনীয় এবং অপ্রয়োজনীয়গুলোর পার্থক্য সবসময় করতে পারে না। সবচেয়ে খারাপ offender শনাক্ত করতে "Avoid enormous network payloads" এবং "Reduce JavaScript execution time" অডিট ব্যবহার করুন, তারপর সেগুলো রাখা মূল্যবান কি না সিদ্ধান্ত নিন।

Sources

Flowchart for reading a Lighthouse report: ignore score first, check LCP CLS INP, review Opportunities by time savings, then use Diagnostics as context
InfographicHow to triage a Lighthouse report — A simple order of operations turns a scary report into a short prioritized checklist
Two-column comparison of Lighthouse items to prioritize versus warnings that can often wait, with examples and numeric thresholds
InfographicLighthouse signals: fix now vs usually ignore — Not every red warning deserves engineering time
Side-by-side diagram comparing Lighthouse lab data and CrUX field data, including 28-day real-user window and example LCP mismatch
InfographicLab data vs field data at a glance — Use lab data to diagnose and field data to confirm what users really feel

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Lighthouse চালালে প্রতিবার আমার স্কোর বদলে যায় কেন?
Lighthouse পরিবর্তনশীল পরিস্থিতিতে পারফরম্যান্স মাপে—network speed, CPU load, এবং browser heuristics সবই ফলাফল প্রভাবিত করে। আরও স্থিতিশীল baseline-এর জন্য incognito mode-এ তিনবার চালিয়ে স্কোরের গড় নিন।
আগে mobile নাকি desktop অপ্টিমাইজ করব?
Mobile। Lighthouse ডিফল্টভাবে mobile simulation ব্যবহার করে, কারণ বেশিরভাগ web traffic mobile এবং mobile device তুলনামূলক ধীর। আপনার mobile score ভালো হলে, desktop score সাধারণত ঠিকই থাকবে।
আমার Lighthouse স্কোর 95, কিন্তু সাইট এখনো ধীর লাগে। সমস্যা কোথায়?
Lighthouse page load মাপে, load-এর পর interactivity নয়। আপনার INP স্কোর দেখুন এবং ব্যবহারকারীরা click বা scroll করলে কী ঘটে তা profile করতে Chrome DevTools Performance panel ব্যবহার করুন। আপনার JavaScript সমস্যা থাকতে পারে যা Lighthouse ধরতে পারে না।
নিখুঁত 100 স্কোর কি দরকার?
না। 90+ স্কোর চমৎকার। 100-এর পেছনে ছোটা প্রায়ই এমন জিনিস অপ্টিমাইজ করা বোঝায় যা ব্যবহারকারীর কাছে গুরুত্বপূর্ণ নয়। বাস্তব মেট্রিক—LCP, CLS, INP—এ মনোযোগ দিন এবং স্কোর উপেক্ষা করুন।
অনেক third-party script ব্যবহার করলে Lighthouse-কে কি বিশ্বাস করতে পারি?
Lighthouse third-party script-গুলোকে সমস্যা হিসেবে ফ্ল্যাগ করবে, কিন্তু প্রয়োজনীয় এবং অপ্রয়োজনীয়গুলোর পার্থক্য সবসময় করতে পারে না। সবচেয়ে খারাপ offender শনাক্ত করতে "Avoid enormous network payloads" এবং "Reduce JavaScript execution time" অডিট ব্যবহার করুন, তারপর সেগুলো রাখা মূল্যবান কি না সিদ্ধান্ত নিন।

স्रोत ও আরও পড়া

  1. Lighthouse performance scoring — Google Developers
  2. Core Web Vitals — web.dev
  3. Chrome User Experience Report — Google Developers
  4. WebPageTest Documentation — WebPageTest.org
লেখক সম্পর্কে
The Wux Webtools Team

শেষ আপডেট:

আরও পড়ুন

Web Performance

আপনার Time to First Byte কেন ধীর এবং এ বিষয়ে কী করবেন

ধীর TTFB সাধারণত ধীর routing, অনুপস্থিত cache, অতিরিক্ত চাপগ্রস্ত servers, অথবা ব্যয়বহুল backend work বোঝায়। কীভাবে এটি নির্ণয় ও ঠিক করবেন, তা এখানে।

5 মিনিট পড়া