CDN वापरू नका

साइट गती ऑप्टिमाइझ करण्यासाठी जवळजवळ प्रत्येक लेख किंवा साधनामध्ये "CDN वापरा" असे माफक कलम आहे. सर्वसाधारणपणे, CDN एक सामग्री वितरण नेटवर्क किंवा सामग्री वितरण नेटवर्क आहे. आम्ही मेथड लॅबमध्ये अनेकदा या विषयावर क्लायंटकडून प्रश्नांचा सामना करतो; त्यापैकी काही त्यांचे स्वतःचे CDN सक्षम करतात. साइट लोडिंग गतीच्या बाबतीत CDN काय प्रदान करू शकते, कोणत्या समस्या उद्भवू शकतात आणि कोणत्या परिस्थितीत CDN चा वापर न्याय्य आहे हे समजून घेणे हा या लेखाचा उद्देश आहे.

चित्रात प्रदक्षिणा घालण्यात येणारा विलंब CDN च्या वापरामुळे होतो.

इतिहास एक बिट

अनेक तंत्रज्ञानाप्रमाणे, सीडीएन आवश्यकतेतून बाहेर पडले. इंटरनेट वापरकर्त्यांमध्ये इंटरनेट चॅनेलच्या विकासासह, ऑनलाइन व्हिडिओ सेवा दिसू लागल्या. स्वाभाविकच, व्हिडिओ सामग्रीसाठी नियमित वेबसाइट सामग्री (चित्रे, मजकूर आणि CSS किंवा JS कोड) च्या तुलनेत अधिक बँडविड्थच्या ऑर्डरची आवश्यकता असते.

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

वैयक्तिक सर्व्हरचे चॅनेल मर्यादित करण्याची समस्या CDN द्वारे उत्तम प्रकारे सोडवली जाते. क्लायंट थेट सर्व्हरशी कनेक्ट होत नाहीत, परंतु CDN नेटवर्कमधील नोड्सशी. आदर्श परिस्थितीत, सर्व्हर CDN नोडवर एक प्रवाह पाठवतो आणि नंतर नेटवर्क अनेक वापरकर्त्यांना हा प्रवाह वितरीत करण्यासाठी स्वतःच्या संसाधनांचा वापर करतो. आर्थिक दृष्टिकोनातून, आम्ही प्रत्यक्षात वापरलेल्या संसाधनांसाठीच पैसे देतो (हे बँडविड्थ किंवा रहदारी असू शकते) आणि आमच्या सेवेची उत्कृष्ट स्केलेबिलिटी मिळवा. जड सामग्री वितरीत करण्यासाठी CDN वापरणे पूर्णपणे न्याय्य आणि तार्किक आहे. जरी हे लक्षात घेण्यासारखे आहे की या जागेतील सर्वात मोठे खेळाडू (उदा. Netflix) मोठे व्यावसायिक CDN (अकामाई, क्लाउडफ्लेअर, फास्टली इ.) वापरण्याऐवजी त्यांचे स्वतःचे CDN तयार करत आहेत.

जसजसे वेब विकसित होत गेले, तसतसे वेब ऍप्लिकेशन स्वतःच अधिक क्लिष्ट आणि गुंतागुंतीचे झाले आहेत. लोडिंग स्पीडचा प्रश्न ऐरणीवर आला. वेबसाइट स्पीड उत्साहींनी त्वरीत अनेक प्रमुख समस्या ओळखल्या ज्यामुळे वेबसाइट्स हळू हळू लोड होतात. त्यापैकी एक नेटवर्क विलंब होता (RTT - राउंड ट्रिप वेळ किंवा पिंग वेळ). वेबसाइट लोडिंगमधील अनेक प्रक्रियांवर विलंब होतो: TCP कनेक्शन स्थापित करणे, TLS सत्र सुरू करणे, प्रत्येक वैयक्तिक संसाधन लोड करणे (प्रतिमा, JS फाइल, HTML दस्तऐवज इ.)

