होस्टिंग आणि कार्यप्रदर्शन

आम्ही WordPress कसे वेगवान बनवतो: LiteSpeed Enterprise, LSCache आणि प्रति-साइट Redis

सर्वात जलद WordPress विनंती ती असते जी कधीही रन होत नाही — PHP किंवा MySQL कॉल होण्यापूर्वीच आमचा स्टॅक कॅशमधून बहुतांश भेटींना कसा प्रतिसाद देतो आणि Core Web Vitals साठी याचा काय अर्थ आहे ते येथे दिले आहे.

Neil Lock द्वारे · १५ जुलै, २०२६ · मध्ये होस्टिंग आणि कार्यप्रदर्शन

सर्वात जलद विनंती ती असते जी कधीही कार्यान्वित होत नाही

एक मानक WordPress विनंती खर्चिक असते. वेब सर्व्हर PHP कडे सुपूर्द करतो, PHP WordPress बूट करते, प्लगइन्स चालवते, MySQL ला काही डझन वेळा क्वेरी करते, HTML एकत्रित करते आणि त्यानंतरच बाइट्स परत पाठवते. एका व्यस्त साइटवर ही संपूर्ण प्रक्रिया प्रत्येक अभ्यागतासाठी घडते, आणि तिथेच तुमचा जवळजवळ सर्व time-to-first-byte खर्च होतो.

बहुतेक भेटींसाठी यातील काहीही घडू नये याची खात्री करणे हे आमचे उत्तर आहे. आम्ही होस्ट करत असलेल्या सर्व साइट्सवर — 1,00,000 पेक्षा जास्त PBN साइट्स आणि मुख्य प्रवाहातील व्यवस्थापित WordPress — फ्रंट-एंड पेज व्ह्यूजपैकी बहुतांश व्ह्यूज PHP ला सुरू न करता किंवा डेटाबेसशी संपर्क न साधता, थेट कॅशेमधून पूर्व-प्रस्तुत (pre-rendered) पूर्ण पेज म्हणून सर्व्ह केले जातात. या पोस्टचा उर्वरित भाग हे शक्य करणारे स्तर एकमेकांशी कसे जुळतात आणि प्रत्येक स्तर आपले स्थान कसे सार्थ ठरवतो याबद्दल आहे.

महत्त्वाची बाब ही आहे की या एकमेकांशी स्पर्धा करणाऱ्या कॅशे नाहीत ज्यांमधून तुम्हाला निवड करावी लागेल. फुल-पेज कॅशे, ऑब्जेक्ट कॅशे आणि CDN एज यांपैकी प्रत्येक वेगवेगळ्या प्रकारच्या विनंत्या हाताळतात, आणि त्यांचे खरे मूल्य ते एकमेकांकडे कार्य कसे सोपवतात यात आहे.

LiteSpeed Enterprise + LSCache: संपूर्ण-पृष्ठ स्तर

प्रत्येक साइट सर्व्हर-स्तरीय LSCache सह LiteSpeed Enterprise वर चालते. जेव्हा फ्रंट-एंड प्रतिसाद कॅश करण्यायोग्य असतो, तेव्हा वेब सर्व्हर त्यावर LiteSpeed कॅश-नियंत्रण आणि टॅग हेडर्स चिन्हांकित करतो, आणि पुढील हिटवर LiteSpeed संपूर्ण पृष्ठ थेट सर्व्ह करते — कोणतीही PHP प्रक्रिया सुरू होत नाही, कोणतीही MySQL क्वेरी पाठवली जात नाही. हा WordPress TTFB वरील सर्वात मोठा घटक आहे, कारण तो हॉट पाथमधून संपूर्ण अ‍ॅप्लिकेशन बूट काढून टाकतो.

