होस्टिंग और प्रदर्शन
हम WordPress को तेज़ कैसे बनाते हैं: LiteSpeed Enterprise, LSCache और प्रति-साइट Redis
सबसे तेज़ WordPress अनुरोध वह है जो कभी निष्पादित नहीं होता — यहाँ बताया गया है कि PHP या MySQL के शुरू होने से पहले ही हमारा स्टैक अधिकांश विज़िट का उत्तर कैश से कैसे देता है, और Core Web Vitals के लिए इसका क्या अर्थ है।
सबसे तेज़ अनुरोध वह है जो कभी निष्पादित नहीं होता
एक मानक WordPress अनुरोध काफी संसाधन-गहन होता है। वेब सर्वर अनुरोध को PHP को सौंपता है, PHP फिर WordPress को बूट करता है, प्लगइन्स चलाता है, MySQL से कई दर्जन बार पूछताछ करता है, HTML तैयार करता है, और केवल उसके बाद बाइट्स वापस भेजता है। किसी व्यस्त साइट पर यह पूरी प्रक्रिया हर विज़िटर के लिए होती है, और यहीं पर आपका लगभग सारा टाइम-टू-फर्स्ट-बाइट (time-to-first-byte) खर्च होता है।
हमारा उत्तर यह सुनिश्चित करना है कि अधिकांश विज़िट के लिए इनमें से कुछ भी न हो। हमारे द्वारा होस्ट की जाने वाली साइटों में — 100,000 से अधिक PBN साइट्स और मुख्यधारा का प्रबंधित WordPress — अधिकांश फ्रंट-एंड पेज व्यू सीधे कैश से प्री-रेंडर्ड पूर्ण पेज के रूप में प्रस्तुत किए जाते हैं, बिना PHP को शुरू किए या डेटाबेस को छुए। इस पोस्ट का शेष भाग इस बारे में है कि इसे संभव बनाने वाली परतें आपस में कैसे जुड़ती हैं, और प्रत्येक परत अपना स्थान कैसे बनाती है।
महत्वपूर्ण बात यह समझना है कि ये कोई परस्पर प्रतिस्पर्धी कैश नहीं हैं जिनमें से आपको किसी एक को चुनना हो। फ़ुल-पेज कैश, ऑब्जेक्ट कैश और CDN एज, इनमें से प्रत्येक अलग-अलग श्रेणी के अनुरोधों को संभालते हैं, और उनका वास्तविक मूल्य इस बात में है कि वे एक-दूसरे को कैसे कार्य सौंपते हैं।
LiteSpeed Enterprise + LSCache: पूर्ण-पृष्ठ स्तर
प्रत्येक साइट सर्वर-स्तरीय LSCache के साथ LiteSpeed Enterprise पर चलती है। जब कोई फ़्रंट-एंड प्रतिक्रिया कैश करने योग्य होती है, तो वेब सर्वर उस पर LiteSpeed cache-control और टैग हेडर स्टैम्प करता है, और LiteSpeed अगले अनुरोध पर सीधे पूरा पृष्ठ प्रस्तुत करता है — कोई PHP प्रक्रिया शुरू नहीं होती, कोई MySQL क्वेरी जारी नहीं की जाती। यह WordPress TTFB पर सबसे बड़ा एकल कारक है, क्योंकि यह हॉट पाथ से संपूर्ण एप्लिकेशन बूट को हटा देता है।
चूँकि LSCache किसी PHP प्लगइन के बजाय सीधे वेब सर्वर के भीतर स्थित होता है, इसलिए यह अनुरोध जीवनचक्र में पहले ही काम करना शुरू कर देता है और पृष्ठों को ऐसे रूप में रखता है जिसे सर्वर तुरंत साफ़ कर सके। एक कैश क्रॉलर लोकप्रिय पृष्ठों को पहले से तैयार रखता है, ताकि कैश साफ़ होने के बाद आने वाले पहले विज़िटर को पृष्ठ को पुनः उत्पन्न करने का भार न उठाना पड़े। इसका परिणाम एक सामान्य स्टैक पर केवल प्लगइन-आधारित कैश की तुलना में स्पष्ट रूप से कम और अधिक सुसंगत TTFB है, जहाँ कैश अभी भी PHP के पीछे रहता है।
हमारा अपना रेपो-ग्रेड कैश प्लगइन हर साइट पर पहले से इंस्टॉल और ऑटो-अपडेटेड होकर आता है, जो WordPress को शुरू से ही LSCache से सही तरीके से जोड़ता है। गैर-LiteSpeed स्रोत पर यह बस कोई फ़ुल-पेज हेडर जारी नहीं करता और रास्ते से हट जाता है, जबकि ऑब्जेक्ट कैश और अपवर्जन नियम अपना काम करते रहते हैं — ताकि माइग्रेट की गई साइट कभी भी टूटी हुई आधी-कॉन्फ़िगर स्थिति में न छूटे।
पुराणी सामग्री दिखाए बिना तेज़ बने रहना: ESI और स्मार्ट ऑटो-पर्ज
आक्रामक फुल-पेज कैशिंग के दो क्लासिक विफलता मोड हैं: किसी लॉग-इन किए गए उपयोगकर्ता को किसी अन्य का पृष्ठ दिखाना, और किसी को भी ऐसा पृष्ठ दिखाना जिसे बदल जाना चाहिए था। इन दोनों का समाधान कम कैश करने के बजाय कैशिंग स्तर पर किया जाता है।
ESI (Edge Side Includes) हमें पेज को कैश करने की सुविधा देता है, साथ ही उन हिस्सों के लिए "होल्स" बनाता है जिन्हें लाइव रहना आवश्यक है। WooCommerce स्टोर पर कैटलॉग, उत्पाद और श्रेणी पेजों को सबसे तेज़ संभव TTFB के लिए फ़ुल-पेज कैश के रूप में परोसा जाता है, जबकि ESI प्रति अनुरोध कार्ट फ़्रैगमेंट, मिनी-कार्ट योग और खाता स्थिति को रेंडर करता है। कार्ट, चेकआउट, माय-अकाउंट और कोई भी नॉनस या सत्र पेज डिफ़ॉल्ट रूप से बाहर रखे जाते हैं। खरीदार हमेशा अपनी स्वयं की बास्केट और एक कार्यशील चेकआउट देखते हैं; सभी को स्टोरफ़्रंट अभी भी कैश से ही मिलता है।
ताज़गी का प्रबंधन स्मार्ट ऑटो-पर्ज द्वारा किया जाता है। सामग्री, उत्पादों, कीमतों या ऑर्डर में बदलाव होने पर पर्ज हुक अपने आप सक्रिय हो जाते हैं, जिससे संबंधित कैश्ड पेज टाइमर के बजाय तुरंत रीफ़्रेश हो जाते हैं, और आप डैशबोर्ड से या WordPress के भीतर से भी मांग पर पर्ज कर सकते हैं। टैग-आधारित पर्जिंग का अर्थ है कि किसी एक पोस्ट को संपादित करने से केवल वह पोस्ट और उसके संग्रह साफ़ होते हैं — पूरा कैश नहीं — ताकि एक संपादन से पूरी साइट कोल्ड-स्टार्ट न हो।
प्रति-साइट Redis ऑब्जेक्ट कैश: उसके लिए जो पूरा पृष्ठ नहीं हो सकता
प्रत्येक अनुरोध एक स्थिर पूर्ण पृष्ठ नहीं हो सकता। लॉग-इन सत्र, WordPress व्यवस्थापक, WooCommerce कार्ट, खोज और ESI द्वारा सक्रिय छोड़े गए गतिशील अंश, इन सभी को PHP चलाना होता है। इनके लिए, लक्ष्य 'एप्लिकेशन छोड़ें' से बदलकर 'डेटाबेस छोड़ें' हो जाता है।
प्रत्येक साइट को अपना समर्पित Redis ऑब्जेक्ट कैश मिलता है। WordPress बार-बार होने वाले डेटाबेस रीड्स के परिणामों — विकल्पों, ट्रांज़िएंट्स, पोस्ट और टर्म लुकअप्स, WooCommerce उत्पाद और सत्र डेटा — को मेमोरी में कैश करता है, ताकि प्रत्येक हिट पर MySQL के विरुद्ध वही क्वेरी न चले। इसका प्रभाव ठीक वहीं सबसे अधिक दिखाई देता है जहाँ फुल-पेज कैश मदद नहीं कर सकता: तेज़ डैशबोर्ड, तेज़ कार्ट्स और ट्रैफ़िक के दौरान डेटाबेस पर काफ़ी कम लोड।
ऑब्जेक्ट कैश प्रत्येक साइट के लिए अलग होता है, साझा नहीं किया जाता, जो प्रदर्शन और अलगाव (आइसोलेशन) दोनों के लिए महत्वपूर्ण है। प्रति-साइट डेटाबेस थ्रॉटलिंग के साथ मिलकर, किसी एक साइट की भारी या खराब तरीके से लिखी गई क्वेरी उसके पड़ोसी साइटों के डेटाबेस संसाधनों को प्रभावित नहीं कर सकती हैं। आप हमारे कैशिंग फीचर पेज पर पढ़ सकते हैं कि यह पूरा बहु-स्तरीय सेटअप कैसे एक साथ काम करता है, और आइसोलेशन के तहत किरायेदारों के बीच की सीमाओं के बारे में अधिक जान सकते हैं।
एज और उसके नीचे का ट्रांसपोर्ट
ओरिजिन सर्वर पर मौजूद कैश को भी नेटवर्क पार करना पड़ता है। सर्वर के आगे CDN एज स्थित होता है, जिससे स्थिर एसेट और कैश किए जा सकने वाले पृष्ठ विज़िटर के नज़दीकी पॉइंट ऑफ़ प्रेज़ेंस से डिलीवर होते हैं, और भारी लोड होने पर भी ओरिजिन पर दबाव नहीं पड़ता। हमारी फ़ुटप्रिंट-मुक्त (footprint-free) होस्टिंग श्रेणी के लिए यही एज कई प्रदाताओं में वितरित एक मल्टी-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, फ़ॉन्ट और विज्ञापनों के लोड होने पर बदलने वाला लेआउट, और प्लगइन्स द्वारा मुख्य-थ्रेड (main-thread) पर डाला जाने वाला भारी काम। सर्वर कैशिंग का कोई भी स्तर 2 MB की हीरो इमेज या मेगाबाइट में JavaScript लोड करने वाली थीम को ठीक नहीं कर सकता। ईमानदार होस्टिंग सर्वर के योगदान को प्रभावी ढंग से नगण्य और सुसंगत बनाती है, इसके बाद फ्रंट एंड को हल्का रखना वेबसाइट की ज़िम्मेदारी होती है।
श्रम का यह विभाजन एक उपयोगी वैचारिक मॉडल है। हम गारंटी देते हैं कि अनुरोध ब्राउज़र तक तेजी से पहुंचे और उच्च ट्रैफ़िक के दौरान भी तेज़ बना रहे; आप पेलोड को छोटा और स्थिर रखते हैं। जहां ये दोनों मिलते हैं — कैश वार्म-अप, एज डिलीवरी, और डेटाबेस को रिस्पॉन्सिव बनाए रखना ताकि डायनेमिक पेज धीमे न पड़ें — ठीक वहीं हमारे स्टैक को अनुकूलित किया गया है, और यही इस प्लेटफ़ॉर्म पर प्रबंधित WordPress को किसी सामान्य होस्ट पर मौजूद उसी साइट की तुलना में अधिक तेज़ बनाता है।
अक्सर पूछे जाने वाले प्रश्न
क्या मुझे अभी भी WP Rocket जैसे कैशिंग प्लगइन की आवश्यकता है?
नहीं। पूर्ण-पृष्ठ कैशिंग को वेब सर्वर पर LiteSpeed के LSCache द्वारा नियंत्रित किया जाता है, और हमारा अपना कैश प्लगइन — जो पहले से इंस्टॉल और स्वचालित रूप से अपडेट होता है — WordPress को इससे सही ढंग से जोड़ता है, जिसके पीछे प्रत्येक साइट के लिए एक Redis ऑब्जेक्ट कैश होता है। इसके ऊपर एक दूसरा पूर्ण-पृष्ठ कैशिंग प्लगइन जोड़ना आम तौर पर मदद करने के बजाय सर्वर-स्तरीय कैश के साथ टकराव पैदा करता है, इसलिए इसकी आवश्यकता नहीं है और इसकी अनुशंसा नहीं की जाती है।
क्या कैशिंग मेरे WooCommerce कार्ट या लॉग-इन किए गए पेजों को खराब कर देगी?
नहीं। कार्ट, चेकआउट, my-account और कोई भी nonce या सत्र पृष्ठ डिफ़ॉल्ट रूप से कैश से बाहर रखे जाते हैं, और ESI अन्यथा-कैश किए गए पृष्ठों पर भी कार्ट अंश और योग को लाइव रखता है। स्टोरफ़्रंट अभी भी कैश से लोड होने के दौरान खरीदार हमेशा अपनी बास्केट और काम करने वाला चेकआउट देखते हैं।
जब मैं प्रकाशित या संपादित करता हूँ तो कैश कैसे ताज़ा रहता है?
स्मार्ट ऑटो-पर्ज प्रासंगिक WordPress हुक्स पर सक्रिय होता है, इसलिए सामग्री प्रकाशित करने, संपादित करने, या किसी उत्पाद, मूल्य या ऑर्डर को बदलने पर केवल प्रभावित पृष्ठ और उनके संग्रह ही साफ़ होते हैं — पूरा कैश नहीं — और एक क्रॉलर उन्हें फिर से वार्म करता है। आप डैशबोर्ड से या WordPress के भीतर से भी मांग पर पर्ज कर सकते हैं।
क्या केवल होस्टिंग ही मुझे सटीक Core Web Vitals दे सकती है?
यह आपको सर्वोत्तम संभव TTFB देता है, जो सर्वर का हिस्सा है और Largest Contentful Paint के लिए एक शुरुआती बढ़त है। लेकिन LCP, CLS और INP काफी हद तक पृष्ठ द्वारा ही तय किए जाते हैं — छवियों के आकार, रेंडर-अवरोधक संपत्तियां, लेआउट स्थिरता और मुख्य-थ्रेड JavaScript। हमारा स्टैक सर्वर के योगदान को तेज़ और सुसंगत बनाता है; फ्रंट-एंड पेलोड को हल्का रखना ही बाकी अंतर को समाप्त करता है।
संबंधित
इसे 14 दिनों के लिए निःशुल्क आज़माएँ
अपनी पहली साइट्स 14 दिनों के लिए निःशुल्क शुरू करें — कार्ड की आवश्यकता नहीं। क्या किसी मौजूदा नेटवर्क को स्थानांतरित कर रहे हैं? माइग्रेशन असीमित और पूरी तरह निःशुल्क हैं।
मुफ़्त शुरू करें