HTTP/1.1 प्रोटोकॉल (SPDY, QUIC आणि HTTP/2 च्या आगमनापूर्वी हा एकमेव पर्याय होता) वापरताना, ब्राउझर एका होस्टसाठी 6 पेक्षा जास्त TCP कनेक्शन उघडत नाहीत या वस्तुस्थितीमुळे समस्या वाढली. या सर्वांमुळे कनेक्शन डाउनटाइम आणि चॅनेल बँडविड्थचा अकार्यक्षम वापर झाला. डोमेन शार्डिंगद्वारे समस्या अंशतः सोडवली गेली - कनेक्शनच्या संख्येवरील मर्यादा ओलांडण्यासाठी अतिरिक्त होस्ट तयार करणे.

येथेच CDN ची दुसरी क्षमता दिसून येते - मोठ्या संख्येने पॉइंट्स आणि वापरकर्त्याच्या नोड्सच्या समीपतेमुळे लेटन्सी (RTT) कमी करणे. अंतर येथे निर्णायक भूमिका बजावते: प्रकाशाचा वेग मर्यादित आहे (ऑप्टिकल फायबरमध्ये सुमारे 200 किमी/सेकंद). याचा अर्थ असा की प्रत्येक 000 किमी प्रवासात RTT मध्ये 1000 एमएस विलंब किंवा 5 एमएस जोडतो. ट्रान्समिशनसाठी लागणारा हा किमान वेळ आहे, कारण मध्यवर्ती उपकरणांवर देखील विलंब होतो. CDN ला सामान्यतः त्याच्या सर्व्हरवर ऑब्जेक्ट्स कसे कॅशे करायचे हे माहित असल्याने, अशा ऑब्जेक्ट्स CDN द्वारे लोड केल्याने आम्हाला फायदा होऊ शकतो. यासाठी आवश्यक अटी: कॅशेमध्ये ऑब्जेक्टची उपस्थिती, वेब ऍप्लिकेशन सर्व्हर (ओरिजिन सर्व्हर) च्या तुलनेत वापरकर्त्याला CDN पॉइंटची समीपता. हे समजून घेणे महत्त्वाचे आहे की CDN नोडची भौगोलिक समीपता कमी विलंबाची हमी देत ​​नाही. क्लायंट आणि CDN मधील राउटिंग अशा प्रकारे तयार केले जाऊ शकते की क्लायंट दुसर्या देशातील होस्टशी कनेक्ट होईल आणि शक्यतो दुसर्या खंडात. येथेच दूरसंचार ऑपरेटर आणि CDN सेवा (पीअरिंग, कनेक्शन, IX मध्ये सहभाग, इ.) यांच्यातील संबंध आणि CDN चे ट्रॅफिक मार्ग धोरण लागू होते. उदाहरणार्थ, Cloudflare, दोन प्रारंभिक योजना (विनामूल्य आणि स्वस्त) वापरताना, जवळच्या होस्टकडून सामग्रीच्या वितरणाची हमी देत ​​​​नाही - किमान खर्च साध्य करण्यासाठी होस्ट निवडला जाईल.

बर्‍याच आघाडीच्या इंटरनेट कंपन्या लोडिंग स्पीड आणि वेबसाइट कार्यप्रदर्शन या विषयाकडे सार्वजनिक हित (वेब ​​विकसक आणि सेवा मालक) आकर्षित करतात. या कंपन्यांमध्ये याहू (Yslow टूल), AOL (वेबपेजटेस्ट) आणि Google (पेज स्पीड इनसाइट्स सेवा) आहेत, ज्या साइट्सला गती देण्यासाठी त्यांच्या स्वतःच्या शिफारसी विकसित करत आहेत (प्रामुख्याने ते क्लायंट ऑप्टिमायझेशनशी संबंधित आहेत). नंतर, नवीन वेबसाइट स्पीड टेस्टिंग टूल्स दिसतात, जे वेबसाइट स्पीड वाढवण्याच्या टिप्स देखील देतात. यापैकी प्रत्येक सेवा किंवा प्लगइनची एक सुसंगत शिफारस आहे: "CDN वापरा." नेटवर्क लेटन्सी कमी होणे हे सहसा CDN च्या प्रभावाचे स्पष्टीकरण म्हणून उद्धृत केले जाते. दुर्दैवाने, प्रत्येकजण CDN चा प्रवेग प्रभाव कसा साधला जातो आणि तो कसा मोजला जाऊ शकतो हे समजून घेण्यास तयार नाही, म्हणून शिफारस विश्वासावर घेतली जाते आणि पोस्टुलेट म्हणून वापरली जाते. खरं तर, सर्व CDN समान तयार केलेले नाहीत.

