[არ] გამოიყენო CDN

საიტის სიჩქარის ოპტიმიზაციის თითქმის ყველა სტატიას ან ინსტრუმენტს აქვს მოკრძალებული პუნქტი "გამოიყენე CDN". ზოგადად, CDN არის შინაარსის მიწოდების ქსელი ან შინაარსის მიწოდების ქსელი. ჩვენ მეთოდოლოგიურ ლაბორატორიაში ხშირად ვხვდებით კლიენტების კითხვებს ამ თემაზე; ზოგიერთი მათგანი ჩართავს საკუთარ CDN-ს. ამ სტატიის მიზანია იმის გაგება, თუ რა შეუძლია უზრუნველყოს CDN-ს საიტის ჩატვირთვის სიჩქარის თვალსაზრისით, რა პრობლემები შეიძლება წარმოიშვას და რა შემთხვევაშია გამართლებული CDN-ის გამოყენება.

სურათზე შემოხაზული შეფერხებები გამოწვეულია CDN-ის გამოყენებით.

პატარა ისტორიის

მრავალი ტექნოლოგიების მსგავსად, CDN-ები წარმოიშვა აუცილებლობის გამო. ინტერნეტის მომხმარებლებში ინტერნეტ არხების განვითარებით, გამოჩნდა ონლაინ ვიდეო სერვისები. ბუნებრივია, ვიდეო კონტენტი მოითხოვს უფრო მეტ სიჩქარეს ვებსაიტის ჩვეულებრივ შინაარსთან შედარებით (სურათები, ტექსტი და CSS ან JS კოდი).

როდესაც ცდილობთ ვიდეო ნაკადის გადაცემას მრავალი კლიენტის პარალელურად ერთი სერვერიდან, სერვერის ინტერნეტ არხი, სავარაუდოდ, გახდება ბოსტნე. როგორც წესი, რამდენიმე ათასი თემა საკმარისია ტიპიური სერვერის არხის დასაბლოკად. რა თქმა უნდა, შეიძლება არსებობდეს რესურსების სხვა შეზღუდვები, მაგრამ ისინი ამჟამად არ არის მნიშვნელოვანი. ასევე მნიშვნელოვანია, რომ სერვერის არხის გაფართოება ძალიან ძვირია (და ზოგჯერ შეუძლებელი) და ასევე არაპრაქტიკული. გადაცემის დროს არხზე დატვირთვა ციკლური იქნება.

ცალკეული სერვერის არხის შეზღუდვის პრობლემა მშვენივრად მოგვარებულია CDN-ით. კლიენტები პირდაპირ არ უკავშირდებიან სერვერს, არამედ კვანძებს CDN ქსელში. იდეალურ სიტუაციაში სერვერი აგზავნის ერთ ნაკადს CDN კვანძში და შემდეგ ქსელი იყენებს საკუთარ რესურსებს ამ ნაკადის მრავალი მომხმარებლისთვის მიწოდებისთვის. ეკონომიკური თვალსაზრისით, ჩვენ ვიხდით მხოლოდ რეალურად მოხმარებულ რესურსებს (ეს შეიძლება იყოს გამტარუნარიანობა ან ტრაფიკი) და ვიღებთ ჩვენი სერვისის შესანიშნავი მასშტაბურობას. CDN-ის გამოყენება მძიმე შინაარსის მიწოდებისთვის სრულიად გამართლებული და ლოგიკურია. თუმცა აღსანიშნავია, რომ ამ სივრცეში ყველაზე დიდი მოთამაშეები (მაგ. Netflix) აშენებენ საკუთარ CDN-ებს დიდი კომერციული CDN-ების გამოყენების ნაცვლად (Akamai, Cloudflare, Fastly და ა.შ.)

ვებგვერდის განვითარებასთან ერთად, თავად ვებ აპლიკაციები უფრო რთული და რთული გახდა. წინა პლანზე წამოვიდა დატვირთვის სიჩქარის პრობლემა. ვებსაიტის სიჩქარის მოყვარულებმა სწრაფად დაადგინეს რამდენიმე ძირითადი პრობლემა, რამაც გამოიწვია ვებსაიტების ნელა ჩატვირთვა. ერთ-ერთი მათგანი იყო ქსელის შეფერხებები (RTT - ორმხრივი მგზავრობის დრო ან პინგ დრო). შეფერხებები გავლენას ახდენს ვებსაიტების ჩატვირთვის ბევრ პროცესზე: TCP კავშირის დამყარება, TLS სესიის დაწყება, თითოეული ინდივიდუალური რესურსის ჩატვირთვა (სურათი, JS ფაილი, HTML დოკუმენტი და ა.შ.)