LSCache हे PHP प्लगइनऐवजी वेब सर्व्हरच्या आत कार्य करत असल्यामुळे, ते विनंतीच्या जीवनचक्रात आधी काम करण्यास सुरुवात करते आणि सर्व्हर त्वरित फ्लश करू शकेल अशा स्वरूपात पृष्ठे साठवून ठेवते. कॅश क्रॉलर लोकप्रिय पृष्ठे नेहमी तयार ठेवतो, त्यामुळे कॅश रिकामी केल्यानंतर येणाऱ्या पहिल्या अभ्यागताला पृष्ठ पुन्हा तयार होण्यासाठी वाट पाहावी लागत नाही. याचा परिणाम म्हणजे, कॅश अजूनही PHP च्या मागे असलेल्या सर्वसामान्य स्टॅकवर जोडलेल्या केवळ-प्लगइन कॅशच्या तुलनेत लक्षणीयरीत्या कमी आणि अधिक सुसंगत TTFB मिळतो.

आमचे स्वतःचे रेपो-दर्जाचे कॅशे प्लगइन प्रत्येक साइटवर पूर्व-स्थापित आणि स्वयंचलितपणे अपडेट केलेले असते, जे बॉक्सच्या बाहेरच WordPress ला LSCache शी योग्यरित्या जोडते. गैर-LiteSpeed मूळ सर्व्हरवर ते फक्त पूर्ण-पृष्ठ शीर्षलेख पाठवत नाही आणि बाजूला होते, तर ऑब्जेक्ट कॅशे आणि वगळण्याचे नियम त्यांचे काम चालू ठेवतात — त्यामुळे स्थलांतरित केलेली साइट कधीही खंडित, अर्धवट कॉन्फिगर केलेल्या स्थितीत राहत नाही.

जुनी सामग्री न दाखवता जलद राहणे: ESI आणि स्मार्ट ऑटो-पर्ज

आक्रमक फुल-पेज कॅशिंगमध्ये दोन क्लासिक अपयश पद्धती आहेत: लॉग-इन केलेल्या वापरकर्त्याला दुसऱ्या कोणाचे तरी पृष्ठ देणे आणि ज्यामध्ये बदल व्हायला हवा होता असे पृष्ठ कोणालाही देणे. हे दोन्ही कमी कॅशिंग करण्याऐवजी कॅशिंग स्तरावर सोडवले जातात.

ESI (Edge Side Includes) आम्हाला पृष्ठ कॅश करण्याची अनुमती देते आणि जे भाग थेट (लाइव्ह) राहणे आवश्यक आहे त्यांच्यासाठी छिद्रे (होल्स) तयार करते. WooCommerce स्टोअरवर कॅटलॉग, उत्पादन आणि श्रेणी पृष्ठे सर्वात जलद संभाव्य TTFB साठी संपूर्ण-पृष्ठ कॅश म्हणून दिली जातात, तर ESI प्रति विनंती कार्ट फ्रॅगमेंट, मिनी-कार्ट एकूण आणि खात्याची स्थिती रेंडर करते. कार्ट, चेकआउट, माय-अकाउंट आणि कोणतीही नॉन किंवा सत्र पृष्ठे डीफॉल्टनुसार वगळली जातात. खरेदीदारांना नेहमी त्यांची स्वतःची बास्केट आणि कार्यरत चेकआउट दिसते; प्रत्येकाला अजूनही कॅशमधून स्टोअरफ्रंट मिळते.

कंटेंटचे ताजेपण स्मार्ट ऑटो-पर्जद्वारे हाताळले जाते. जेव्हा सामग्री, उत्पादने, किमती किंवा ऑर्डर्स बदलतात तेव्हा पर्ज हुक्स आपोआप कार्यान्वित होतात, ज्यामुळे संबंधित कॅश केलेली पृष्ठे टाइमरवर अवलंबून न राहता लगेच रिफ्रेश होतात, तसेच आपण डॅशबोर्डवरून किंवा WordPress च्या आतून मागणीनुसार पर्ज देखील करू शकता. टॅग-आधारित पर्जिंगचा अर्थ असा आहे की एका पोस्टमध्ये संपादन केल्याने केवळ ती पोस्ट आणि तिचे संग्रहण (आर्काइव्ह्ज) साफ होतात — संपूर्ण कॅश नाही — त्यामुळे एका संपादनामुळे संपूर्ण साइट कोल्ड-स्टार्ट होत नाही.