CDN आज वापरणे

CDN वापरण्याच्या उपयुक्ततेचे मूल्यांकन करण्यासाठी, त्यांचे वर्गीकरण करणे आवश्यक आहे. आता सरावात काय आढळू शकते (कंसातील उदाहरणे अर्थातच संपूर्ण नाहीत):

1. JS लायब्ररी वितरीत करण्यासाठी मोफत CDN (MaxCDN, Google. Yandex).
2. क्लायंट ऑप्टिमायझेशनसाठी सेवांचा CDN (उदाहरणार्थ, फॉन्टसाठी Google फॉन्ट, क्लाउडिनरी, प्रतिमांसाठी क्लाउड इमेज).
3. CMS मध्ये स्थिर आणि संसाधन ऑप्टिमायझेशनसाठी CDN (Bitrix, WordPress आणि इतरांमध्ये उपलब्ध).
4. सामान्य उद्देश CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. वेबसाइट प्रवेगसाठी CDN (क्लाउडफ्लेअर, इम्परवा, एअरी).

या प्रकारांमधील महत्त्वाचा फरक म्हणजे CDN मधून किती रहदारी जाते. प्रकार 1-3 सामग्रीचा फक्त एक भाग वितरित करतात: एका विनंतीपासून अनेक डझनपर्यंत (सामान्यतः चित्रे). प्रकार 4 आणि 5 हे CDN द्वारे ट्रॅफिकचे संपूर्ण प्रॉक्सींग आहेत.

सराव मध्ये, याचा अर्थ साइट लोड करण्यासाठी वापरल्या जाणार्‍या कनेक्शनची संख्या. HTTP/2 सह, आम्ही कितीही विनंत्यांवर प्रक्रिया करण्यासाठी होस्टला एकल TCP कनेक्शन वापरतो. जर आम्ही संसाधने मुख्य होस्ट (मूळ) आणि CDN मध्ये विभाजित केली, तर अनेक डोमेनवर विनंत्या वितरित करणे आणि अनेक TCP कनेक्शन तयार करणे आवश्यक आहे. सर्वात वाईट स्थिती आहे: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. हे सूत्र डिव्हाइसच्या रेडिओ चॅनेलच्या सक्रियतेसाठी मोबाइल नेटवर्कमध्ये होणारा विलंब (ते सक्रिय नसल्यास) आणि सेल टॉवरवरील विलंब विचारात घेत नाही.

साइटच्या लोडिंग धबधब्यावर ते कसे दिसते ते येथे आहे (CDN शी कनेक्ट करण्यासाठी लेटेंसी RTT 150 ms वर हायलाइट केल्या आहेत):

जर CDN सर्व साइट ट्रॅफिक (तृतीय-पक्ष सेवा वगळता) कव्हर करत असेल, तर आम्ही एकल TCP कनेक्शन वापरू शकतो, अतिरिक्त होस्टशी कनेक्ट होण्यात होणारा विलंब वाचवू शकतो. अर्थात, हे HTTP/2 कनेक्शनवर लागू होते.

पुढील फरक विशिष्ट CDN च्या कार्यक्षमतेद्वारे निर्धारित केले जातात - पहिल्या प्रकारासाठी ते फक्त एक स्थिर फाइल होस्ट करत आहे, पाचव्यासाठी ते ऑप्टिमायझेशनच्या उद्देशाने साइट सामग्रीचे अनेक प्रकार बदलत आहे.