პრობლემა გამწვავდა იმით, რომ HTTP/1.1 პროტოკოლის გამოყენებისას (SPDY, QUIC და HTTP/2 ეს იყო ერთადერთი ვარიანტი), ბრაუზერები ხსნიან არაუმეტეს 6 TCP კავშირს ერთ ჰოსტთან. ამ ყველაფერმა გამოიწვია კავშირის შეფერხება და არხის გამტარუნარიანობის არაეფექტური გამოყენება. პრობლემა ნაწილობრივ მოგვარდა დომენის გაზიარებით - დამატებითი ჰოსტების შექმნა კავშირების რაოდენობის ლიმიტის დასაძლევად.

სწორედ აქ ჩნდება CDN-ის მეორე შესაძლებლობა - შეყოვნების შემცირება (RTT) ქულების დიდი რაოდენობისა და მომხმარებელთან კვანძების სიახლოვის გამო. მანძილი აქ გადამწყვეტ როლს თამაშობს: სინათლის სიჩქარე შეზღუდულია (დაახლოებით 200 კმ/წმ ოპტიკურ ბოჭკოში). ეს ნიშნავს, რომ ყოველი 000 კმ მგზავრობისას ემატება 1000 ms დაგვიანება ან 5 ms RTT. ეს არის მინიმალური დრო, რომელიც საჭიროა გადაცემისთვის, რადგან შუალედურ აღჭურვილობაზეც არის შეფერხებები. ვინაიდან CDN-მა ჩვეულებრივ იცის როგორ მოახდინოს ობიექტების ქეშირება თავის სერვერებზე, ჩვენ შეგვიძლია ვისარგებლოთ ასეთი ობიექტების ჩატვირთვით CDN-ის მეშვეობით. ამისათვის აუცილებელი პირობები: ობიექტის არსებობა ქეშში, CDN წერტილის სიახლოვე მომხმარებლისთვის ვებ აპლიკაციის სერვერთან (origin server) შედარებით. მნიშვნელოვანია გვესმოდეს, რომ CDN კვანძის გეოგრაფიული სიახლოვე არ იძლევა დაბალი შეყოვნების გარანტიას. კლიენტსა და CDN-ს შორის მარშრუტი შეიძლება აშენდეს ისე, რომ კლიენტი დაუკავშირდეს ჰოსტს სხვა ქვეყანაში და შესაძლოა სხვა კონტინენტზე. სწორედ აქ მოქმედებს კავშირი ტელეკომის ოპერატორებსა და CDN სერვისს შორის (პირინგი, კავშირები, მონაწილეობა IX-ში და ა.შ.) და თავად CDN-ის ტრაფიკის მარშრუტიზაციის პოლიტიკა. მაგალითად, Cloudflare ორი საწყისი გეგმის (უფასო და იაფი) გამოყენებისას არ იძლევა გარანტიას კონტენტის მიწოდებაზე უახლოესი ჰოსტიდან – ჰოსტი შეირჩევა მინიმალური ღირებულების მისაღწევად.

ბევრი წამყვანი ინტერნეტ კომპანია იზიდავს საზოგადოების ინტერესს (ვებ დეველოპერები და სერვისის მფლობელები) ჩატვირთვის სიჩქარისა და ვებსაიტის მუშაობის თემის მიმართ. ამ კომპანიებს შორისაა Yahoo (Yslow ინსტრუმენტი), AOL (WebPageTest) და Google (Page Speed ​​​​Insights სერვისი), რომლებიც ავითარებენ საკუთარ რეკომენდაციებს საიტების დაჩქარების მიზნით (უპირველეს ყოვლისა ისინი ეხება კლიენტის ოპტიმიზაციას). მოგვიანებით გამოჩნდება ვებსაიტის სიჩქარის ტესტირების ახალი ინსტრუმენტები, რომლებიც ასევე გვაწვდიან რჩევებს ვებსაიტის სიჩქარის გაზრდის შესახებ. თითოეულ ამ სერვისს ან დანამატს აქვს თანმიმდევრული რეკომენდაცია: „გამოიყენე CDN“. ქსელის შეყოვნების შემცირება ჩვეულებრივ ციტირებულია როგორც CDN-ის ეფექტის ახსნა. სამწუხაროდ, ყველა არ არის მზად ზუსტად გაიგოს, თუ როგორ მიიღწევა CDN-ის აჩქარების ეფექტი და როგორ შეიძლება მისი გაზომვა, ამიტომ რეკომენდაცია აღებულია რწმენაზე და გამოიყენება პოსტულატად. სინამდვილეში, ყველა CDN არ არის შექმნილი თანაბარი.

