Core Web Vitals: बड़ी साइट्स Sub-1.5s LCP तक कैसे पहुँचती हैं

2022 में, एक hosting comparison साइट मेरे inbox में आई। बड़ा कैटलॉग, लगभग 4,000 पेज, गहरी तरह से nested category structure, affiliate links हर जगह बिखरे हुए, hero images जो छोटे महाद्वीपों के आकार के हैं। उनका Google Search Console एक भयानक दृश्य था। LCP mobile पर 4.2 सेकंड पर बैठा था। INP (तब अभी भी FID कहलाता था) सीमांत पर। क्लाइंट ने पहले से ही एक पिछली एजेंसी के साथ £6,000 खर्च कर चुका था जिसने एक CDN फेंक दिया था और काम पूरा होने का दिखावा किया था।

वह प्रोजेक्ट ही वह है जिसने अंततः Seahawk पर high-page-count साइट्स, directory साइट्स, listing platforms, HostList-style builds जैसी hosting review properties के लिए performance के बारे में हमारे सोचने का तरीका तय किया। जो आता है वह वास्तविक playbook है।

---

बड़ी साइट्स LCP को अलग तरीके से क्यों तोड़ती हैं

छोटी साइट्स की साधारण समस्याएँ हैं। एक हीरो इमेज, एक थीम, एक प्लगइन बहुत कुछ कर रहा है। इन तीनों को ठीक करें और आप 2 सेकंड से नीचे हैं।

बड़ी साइट्स? बिल्कुल अलग animal। LCP element इस बात पर निर्भर करता है कि आप किस पेज पर हैं। एक category archive के पास एक product detail page से अलग LCP candidate होता है, जिसके पास homepage से अलग candidate होता है। अधिकांश performance tools एक single score रिपोर्ट करते हैं। वह संख्या एक झूठ है, यह pages के एक wildly varied set का average है, और homepage को ठीक करते हुए नीचे के 3,800 listing pages को ignore करना बिल्कुल वही तरीका है जिससे agencies को बुरी reputation मिलती है।

Google से Core Web Vitals documentation स्पष्ट है कि field data, जो real users experience करते हैं, Chrome User Experience Report में measure किया गया, वह है जो Google वास्तव में ranking signals के लिए use करता है। PageSpeed Insights से Lab data directional है, definitive नहीं। मैंने ऐसी साइट्स देखी हैं जो PSI पर 95 score करती हैं फिर भी CrUX data में Poor LCP होता है। दोनों को confuse न करें।

लिस्टिंग साइटों पर तीन असली कसूरवार

हर बड़ी साइट जिसका मैंने ऑडिट किया है (और इस बिंदु तक मैं सैकड़ों से गुजर चुका हूँ), LCP की विफलता लगभग हर बार तीन मूल कारणों तक पहुंचती है:

Unoptimised hero या card images, अक्सर full resolution पर serve किए गए, गलत format, कोई fetchpriority hint नहीं
Render-blocking third-party scripts, affiliate trackers, ad networks, comparison widgets browser के paint करने से पहले load हो रहे हैं
TTFB LCP budget को inflate करता है, slow server response 600-900ms खा रहा है इससे पहले कि page load होना शुरू भी हो

वह तीसरा underestimate किया गया है। अगर आपका TTFB 700ms है, तो आप पहले से ही अपना "Good" LCP budget का लगभग आधा spend कर चुके हैं browser ने एक भी pixel render करने से पहले। Hosting choice और server-side caching DevOps concerns नहीं हैं, वे SEO concerns हैं।

---

TTFB से शुरू करो: यह पहले एक होस्टिंग और कैशिंग की समस्या है

HostList-type project जिसका मैंने ऊपर उल्लेख किया? पहली चीज़ जो मैंने की वह WebPageTest को पाँच different geographic locations से run करना था। TTFB consistently 680-820ms था। साइट Virginia में एक shared host पर थी। उनका अधिकांश organic traffic UK और Germany से आ रहा था।