वेबसाइट प्रवेगासाठी CDN क्षमता

सीडीएनच्या वैयक्तिक प्रकारांच्या कार्यक्षमतेचा विचार न करता, साइट्सला गती देण्यासाठी सीडीएन क्षमतांच्या संपूर्ण श्रेणीचे वर्णन करूया आणि नंतर त्या प्रत्येकामध्ये काय लागू केले आहे ते पाहू.

1. मजकूर संसाधनांचे कॉम्प्रेशन

सर्वात मूलभूत आणि समजण्यायोग्य वैशिष्ट्य, तरीही बर्याचदा खराबपणे अंमलात आणले जाते. सर्व CDN त्यांच्या प्रवेग वैशिष्ट्य म्हणून कॉम्प्रेशनची उपस्थिती घोषित करतात. परंतु आपण अधिक तपशीलवार पाहिल्यास, कमतरता स्पष्ट होतील:

• डायनॅमिक कॉम्प्रेशनसाठी कमी अंश वापरले जाऊ शकतात - 5-6 (उदाहरणार्थ, gzip साठी कमाल 9 आहे);
• स्टॅटिक कॉम्प्रेशन (कॅशेमधील फायली) अतिरिक्त वैशिष्ट्ये वापरत नाहीत (उदाहरणार्थ, डिग्री 11 सह झॉपफी किंवा ब्रॉटली)
• कार्यक्षम ब्रॉटली कॉम्प्रेशनसाठी कोणतेही समर्थन नाही (जीझिपच्या तुलनेत सुमारे 20% बचत).

तुम्ही CDN वापरत असल्यास, हे काही मुद्दे तपासण्यासारखे आहे: CDN वरून आलेली फाईल घ्या, तिचा संकुचित आकार रेकॉर्ड करा आणि तुलना करण्यासाठी ती मॅन्युअली कॉम्प्रेस करा (उदाहरणार्थ, तुम्ही ब्रॉटली सपोर्टसह काही ऑनलाइन सेवा वापरू शकता. vsszhat.rf).

2. क्लायंट कॅशिंग शीर्षलेख सेट करणे

तसेच एक साधे स्पीडअप वैशिष्ट्य: क्लायंट (ब्राउझर) द्वारे सामग्री कॅशिंगसाठी शीर्षलेख जोडा. सर्वात वर्तमान शीर्षलेख कॅशे-नियंत्रण आहे, जुने कालबाह्य झाले आहे. याव्यतिरिक्त, Etag वापरले जाऊ शकते. मुख्य गोष्ट अशी आहे की कॅशे-नियंत्रणाचे कमाल-वय पुरेसे मोठे आहे (एक महिना किंवा त्याहून अधिक) जर तुम्ही संसाधन शक्य तितक्या कठोरपणे कॅशे करण्यास तयार असाल, तर तुम्ही अपरिवर्तनीय पर्याय जोडू शकता.

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

3. प्रतिमा ऑप्टिमायझेशन

CDN प्रतिमा कॅशिंग आणि सर्व्हिंगची कार्ये घेत असल्याने, त्यांना CDN बाजूने ऑप्टिमाइझ करणे आणि वापरकर्त्यांना या फॉर्ममध्ये सेवा देणे तर्कसंगत असेल. हे वैशिष्ट्य फक्त CDN प्रकार 2, 3 आणि 5 साठी उपलब्ध आहे हे लगेच आरक्षण करूया.

तुम्ही प्रतिमा विविध प्रकारे ऑप्टिमाइझ करू शकता: प्रगत कॉम्प्रेशन फॉरमॅट्स (जसे की WebP), अधिक कार्यक्षम एन्कोडर (MozJPEG) वापरून किंवा फक्त अनावश्यक मेटाडेटा साफ करणे.

