2022 में, एक होस्टिंग तुलना साइट मेरे इनबॉक्स में आई। बड़ा कैटलॉग — करीब 4,000 पेज, गहरी नेस्टेड कैटेगरी स्ट्रक्चर, हर जगह एफिलिएट लिंक्स, हीरो इमेजेस जो छोटे महाद्वीपों के आकार की थीं। उनका Google Search Console एक डरावना दृश्य था। LCP मोबाइल पर 4.2 सेकंड पर बैठा था। INP (तब अभी भी FID कहलाता था) सीमावर्ती। क्लाइंट ने पहले ही एक पिछली एजेंसी के साथ £6,000 खर्च कर चुका था जिसने इसे CDN से मार दिया और इसे एक दिन कहकर चले गए।
यह प्रोजेक्ट ही वह है जिसने आखिरकार Seahawk में हाई-पेज-काउंट साइट्स के लिए परफॉर्मेंस के बारे में हमारी सोच को आकार दिया — डायरेक्टरी साइट्स, लिस्टिंग प्लेटफॉर्म्स, होस्टिंग रिव्यू प्रॉपर्टीज जैसे HostList-स्टाइल बिल्ड्स। जो आता है वह असली प्लेबुक है।Seahawk for high-page-count sites — directory sites, listing platforms, hosting review properties like HostList-style builds. What follows is the actual playbook.
---
बड़ी साइट्स LCP को अलग तरीके से क्यों तोड़ती हैं
छोटी साइट्स की साधारण समस्याएँ हैं। एक हीरो इमेज, एक थीम, एक प्लगइन बहुत कुछ कर रहा है। इन तीनों को ठीक करें और आप 2 सेकंड से नीचे हैं।
बड़ी साइटों के लिए? बिल्कुल अलग बात है। LCP एलिमेंट इस बात पर निर्भर करता है कि आप किस पेज पर हैं। कैटेगरी आर्काइव का एक अलग LCP कैंडिडेट होता है, प्रोडक्ट डिटेल पेज का एक अलग, और होमपेज का अलग। ज्यादातर परफॉर्मेंस टूल्स एक ही स्कोर रिपोर्ट करते हैं। वह संख्या झूठ है — यह जंगली तरीके से अलग-अलग पेजों का एवरेज है, और होमपेज को ठीक करते हुए नीचे मौजूद 3,800 लिस्टिंग पेजों को नजरअंदाज करना बिल्कुल वही है जिससे एजेंसियों की बदनामी होती है।which page you're on. A category archive has a different LCP candidate than a product detail page, which has a different candidate than the homepage. Most performance tools report a single score. That number is a lie — it's an average of a wildly varied set of pages, and fixing the homepage while ignoring the 3,800 listing pages underneath it is exactly how agencies earn bad reputations.
Google के Core Web Vitals डॉक्यूमेंटेशन साफ करता है कि फील्ड डेटा — जो असली यूजर्स को मिलता है, Chrome User Experience Report में मापा जाता है — ही वह है जो Google रैंकिंग सिग्नल के लिए इस्तेमाल करता है। PageSpeed Insights का लैब डेटा दिशा दिखाता है, निर्णायक नहीं है। मैंने ऐसी साइटें देखी हैं जो PSI पर 95 स्कोर करती हैं पर अभी भी CrSX डेटा में Poor LCP है। दोनों को गड़बड़ा मत दो।Core Web Vitals documentation from Google is clear that field data — what real users experience, measured in Chrome User Experience Report — is what Google actually uses for ranking signals. Lab data from PageSpeed Insights is directional, not definitive. I've seen sites score 95 on PSI and still have Poor LCP in CrSX data. Don't confuse the two.
लिस्टिंग साइटों पर तीन असली कसूरवार
हर बड़ी साइट जिसका मैंने ऑडिट किया है (और इस बिंदु तक मैं सैकड़ों से गुजर चुका हूँ), LCP की विफलता लगभग हर बार तीन मूल कारणों तक पहुंचती है:
- Unoptimised हीरो या कार्ड इमेजेस — अक्सर पूरी रेजोल्यूशन पर परोसी जाती हैं, गलत फॉर्मेट, कोई fetchpriority हिंट नहीं — often served at full resolution, wrong format, no
fetchpriorityhint - Render-blocking थर्ड-पार्टी स्क्रिप्ट्स — एफिलिएट ट्रैकर्स, एड नेटवर्क्स, कंपेरिजन विजेट्स जो ब्राउजर कुछ भी पेंट कर सकने से पहले लोड होते हैं — affiliate trackers, ad networks, comparison widgets loading before the browser can paint anything
- TTFB LCP बजट को बढ़ा देता है — सर्वर रिस्पांस धीमा होना 600–900ms खा जाता है इससे पहले कि पेज लोडिंग शुरू ही हो — slow server response eating 600–900ms before the page even starts loading
वह तीसरा वाला वह है जिसे लोग कम आंकते हैं। अगर आपका TTFB 700ms है, तो आपने पहले से ही अपने "Good" LCP बजट का लगभग आधा खर्च कर चुके हैं इससे पहले कि ब्राउजर एक भी पिक्सल रेंडर करे। होस्टिंग की पसंद और सर्वर-साइड कैशिंग DevOps की चिंता नहीं है — ये SEO की चिंता है।
---
TTFB से शुरू करो: यह पहले एक होस्टिंग और कैशिंग की समस्या है
मैंने ऊपर जिस HostList-type प्रोजेक्ट का जिक्र किया? पहली चीज़ जो मैंने की, वह पाँच अलग-अलग भौगोलिक स्थानों से WebPageTest चलाना था। TTFB लगातार 680–820ms था। साइट Virginia में एक shared host पर थी। उनका ज़्यादातर organic traffic UK और Germany से आ रहा था।WebPageTest from five different geographic locations. TTFB was consistently 680–820ms. The site was on a shared host in Virginia. Most of their organic traffic came from the UK and Germany.
उन्हें एक managed WordPress host पर shift किया जिसके edge nodes London और Frankfurt में थे। Listing pages पर 12 घंटे के cache lifetime के साथ full-page caching configure की (वैसे भी डेटा उतनी बार change नहीं होता था)। TTFB repeat requests पर 120–180ms तक गिर गया, first-hit cache misses पर 280–350ms। उस एक ही change ने मेरे किसी भी image को touch करने से पहले LCP से लगभग 500ms निकाल दिया।
होस्टिंग साइड पर कुछ चीज़ें हैं जो मैं हमेशा check करता हूँ:
- क्या full-page caching actually काम कर रही है? X-Cache response header को check करो। अगर हर एक request पर MISS दिख रहा है, तो तुम्हारी caching layer काम नहीं कर रही। Check the
X-Cacheresponse header. If it saysMISSon every single request, your caching layer isn't functioning. - क्या origin server भौगोलिक रूप से तुम्हारे primary audience के करीब है? यह सुनने में obvious लगता है। तुम्हें हैरानी होगी कि यह कितनी बार गलत होता है। This sounds obvious. You'd be surprised how often it's wrong.
- क्या keep-alive enable है? कुछ सस्ते hosts अभी भी persistent connections को disable करते हैं। 2024 में यह पागलपन है, लेकिन होता है। Some cheaper hosts still disable persistent connections. Wild in 2024, but it happens.
- क्या HTTP/2 या HTTP/3 active है? curl -I --http2 https://yourdomain.com run करो और response में protocol को check करो। Run
curl -I --http2 https://yourdomain.comand check the protocol in the response.
TTFB को sort करने तक image optimisation को touch मत करो। एक slow server पर images optimize करना उस घर को paint करने जैसा है जो आग में जल रहा है।
---
The LCP Image Problem (And Why `fetchpriority` Changes Everything)
सही है। इमेज़। कार्ड-ग्रिड लेआउट वाली लिस्टिंग साइट पर, LCP एलिमेंट लगभग हमेशा फोल्ड से ऊपर पहली कार्ड की इमेज होती है — या हीरो बैनर। ब्राउज़र को इसे खोजना पड़ता है, फेच करना पड़ता है, डिकोड करना पड़ता है, और रेंडर करना पड़ता है। इन चरणों में से हर एक में देरी हो सकती है।
यहाँ बताता हूँ कि हमने HostList प्रोजेक्ट पर क्या किया, क्रम में:
- सभी कार्ड इमेज़ को WebP में कनवर्ट किया — Imagify की बल्क कनवर्जन का उपयोग करके। औसत फ़ाइल साइज़ 58% गिरा, जो कार्ड थंबनेल साइज़ (280×180px डिस्प्ले, रेटिना के लिए 2x पर सर्व किए गए) पर दृश्य गुणवत्ता खोए बिना। — using Imagify's bulk conversion. Average file size dropped 58% without visible quality loss at the card thumbnail sizes we were using (280×180px display, served at 2x for retina).
- पहली कार्ड इमेज में `fetchpriority="high"` जोड़ा — सिर्फ यह एक बदलाव ही WebPageTest में मापे गए LCP से लगभग 200ms कम कर दिया। ब्राउज़र इसे एक नियमित लेज़ी इमेज मानना बंद कर देता है और इसे preload स्कैनर में तुरंत क्यू में डालता है। — This one change alone knocked ~200ms off measured LCP in WebPageTest. The browser stops treating it like a regular lazy image and queues it immediately in the preload scanner.
- कार्ड इमेज की पहली दो पंक्तियों से `loading="lazy"` हटाया — लेज़ी लोडिंग फोल्ड के नीचे की इमेज़ के लिए शानदार है। पहली दृश्य पंक्ति पर, यह सक्रिय रूप से आपको नुकसान पहुँचाता है। यह ब्राउज़र को बताता है कि इमेज़ को तब तक न फेच करें जब तक वह व्यूपोर्ट के पास न हो — जहाँ यह पहले से ही है। — Lazy loading is brilliant for below-fold images. On the first visible row, it actively hurts you. It tells the browser to not fetch the image until it's near the viewport — which it already is.
- होमपेज टेम्पलेट पर विशेष रूप से `<head>` में हीरो इमेज के लिए एक `<link rel="preload">` टैग जोड़ा। in the
<head>on the homepage template specifically.
उस क्रम से होमपेज LCP को लैब शर्तों में 3.1s से 1.4s तक लाया गया। फील्ड डेटा लगभग 28 दिनों में आया (यह CrUX डेटा को स्केल पर बदलाव दिखाने में लगभग इतना समय लगता है)।
रेस्पॉन्सिव इमेज पर एक नोट
अगर आप एक ही 1400px-चौड़ी इमेज को मोबाइल डिवाइस पर सर्व कर रहे हैं, तो आप बैंडविड्थ बर्बाद कर रहे हैं और डिकोड समय जोड़ रहे हैं। srcset को सही तरीके से उपयोग करें। मुझे पता है कि यह 2016 की बातचीत जैसा लगता है लेकिन मैं अभी भी Seahawk से गुज़रने वाली लगभग 40% साइट्स पर इसे देखता हूँ। WordPress का wp_get_attachment_image() फंक्शन स्वचालित रूप से srcset जेनरेट करता है — लेकिन केवल अगर इमेज पर्याप्त रिज़ॉल्यूशन पर अपलोड की गई थी और थीम ने इसे add_filter('max_srcset_width', ...) से दबाया नहीं है।srcset properly. I know this sounds like a 2016 conversation but I still see it on probably 40% of the sites that come through Seahawk. The WordPress wp_get_attachment_image() function generates srcset automatically — but only if the image was uploaded at sufficient resolution and the theme hasn't suppressed it with add_filter('max_srcset_width', ...).
---
रेंडर-ब्लॉकिंग स्क्रिप्ट्स: एफिलिएट साइट का टैक्स
होस्टिंग कम्पेरिजन साइट्स और लिस्टिंग प्लेटफॉर्म्स एफिलिएट रेवेन्यू पर निर्भर रहती हैं। इसका मतलब है थर्ड-पार्टी ट्रैकिंग स्क्रिप्ट्स। Commission Junction, Impact, Awin, कस्टम पिक्सल ट्रैकर्स — ये सब जमा हो जाते हैं। मैंने एक ही लिस्टिंग साइट पर 14 अलग-अलग थर्ड-पार्टी स्क्रिप्ट ऑरिजिन्स देखे हैं। हर एक के लिए अलग DNS लुकअप, TCP कनेक्शन, और TLS हैंडशेक की जरूरत होती है इससे पहले कि उस स्क्रिप्ट का एक भी बाइट मिले।
फिक्स स्क्रिप्ट्स को हटाना नहीं है। आप कर नहीं सकते — रेवेन्यू इन पर निर्भर करती है। फिक्स है सीक्वेंसिंग।
कोई भी थर्ड-पार्टी स्क्रिप्ट कभी भी LCP एलिमेंट के शुरुआती रेंडर को ब्लॉक नहीं करनी चाहिए। बस।
व्यावहारिक तौर पर, इसका मतलब है:
- सभी एफिलिएट/एनालिटिक्स स्क्रिप्ट्स को <head> में नहीं, DOMContentLoaded इवेंट के बाद लोड करें।after the
DOMContentLoadedevent, not in<head>. - जिन स्क्रिप्ट्स को आप कंट्रोल करते हैं, उन सभी पर async या defer एट्रिब्यूट्स लगाएँ।
asyncordeferattributes on every script you control. - जिन स्क्रिप्ट्स को आप कंट्रोल नहीं करते (tag managers द्वारा inject किए गए), Google Tag Manager को ही defer के साथ लोड करें — हाँ, यह ज्यादातर एफिलिएट ट्रैकिंग यूज केसेज के लिए सुरक्षित है, और GTM का अपना डॉक्यूमेंटेशन इस अप्रोच को स्वीकार करता है।
defer— yes, this is safe for most affiliate tracking use cases, and GTM's own documentation acknowledges this approach. - Asset CleanUp Pro या WP Rocket की script delay फीचर जैसे script manager का उपयोग करें ताकि नॉन-एसेंशियल थर्ड पार्टीज को यूजर इंटरेक्शन के बाद तक defer किया जा सके (पहली स्क्रॉल या पहला क्लिक)।
HostList रीबिल्ड पर, थर्ड-पार्टी स्क्रिप्ट्स को defer करने से Total Blocking Time 1,840ms से घटकर 290ms हो गया। TBT सीधे तौर पर Core Web Vital नहीं है, लेकिन यह INP के साथ मजबूती से कोरिलेट करता है, जो है।is.
---
फ़ॉन्ट लोडिंग: वह साइलेंट LCP किलर जिसके बारे में कोई बात नहीं करता
कस्टम फ़ॉन्ट एक विशिष्ट विफलता मोड का कारण बनते हैं। ब्राउज़र आपका लेआउट रेंडर करता है, LCP टेक्स्ट एलिमेंट तक पहुँचता है (कभी-कभी LCP एक इमेज नहीं, बल्कि एक हेडिंग होता है), और फिर इसे पेंट करने से पहले फ़ॉन्ट फ़ाइल की प्रतीक्षा करता है। इसे Flash of Invisible Text कहते हैं, और यह LCP को 200ms से लेकर एक सेकंड से अधिक तक विलंबित कर सकता है, फ़ॉन्ट फ़ाइल साइज़ और सर्वर निकटता के आधार पर।
दो चीज़ें इसे ठीक करती हैं:
आपके @font-face डिक्लेरेशन में font-display: swap — ब्राउज़र तुरंत एक फ़ॉलबैक फ़ॉन्ट में रेंडर करता है और कस्टम फ़ॉन्ट लोड होने पर स्वैप कर देता है। LCP कैंडिडेट समय पर पेंट हो जाता है।in your@font-facedeclaration — the browser renders in a fallback font immediately and swaps when the custom font loads. LCP candidate gets painted on time.- अपने फ़ॉन्ट को सेल्फ-होस्ट करें। Google Fonts एक क्रॉस-ऑरिजिन रिक्वेस्ट जोड़ता है। google-webfonts-helper टूल के साथ सेल्फ-होस्टिंग आपको अपने डोमेन से फ़ॉन्ट परोसने देती है, जो उस अतिरिक्त कनेक्शन को कम कर देता है।google-webfonts-helper tool lets you serve fonts from your own domain, cutting that extra connection.
मैंने उस टूल का उपयोग करके लगभग 45 मिनट में एक बड़ी डायरेक्टरी साइट को Google Fonts से कनवर्ट किया। LCP में 180ms की सुधार हुई। अकेले यह बदलाव नहीं लाता, लेकिन बाकी सब कुछ के साथ मिलकर, ये मार्जिन जमा होते हैं।
---
फील्ड में वास्तव में मायने रखने वाली चीज़ों को मापना
CrUX डेटा ही सच है। लेकिन यह केवल महीने में एक बार अपडेट होता है और केवल पर्याप्त ट्रैफिक वाले URLs के लिए। हज़ारों पेजेस वाली बड़ी साइटों के लिए, आपको कुछ ज़्यादा विस्तृत की ज़रूरत है।
मैं PageSpeed Insights API का उपयोग करता हूँ, जिसे URLs के एक प्रतिनिधि नमूने पर स्क्रिप्ट किया जाता है — आमतौर पर ट्रैफ़िक के अनुसार शीर्ष 100 पेज, 50 कैटेगरी-स्तर के पेज, और 20 "थिन" डीप-कैटलॉग पेज। यह मासिक रूप से चलाने से एक उचित प्रदर्शन वितरण मिलता है, अकेला बिंदु स्कोर नहीं।PageSpeed Insights API scripted across a representative sample of URLs — typically the top 100 pages by traffic, 50 category-level pages, and 20 "thin" deep-catalogue pages. Running this monthly gives a proper performance distribution, not a single-point score.
Lighthouse CI में (जिसे हम उन क्लाइंट्स के लिए CI/CD पाइपलाइन में चलाते हैं जिनके पास dev साइकिल है), हम इसके विरुद्ध दावा करते हैं:
- LCP ≤ 2.5s lab में (रूढ़िवादी लक्ष्य, क्योंकि field आमतौर पर lab से 10–15% पीछे रहता है)
- TBT ≤ 300ms
- CLS ≤ 0.1
लेकिन ईमानदारी से — HostList-प्रकार की बिल्ड के लिए जहाँ लक्ष्य sub-1.5s LCP है — lab लक्ष्यों को कठोर होना चाहिए। हम उन परियोजनाओं के लिए Lighthouse CI में LCP ≤ 1.8s सेट करते हैं, जो आमतौर पर 1.3–1.5s field डेटा में देते हैं जब CrUX पकड़ता है।
---
यह सब एक साथ रखना: HostList परिणाम
उपरोक्त सभी के माध्यम से चलने के बाद — होस्टिंग माइग्रेशन, पूर्ण-पृष्ठ कैशिंग, छवि प्रारूप रूपांतरण, LCP उम्मीदवारों पर fetchpriority, above-fold पंक्तियों से lazy-load हटाना, script deferral, और font self-hosting — यहाँ संख्याएँ कैसी दिखीं:fetchpriority on LCP candidates, lazy-load removal from above-fold rows, script deferral, and font self-hosting — here's what the numbers looked like:
- TTFB: 780ms → 160ms (माध्य, UK विज़िटर): 780ms → 160ms (median, UK visitors)
- LCP (lab, mobile): 4.2s → 1.4s: 4.2s → 1.4s
- LCP (field, CrUX, 75th percentile): 3.8s → 1.6s (migration के 60 दिन बाद मापा गया): 3.8s → 1.6s (measured 60 days post-migration)
- TBT: 1,840ms → 290ms: 1,840ms → 290ms
- CLS: पहले से ही 0.03 पर ठीक था, अपरिवर्तित: was already fine at 0.03, unchanged
हर साइट को 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 सपोर्ट Firefox 132 में आया। जो ब्राउजर इसे सपोर्ट नहीं करते, यह सुरक्षित रूप से नज़रअंदाज़ कर दिया जाता है। अपने LCP इमेज एलिमेंट में इसे जोड़ने का कोई नुकसान नहीं है।
CrUX डेटा को सुधार को दिखाने में कितना समय लगता है?
मोटे तौर पर 28 दिन जब से असली यूजर साइट के तेज़ संस्करण का अनुभव करना शुरू करते हैं। CrUX एक रोलिंग 28-दिन की विंडो का उपयोग करता है। तो अगर आप आज बदलाव डिप्लॉय करते हैं, तो आपका फील्ड डेटा स्कोर लगभग एक महीने के लिए उन्हें पूरी तरह से दिखाएगा नहीं। अगर PageSpeed Insights आपके ऑप्टिमाइज़ेशन स्प्रिंट के अगले दिन अभी भी "Needs Improvement" दिखाता है तो घबराएं मत।
एक लिस्टिंग साइट के लिए सबसे ज्यादा असर वाला एकल बदलाव कौन सा है?
लगभग हर प्रोजेक्ट में, यह TTFB रहा है। लेकिन दूसरा सबसे ज्यादा असर वाला लगातार above-fold कार्ड इमेजेज से `loading="lazy"` हटाना और `fetchpriority="high"` जोड़ना रहा है। ये दोनों चीजें आमतौर पर कुल LCP सुधार का 40–60% हिस्सा होती हैं। बाकी सब कुछ उस नींव के ऊपर प्रगतिशील लाभ है।loading="lazy" from above-fold card images and adding fetchpriority="high". Together those two things usually account for 40–60% of the total LCP improvement. Everything else is compounding gains on top of that foundation.
---
बड़ी साइटों पर परफॉर्मेंस का काम ज्यादातर प्लंबिंग है। बेरौनक, पद्धतिगत, और गहरी संतुष्टि की बात है जब आप 4-सेकंड का LCP को 1.4 सेकंड तक खींच लाते हैं और दो महीने बाद ऑर्गेनिक ट्रैफिक में उछाल देखते हैं। कोई एकल जादुई सेटिंग नहीं है — बस सही क्रम में लिए गए विशिष्ट निर्णयों का एक क्रम।
सर्वर को तेज़ करें। फिर LCP एलिमेंट को जल्दी खोजा जाए और फेच किया जाए। फिर बाकी सब कुछ को इसके रास्ते से हटा दें।