उन्हें एक managed WordPress host पर move किया जिसके edge nodes London और Frankfurt में हैं। Full-page caching configure की, listing pages पर cache lifetime 12 घंटे की रखी (data उतनी बार change ही नहीं होता था)। TTFB repeat requests पर 120-180ms तक गिर गया, first-hit cache misses पर 280-350ms। इस एक ही change ने image को छुए बिना LCP से लगभग 500ms निकाल दिया।

होस्टिंग साइड पर कुछ चीज़ें हैं जो मैं हमेशा check करता हूँ:

क्या full-page caching actually काम कर रही है? X-Cache response header को check करो। अगर हर एक request पर MISS दिख रहा है, तो तुम्हारी caching layer काम नहीं कर रही।
क्या origin server भौगोलिक रूप से तुम्हारे primary audience के करीब है? यह सुनने में obvious लगता है। तुम्हें हैरानी होगी कि यह कितनी बार गलत होता है।
क्या keep-alive enable है? कुछ सस्ते hosts अभी भी persistent connections को disable करते हैं। 2024 में यह पागलपन है, लेकिन होता है।
क्या HTTP/2 या HTTP/3 active है? curl -I --http2 https://yourdomain.com run करो और response में protocol को check करो।

TTFB को sort करने तक image optimisation को touch मत करो। एक slow server पर images optimize करना उस घर को paint करने जैसा है जो आग में जल रहा है।

---

LCP Image Problem (और क्यों `fetchpriority` सब कुछ बदल देता है)

सही है। Images। एक listing site पर card-grid layouts के साथ, LCP element लगभग हमेशा पहली above-the-fold card image है, या hero banner। Browser को इसे discover करना होता है, fetch करना होता है, decode करना होता है, और render करना होता है। इन steps में से हर एक को delay किया जा सकता है।

यहाँ बताता हूँ कि हमने HostList प्रोजेक्ट पर क्या किया, क्रम में:

सभी कार्ड इमेजेस को WebP में कन्वर्ट किया, Imagify के बल्क कन्वर्जन का उपयोग करते हुए। एवरेज फाइल साइज 58% गिर गया बिना किसी दृश्य क्वालिटी लॉस के उन कार्ड थंबनेल साइज़ों पर जो हम यूज कर रहे थे (280×180px डिस्प्ले, रेटिना के लिए 2x पर सर्व किया गया)।
पहली कार्ड इमेज में `fetchpriority="high"` जोड़ा। यह एक ही बदलाव WebPageTest में मापे गए LCP से करीब 200ms काट दिया। ब्राउजर इसे नियमित लेजी इमेज की तरह ट्रीट करना बंद कर देता है और इसे प्रीलोड स्कैनर में तुरंत क्यू करता है।
पहली दो पंक्तियों की कार्ड इमेजेस से `loading="lazy"` हटाया। लेजी लोडिंग below-fold इमेजेस के लिए शानदार है। पहली दृश्य पंक्ति पर, यह आपको नुकसान पहुंचाता है। यह ब्राउजर को बताता है कि इमेज को फेच न करें जब तक वह व्यूपोर्ट के पास न हो, जो वह पहले से ही है।
होमपेज टेम्पलेट पर विशेष रूप से `<head>` में हीरो इमेज के लिए एक `<link rel="preload">` टैग जोड़ा।

उस क्रम से होमपेज LCP को लैब शर्तों में 3.1s से 1.4s तक लाया गया। फील्ड डेटा लगभग 28 दिनों में आया (यह CrUX डेटा को स्केल पर बदलाव दिखाने में लगभग इतना समय लगता है)।

रेस्पॉन्सिव इमेज पर एक नोट

