Lighthouse रिपोर्ट को बिना घबराए कैसे पढ़ें

पहला नियम: आपका स्कोर आपकी साइट नहीं है

पहली बार Lighthouse रिपोर्ट खोलते ही आपके सामने संख्याओं, रंगों से कोड किए गए बॉक्सों और उन चीज़ों की चेतावनियों की दीवार आ जाती है जिनके बारे में आपने कभी सुना भी नहीं होता। स्वाभाविक प्रतिक्रिया घबराहट होती है। स्कोर लाल है। सत्रह audits असफल हैं। क्या साइट ज़रूर टूटी हुई है?

शायद नहीं। Lighthouse एक diagnostic tool है, रिपोर्ट कार्ड नहीं। स्कोर lab conditions में चलाया गया एक synthetic benchmark है—अक्सर throttled connection पर, 2017 के mid-range phone का simulation करते हुए। यह बताता है कि उस खास scenario में आपकी साइट कैसे perform करती है, न कि वास्तविक users उसे बाहर की दुनिया में कैसे अनुभव करते हैं।

यह इसलिए मायने रखता है क्योंकि अधिकांश टीमें स्कोर पर अटक जाती हैं और context खो देती हैं। real-time data वाले complex web app के लिए 65 का स्कोर ठीक हो सकता है। 95 का स्कोर भी खराब experience दे सकता है अगर गलत चीज़ें optimize की गई हों। स्कोर investigation का शुरुआती बिंदु है, success metric नहीं।

पहले क्या पढ़ें: Core Web Vitals

कुल performance score को छोड़ दें। नीचे Metrics section तक scroll करें और तीन numbers देखें: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), और Interaction to Next Paint (INP)। ये Core Web Vitals हैं, और ये ही वे performance metrics हैं जिन्हें Google ranking signal के रूप में इस्तेमाल करता है।

• LCP मापता है कि सबसे बड़ा visible element render होने में कितना समय लेता है। लक्ष्य: 2.5 seconds से कम। अगर आप 4 seconds से ऊपर हैं, तो users meaningful content देखने के लिए बहुत लंबा इंतज़ार कर रहे हैं।
• CLS visual stability मापता है—page load होते समय कितना उछलता-कूदता है। लक्ष्य: 0.1 से कम। अगर आप 0.25 से ऊपर हैं, तो buttons खिसकने की वजह से users गलती से गलत चीज़ पर click कर रहे हैं।
• INP responsiveness मापता है—page clicks, taps और keystrokes पर कितनी जल्दी प्रतिक्रिया देता है। लक्ष्य: 200ms से कम। अगर आप 500ms से ऊपर हैं, तो site सुस्त महसूस होती है।

ये तीन metrics वास्तविक user frustration से correlate करते हैं। किसी और चीज़ की चिंता करने से पहले इन्हें ठीक करें।

Opportunities बनाम diagnostics: अंतर जानें

Lighthouse अपनी findings को दो categories में बाँटता है: Opportunities और Diagnostics। Opportunities को estimated time savings के आधार पर rank किया जाता है। Diagnostics अतिरिक्त context हैं—ऐसी चीज़ें जो problems हो सकती हैं, या नहीं भी हो सकतीं।

Opportunities से शुरू करें। अगर Lighthouse कहता है कि "Eliminate render-blocking resources" 1.2 seconds बचा सकता है, तो यह एक ठोस जीत है। अगर वह कहता है कि "Reduce unused JavaScript" 0.1 seconds बचा सकता है, तो शायद refactor करने लायक नहीं है।

Diagnostics ज्यादा पेचीदा हैं। "Avoid an excessive DOM size" बुरा सुनाई देता है, लेकिन अगर आपका CLS ठीक है और आपका INP तेज़ है, तो बड़ा DOM शायद किसी को नुकसान नहीं पहुँचा रहा। Diagnostics संकेत हैं, आदेश नहीं। उन्हीं की जाँच करें जो आपके actual metrics से मेल खाते हैं।

वे audits जिन्हें आप आम तौर पर नज़रअंदाज़ कर सकते हैं

कुछ Lighthouse warnings पुरानी बची हुई चीज़ें हैं या बहुत aggressive हैं। ये वे हैं जो सबसे अधिक अनावश्यक घबराहट पैदा करती हैं:

• "Does not use passive listeners to improve scrolling performance" — यह एक micro-optimization है जो शायद ही कभी बड़ा असर डालती है। जब तक आपके पास janky scrolling का evidence न हो, इसे छोड़ दें।
• "Image elements do not have explicit width and height" — यह CLS के लिए मायने रखता है, लेकिन केवल तब जब images layout shifts करा रही हों। अगर आपका CLS पहले से अच्छा है, तो audit के लिए refactor न करें।
• "Serve images in next-gen formats" — हाँ, WebP और AVIF छोटे होते हैं। लेकिन अगर आपकी images पहले से optimized हैं और आपका LCP तेज़ है, तो यह nice-to-have है, संकट नहीं।
• "Avoid enormous network payloads" — Lighthouse 1.6 MB से ऊपर किसी भी चीज़ को flag करता है। लेकिन तेज़ी से load होने वाला 2 MB page उस 500 KB page से बेहतर है जो rendering को block करता है। सिर्फ कुल bytes पर नहीं, बल्कि bytes कैसे deliver होते हैं, इस पर ध्यान दें।

जब सब कुछ लाल हो तो क्या करें

अगर आपका Lighthouse score 50 से नीचे है और अधिकतर audits fail हो रहे हैं, तो आप शायद तीन root causes में से किसी एक से जूझ रहे हैं:

1. Unoptimized fonts। Web fonts अभी भी अधिकांश sites पर सबसे आसान performance win हैं। देखें कि क्या आप दो का उपयोग करते हुए भी छह font weights load कर रहे हैं, या WOFF2 के बजाय WOFF files भेज रहे हैं।
2. Render-blocking CSS और JavaScript। अगर आपका First Contentful Paint (FCP) 3 seconds से अधिक है, तो कुछ browser को paint करने से रोक रहा है। <head> में बड़ी CSS files या synchronous scripts देखें।
3. Oversized images। अगर आपका LCP element एक image है और वह 4 MB की है, तो समस्या वही है। उसे compress करें, below-the-fold images को lazy-load करें, और responsive image syntax का उपयोग करें।

इनमें से एक को ठीक करें और Lighthouse फिर से चलाएँ। अक्सर आपको 20-30 points की छलांग दिखेगी। फिर अगली समस्या पर काम करें।

Lab data बनाम field data: वास्तविकता की जाँच

Lighthouse lab में चलता है। यह slow connection और slow device simulate करता है, लेकिन वास्तविक user behavior—लोग कैसे scroll करते हैं, क्या click करते हैं, क्या वे flaky Wi-Fi पर हैं—simulate नहीं कर सकता।

वास्तविकता की जाँच के लिए, अपने Lighthouse results की तुलना Chrome User Experience Report (CrUX) के field data से करें। CrUX दिखाता है कि पिछले 28 दिनों में वास्तविक Chrome users ने आपकी site को कैसे अनुभव किया। अगर Lighthouse कहता है कि आपका LCP 4 seconds है लेकिन CrUX 2 seconds दिखाता है, तो CrUX पर भरोसा करें। अगर दोनों खराब हैं, तो आपके पास वास्तविक समस्या है।

आप CrUX data PageSpeed Insights (Lighthouse का web version) में या Google Search Console में "Core Web Vitals" के तहत पा सकते हैं। अगर mismatch है, तो कारण जाँचें। हो सकता है आपके real users तेज़ networks पर हों। हो सकता है Lighthouse किसी unoptimized dev build को test कर रहा हो।

Lighthouse फिर से कब चलाएँ

Lighthouse noisy है। इसे लगातार तीन बार चलाएँ और आपको तीन अलग-अलग scores मिलेंगे, उसी page पर भी। ऐसा इसलिए है क्योंकि performance variable होती है—background processes, network jitter और browser heuristics सभी result को प्रभावित करते हैं।

stable baseline पाने के लिए, Lighthouse को सभी extensions disabled करके incognito mode में चलाएँ, या अधिक consistent results के लिए CLI को --preset=desktop flag के साथ उपयोग करें। इसे तीन बार चलाएँ और scores का average लें। अगर आपको बहुत बड़े उतार-चढ़ाव दिख रहे हैं (10 points से अधिक), तो कुछ और गलत है—शायद server slow है, या page हर बार अलग resources load कर रहा है।