გამოიყენეთ CDN დღეს

CDN-ების გამოყენების სარგებლიანობის შესაფასებლად, საჭიროა მათი კლასიფიცირება. რა შეგიძლიათ ნახოთ ახლა პრაქტიკაში (მაგალითები ფრჩხილებში, რა თქმა უნდა, არ არის ამომწურავი):

1. უფასო CDN JS ბიბლიოთეკების გავრცელებისთვის (MaxCDN, Google. Yandex).
2. კლიენტის ოპტიმიზაციის სერვისების CDN (მაგალითად, Google Fonts შრიფტებისთვის, Cloudinary, Cloudimage სურათებისთვის).
3. CDN სტატიკური და რესურსების ოპტიმიზაციისთვის CMS-ში (ხელმისაწვდომია Bitrix-ში, WordPress-ში და სხვებში).
4. ზოგადი დანიშნულების CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ვებსაიტის აჩქარებისთვის (Cloudflare, Imperva, Airi).

ამ ტიპებს შორის მთავარი განსხვავებაა ტრაფიკის რამდენი გადის 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 შესაძლებლობები ვებსაიტის აჩქარებისთვის

მოდით აღვწეროთ CDN შესაძლებლობების სრული დიაპაზონი საიტების დაჩქარებისთვის, CDN-ის ცალკეული ტიპების ფუნქციონალურობის გათვალისწინების გარეშე და შემდეგ ვნახოთ, რა არის დანერგილი თითოეულ მათგანში.

1. ტექსტური რესურსების შეკუმშვა

ყველაზე ძირითადი და გასაგები ფუნქცია, მაგრამ ხშირად ცუდად განხორციელებული. ყველა CDN აცხადებს შეკუმშვის არსებობას, როგორც მათი აჩქარების ფუნქციას. მაგრამ თუ უფრო დეტალურად განიხილავთ, ნაკლოვანებები აშკარა გახდება:

• დაბალი გრადუსი დინამიური შეკუმშვისთვის შეიძლება გამოყენებულ იქნას - 5-6 (მაგალითად, gzip-ისთვის მაქსიმალურია 9);
• სტატიკური შეკუმშვა (ფაილები ქეშში) არ იყენებს დამატებით ფუნქციებს (მაგალითად, zopfi ან brotli მე-11 ხარისხით)
• არ არსებობს ბროტლის ეფექტური შეკუმშვის მხარდაჭერა (დაზოგავს დაახლოებით 20% gzip-თან შედარებით).

თუ იყენებთ CDN-ს, ღირს ამ რამდენიმე პუნქტის შემოწმება: აიღეთ ფაილი, რომელიც მოვიდა CDN-დან, ჩაწერეთ მისი შეკუმშული ზომა და შეკუმშეთ იგი ხელით შედარებისთვის (შეგიძლიათ გამოიყენოთ ზოგიერთი ონლაინ სერვისი brotli-ს მხარდაჭერით, მაგალითად, vsszhat.rf).

2. კლიენტის ქეშირების სათაურების დაყენება

ასევე მარტივი სიჩქარის ფუნქცია: დაამატეთ სათაურები კლიენტის (ბრაუზერის) მიერ შინაარსის ქეშირებისთვის. ყველაზე აქტუალური სათაური არის ქეში-კონტროლი, მოძველებული იწურება. გარდა ამისა, Etag შეიძლება გამოყენებულ იქნას. მთავარია, რომ cache-control-ის მაქსიმალური ასაკი იყოს საკმარისად დიდი (ერთი თვიდან და მეტი), თუ მზად ხართ რესურსის ქეშირება მაქსიმალურად მყარი, შეგიძლიათ დაამატოთ უცვლელი ვარიანტი.

