লাইটহাউস স্কোর একটি আর্কিটেকচারাল সিগন্যাল, অপ্টিমাইজেশন চেকলিস্ট নয়

দীর্ঘ সময় ধরে, আমি ধরে নিয়েছিলাম যে উচ্চ Lighthouse স্কোর মূলত টিউনিং এর ফলাফল। ছবি সংকোচন করা, স্ক্রিপ্ট বিলম্বিত করা, লেআউট শিফট ঠিক করা, থিম সামঞ্জস্য করা, প্লাগইন অদলবদল করা, এবং প্রতিবার নতুন সতর্কতা দেখা দিলে চক্রটি পুনরাবৃত্তি করা।

সময়ের সাথে সাথে, সেই ধারণাটি আমি বাস্তবে যা দেখছিলাম তার সাথে মিলছিল না।

যে সাইটগুলি ধারাবাহিকভাবে ভাল স্কোর করেছিল সেগুলি সবচেয়ে বেশি অপটিমাইজেশন প্রচেষ্টার সাথে ছিল না। সেগুলি ছিল যেখানে ব্রাউজারকে কেবল কম কাজ করতে হয়েছিল।

সেই মুহূর্তে, Lighthouse একটি অপটিমাইজেশন টুল হিসাবে অনুভব করা বন্ধ করে এবং স্থাপত্য পছন্দের জন্য একটি ডায়াগনস্টিক সংকেত হিসাবে অনুভব করা শুরু করে।

Lighthouse আসলে কী পরিমাপ করে

Lighthouse ফ্রেমওয়ার্ক বা টুল মূল্যায়ন করে না। এটি ফলাফল মূল্যায়ন করে।

কত দ্রুত অর্থপূর্ণ কন্টেন্ট প্রদর্শিত হয়।

কতটা JavaScript প্রধান থ্রেড ব্লক করে।

লোডের সময় লেআউট কতটা স্থিতিশীল থাকে।

ডকুমেন্ট কাঠামো কতটা অ্যাক্সেসযোগ্য এবং ক্রলযোগ্য।

এই ফলাফলগুলি স্ট্যাকে অনেক আগে নেওয়া সিদ্ধান্তের ডাউনস্ট্রিম প্রভাব। বিশেষত, তারা প্রতিফলিত করে যে রানটাইমে ব্রাউজারে কতটা গণনা বিলম্বিত করা হয়।

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

প্রাথমিক বৈচিত্র্যের উৎস হিসাবে JavaScript

আমি যে অডিটগুলি চালিয়েছি এবং যে প্রকল্পগুলিতে আমি কাজ করেছি তার মধ্যে, JavaScript এক্সিকিউশন হল Lighthouse রিগ্রেশনের সবচেয়ে সাধারণ উৎস।

এটি কোডের মান কম হওয়ার কারণে নয়। এটি কারণ পেজ লোডের সময় JavaScript একটি সিঙ্গেল-থ্রেডেড এক্সিকিউশন এনভায়রনমেন্টের জন্য প্রতিযোগিতা করে।

ফ্রেমওয়ার্ক রানটাইম, হাইড্রেশন লজিক, ডিপেনডেন্সি গ্রাফ, এবং স্টেট ইনিশিয়ালাইজেশন সবকিছু পেজ ইন্টারঅ্যাক্টিভ হওয়ার আগে সময় গ্রাস করে। এমনকি ছোট ইন্টারঅ্যাক্টিভ ফিচারগুলিও প্রায়শই অসামঞ্জস্যপূর্ণভাবে বড় বান্ডেল প্রয়োজন করে।

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

স্ট্যাটিক আউটপুট অনিশ্চয়তা হ্রাস করে

প্রি-রেন্ডার করা আউটপুট পারফরম্যান্স সমীকরণ থেকে বেশ কয়েকটি ভেরিয়েবল সরিয়ে দেয়।

রিকোয়েস্ট টাইমে কোন সার্ভার-সাইড রেন্ডারিং খরচ নেই।

কন্টেন্ট প্রদর্শিত হওয়ার জন্য কোন ক্লায়েন্ট-সাইড বুটস্ট্র্যাপ প্রয়োজন নেই।

ব্রাউজার পূর্বাভাসযোগ্য, সম্পূর্ণ HTML পায়।

Lighthouse এর দৃষ্টিকোণ থেকে, এটি লক্ষ্যবস্তু অপটিমাইজেশন কাজের প্রয়োজন ছাড়াই TTFB, LCP, এবং CLS এর মতো মেট্রিক্স উন্নত করে। স্ট্যাটিক জেনারেশন নিখুঁত স্কোরের গ্যারান্টি দেয় না, তবে এটি উল্লেখযোগ্যভাবে ব্যর্থতার মোডের পরিসীমা সংকুচিত করে।

একটি কেস স্টাডি

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

কৌতূহলের বশে, আমি একটি ভিন্ন পদ্ধতি চেষ্টা করেছি যা প্রথমে স্ট্যাটিক HTML ধরে নিয়েছে এবং JavaScript কে একটি ব্যতিক্রম হিসাবে বিবেচনা করেছে। আমি এই পরীক্ষার জন্য Astro বেছে নিয়েছিলাম, কারণ এর ডিফল্ট সীমাবদ্ধতা আমি যে প্রশ্নগুলি পরীক্ষা করতে চেয়েছিলাম তার সাথে সামঞ্জস্যপূর্ণ ছিল।

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

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

ট্রেড-অফ গুরুত্বপূর্ণ

এই পদ্ধতি সর্বজনীনভাবে ভাল নয়।

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

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

কেন Lighthouse স্কোর স্থিতিশীল বা ভঙ্গুর হতে থাকে

Lighthouse যা প্রকাশ করে তা প্রচেষ্টা নয়, বরং এনট্রপি।

যে সিস্টেমগুলি রানটাইম কম্পিউটেশনের উপর নির্ভর করে সেগুলি ফিচার যুক্ত হওয়ার সাথে সাথে জটিলতা সংগ্রহ করে। যে সিস্টেমগুলি বিল্ড টাইমে আরও কাজ করে সেগুলি ডিফল্টভাবে সেই জটিলতাকে সীমাবদ্ধ করে।

এই পার্থক্য ব্যাখ্যা করে কেন কিছু সাইটে ক্রমাগত পারফরম্যান্স কাজের প্রয়োজন হয় যখন অন্যরা ন্যূনতম হস্তক্ষেপের সাথে স্থিতিশীল থাকে।

সমাপনী চিন্তা

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

টুল আসে এবং যায়, কিন্তু অন্তর্নিহিত নীতি একই থাকে। যখন পারফরম্যান্স একটি লক্ষ্যের পরিবর্তে একটি ডিফল্ট সীমাবদ্ধতা হয়, তখন Lighthouse এমন কিছু হওয়া বন্ধ করে যা আপনি তাড়া করেন এবং এমন কিছু হয়ে ওঠে যা আপনি পর্যবেক্ষণ করেন।

এই পরিবর্তন সঠিক ফ্রেমওয়ার্ক নির্বাচন করার বিষয়ে কম এবং জটিলতা কোথায় বিদ্যমান থাকার অনুমতি দেওয়া হয় তা নির্বাচন করার বিষয়ে বেশি।