सर्वसाधारणपणे, अशा ऑप्टिमायझेशनचे दोन प्रकार आहेत: गुणवत्तेच्या नुकसानासह आणि गुणवत्तेच्या नुकसानाशिवाय. प्रतिमेच्या गुणवत्तेतील बदलांबद्दल ग्राहकांच्या संभाव्य तक्रारी टाळण्यासाठी CDN सहसा लॉसलेस ऑप्टिमायझेशन वापरण्याचा प्रयत्न करतात. अशा परिस्थितीत, नफा कमीतकमी असेल. प्रत्यक्षात, बर्‍याचदा JPEG गुणवत्ता पातळी आवश्यकतेपेक्षा खूप जास्त असते आणि वापरकर्त्याच्या अनुभवाशी तडजोड न करता तुम्ही सुरक्षितपणे खालच्या गुणवत्तेच्या पातळीसह पुन्हा संकुचित करू शकता. दुसरीकडे, सर्व संभाव्य वेब ऍप्लिकेशन्ससाठी गुणवत्ता आणि सेटिंग्जची पातळी सार्वत्रिकपणे निर्धारित करणे कठीण आहे, त्यामुळे संदर्भ लक्षात घेऊन लागू केल्या जाऊ शकतात त्या तुलनेत सीडीएन अधिक पुराणमतवादी सेटिंग्ज वापरतात (प्रतिमांचा उद्देश, वेब अनुप्रयोगाचा प्रकार , इ.)

4. TLS कनेक्शन ऑप्टिमाइझ करणे

आज बहुतेक ट्रॅफिक TLS कनेक्शनवरून प्रवास करतात, याचा अर्थ आम्ही TLS वाटाघाटींवर अतिरिक्त वेळ घालवतो. अलीकडे, या प्रक्रियेला गती देण्यासाठी नवीन तंत्रज्ञान विकसित केले गेले आहे. उदाहरणार्थ, हे EC क्रिप्टोग्राफी, TLS 1.3, सत्र कॅशे आणि तिकिटे, हार्डवेअर एन्क्रिप्शन प्रवेग (AES-NI), इ. योग्यरित्या TLS सेट केल्याने कनेक्शन वेळ 0-1 RTT (DNS आणि TCP मोजत नाही) कमी होऊ शकतो.

आधुनिक सॉफ्टवेअरसह, अशा पद्धती स्वतःच अंमलात आणणे कठीण नाही.

सर्व CDN TLS सर्वोत्तम पद्धती लागू करत नाहीत; तुम्ही TLS कनेक्शन वेळ मोजून हे तपासू शकता (उदाहरणार्थ, वेबपेजटेस्टमध्ये). नवीन कनेक्शनसाठी आदर्श - 1RTT, 2RTT - सरासरी पातळी, 3RTT आणि अधिक - खराब.

हे देखील लक्षात घेतले पाहिजे की CDN स्तरावर TLS वापरताना, आमच्या वेब अनुप्रयोगासह सर्व्हरने TLS देखील प्रक्रिया करणे आवश्यक आहे, परंतु CDN बाजूने, कारण सर्व्हर आणि CDN मधील रहदारी सार्वजनिक नेटवर्कवरून जाते. सर्वात वाईट परिस्थितीत, आम्हाला दुहेरी TLS कनेक्शन विलंब मिळेल (सीडीएन होस्टला पहिला, तो आणि आमच्या सर्व्हरमधील दुसरा).

काही ऍप्लिकेशन्ससाठी, सुरक्षा समस्यांकडे लक्ष देणे योग्य आहे: ट्रॅफिक सहसा CDN नोड्सवर डिक्रिप्ट केले जाते आणि ट्रॅफिक व्यत्यय आणण्याची ही संभाव्य संधी आहे. रहदारीच्या प्रकटीकरणाशिवाय काम करण्याचा पर्याय सामान्यतः अतिरिक्त शुल्कासाठी शीर्ष दर योजनांमध्ये ऑफर केला जातो.

5. कनेक्शन विलंब कमी करा

