लाइटहाउस स्कोर एक आर्किटेक्चरल सिग्नल हैं, ऑप्टिमाइज़ेशन चेकलिस्ट नहीं

लंबे समय तक, मैंने मान लिया था कि उच्च 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 कुछ ऐसा होना बंद हो जाता है जिसका आप पीछा करते हैं और कुछ ऐसा हो जाता है जिसे आप देखते हैं।

यह बदलाव सही फ्रेमवर्क चुनने के बारे में कम है और इस बारे में अधिक है कि जटिलता को कहां मौजूद रहने की अनुमति दी जाती है।