होस्टिंग और प्रदर्शन
हम WordPress को कैसे तेज़ बनाते हैं: LiteSpeed Enterprise, LSCache और प्रति-साइट Redis
सबसे तेज़ WordPress अनुरोध वह होता है जो कभी नहीं चलता — यहाँ बताया गया है कि हमारा स्टैक PHP या MySQL के शुरू होने से पहले कैश से अधिकांश विज़िट का उत्तर कैसे देता है, और Core Web Vitals के लिए इसका क्या अर्थ है।
सबसे तेज़ अनुरोध वह है जो कभी निष्पादित नहीं होता
एक मानक WordPress अनुरोध महंगा होता है। वेब सर्वर PHP को काम सौंपता है, PHP WordPress को बूट करता है, प्लगइन्स चलाता है, MySQL से कुछ दर्जन बार पूछताछ करता है, HTML को जोड़ता है, और उसके बाद ही बाइट्स वापस भेजता है। एक व्यस्त साइट पर वह पूरी प्रक्रिया हर आगंतुक के लिए होती है, और यही वह जगह है जहाँ आपके टाइम-टू-फर्स्ट-बाइट का लगभग सारा समय जाता है।
हमारा उत्तर यह सुनिश्चित करना है कि अधिकांश विज़िट्स के लिए, इनमें से कुछ भी न हो। हमारे द्वारा होस्ट की जाने वाली साइटों — 100,000 से अधिक PBN साइटों और मुख्यधारा के प्रबंधित WordPress पर — फ्रंट-एंड पेज व्यूज़ का अधिकांश हिस्सा कैश से सीधे प्री-रेंडर्ड फुल पेज के रूप में परोसा जाता है, बिना PHP को कॉल किए या डेटाबेस को छुए। इस पोस्ट का बाकी हिस्सा इस बारे में है कि वे परतें जो इसे संभव बनाती हैं, कैसे आपस में जुड़ी हुई हैं, और प्रत्येक परत अपना स्थान कैसे बनाती है।
महत्वपूर्ण बात यह है कि ये कोई ऐसे प्रतिस्पर्धी कैशे (caches) नहीं हैं जिनमें से आपको किसी एक को चुनना हो। फुल-पेज कैशे, ऑब्जेक्ट कैशे और CDN एज—प्रत्येक अलग प्रकार के अनुरोध को संभालते हैं, और असली लाभ इस बात में है कि वे एक-दूसरे को डेटा कैसे सौंपते हैं।
LiteSpeed Enterprise + LSCache: द फुल-पेज लेयर
हर साइट सर्वर-स्तरीय LSCache के साथ LiteSpeed Enterprise पर चलती है। जब फ्रंट-एंड रिस्पॉन्सेज़ कैश करने योग्य होते हैं, तो वेब सर्वर इसे LiteSpeed कैश-कंट्रोल और टैग हैडर के साथ स्टैम्प करता है, और LiteSpeed अगली हिट पर सीधे पूरा पेज सर्व करता है — कोई PHP प्रोसेस स्पॉन नहीं होता, कोई MySQL क्वेरी जारी नहीं होती। यह WordPress TTFB पर सबसे बड़ा सिंगल लेवर है, क्योंकि यह हॉट पाथ से पूरे एप्लिकेशन बूट को हटा देता है।
चूँकि LSCache किसी PHP प्लगइन के बजाय सीधे वेब सर्वर के भीतर काम करता है, यह अनुरोध जीवनचक्र में बहुत पहले ही सक्रिय हो जाता है और पृष्ठों को ऐसे रूप में सहेज कर रखता है जिसे सर्वर तुरंत फ्लश कर सकता है। एक कैश क्रॉलर लोकप्रिय पृष्ठों को सक्रिय रखता है, ताकि किसी कैश को हटाने (purge) के बाद आने वाला पहला आगंतुक पृष्ठ को फिर से जनरेट करने की लागत न चुकाए। इसका परिणाम यह होता है कि जेनेरिक स्टैक पर जोड़े गए केवल-प्लगइन वाले कैश की तुलना में TTFB काफी कम और अधिक स्थिर होता है, जहाँ कैश अभी भी PHP के पीछे रहता है।
हमारा अपना रिपो-ग्रेड कैश प्लगइन हर साइट पर पहले से इंस्टॉल और ऑटो-अपडेट होकर आता है, जो WordPress को बॉक्स से बाहर निकालते ही LSCache से सही ढंग से जोड़ देता है। नॉन-LiteSpeed ऑरिजिन पर यह केवल कोई फुल-पेज हेडर एमिट नहीं करता और रास्ते से हट जाता है, जबकि ऑब्जेक्ट कैश और एक्सक्लूजन नियम अपना काम करते रहते हैं — ताकि माइग्रेट की गई साइट कभी भी टूटी हुई या आधी-कॉन्फ़िगर स्थिति में न छूटे।
बिना बासी सामग्री परोसे तेज रहना: ईएसआई और स्मार्ट ऑटो-पर्ज
आक्रामक फुल-पेज कैशिंग में दो पारंपरिक विफलता मोड होते हैं: लॉग-इन किए गए उपयोगकर्ता को किसी अन्य का पेज दिखाना, और किसी को भी ऐसा पेज दिखाना जिसे बदल जाना चाहिए था। दोनों का समाधान कम कैश करने के बजाय कैशिंग लेयर पर किया जाता है।
ESI (Edge Side Includes) हमें लाइव रहने वाले हिस्सों के लिए छेद बनाते हुए पेज को कैश करने की अनुमति देता है। एक WooCommerce स्टोर पर कैटलॉग, उत्पाद और श्रेणी पेज सबसे तेज़ संभव TTFB के लिए फुल-पेज कैश के रूप में परोसे जाते हैं, जबकि ESI प्रति अनुरोध कार्ट फ़्रैगमेंट, मिनी-कार्ट टोटल और अकाउंट स्थिति को रेंडर करता है। कार्ट, चेकआउट, मेरा-अकाउंट और कोई भी नॉनस या सेशन पेज डिफ़ॉल्ट रूप से बाहर रखे जाते हैं। खरीदारों को हमेशा उनकी अपनी टोकरी और एक काम करने वाला चेकआउट दिखाई देता है; हर किसी को अभी भी कैश से स्टोरफ्रंट मिलता है।
फ़्रेशनेस को स्मार्ट ऑटो-पर्ज द्वारा प्रबंधित किया जाता है। जब सामग्री, उत्पाद, मूल्य या ऑर्डर बदलते हैं, तो पर्ज हुक अपने आप सक्रिय हो जाते हैं, जिससे प्रासंगिक कैश किए गए पेज टाइमर के बजाय तुरंत रीफ़्रेश हो जाते हैं, और आप डैशबोर्ड से या WordPress के अंदर से भी ऑन-डिमांड पर्ज कर सकते हैं। टैग-आधारित पर्जिंग का मतलब है कि एक पोस्ट को संपादित करने से वह पोस्ट और उसके आर्काइव साफ़ हो जाते हैं — न कि पूरा कैश — ताकि एक ही संपादन से पूरी साइट कोल्ड-स्टार्ट न हो।
प्रति-साइट Redis ऑब्जेक्ट कैश: जो पूर्ण पृष्ठ नहीं हो सकता
हर अनुरोध एक स्थिर पूर्ण पृष्ठ नहीं हो सकता। लॉग-इन किए गए सत्र, WordPress व्यवस्थापक, WooCommerce कार्ट, खोज, और गतिशील अंश जिन्हें ESI लाइव छोड़ता है, उन सभी को PHP चलाना पड़ता है। उनके लिए, लक्ष्य 'एप्लिकेशन को छोड़ने' से बदलकर 'डेटाबेस को छोड़ने' पर आ जाता है।
हर साइट को अपना खुद का समर्पित Redis ऑब्जेक्ट कैश मिलता है। WordPress बार-बार होने वाले डेटाबेस रीड्स के परिणामों—ऑप्शंस, ट्रांजिएंट्स, पोस्ट और टर्म लुकअप्स, WooCommerce प्रोडक्ट और सेशन डेटा—को मेमोरी में कैश करता है, जिससे हर हिट पर MySQL के खिलाफ वही क्वेरी नहीं चलाई जाती। इसका असर ठीक वहीं सबसे ज्यादा दिखाई देता है जहाँ फुल-पेज कैश मदद नहीं कर सकता: तेज़ डैशबोर्ड, तेज़ कार्ट, और ट्रैफ़िक के तहत डेटाबेस का बहुत कम लोड।
ऑब्जेक्ट कैश प्रति-साइट है, साझा किया गया नहीं है, जो प्रदर्शन और आइसोलेशन दोनों के लिए महत्वपूर्ण है। प्रति-साइट डेटाबेस थ्रॉटलिंग के साथ मिलकर, किसी एक साइट की भारी या खराब तरीके से लिखी गई क्वेरीज़ अपने पड़ोसियों के लिए डेटाबेस को भूखा नहीं रख सकती हैं। आप हमारे कैशिंग फ़ीचर पेज पर इस बारे में अधिक पढ़ सकते हैं कि पूरा मल्टी-लेयर सेटअप कैसे एक साथ काम करता है, और आइसोलेशन के तहत टेनेंट के बीच की सीमाओं के बारे में भी जान सकते हैं।
एज और इसके नीचे का ट्रांसपोर्ट
ओरिजिन पर रहने वाले कैश को भी नेटवर्क पार करना होता है। सर्वर के सामने CDN एज होता है, इसलिए स्टैटिक एसेट्स और कैश करने योग्य पेजेज़ विज़िटर के पास के पॉइंट ऑफ़ प्रेजेंस से सर्व किए जाते हैं, और लोड होने पर भी ओरिजिन शांत रहता है। हमारे फुटप्रिंट-फ्री होस्टिंग लाइन के लिए यही एज कई प्रोवाइडर्स में फैला हुआ एक मल्टी-CDN पूल है, जो परफॉर्मेंस के साथ-साथ एक फुटप्रिंट उद्देश्य को भी पूरा करता है; मुख्यधारा के WordPress पर यह केवल एक तेज़, अच्छी तरह से काम करने वाली लेयर है जो ओरिजिन को निष्क्रिय रखती है।
तले में बुनियादी बातों पर कोई कंजूसी नहीं की जाती। साइटें HTTP/3 के साथ NVMe स्टोरेज पर चलती हैं, इसलिए कैश द्वारा भेजे जाने वाले बाइट्स किसी भी कैश मिस के पीछे तेज़ स्टोरेज के साथ एक आधुनिक, मल्टीप्लेक्स ट्रांसपोर्ट के ज़रिए पहुँचते हैं। इनमें से कोई भी लेयर कोई ऐड-ऑन नहीं है: LiteSpeed, LSCache, प्रति-साइट Redis, NVMe और HTTP/3 हर प्लान पर आधार हैं, कोई अपसेल टियर नहीं।
Core Web Vitals को असल में क्या चीज़ प्रभावित करती है
यह सटीक होना सार्थक है, क्योंकि होस्टिंग के मामले में अक्सर Core Web Vitals को लेकर बढ़ा-चढ़ाकर दावे किए जाते हैं। TTFB समीकरण का वह हिस्सा है जिस पर सर्वर का नियंत्रण होता है, और इसके ऊपर मौजूद कैशिंग स्टैक ही इसे कम करता है—एज से HTTP/3 के ज़रिए परोसा गया कैश किया हुआ पूरा पेज TTFB को लगभग सबसे कम स्तर पर ले आता है। चूँकि TTFB, Largest Contentful Paint का मुख्य हिस्सा है, इसलिए एक तेज़ ऑरिजिन हर डाउनस्ट्रीम मीट्रिक को वह शुरुआती बढ़त देता है जो उसे अन्यथा नहीं मिल सकती।
लेकिन LCP, CLS और INP का निर्धारण ज़्यादातर ब्राउज़र में, खुद पेज द्वारा होता है: एक बिना ऑप्टिमाइज़ की गई हीरो इमेज, रेंडर-ब्लॉकिंग CSS और JavaScript, फ़ॉन्ट और विज्ञापनों के लोड होने पर हिलने वाला लेआउट, और प्लगिन से मेन-थ्रेड पर पड़ने वाला भारी काम। सर्वर कैशिंग का कोई भी स्तर 2 MB की हीरो इमेज या मेगाबाइट JavaScript भेजने वाली थीम को ठीक नहीं कर सकता। ईमानदारी से दी जाने वाली होस्टिंग सर्वर के योगदान को प्रभावी रूप से मुफ़्त और सुसंगत बनाती है, फिर फ्रंट एंड को हल्का रखना साइट की ज़िम्मेदारी होती है।
श्रम का यह विभाजन एक उपयोगी मानसिक मॉडल है। हम यह सुनिश्चित करते हैं कि अनुरोध तेज़ी से ब्राउज़र तक पहुँचे और ट्रैफ़िक के दौरान तेज़ बना रहे; आप पेलोड को छोटा और स्थिर रखते हैं। जहाँ दोनों मिलते हैं — कैश वार्म-अप, एज डिलीवरी, और डेटाबेस को रिस्पॉन्सिव रखना ताकि डायनेमिक पेज धीमे न पड़ें — यह ठीक वही जगह है जहाँ हमारा स्टैक ट्यून किया गया है, और यही चीज़ इस प्लेटफ़ॉर्म पर प्रबंधित WordPress को सामान्य होस्ट की तुलना में उसी साइट से अधिक तेज़ बनाती है।
अक्सर पूछे जाने वाले प्रश्न
क्या मुझे अभी भी WP Rocket जैसे कैशिंग प्लगइन की आवश्यकता है?
नहीं। फुल-पेज कैशिंग वेब सर्वर पर LiteSpeed के LSCache द्वारा संभाली जाती है, और हमारा अपना कैश प्लगइन—जो पहले से इंस्टॉल और ऑटो-अपडेटेड है—WordPress को इसके साथ सही ढंग से जोड़ता है, जिसके पीछे प्रति-साइट Redis ऑब्जेक्ट कैश होता है। इसके ऊपर दूसरा फुल-पेज कैशिंग प्लगइन लगाने से आमतौर पर मदद मिलने के बजाय सर्वर-स्तर के कैश से संघर्ष होता है, इसलिए इसकी आवश्यकता नहीं है और इसकी अनुशंसा भी नहीं की जाती है।
क्या कैशिंग (caching) मेरे WooCommerce कार्ट या लॉग-इन किए गए पृष्ठों को तोड़ देगी?
नहीं। कार्ट, चेकआउट, my-account और कोई भी नॉनस या सेशन पेज डिफ़ॉल्ट रूप से कैश से बाहर रखे जाते हैं, और ESI अन्यथा-कैश किए गए पेजों पर कार्ट फ़्रैगमेंट और कुल को लाइव रखता है। खरीदारों को हमेशा अपनी टोकरी और काम करने वाला चेकआउट दिखाई देता है, जबकि स्टोरफ्रंट अभी भी कैश से लोड होता है।
जब मैं प्रकाशित या संपादित करता हूँ, तो कैश्ड डेटा ताज़ा कैसे रहता है?
स्मार्ट ऑटो-पर्ज (Smart auto-purge) प्रासंगिक WordPress हुक पर काम करता है, इसलिए सामग्री प्रकाशित करने, संपादित करने, या किसी उत्पाद, मूल्य या ऑर्डर को बदलने पर केवल प्रभावित पेज और उनके आर्काइव साफ़ होते हैं — पूरा कैशे नहीं — और एक क्रॉलर उन्हें फिर से वॉर्म करता है। आप डैशबोर्ड से या WordPress के भीतर से भी मांग पर पर्ज कर सकते हैं।
क्या केवल होस्टिंग मुझे सही Core Web Vitals दे सकती है?
यह आपको सर्वोत्तम संभव TTFB देता है, जो सर्वर का हिस्सा है और Largest Contentful Paint के लिए एक शुरुआती बढ़त है। लेकिन LCP, CLS और INP का निर्णय काफी हद तक पेज द्वारा ही किया जाता है — इमेज साइज़, रेंडर-ब्लॉकिंग एसेट्स, लेआउट स्थिरता और मेन-थ्रेड JavaScript। हमारा स्टैक सर्वर के योगदान को तेज़ और सुसंगत बनाता है; फ्रंट-энд पेलोड को कम रखना ही बाकी के अंतर को पाटने का काम करता है।
संबंधित
14 दिन के लिए निःशुल्क आज़माएं
अपनी पहली साइटें 14 दिनों के लिए निःशुल्क शुरू करें - कोई कार्ड नहीं। कोई मौजूदा नेटवर्क स्थानांतरित कर रहे हैं? आपकी पहली माइग्रेशन हमारी तरफ से है।
निःशुल्क शुरू करें