CDN-ებს შეუძლიათ შეამცირონ მაქსიმალური ასაკის მნიშვნელობა, რაც აიძულებს მომხმარებელს უფრო ხშირად გადატვირთოს სტატიკური შინაარსი. გაუგებარია რასთან არის დაკავშირებული ეს: ქსელში ტრაფიკის გაზრდის სურვილს ან საიტებთან თავსებადობის გაზრდას, რომლებმაც არ იციან როგორ აღადგინონ ქეში. მაგალითად, ნაგულისხმევი Cloudflare სათაურის ქეშის დრო არის 1 საათი, რაც ძალიან დაბალია უცვლელი სტატიკური მონაცემებისთვის.

3. გამოსახულების ოპტიმიზაცია

ვინაიდან CDN იღებს სურათების ქეშირებისა და სერვისის ფუნქციებს, ლოგიკური იქნება მათი ოპტიმიზაცია CDN მხარეს და ამ ფორმით მომხმარებლებს მიეწოდება. მოდით დაუყოვნებლივ გავაკეთოთ დაჯავშნა, რომ ეს ფუნქცია ხელმისაწვდომია მხოლოდ CDN ტიპის 2, 3 და 5-ისთვის.

სურათების ოპტიმიზაცია შეგიძლიათ სხვადასხვა გზით: გაფართოებული შეკუმშვის ფორმატების გამოყენებით (როგორიცაა WebP), უფრო ეფექტური ენკოდერები (MozJPEG) ან უბრალოდ არასაჭირო მეტამონაცემების გასუფთავება.

ზოგადად, ასეთი ოპტიმიზაციის ორი ტიპი არსებობს: ხარისხის დაკარგვით და ხარისხის დაკარგვის გარეშე. CDN-ები, როგორც წესი, ცდილობენ გამოიყენონ უზარმაზარ ოპტიმიზაცია, რათა თავიდან აიცილონ მომხმარებლების შესაძლო საჩივრები გამოსახულების ხარისხის ცვლილებებთან დაკავშირებით. ასეთ პირობებში მოგება მინიმალური იქნება. სინამდვილეში, ხშირად JPEG ხარისხის დონე გაცილებით მაღალია ვიდრე საჭიროა და შეგიძლიათ უსაფრთხოდ შეკუმშოთ დაბალი ხარისხის დონით, მომხმარებლის გამოცდილებაზე კომპრომეტირების გარეშე. მეორე მხრივ, ძნელია ხარისხისა და პარამეტრების დონის დადგენა უნივერსალურად ყველა შესაძლო ვებ აპლიკაციისთვის, ამიტომ CDN-ები უფრო კონსერვატიულ პარამეტრებს იყენებენ მათთან შედარებით, რომელთა გამოყენება შესაძლებელია კონტექსტის გათვალისწინებით (სურათების დანიშნულება, ვებ აპლიკაციის ტიპი). და ა.შ.)

4. TLS კავშირის ოპტიმიზაცია

დღეს ტრაფიკის უმეტესობა გადადის TLS კავშირებზე, რაც ნიშნავს, რომ ჩვენ დამატებით დროს ვხარჯავთ TLS მოლაპარაკებებზე. ამ პროცესის დასაჩქარებლად ბოლო დროს შემუშავდა ახალი ტექნოლოგიები. მაგალითად, ეს არის EC კრიპტოგრაფია, TLS 1.3, სესიების ქეში და ბილეთები, ტექნიკის დაშიფვრის დაჩქარება (AES-NI) და ა.შ. TLS-ის სწორად დაყენებამ შეიძლება შეამციროს კავშირის დრო 0-1 RTT-მდე (DNS და TCP-ის გარეშე).

თანამედროვე პროგრამული უზრუნველყოფის საშუალებით, ასეთი პრაქტიკის დამოუკიდებლად განხორციელება არ არის რთული.

ყველა CDN არ ახორციელებს TLS საუკეთესო პრაქტიკას; ამის შემოწმება შეგიძლიათ TLS კავშირის დროის გაზომვით (მაგალითად, Webpagetest-ში). იდეალურია ახალი კავშირისთვის - 1RTT, 2RTT - საშუალო დონე, 3RTT და მეტი - ცუდი.

აქვე უნდა აღინიშნოს, რომ CDN დონეზე TLS-ის გამოყენებისასაც, სერვერმა ჩვენი ვებ აპლიკაციით ასევე უნდა დაამუშავოს TLS, მაგრამ CDN მხრიდან, რადგან სერვერსა და CDN-ს შორის ტრაფიკი გადის საჯარო ქსელში. უარეს შემთხვევაში, ჩვენ მივიღებთ ორმაგ TLS კავშირის შეფერხებებს (პირველი CDN ჰოსტში, მეორე მასა და ჩვენს სერვერს შორის).

