WordPress होस्टिंग और प्लगइन्स
WordPress को तेज़ और सुरक्षित बनाना: एक परफॉर्मेंस और प्लगइन चेकलिस्ट
WordPress केवल उतना ही तेज़ और सुरक्षित है जितना कि इस पर चलने वाला सिस्टम। यहाँ वह व्यावहारिक चेकलिस्ट दी गई है जिसे हम होस्ट किए जाने वाले प्रत्येक WordPress साइट पर लागू करते हैं — क्या कैश करना है, क्या सुरक्षित करना है, और कौन से प्लगइन्स अपनी जगह बनाते हैं बनाम जिन्हें यह प्लेटफ़ॉर्म निरर्थक बना देता है।
WordPress उतना ही अच्छा है जितना इसे चलाने वाला सॉफ़्टवेयर है
WordPress वेब का एक बड़ा हिस्सा संचालित करता है क्योंकि यह लचीला है, लेकिन वह लचीलापन यह भी कारण है कि यह धीरा और असुरक्षित हो जाता है: एक डिफ़ॉल्ट इंस्टॉल प्रति पेज दर्जनों बार डेटाबेस को क्वेरी करता है, देखने वाले किसी भी व्यक्ति को अपना वर्शन और स्टैक प्रसारित करता है, और आपको तब तक प्लगइन्स जोड़ने के लिए आमंत्रित करता है जब तक कि प्रदर्शन और हमला करने योग्य सतह दोनों चुपचाप न बढ़ जाएं। इनमें से कोई भी WordPress में कोई दोष नहीं है, बल्कि यह इसे ऐसे बुनियादी ढांचे पर चलाने का परिणाम है जो मदद के लिए कुछ नहीं करता।
अच्छी खबर यह है कि कुछ गिने-चुने निर्णय इनमें से अधिकांश समस्याओं को ठीक कर देते हैं, और ये निर्णय सामग्री के बजाय स्टैक से जुड़े होते हैं। सही परत पर आक्रामकता से कैश करें, डेटाबेस को मुख्य पाथ से दूर रखें, केवल उन्हीं कुछ प्लगइन्स का उपयोग करें जो वास्तव में इसके योग्य हैं, हर चीज़ को पैच करते रहें, और साइट को अलग-थलग (आइसोलेट) रखें ताकि कोई भी समस्या सीमित रहे। यह पोस्ट वही चेकलिस्ट है, उसी क्रम में जिसे हम प्लेटफ़ॉर्म की प्रत्येक WordPress साइट पर लागू करते हैं।
सर्वर पर कैश करें, केवल किसी प्लगइन में नहीं
WordPress की गति को बढ़ाने का सबसे बड़ा और एकमात्र तरीका अधिकांश विज़िट के लिए WordPress को बिल्कुल भी न चलाना है। एक मानक अनुरोध WordPress को बूट करता है, एक बाइट भेजने से पहले आपके प्लगइन्स को चलाता है और डेटाबेस से क्वेरी करता है; एक फुल-पेज कैश अगले हिट पर सीधे वेब सर्वर से तैयार पेज को परोसता है, और उस पूरे बूट को छोड़ देता है। वह कैश कहाँ रहता है, यह मायने रखता है: एक कैशिंग प्लगइन PHP के अंदर रहता है, इसलिए कैश के जवाब देने से पहले PHP अभी भी शुरू होता है, जबकि सर्वर-लेवल का कैश अनुरोध में पहले जवाब देता है और पेजों को ऐसे रूप में रखता है जिसे सर्वर तुरंत फ्लश कर सके।
हमारे द्वारा होस्ट की जाने वाली हर WordPress साइट सर्वर-स्तरीय LSCache के साथ LiteSpeed Enterprise पर चलती है, और हमारा अपना कैशे प्लगइन डिफ़ॉल्ट रूप से WordPress को इससे सही ढंग से जोड़ता है — यह पहले से इंस्टॉल और ऑटो-अपडेट होता है, इसलिए इसे कॉन्फ़िगर करने या अपडेट रखने की चिंता कम हो जाती है। गैर-LiteSpeed ऑरिजिन पर यही प्लगइन केवल फुल-पेज हेडर उत्सर्जित नहीं करता है और रास्ते से हट जाता है जबकि ऑब्जेक्ट कैशे काम करता रहता है, जिससे माइग्रेट की गई साइट कभी भी आधी-अधूरी कॉन्फ़िगर नहीं रहती। आपकी अपनी चेकलिस्ट के लिए व्यावहारिक नियम: सर्वर पर एक फुल-पेज कैशे, और इसके ऊपर दूसरा कैशे प्लगइन न लगाएं — वे आपस में टकराते हैं।
ऑब्जेक्ट कैश और डेटाबेस
हर अनुरोध एक स्टेटिक पेज नहीं हो सकता। लॉग-इन किए गए सत्र, एडमिन, खोज, कार्ट और किसी भी व्यक्तिगत फ़्रैगमेंट को PHP चलाना पड़ता है, और उनके लिए लक्ष्य एप्लीकेशन को छोड़ना से बदलकर डेटाबेस को छोड़ना हो जाता है। प्रति-साइट ऑब्जेक्ट कैश — हमारे मामले में, Redis — बार-बार होने वाले डेटाबेस रीड के परिणामों को मेमोरी में रखता है, ताकि हर हिट पर डेटाबेस पर समान विकल्पों, ट्रांसिएंट्स और लुकअप की क्वेरी न की जा सके। इसका असर ठीक वहीं दिखाई देता है जहाँ फुल-पेज कैश मदद नहीं कर सकता: ट्रैफ़िक के तहत तेज़ एडमिन, तेज़ कार्ट और बहुत कम डेटाबेस लोड।
वह शब्द जो मायने रखता है वह है पर-साइट। एक साझा ऑब्जेक्ट कैश का मतलब है कि एक व्यस्त या खराब तरीके से लिखा गया साइट बाकी सभी का कैश्ड डेटा हटा सकता है और अपने आस-पास के लोगों के लिए डेटाबेस को भूखा रख सकता है; एक समर्पित पर-साइट कैश, पर-साइट डेटाबेस सीमाओं के साथ, उस ब्लास्ट के दायरे को सीमित रखता है। अपनी चेकलिस्ट पर, लॉग-इन किए गए उपयोगकर्ताओं या स्टोर वाली किसी भी साइट के लिए लगातार ऑब्जेक्ट कैश को गैर-वैकल्पिक मानें, और ऐसी होस्टिंग से सावधान रहें जहाँ इसे किरायेदारों के बीच साझा किया जाता है।
वे प्लगइन्स जो इस्तेमाल करने लायक हैं — और वे जिन्हें यह प्लेटफ़ॉर्म रिप्लेस करता है
आपके द्वारा जोड़ा जाने वाला हर प्लगइन ऐसा कोड है जो अनुरोधों पर चलता है और एक ऐसा दरवाजा है जिससे कोई एक दिन गुजर सकता है, इसलिए इसका ईमानदार लक्ष्य यह है कि सबसे कम प्लगइन हों जो सबसे अधिक काम करें। एक अच्छा होस्ट उनमें से पूरी श्रेणी की आवश्यकता को समाप्त कर देता है: सर्वर-स्तरीय कैचिंग, एक प्रबंधित ऑब्जेक्ट कैच और प्लेटफ़ॉर्म बैकअप के साथ, आपको कैचिंग प्लगइन, एक अलग ऑब्जेक्ट-कैच प्लगइन या बैकअप प्लगइन की आवश्यकता नहीं होती है — वे काम WordPress के नीचे बेहतर तरीके से किए जाते हैं, और उनके ऊपर उन्हें चलाना केवल संघर्ष और ओवरहेड जोड़ता है।
जो कुछ भी चलाने लायक बचा है, वह उन चुनिंदा प्लगइन्स का छोटा समूह है जो वास्तविक क्षमता जोड़ते हैं: वे प्लगइन्स जिनकी आपके साइट को उसके कार्य के लिए वास्तव में आवश्यकता है, और — हमारे प्लेटफ़ॉर्म पर — दो रेपो-ग्रेड प्लगइन्स जिन्हें हम प्रत्येक साइट के साथ बनाते और शिप करते हैं। हमारा कैशे प्लगइन WordPress को सर्वर कैशे से जोड़ता है और स्मार्ट पर्जिंग को संभालता है ताकि एक संपादन केवल उन्हीं पृष्ठों को साफ़ करे जिन्हें इसे करना चाहिए। हमारा फ़ुटप्रिंट प्लगइन हर डिप्लॉय पर डिफ़ॉल्ट WordPress इंस्टॉल द्वारा प्रसारित होने वाले संकेतों — वर्शन और जेनरेटर टैग, डिस्कवरी एंडपॉइंट्स, XML-RPC, पिंगबैक्स और पावर्ड-बाय हेडर — को हटा देता है, ताकि कोई प्लगइन या थीम अपडेट चुपचाप उन्हें वापस न ला सके। दोनों WordPress.org प्लगइन-डायरेक्टरी मानकों के अनुसार बनाए गए हैं, मुफ़्त हैं, और खुद को अपडेट करते हैं।
WordPress को सुरक्षित और अपडेट रखना
ज़्यादादा WordPress सुरक्षा उल्लंघन चालाक नहीं होते; वे पुराने होते हैं। एक पुराना कोर, थीम या प्लगइन जिसमें जानी-मानी और प्रकाशित कमज़ोरी हो, साइटों के शिकार होने का सबसे आम तरीका है, जो अप-टू-डेट रहना सबसे मूल्यवान सुरक्षा कार्य बनाता है — और सबसे थकाऊ भी, इसीलिए इसे छोड़ दिया जाता है। मैनेज्ड होस्टिंग को इसे आपके ज़िम्मे से हटा देना चाहिए: WordPress के नीचे के स्टैक को पैच करना, और आपको परीक्षण के लिए एक स्टेजिंग कॉपी और रोल बैक करने के लिए एक बैकअप देकर कोर और प्लगइन अपडेट को लागू करने के लिए सुरक्षित बनाना।
मुद्रा के अलावा, सीमाओं के लागू होने की भी अपेक्षा रखें: मैलवेयर स्कैनिंग डिफ़ॉल्ट रूप से चालू है ताकि किसी संक्रमण को आगंतुक द्वारा खोजे जाने के बजाय समय रहते पकड़ा जा सके, आइसोलेशन ताकि एक समझौता किया गया साइट दूसरे तक न पहुँच सके, किनारे पर डीडीओएस सुरक्षा, और हर जगह टीएलएस, प्रमाणपत्रों के साथ जो स्वचालित रूप से नवीनीकृत होते हैं। इनमें से कोई भी चीज़ बुनियादी स्वच्छता की जगह नहीं लेती — मजबूत क्रेडेंशियल्स, न्यूनतम- विशेषाधिकार पहुंच, उन प्लगइन को हटाना जिनका आप अब उपयोग नहीं करते हैं — लेकिन इसका मतलब यह है कि बुनियादी ढांचा कमजोर कड़ी नहीं है। आपकी चेकलिस्ट पर, किसी भी होस्ट के लिए सवाल सीधा है: क्या सुरक्षा डिफ़ॉल्ट है, या कोई ऐसा बंडल जिसे आप खरीदते हैं?
WooCommerce और वे पृष्ठ जिन्हें आपको कभी कैश नहीं करना चाहिए
एक स्टोर वह जगह है जहाँ आक्रामक कैशिंग (aggressive caching) से सबसे बड़ा फायदा मिलता है और अगर यह नासमझ हो, तो सबसे ज़्यादा नुकसान भी होता है। कैटलॉग, उत्पाद और श्रेणी के पेज आपके सबसे ज़्यादा ट्रैफ़िक वाले, सबसे ज़्यादा कैश किए जाने सकने वाले पेज होते हैं, और उन्हें फुल-पेज कैश से सर्व करना किसी स्टोर की गति के लिए सबसे बेहतरीन काम है। लेकिन कार्ट, चेकआउट और अकाउंट पेज व्यक्तिगत होते हैं और इन्हें कभी भी शेयर किए गए कैश से सर्व नहीं किया जाना चाहिए — ऐसा करने पर एक खरीदार को किसी और की टोकरी (बास्केट) दिखाई देगी, जो कि एक टूटा हुआ स्टोर और गोपनीयता की विफलता, दोनों है।
दोनों चीजें हासिल करने का तरीका यह है कि पेज को कैश किया जाए और लाइव हिस्सों के लिए होल पंचिंग की जाए। Edge Side Includes प्रति अनुरोध कार्ट फ़्रैगमेंट, मिनी-कार्ट टोटल और अकाउंट स्टेट को रेंडर करते हैं, जबकि बाकी पेज कैश से सर्व किया जाता है, और कार्ट, चेकआउट, माइ-अकाउंट तथा कोई भी नॉन्स या सेशन पेज डिफ़ॉल्ट रूप से बाहर रखे जाते हैं। ताज़गी को स्मार्ट ऑटो-पर्ज द्वारा संभाला जाता है जो उत्पाद, कीमत या ऑर्डर बदलने पर सक्रिय होता है, जिससे कोई पुरानी कीमत कभी बनी नहीं रहती। यदि आप WooCommerce चलाते हैं, तो चेकलिस्ट का यह वह हिस्सा है जिसे बिल्कुल सही करना है: कैश से तेज़ स्टोरफ़्रंट, प्रति उपयोगकर्ता लाइव कार्ट, और कोई भी व्यक्तिगत चीज़ कभी कैश न हो।
अक्सर पूछे जाने वाले प्रश्न
क्या मुझे अभी भी WP Rocket जैसे कैशिंग प्लगइन की आवश्यकता है?
नहीं। फुल-पेज कैशिंग वेब सर्वर पर LiteSpeed के LSCache द्वारा संभाली जाती है, हमारा अपना कैश प्लगइन WordPress को इससे जोड़ता है और स्मार्ट पर्जिंग को संभालता है, और इसके पीछे प्रति-साइट (per-site) Redis ऑब्जेक्ट कैश होता है। इसके ऊपर दूसरा फुल-पेज कैशिंग प्लगइन जोड़ने से आमतौर पर सर्वर-स्तरीय कैश को मदद मिलने के बजाय उससे टकराव होता है, इसलिए इसकी न तो कोई आवश्यकता है और न ही इसकी अनुशंसा की जाती है।
यह प्लेटफ़ॉर्म कौन से प्लगइन्स को अनावश्यक बना देता है?
कैचिंग प्लगइन, अलग ऑब्जेक्ट-कैश प्लगइन और बैकअप प्लगइन यहाँ सभी अनावश्यक हैं, क्योंकि वे काम WordPress के नीचे किए जाते हैं — सर्वर-स्तरीय कैशिंग, प्रबंधित प्रति-साइट ऑब्जेक्ट कैश और प्लेटफ़ॉर्म बैकअप। उन्हें हटाने से संघर्ष और अटैक सरफेस कम होते हैं। जो चलाने लायक बचा है, वह वे प्लगइन हैं जिनकी आपके साइट को इसके कार्य के लिए वास्तविक रूप से आवश्यकता है, साथ ही हमारे दो मुफ़्त कैश और फ़ुटप्रिंट प्लगइन, जो पहले से इंस्टॉल आते हैं।
क्या कैशिंग (caching) मेरे WooCommerce कार्ट या लॉग-इन किए गए पृष्ठों को तोड़ देगी?
संख्या. कार्ट, चेकआउट, मेरा-खाता और कोई भी नॉनसेंस या सत्र पृष्ठ डिफ़ॉल्ट रूप से कैश से बाहर रखे जाते हैं, और एज साइड इन्क्लूड्स अन्यथा कैश किए गए पृष्ठों पर कार्ट फ़्रैगमेंट और कुल को लाइव रखते हैं। खरीदार हमेशा अपनी बास्केट और एक काम करने वाला चेकआउट देखते हैं, जबकि स्टोरफ्रंट अभी भी कैश से लोड होता है, और स्मार्ट ऑटो-पर्ज किसी उत्पाद, कीमत या ऑर्डर में बदलाव होने पर प्रभावित पृष्ठों को साफ़ कर देता है।
मैं इसे प्रबंधित किए बिना WordPress को सुरक्षित कैसे रख सकता हूँ?
हम WordPress के नीचे के स्टैक को पैच करते हैं, स्टेजिंग और वन-क्लिक रिस्टोर के साथ कोर और प्लगइन अपडेट को लागू करना सुरक्षित बनाते हैं, डिफ़ॉल्ट रूप से मैलवेयर स्कैनिंग और DDoS सुरक्षा चलाते हैं, प्रत्येक साइट को अलग करते हैं ताकि एक संक्रमण फैल न सके, और TLS प्रमाणपत्रों को स्वचालित रूप से जारी और नवीनीकृत करते हैं। यह बुनियादी ढांचें को कमजोर कड़ी के रूप में हटा देता है; मजबूत क्रेडेंशियल और उपयोग न किए जाने वाले प्लगइन को हटाने जैसी बुनियादी स्वच्छता अभी भी आपकी ज़िम्मेदारी है।
संबंधित
14 दिन के लिए निःशुल्क आज़माएँ
अपनी पहली साइटें 14 दिनों के लिए मुफ़्त में शुरू करें — किसी कार्ड की आवश्यकता नहीं है। किसी मौजूदा साइट या नेटवर्क को ले जा रहे हैं? आपका पहला माइग्रेशन हमारी तरफ़ से है।
निःशुल्क शुरू करें