प्रति-साइट Redis ऑब्जेक्ट कॅश: जे संपूर्ण पृष्ठ असू शकत नाही त्यासाठी

प्रत्येक विनंती ही स्थिर संपूर्ण पृष्ठ असू शकत नाही. लॉग-इन केलेली सत्रां, WordPress ॲडमिन, WooCommerce कार्ट, शोध आणि ESI थेट सोडत असलेले डायनॅमिक तुकडे या सर्वांना PHP चालवावे लागते. त्यांच्यासाठी, ध्येय 'ॲप्लिकेशन वगळा' वरून 'डेटाबेस वगळा' वर बदलते.

प्रत्येक साइटला स्वतःचे समर्पित Redis ऑब्जेक्ट कॅशे मिळते. WordPress वारंवार होणाऱ्या डेटाबेस वाचनाचे परिणाम — पर्याय, ट्रान्झिएंट्स, पोस्ट आणि टर्म शोध, WooCommerce उत्पादन आणि सत्र डेटा — मेमरीमध्ये कॅशे करते, ज्यामुळे प्रत्येक वेळी MySQL वर तीच क्वेरी चालवली जात नाही. याचा प्रभाव अशा ठिकाणी सर्वात जास्त दिसून येतो जेथे फुल-पेज कॅशे मदत करू शकत नाही: जलद डॅशबोर्ड, जलद कार्ट्स आणि ट्रॅफिक दरम्यान अत्यंत कमी डेटाबेस भार.

ऑब्जेक्ट कॅश ही सामायिक नसून प्रत्येक साइटसाठी स्वतंत्र असते, जी कार्यक्षमता आणि पृथक्करण (आयझोलेशन) या दोन्ही दृष्टीने महत्त्वाची आहे. प्रत्येक साइटच्या डेटाबेस थ्रॉटलिंगसह एकत्रित केल्यामुळे, एका साइटच्या मोठ्या किंवा चुकीच्या पद्धतीने लिहिलेल्या क्वेरी शेजारच्या साइट्ससाठी डेटाबेस संसाधनांची कमतरता निर्माण करू शकत नाहीत. संपूर्ण बहुस्तरीय सेटअप एकत्र कसे कार्य करतो याबद्दल तुम्ही आमच्या कॅशिंग वैशिष्ट्य पृष्ठावर आणि आयझोलेशन अंतर्गत भाडेकरूंमधील (टेनंट्स) सीमांबद्दल अधिक वाचू शकता.

एज आणि त्याखालील ट्रान्सपोर्ट