अगर आप मोबाइल डिवाइस को समान 1400px-चौड़ी इमेज सर्व कर रहे हैं, तो आप बैंडविड्थ बर्बाद कर रहे हैं और डिकोड टाइम जोड़ रहे हैं। srcset को सही तरीके से यूज करें। मुझे पता है कि यह 2016 की बातचीत जैसा लगता है लेकिन मैं अभी भी इसे शायद 40% साइट्स पर देखता हूं जो Seahawk से गुजरती हैं। WordPress का wp_get_attachment_image() फंक्शन srcset को ऑटोमैटिकली जेनरेट करता है, लेकिन सिर्फ अगर इमेज को सफिशिएंट रेजोल्यूशन पर अपलोड किया गया हो और थीम ने इसे add_filter('max_srcset_width', ...) से सप्रेस न किया हो।

---

रेंडर-ब्लॉकिंग स्क्रिप्ट्स: एफिलिएट साइट का टैक्स

होस्टिंग कम्पेरिजन साइट्स और लिस्टिंग प्लेटफॉर्म्स एफिलिएट रेवेन्यू पर जीते हैं। मतलब थर्ड-पार्टी ट्रैकिंग स्क्रिप्ट्स। Commission Junction, Impact, Awin, कस्टम पिक्सल ट्रैकर्स, ये सब जमा होते हैं। मैंने एक सिंगल लिस्टिंग साइट पर 14 अलग थर्ड-पार्टी स्क्रिप्ट ऑरिजन्स गिने हैं। हर एक एक अलग DNS लुकअप, TCP कनेक्शन, और TLS हैंडशेक है उससे पहले कि उस स्क्रिप्ट का एक सिंगल बाइट रिसीव हो।

फिक्स स्क्रिप्ट्स को हटाना नहीं है। आप कर नहीं सकते, रेवेन्यू इन पर डिपेंड करता है। फिक्स सीक्वेंसिंग है।

कोई भी थर्ड-पार्टी स्क्रिप्ट कभी भी LCP एलिमेंट के शुरुआती रेंडर को ब्लॉक नहीं करनी चाहिए। बस।

व्यावहारिक तौर पर, इसका मतलब है:

सभी एफिलिएट/एनालिटिक्स स्क्रिप्ट्स को <head> में नहीं, DOMContentLoaded इवेंट के बाद लोड करें।
जिन स्क्रिप्ट्स को आप कंट्रोल करते हैं, उन सभी पर async या defer एट्रिब्यूट्स लगाएँ।
स्क्रिप्ट्स के लिए जिन्हें आप कंट्रोल नहीं करते (tag मैनेजर्स द्वारा इंजेक्ट किए गए), Google Tag Manager को खुद defer के साथ लोड करें, हां, यह ज्यादातर एफिलिएट ट्रैकिंग यूज केसेस के लिए सेफ है, और GTM की खुद की डॉक्यूमेंटेशन इस अप्रोच को स्वीकार करती है।
Asset CleanUp Pro या WP Rocket की script delay फीचर जैसे script manager का उपयोग करें ताकि नॉन-एसेंशियल थर्ड पार्टीज को यूजर इंटरेक्शन के बाद तक defer किया जा सके (पहली स्क्रॉल या पहला क्लिक)।

HostList रीबिल्ड पर, थर्ड-पार्टी स्क्रिप्ट्स को defer करने से Total Blocking Time 1,840ms से घटकर 290ms हो गया। TBT सीधे तौर पर Core Web Vital नहीं है, लेकिन यह INP के साथ मजबूती से कोरिलेट करता है, जो है।

---

फ़ॉन्ट लोडिंग: वह साइलेंट LCP किलर जिसके बारे में कोई बात नहीं करता

कस्टम फ़ॉन्ट एक विशिष्ट विफलता मोड का कारण बनते हैं। ब्राउज़र आपका लेआउट रेंडर करता है, LCP टेक्स्ट एलिमेंट तक पहुँचता है (कभी-कभी LCP एक इमेज नहीं, बल्कि एक हेडिंग होता है), और फिर इसे पेंट करने से पहले फ़ॉन्ट फ़ाइल की प्रतीक्षा करता है। इसे Flash of Invisible Text कहते हैं, और यह LCP को 200ms से लेकर एक सेकंड से अधिक तक विलंबित कर सकता है, फ़ॉन्ट फ़ाइल साइज़ और सर्वर निकटता के आधार पर।