CDN चा मुख्य फायदा ज्याबद्दल प्रत्येकजण बोलतो: CDN होस्ट आणि वापरकर्ता यांच्यातील कमी विलंबता (कमी अंतर). भौगोलिकदृष्ट्या वितरित नेटवर्क आर्किटेक्चर तयार करून प्राप्त केले, ज्यामध्ये होस्ट वापरकर्त्यांच्या एकाग्रतेच्या बिंदूंमध्ये स्थित आहेत (शहरे, रहदारी विनिमय बिंदू इ.)

सराव मध्ये, भिन्न नेटवर्कसाठी प्राधान्यक्रम विशिष्ट क्षेत्रांमध्ये असू शकतात. उदाहरणार्थ, रशियन सीडीएनची रशियामध्ये उपस्थितीचे अधिक गुण असतील. अमेरिकन सर्व प्रथम यूएसए मध्ये नेटवर्क विकसित करतील. उदाहरणार्थ, सर्वात मोठ्या सीडीएन क्लाउडफ्लेअरमध्ये रशियामध्ये फक्त 2 गुण आहेत - मॉस्को आणि सेंट पीटर्सबर्ग. म्हणजेच, मॉस्कोमधील थेट प्लेसमेंटच्या तुलनेत आम्ही कमाल 10 ms लेटन्सी वाचवू शकतो.

बहुतेक पाश्चात्य CDN ला रशियामध्ये अजिबात गुण नाहीत. त्यांच्याशी कनेक्ट करून, आपण केवळ आपल्या रशियन प्रेक्षकांसाठी विलंब वाढवू शकता.

6. सामग्री ऑप्टिमायझेशन (मिनिफिकेशन, संरचनात्मक बदल)

सर्वात जटिल आणि तांत्रिकदृष्ट्या प्रगत बिंदू. वितरणादरम्यान सामग्री बदलणे खूप धोकादायक असू शकते. जरी आम्ही मिनिफिकेशन घेतले तरीही: स्त्रोत कोड कमी केल्याने (अतिरिक्त जागा, बिनमहत्त्वाची रचना इ.) त्याच्या कार्यक्षमतेवर परिणाम करू शकते. जर आपण अधिक गंभीर बदलांबद्दल बोललो - जेएस कोडला एचटीएमएलच्या शेवटी हलवणे, फायली एकत्र करणे इ. - साइटच्या कार्यक्षमतेत व्यत्यय आणण्याचा धोका अधिक आहे.

म्हणून, फक्त काही प्रकार 5 CDN हे करतात. अर्थात, गोष्टींना गती देण्यासाठी आवश्यक असलेले सर्व बदल स्वयंचलित करणे शक्य होणार नाही—मॅन्युअल विश्लेषण आणि ऑप्टिमायझेशन आवश्यक आहे. उदाहरणार्थ, न वापरलेले किंवा डुप्लिकेट कोड काढणे हे मॅन्युअल कार्य आहे.

नियमानुसार, अशी सर्व ऑप्टिमायझेशन सेटिंग्जद्वारे नियंत्रित केली जातात आणि सर्वात धोकादायक डीफॉल्टनुसार अक्षम केली जातात.

CDN प्रकारानुसार प्रवेग क्षमतांसाठी समर्थन

त्यामुळे विविध प्रकारचे CDN कोणत्या संभाव्य प्रवेग संधी प्रदान करतात ते पाहू या.

सोयीसाठी, आम्ही वर्गीकरण पुन्हा करतो.

1. JS लायब्ररी वितरीत करण्यासाठी मोफत CDN (MaxCDN, Google. Yandex).
2. क्लायंट ऑप्टिमायझेशनसाठी सेवांचा CDN (उदाहरणार्थ, फॉन्टसाठी Google फॉन्ट, क्लाउडिनरी, प्रतिमांसाठी क्लाउड इमेज).
3. CMS मध्ये स्थिर आणि संसाधन ऑप्टिमायझेशनसाठी CDN (Bitrix, WordPress आणि इतरांमध्ये उपलब्ध).
4. सामान्य उद्देश CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. वेबसाइट प्रवेगसाठी CDN (क्लाउडफ्लेअर, इम्परवा, एअरी).

आता CDN ची वैशिष्ट्ये आणि प्रकारांची तुलना करूया.