मूळ सर्व्हरवर (origin) असलेली कॅशे देखील नेटवर्कवरूनच जावी लागते. सर्व्हरच्या समोर CDN एज (edge) असल्यामुळे, स्टॅटिक ॲसेट्स आणि कॅशे करता येणारी पृष्ठे ही वापरकर्त्याच्या जवळील पॉइंट ऑफ प्रेझेन्समधून पुरवली जातात, आणि जास्त भार असतानाही मूळ सर्व्हर शांत राहतो. आमच्या फूटप्रिंट-मुक्त (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, फॉन्ट आणि जाहिराती लोड होताना बदलणारा लेआउट, आणि प्लगइन्सकडून होणारे मुख्य-थ्रेडचे जड काम. सर्व्हर कॅशिंगचे कोणतेही प्रमाण 2 MB ची हिरो इमेज किंवा मेगाबाईट्सचे JavaScript देणारी थीम दुरुस्त करू शकत नाही. प्रामाणिक होस्टिंग सर्व्हरचे योगदान प्रभावीपणे विनामूल्य आणि सुसंगत बनवते, त्यानंतर फ्रंट एंड हलके ठेवणे हे साइटवर अवलंबून असते.

कामाची ही विभागणी एक उपयुक्त मानसिक मॉडेल आहे. विनंती ब्राउझरपर्यंत वेगाने पोहोचेल आणि जास्त ट्रॅफिक असतानाही वेगवान राहील याची आम्ही हमी देतो; आपण पेलोड लहान आणि स्थिर ठेवणे आवश्यक आहे. या दोन्ही गोष्टी जिथे एकत्र येतात — कॅशे वॉर्म-अप, एज डिलिव्हरी आणि डायनॅमिक पृष्ठे अडखळू नयेत म्हणून डेटाबेस प्रतिसादक्षम ठेवणे — नेमके तिथेच आमचा स्टॅक अनुकूलित केलेला आहे, आणि यामुळेच या प्लॅटफॉर्मवरील व्यवस्थापित WordPress हे सामान्य होस्टवरील त्याच साइटपेक्षा अधिक जलद बनते.

नेहमी विचारले जाणारे प्रश्न

मला अजूनही WP Rocket सारख्या कॅशिंग प्लगइनची आवश्यकता आहे का?

नाही. संपूर्ण-पृष्ठ कॅशिंग हे वेब सर्व्हरवर LiteSpeed च्या LSCache द्वारे हाताळले जाते आणि आमचे स्वतःचे कॅश प्लगइन — पूर्व-स्थापित आणि स्वयंचलितपणे अपडेट होणारे — WordPress ला त्याच्याशी योग्यरित्या जोडते, ज्याच्या मागे प्रत्येक साइटसाठी स्वतंत्र Redis ऑब्जेक्ट कॅश असते. यावर दुसरे संपूर्ण-पृष्ठ कॅशिंग प्लगइन जोडल्याने मदत होण्याऐवजी सर्व्हर-स्तरीय कॅशसोबत संघर्ष निर्माण होतो, त्यामुळे याची आवश्यकता नाही आणि याची शिफारस केली जात नाही.

कॅशिंगमुळे माझी WooCommerce कार्ट किंवा लॉग-इन केलेली पृष्ठे बिघडतील का?

नाही. Cart, checkout, my-account आणि कोणतीही nonce किंवा session पृष्ठे डीफॉल्टनुसार कॅशमधून वगळली जातात आणि ESI कार्ट फ्रॅगमेंट आणि बेरीज इतर कॅश केलेल्या पृष्ठांवर थेट (live) ठेवते. स्टोअरफ्रंट कॅशमधून लोड होत असतानाही खरेदीदारांना नेहमी त्यांची स्वतःची बास्केट आणि कार्यरत चेकआउट दिसते.

मी प्रकाशित किंवा संपादित करतो तेव्हा कॅशे कसा ताजा राहतो?

स्मार्ट ऑटो-पर्ज संबंधित WordPress हुक्सवर कार्यान्वित होते, त्यामुळे सामग्री प्रकाशित करणे, संपादित करणे किंवा उत्पादन, किंमत अथवा ऑर्डर बदलल्याने संपूर्ण कॅशे नव्हे, तर केवळ प्रभावित पृष्ठे आणि त्यांचे संग्रह साफ होतात — आणि क्रॉलर त्यांना पुन्हा वॉर्म करतो. तुम्ही डॅशबोर्डवरून किंवा WordPress च्या आतून मागणीनुसार देखील पर्ज करू शकता.

फक्त होस्टिंग मला परिपूर्ण Core Web Vitals देऊ शकते का?

हे तुम्हाला सर्वोत्तम संभाव्य TTFB देते, जे सर्व्हरचे योगदान आहे आणि Largest Contentful Paint साठी एक चांगली सुरुवात आहे. परंतु LCP, CLS आणि INP हे मुख्यत्वे पृष्ठाद्वारेच ठरवले जातात — चित्रांचे आकार, रेंडरिंग रोखणारी संसाधने, लेआउटची स्थिरता आणि मुख्य-थ्रेड JavaScript. आमचा स्टॅक सर्व्हरचे योगदान जलद आणि सुसंगत बनवतो; फ्रंट-एंड पेलोड हलका ठेवणे हेच उर्वरित अंतर भरून काढते.

१४ दिवसांसाठी मोफत वापरून पहा

तुमच्या पहिल्या साइट्स १४ दिवसांसाठी मोफत सुरू करा — कार्डची आवश्यकता नाही. अस्तित्वात असलेले नेटवर्क स्थलांतरित करत आहात? स्थलांतर विनामूल्य आणि अमर्यादित आहे.

विनामूल्य सुरू करा