ზოგიერთი აპლიკაციისთვის ღირს ყურადღების მიქცევა უსაფრთხოების საკითხებზე: ტრაფიკი ჩვეულებრივ გაშიფრულია CDN კვანძებზე და ეს არის ტრაფიკის ჩარევის პოტენციური შესაძლებლობა. ტრაფიკის გამჟღავნების გარეშე მუშაობის შესაძლებლობა ჩვეულებრივ შემოთავაზებულია ტოპ სატარიფო გეგმებში დამატებითი საფასურისთვის.

5. შეამცირეთ კავშირის შეფერხებები

CDN-ის მთავარი სარგებელი, რომელზეც ყველა საუბრობს: დაბალი შეყოვნება (ნაკლები მანძილი) CDN ჰოსტსა და მომხმარებელს შორის. მიღწეულია გეოგრაფიულად განაწილებული ქსელის არქიტექტურის შექმნით, რომელშიც ჰოსტები განლაგებულია მომხმარებლების კონცენტრაციის წერტილებში (ქალაქები, ტრაფიკის გაცვლის წერტილები და ა.შ.)

პრაქტიკაში, სხვადასხვა ქსელის პრიორიტეტები შეიძლება იყოს კონკრეტულ რეგიონებში. მაგალითად, რუსულ CDN-ებს ექნებათ მეტი ადგილი რუსეთში. ამერიკელები ქსელს პირველ რიგში აშშ-ში განავითარებენ. მაგალითად, ერთ-ერთ უდიდეს CDN Cloudflare-ს აქვს მხოლოდ 2 ქულა რუსეთში - მოსკოვსა და სანკტ-პეტერბურგში. ანუ, ჩვენ შეგვიძლია დაზოგოთ მაქსიმუმ დაახლოებით 10 ms შეყოვნება მოსკოვში პირდაპირ განთავსებასთან შედარებით.

დასავლური CDN-ების უმეტესობას საერთოდ არ აქვს ქულები რუსეთში. მათთან დაკავშირებით, თქვენ შეგიძლიათ მხოლოდ გაზარდოთ შეფერხებები თქვენი რუსი აუდიტორიისთვის.

6. კონტენტის ოპტიმიზაცია (მინიმიზაცია, სტრუქტურული ცვლილებები)

ყველაზე რთული და ტექნოლოგიურად მოწინავე წერტილი. მიწოდების დროს შინაარსის შეცვლა შეიძლება ძალიან სარისკო იყოს. თუნდაც ავიღოთ მინიმიზაცია: წყაროს კოდის შემცირება (დამატებითი სივრცეების, უმნიშვნელო სტრუქტურების და ა.შ. გამო) შეიძლება გავლენა იქონიოს მის შესრულებაზე. თუ ვსაუბრობთ უფრო სერიოზულ ცვლილებებზე - JS კოდის HTML-ის ბოლოში გადატანა, ფაილების გაერთიანება და ა.შ. - საიტის ფუნქციონირების დარღვევის რისკი კიდევ უფრო მაღალია.

აქედან გამომდინარე, მხოლოდ ზოგიერთი ტიპის 5 CDN აკეთებს ამას. რა თქმა უნდა, შეუძლებელი იქნება ყველა ცვლილების ავტომატიზაცია, რომელიც საჭიროა პროცესის დასაჩქარებლად - საჭიროა ხელით ანალიზი და ოპტიმიზაცია. მაგალითად, გამოუყენებელი ან დუბლიკატი კოდის ამოღება არის ხელით დავალება.

როგორც წესი, ყველა ასეთი ოპტიმიზაცია კონტროლდება პარამეტრებით და ყველაზე საშიში გამორთულია ნაგულისხმევად.

აჩქარების შესაძლებლობების მხარდაჭერა CDN ტიპის მიხედვით

მოდით შევხედოთ რა პოტენციურ აჩქარების შესაძლებლობებს იძლევა სხვადასხვა ტიპის CDN-ები.

მოხერხებულობისთვის, ჩვენ ვიმეორებთ კლასიფიკაციას.