संधी
1 टाइप करा
2 टाइप करा
3 टाइप करा
4 टाइप करा
5 टाइप करा

मजकूर कॉम्प्रेशन
+–
-
+–
+–
+

कॅशे शीर्षलेख
+
+
+
+
+

चित्रे
-
+–
+–
-
+

TLS
-
-
-
+–
+

विलंब होतो
-
-
-
+
+

सामग्री
-
-
-
-
+

या सारणीमध्ये, "+" पूर्ण समर्थन दर्शवण्यासाठी वापरले जाते, "–" समर्थन नाही आणि "+–" आंशिक समर्थन आहे. अर्थात, प्रत्यक्षात या सारणीतून काही विचलन असू शकतात (उदाहरणार्थ, काही सामान्य-उद्देश सीडीएन प्रतिमा ऑप्टिमाइझ करण्यासाठी वैशिष्ट्ये लागू करतील), परंतु सामान्य कल्पनांसाठी ते उपयुक्त आहे.

परिणाम

आशा आहे की, हा लेख वाचल्यानंतर तुम्हाला तुमच्या साइट्सचा वेग वाढवण्यासाठी "CDN वापरा" शिफारशीशी संबंधित एक स्पष्ट चित्र असेल.

कोणत्याही व्यवसायाप्रमाणे, आपण कोणत्याही सेवेच्या विपणन आश्वासनांवर विश्वास ठेवू शकत नाही. वास्तविक परिस्थितीत परिणाम मोजणे आणि तपासणे आवश्यक आहे. तुम्ही आधीच CDN वापरत असल्यास, लेखात वर्णन केलेल्या निकषांचा वापर करून परिणामकारकता तपासा.

हे शक्य आहे की आत्ता CDN वापरल्याने तुमच्या साइटची लोडिंग वेळ कमी होत आहे.

सामान्य शिफारस म्हणून, आम्ही खालील गोष्टींवर लक्ष केंद्रित करू शकतो: तुमच्या प्रेक्षकांचा अभ्यास करा, त्याची भौगोलिक व्याप्ती निश्चित करा. जर तुमचे मुख्य प्रेक्षक 1-2 हजार किलोमीटरच्या त्रिज्यामध्ये केंद्रित असतील, तर तुम्हाला त्याच्या मुख्य उद्देशासाठी CDN ची आवश्यकता नाही - विलंब कमी करणे. त्याऐवजी, तुम्ही तुमचा सर्व्हर तुमच्या वापरकर्त्यांच्या जवळ ठेवू शकता आणि लेखात वर्णन केलेले बहुतांश ऑप्टिमायझेशन (विनामूल्य आणि कायमस्वरूपी) मिळवून ते योग्यरित्या कॉन्फिगर करू शकता.

जर तुमचे प्रेक्षक भौगोलिकदृष्ट्या (3000 किलोमीटरपेक्षा जास्त त्रिज्या) वितरित केले गेले असतील तर, दर्जेदार CDN वापरणे खरोखर उपयुक्त ठरेल. तथापि, तुमची सीडीएन नेमकी काय गती वाढवू शकते हे तुम्हाला आगाऊ समजून घेणे आवश्यक आहे (क्षमतेचे सारणी आणि त्यांचे वर्णन पहा). तथापि, वेबसाइट प्रवेग अजूनही एक जटिल कार्य आहे जे CDN कनेक्ट करून सोडवता येत नाही. वरील ऑप्टिमायझेशन व्यतिरिक्त, प्रवेग करण्याचे सर्वात प्रभावी माध्यम CDN च्या मागे राहतात: सर्व्हरच्या भागाचे ऑप्टिमायझेशन, क्लायंटच्या भागामध्ये प्रगत बदल (न वापरलेले कोड काढून टाकणे, प्रस्तुतीकरण प्रक्रिया ऑप्टिमाइझ करणे, सामग्रीसह कार्य करणे, फॉन्ट, अनुकूलता इ. )

स्त्रोत: www.habr.com