दो चीज़ें इसे ठीक करती हैं:

अपने @font-face डिक्लेरेशन में `font-display: swap` लगाएं, ब्राउजर एक फॉलबैक फॉन्ट में तुरंत रेंडर करता है और कस्टम फॉन्ट लोड होने पर स्वैप करता है। LCP कैंडिडेट टाइम पर पेंट हो जाता है।
अपने फ़ॉन्ट को सेल्फ-होस्ट करें। Google Fonts एक क्रॉस-ऑरिजिन रिक्वेस्ट जोड़ता है। google-webfonts-helper टूल के साथ सेल्फ-होस्टिंग आपको अपने डोमेन से फ़ॉन्ट परोसने देती है, जो उस अतिरिक्त कनेक्शन को कम कर देता है।

मैंने उस टूल का उपयोग करके लगभग 45 मिनट में एक बड़ी डायरेक्टरी साइट को Google Fonts से कनवर्ट किया। LCP में 180ms की सुधार हुई। अकेले यह बदलाव नहीं लाता, लेकिन बाकी सब कुछ के साथ मिलकर, ये मार्जिन जमा होते हैं।

---

फील्ड में वास्तव में मायने रखने वाली चीज़ों को मापना

CrUX डेटा ही सच है। लेकिन यह केवल महीने में एक बार अपडेट होता है और केवल पर्याप्त ट्रैफिक वाले URLs के लिए। हज़ारों पेजेस वाली बड़ी साइटों के लिए, आपको कुछ ज़्यादा विस्तृत की ज़रूरत है।

मैं PageSpeed Insights API का उपयोग करता हूं जो URLs के एक रिप्रेजेंटेटिव सैंपल पर स्क्रिप्टेड है, आमतौर पर ट्रैफिक से टॉप 100 पेजेस, 50 कैटेगरी-लेवल पेजेस, और 20 "थिन" डीप-कैटलॉग पेजेस। इसे मंथली रन करने से एक प्रॉपर परफॉर्मेंस डिस्ट्रिब्यूशन मिलता है, एक सिंगल-पॉइंट स्कोर नहीं।

Lighthouse CI में (जिसे हम उन क्लाइंट्स के लिए CI/CD पाइपलाइन में चलाते हैं जिनके पास dev साइकिल है), हम इसके विरुद्ध दावा करते हैं:

LCP ≤ 2.5s lab में (रूढ़िवादी लक्ष्य, क्योंकि field आमतौर पर lab से 10-15% पीछे रहता है)
TBT ≤ 300ms
CLS ≤ 0.1

लेकिन ईमानदारी से, HostList-टाइप बिल्ड के लिए जहां गोल sub-1.5s LCP है, लैब टार्गेट्स को ज्यादा टाइट होना चाहिए। हमने इन प्रोजेक्ट्स के लिए Lighthouse CI में LCP ≤ 1.8s सेट किया है, जो आमतौर पर 1.3-1.5s प्रोड्यूस करता है फील्ड डेटा में एक बार CrUX कैच अप हो जाता है।

---

यह सब एक साथ रखना: HostList परिणाम

ऊपर दिए गए सभी काम करने के बाद — hosting migration, full-page caching, image format conversion, LCP candidates पर fetchpriority, above-fold rows से lazy-load हटाना, script deferral, और font self-hosting — नंबर कुछ इस तरह दिख रहे थे:

TTFB: 780ms → 160ms (माध्य, UK विज़िटर)
LCP (lab, mobile): 4.2s → 1.4s
LCP (field, CrUX, 75th percentile): 3.8s → 1.6s (migration के 60 दिन बाद मापा गया)
TBT: 1,840ms → 290ms
CLS: पहले से ही 0.03 पर ठीक था, अपरिवर्तित