हर significant change के बाद Lighthouse फिर से चलाएँ। नई font strategy deploy की? LCP check करें। Images lazy-load कीं? CLS check करें। Third-party script जोड़ी? INP check करें। Performance एक बार का fix नहीं है; यह एक budget है जिसकी आप रक्षा करते हैं।

वे tools जो Lighthouse findings पर कार्रवाई करने में मदद करते हैं

Lighthouse आपको बताता है कि क्या slow है। यह हमेशा नहीं बताता कि उसे कैसे ठीक करें। इसके लिए आपको additional tools चाहिए:

• WebPageTest आपको page के load होने का filmstrip view देता है, frame by frame। LCP और CLS issues diagnose करने के लिए essential।
• Chrome DevTools Performance panel आपको ठीक-ठीक दिखाता है कि कौन-सा JavaScript main thread को block कर रहा है। खराब INP score का source खोजने के लिए इसका उपयोग करें।
• Image compressor tools आपको browser में सीधे images optimize करने देते हैं, जो third-party service पर upload करने से तेज़ और अधिक private है। Client-side image processing privacy के लिए अच्छा है क्योंकि आपकी images आपकी machine से कभी बाहर नहीं जातीं।

Lighthouse शुरुआती बिंदु है। ये tools काम पूरा करने में मदद करते हैं।

मुख्य बातें

• आपका Lighthouse score lab benchmark है, real-world user experience का माप नहीं। घबराने से पहले इसे CrUX के field data से compare करें।
• पहले Core Web Vitals (LCP, CLS, INP) पर ध्यान दें। यही वे metrics हैं जो user frustration और SEO impact से correlate करते हैं।
• Opportunities को estimated time savings के आधार पर prioritize करें। उन Diagnostics को ignore करें जो आपकी actual performance problems से मेल नहीं खाते।
• कुछ audits—जैसे passive listeners या next-gen image formats—micro-optimizations हैं। पहले बड़ी चीज़ें ठीक करें।
• Lighthouse तीन बार चलाएँ और results का average लें। Performance variable है, और एक single run misleading हो सकता है।

FAQ

Q: मेरा Lighthouse score हर बार चलाने पर क्यों बदलता है?
A: Lighthouse variable conditions में performance मापता है—network speed, CPU load और browser heuristics सभी result को प्रभावित करते हैं। अधिक stable baseline के लिए इसे incognito mode में तीन बार चलाएँ और scores का average लें।

Q: क्या मुझे पहले mobile या desktop के लिए optimize करना चाहिए?
A: Mobile। Lighthouse default रूप से mobile simulation करता है क्योंकि अधिकांश web traffic mobile है, और mobile devices धीमे होते हैं। अगर आपका mobile score अच्छा है, तो आपका desktop score आम तौर पर ठीक होगा।

Q: मेरा Lighthouse score 95 है, लेकिन मेरी site अभी भी slow महसूस होती है। क्या गलत है?
A: Lighthouse page load मापता है, load के बाद की interactivity नहीं। अपना INP score check करें और users के click या scroll करने पर क्या होता है, उसे profile करने के लिए Chrome DevTools Performance panel का उपयोग करें। आपके पास JavaScript problem हो सकती है जिसे Lighthouse नहीं पकड़ता।

Q: क्या मुझे perfect 100 score चाहिए?
A: नहीं। 90+ का score उत्कृष्ट है। 100 के पीछे भागने का मतलब अक्सर उन चीज़ों को optimize करना होता है जो users के लिए मायने नहीं रखतीं। वास्तविक metrics—LCP, CLS, INP—पर ध्यान दें और score को ignore करें।

Q: अगर मैं बहुत सारे third-party scripts उपयोग कर रहा हूँ, तो क्या मैं Lighthouse पर भरोसा कर सकता हूँ?
A: Lighthouse third-party scripts को problem के रूप में flag करेगा, लेकिन यह हमेशा necessary और unnecessary ones में अंतर नहीं कर सकता। सबसे खराब offenders पहचानने के लिए "Avoid enormous network payloads" और "Reduce JavaScript execution time" audits का उपयोग करें, फिर तय करें कि उन्हें रखना worthwhile है या नहीं।

Sources

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org