1. უფასო CDN JS ბიბლიოთეკების გავრცელებისთვის (MaxCDN, Google. Yandex).
2. კლიენტის ოპტიმიზაციის სერვისების CDN (მაგალითად, Google Fonts შრიფტებისთვის, Cloudinary, Cloudimage სურათებისთვის).
3. CDN სტატიკური და რესურსების ოპტიმიზაციისთვის CMS-ში (ხელმისაწვდომია Bitrix-ში, WordPress-ში და სხვებში).
4. ზოგადი დანიშნულების CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ვებსაიტის აჩქარებისთვის (Cloudflare, Imperva, Airi).

ახლა შევადაროთ CDN-ის მახასიათებლები და ტიპები.

შესაძლებლობა
ტიპი 1
ტიპი 2
ტიპი 3
ტიპი 4
ტიპი 5

ტექსტის შეკუმშვა
+–
-
+–
+–
+

ქეშის სათაურები
+
+
+
+
+

სურათები
-
+–
+–
-
+

TLS
-
-
-
+–
+

დაგვიანებები
-
-
-
+
+

შინაარსი
-
-
-
-
+

ამ ცხრილში „+“ გამოიყენება სრული მხარდაჭერის აღსანიშნავად, „–“ არ არის მხარდაჭერა და „+–“ არის ნაწილობრივი მხარდაჭერა. რა თქმა უნდა, შეიძლება რეალურად იყოს გადახრები ამ ცხრილიდან (მაგალითად, ზოგიერთი ზოგადი დანიშნულების CDN განახორციელებს სურათების ოპტიმიზაციის ფუნქციებს), მაგრამ ზოგადი იდეისთვის ეს სასარგებლოა.

შედეგები

იმედია, ამ სტატიის წაკითხვის შემდეგ თქვენ გექნებათ უფრო მკაფიო სურათი "გამოიყენეთ CDN" რეკომენდაციის შესახებ თქვენი საიტების დაჩქარების მიზნით.

როგორც ნებისმიერ ბიზნესში, თქვენ ვერ დაიჯერებთ რაიმე სერვისის მარკეტინგულ დაპირებებს. ეფექტის გაზომვა და ტესტირება საჭიროა რეალურ პირობებში. თუ უკვე იყენებთ CDN-ს, შეამოწმეთ იგი ეფექტურობისთვის სტატიაში აღწერილი კრიტერიუმების გამოყენებით.

შესაძლებელია, რომ ახლავე CDN-ის გამოყენება ანელებს თქვენი საიტის ჩატვირთვის დროს.

როგორც ზოგადი რეკომენდაცია, შეგვიძლია ყურადღება გავამახვილოთ შემდეგზე: შეისწავლეთ თქვენი აუდიტორია, განსაზღვრეთ მისი გეოგრაფიული არეალი. თუ თქვენი ძირითადი აუდიტორია კონცენტრირებულია 1-2 ათასი კილომეტრის რადიუსში, თქვენ არ გჭირდებათ CDN მისი მთავარი მიზნისთვის - შეფერხების შემცირება. ამის ნაცვლად, თქვენ შეგიძლიათ მოათავსოთ თქვენი სერვერი თქვენს მომხმარებლებთან უფრო ახლოს და სწორად დააკონფიგურიროთ იგი, მიიღოთ სტატიაში აღწერილი ოპტიმიზაციის უმეტესი ნაწილი (უფასო და მუდმივი).

იმ შემთხვევაში, თუ თქვენი აუდიტორია ნამდვილად გეოგრაფიულად არის განაწილებული (რადიუსი 3000 კილომეტრზე მეტი), ხარისხიანი CDN-ის გამოყენება ნამდვილად სასარგებლო იქნება. თუმცა, წინასწარ უნდა გესმოდეთ, რისი დაჩქარება შეუძლია თქვენს CDN-ს (იხ. შესაძლებლობების ცხრილი და მათი აღწერა). ამასთან, ვებსაიტის აჩქარება კვლავ რჩება რთულ ამოცანად, რომლის გადაჭრა შეუძლებელია CDN-ის დაკავშირებით. ზემოაღნიშნული ოპტიმიზაციის გარდა, CDN-ს მიღმა რჩება აჩქარების ყველაზე ეფექტური საშუალებები: სერვერის ნაწილის ოპტიმიზაცია, კლიენტის ნაწილის გაფართოებული ცვლილებები (გამოუყენებელი კოდის ამოღება, რენდერის პროცესის ოპტიმიზაცია, კონტენტთან მუშაობა, შრიფტები, ადაპტირება და ა.შ. )

წყარო: www.habr.com