हर साइट को 2.8 सेकंड का सुधार नहीं मिलेगा। लेकिन लगभग हर बड़ी listing site जिसपर मैंने काम किया है, उसमें ये सभी समस्याएं एक साथ थीं, जिसका मतलब है कि लाभ स्टैक होते हैं। एक चीज़ ठीक करो और तुम्हें 300ms मिलते हैं। सब कुछ ठीक करो और तुम्हें 2.5 सेकंड मिलते हैं।

---

FAQ

क्या होस्टिंग सच में LCP के लिए इतना महत्वपूर्ण है?

हां, शुरुआत में संभवतः किसी और चीज़ से अधिक। अगर आपका TTFB 500ms से ऊपर है, तो image optimisation से आप "Good" LCP तक नहीं पहुंच सकते। TTFB ही वह नींव है जिस पर बाकी सब कुछ खड़ा है। पहले इसे 200ms के नीचे लाएं, फिर बाकी चीजों के बारे में सोचें।

क्या मुझे होस्ट माइग्रेट करने की जगह CDN का इस्तेमाल करना चाहिए?

CDN स्टैटिक एसेट डिलीवरी में मदद करता है और अगर सही तरीके से कॉन्फ़िगर किया जाए तो कैश किए गए फुल-पेज HTML के लिए TTFB को कम कर सकता है। लेकिन कई CDN सेटअप सिर्फ एसेट को कैश करते हैं, पूरे HTML रेस्पांस को नहीं। चेक करें कि आपका CDN वास्तव में कैश किया गया HTML सर्व कर रहा है या सिर्फ इमेजेज को ऑफलोड कर रहा है। अगर यह दूसरा विकल्प है, तो एक बेहतर ऑरिजिन होस्ट LCP के लिए ज्यादा फायदा करेगा।

क्या `fetchpriority="high"` अब व्यापक रूप से सपोर्ट किया जाता है?

2024 तक, हां, यह Chrome, Edge, और Safari (Safari 17.2 से) में सपोर्ट है। Firefox support Firefox 132 में आया। जो ब्राउज़र इसे सपोर्ट नहीं करते हैं, इसे सुरक्षित रूप से ignore किया जाता है। आपके LCP image element में इसे add करने का कोई नकारात्मक पहलू नहीं है।

CrUX डेटा को सुधार को दिखाने में कितना समय लगता है?

मोटे तौर पर 28 दिन जब से असली यूजर साइट के तेज़ संस्करण का अनुभव करना शुरू करते हैं। CrUX एक रोलिंग 28-दिन की विंडो का उपयोग करता है। तो अगर आप आज बदलाव डिप्लॉय करते हैं, तो आपका फील्ड डेटा स्कोर लगभग एक महीने के लिए उन्हें पूरी तरह से दिखाएगा नहीं। अगर PageSpeed Insights आपके ऑप्टिमाइज़ेशन स्प्रिंट के अगले दिन अभी भी "Needs Improvement" दिखाता है तो घबराएं मत।

एक लिस्टिंग साइट के लिए सबसे ज्यादा असर वाला एकल बदलाव कौन सा है?

लगभग हर project पर, यह TTFB रहा है। लेकिन दूसरा सबसे ज्यादा above-fold card images से loading="lazy" हटाना और fetchpriority="high" जोड़ना रहा है। ये दोनों चीजें साथ में आमतौर पर कुल LCP improvement का 40-60% explain करती हैं। बाकी सब कुछ उस नींव के ऊपर compounding gains है।

---

बड़ी साइटों पर performance work ज़्यादातर plumbing है। बेमतलब, methodical, और गहरे रूप से संतोषजनक जब आप 4-second LCP को 1.4 seconds तक pull down करते हैं और दो महीने बाद organic traffic में lift देखते हैं। कोई single magic setting नहीं है, बस सही क्रम में लिए गए specific decisions का एक sequence है।

सर्वर को तेज़ करें। फिर LCP एलिमेंट को जल्दी खोजा जाए और फेच किया जाए। फिर बाकी सब कुछ को इसके रास्ते से हटा दें।