მესამე მხარის რესურსების თვითმასპინძლობა: კარგი, ცუდი, მახინჯი

ბოლო წლების განმავლობაში, უფრო და უფრო მეტი პლატფორმა ფრონტ-ენდის პროექტების ოპტიმიზაციისთვის გვთავაზობს შესაძლებლობებს თვითჰოსტინგის ან მესამე მხარის რესურსების პროქსირებისთვის. Akamai გაძლევთ საშუალებას დააყენოთ კონკრეტული პარამეტრები თვითშექმნილი URL-ებისთვის. Cloudflare-ს აქვს Edge Workers ტექნოლოგია. Fasterzine შეუძლია გადაწერა URL-ები გვერდებზე ისე, რომ ისინი მიუთითებენ მესამე მხარის რესურსებზე, რომლებიც მდებარეობს საიტის მთავარ დომენზე.

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

კარგი: გაუმჯობესებული შესრულება

სხვისი რესურსების თვითმმართველობა აუმჯობესებს შესრულებას ძალიან აშკარა გზით. ბრაუზერს არ სჭირდება DNS ხელახლა წვდომა, არ სჭირდება TCP კავშირის დამყარება და TLS ხელის ჩამორთმევა მესამე მხარის დომენზე. თქვენ შეგიძლიათ ნახოთ, თუ როგორ მოქმედებს სხვისი რესურსების თვითმმართველობა, შესრულებაზე შემდეგი ორი ფიგურის შედარებით.

მესამე მხარის რესურსები ჩამოტვირთულია გარე წყაროებიდან (აღებულია აქედან გამომდინარე,)

მესამე მხარის რესურსები ინახება იმავე ადგილას, სადაც საიტის დანარჩენი მასალები (აღებულია აქედან გამომდინარე,)

მდგომარეობას აუმჯობესებს ის ფაქტიც, რომ ბრაუზერი გამოიყენებს მთავარ დომენთან უკვე დამყარებული HTTP/2 კავშირიდან მონაცემების მულტიპლექსირებისა და პრიორიტეტის მინიჭების შესაძლებლობას.

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

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

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

• შეგიძლიათ უზრუნველყოთ, რომ გამოყენებულია მონაცემთა შეკუმშვის ალგორითმი, რომელიც საუკეთესოდ შეესაბამება თითოეულ ბრაუზერს (Brotli/gzip).
• თქვენ შეგიძლიათ გაზარდოთ ქეშირების დრო რესურსებისთვის, რომლებიც, როგორც წესი, არც თუ ისე გრძელია, თუნდაც ყველაზე ცნობილ პროვაიდერებთან (მაგალითად, GA ტეგის შესაბამისი მნიშვნელობა დაყენებულია 30 წუთზე).

თქვენ შეგიძლიათ კიდევ გააფართოვოთ TTL რესურსისთვის, ვთქვათ, ერთ წლამდე, თქვენი ქეშირების მართვის სტრატეგიაში შესაბამისი შინაარსის ჩართვით (URL ჰეშები, ვერსიების და ა.შ.). ამაზე ქვემოთ ვისაუბრებთ.

▍მესამე მხარის სერვისების ფუნქციონირების შეფერხებისგან ან მათი გათიშვისგან დაცვა

მესამე მხარის რესურსების თვითჰოსტინგის კიდევ ერთი საინტერესო ასპექტი არის ის, რომ ის საშუალებას გაძლევთ შეამციროთ მესამე მხარის სერვისების გათიშვასთან დაკავშირებული რისკები. დავუშვათ, რომ მესამე მხარის A/B ტესტირების გადაწყვეტა, რომელსაც თქვენ იყენებთ, დანერგილია როგორც ბლოკირების სკრიპტი, რომელიც იტვირთება გვერდის სათაურ განყოფილებაში. ეს სკრიპტი ნელა იტვირთება. თუ შესაბამისი სკრიპტი ვერ ჩაიტვირთება, გვერდი ცარიელი იქნება. თუ ჩატვირთვას ძალიან დიდი დრო დასჭირდება, გვერდი დიდი დაგვიანებით გამოჩნდება. ან, დავუშვათ, რომ პროექტი იყენებს ბიბლიოთეკას, რომელიც გადმოწერილია მესამე მხარის CDN რესურსიდან. წარმოვიდგინოთ, რომ ამ რესურსმა განიცადა მარცხი ან დაბლოკილი იყო კონკრეტულ ქვეყანაში. ასეთი ვითარება გამოიწვევს საიტის ლოგიკის დარღვევას.

იმის გასარკვევად, თუ როგორ მუშაობს თქვენი საიტი, როდესაც ზოგიერთი გარე სერვისი მიუწვდომელია, შეგიძლიათ გამოიყენოთ SPOF განყოფილება webpagetest.org.

SPOF განყოფილება webpagetest.org-ზე

▍ რაც შეეხება ბრაუზერებში მასალების ქეშირების პრობლემებს? (მინიშნება: ეს მითია)

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

ვთქვათ, გვაქვს რამდენიმე განსხვავებული საიტი: website1.com, website2.com, website3.com. ყველა ეს საიტი იყენებს jQuery ბიბლიოთეკას. ჩვენ მას ვუკავშირდებით მათ CDN-ის გამოყენებით, მაგალითად - googleapis.com. შეგიძლიათ ველოდოთ, რომ ბრაუზერი ერთხელ ჩამოტვირთავს და ქეშებს ბიბლიოთეკას და შემდეგ გამოიყენებს მას სამივე საიტზე. ამან შეიძლება შეამციროს დატვირთვა ქსელში. შესაძლოა, ეს საშუალებას მოგცემთ დაზოგოთ ფული სადმე და დაგეხმაროთ რესურსების მუშაობის გაუმჯობესებაში. პრაქტიკული თვალსაზრისით, ყველაფერი სხვაგვარად გამოიყურება. მაგალითად, Safari-ს აქვს ფუნქცია ე.წ ინტელექტუალური თვალყურის დევნის პრევენცია: ქეში იყენებს ორმაგ კლავიშს, რომელიც ეფუძნება დოკუმენტის წყაროს და მესამე მხარის რესურსის წყაროს. აქ კარგი სტატია ამ თემაზე.

ძველი კვლევები Yahoo и Facebook, ისევე როგორც უფრო უახლესი კვლევა პოლ კალვანო, აჩვენეთ, რომ რესურსები არ ინახება ბრაუზერის ქეშებში იმდენ ხანს, რამდენიც შეიძლება მოველით: „პროექტის საკუთარი და მესამე მხარის რესურსების ქეშირების დროს შორის სერიოზული უფსკრულია. საუბარია CSS-ზე და ვებ ფონტებზე. კერძოდ, მშობლიური შრიფტების 95%-ს აქვს ქეშის ვადა კვირაზე მეტი, ხოლო მესამე მხარის შრიფტების 50%-ს აქვს ქეში კვირაზე ნაკლები! ეს აძლევს ვებ დეველოპერებს დამაჯერებელ მიზეზს, რომ თავად უმასპინძლონ შრიფტის ფაილებს!”

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

ახლა, როდესაც ჩვენ განვიხილეთ მესამე მხარის თვითჰოსტინგის ძლიერი მხარეები, მოდით ვისაუბროთ იმაზე, თუ როგორ განვასხვავოთ ამ მიდგომის კარგი განხორციელება ცუდიდან.

ცუდი: ეშმაკი დეტალებშია

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

აქ ერთ-ერთი მთავარი პრობლემა არის ქეშირების დრო. მაგალითად, ვერსიის ინფორმაცია შედის მესამე მხარის სკრიპტის სახელებში, როგორიცაა: jquery-3.4.1.js. ასეთი ფაილი არ შეიცვლება მომავალში და შედეგად ეს არ გამოიწვევს რაიმე პრობლემას მის ქეშირებასთან დაკავშირებით.

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

მართალია, თუ ვსაუბრობთ მასალებზე, რომლებიც ხშირად განახლდება (ტეგ მენეჯერები, გადაწყვეტილებები A/B ტესტირებისთვის), მაშინ მათი ქეშირება CDN ინსტრუმენტების გამოყენებით არის ამოცანა, რომელიც შეიძლება გადაჭრას, მაგრამ ბევრად უფრო რთული. სერვისები, როგორიცაა Commanders Act, ტეგების მართვის გადაწყვეტა, იყენებენ ვებჰუკებს ახალი ვერსიების გამოქვეყნებისას. ეს გაძლევთ შესაძლებლობას აიძულოთ ქეშის გარეცხვა CDN-ზე, ან, კიდევ უკეთესი, ჰაშის ან URL-ის განახლების იძულების უნარი.

▍მასალების ადაპტირებული მიწოდება კლიენტებისთვის

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

აქ შეგიძლიათ გახსოვდეთ ორი სერვისი. პირველი არის googlefonts.com. მეორე არის polyfill.io. Google Fonts სერვისი უზრუნველყოფს, გარკვეული რესურსისთვის, სხვადასხვა CSS კოდს, ბრაუზერის შესაძლებლობებიდან გამომდინარე (ბმულების მიცემა woff2 რესურსების გამოყენებით unicode-range).

აქ მოცემულია Google Fonts-ის რამდენიმე მოთხოვნის შედეგები, რომლებიც შესრულებულია სხვადასხვა ბრაუზერებიდან.

Google Fonts-ის მოთხოვნის შედეგი Chrome-იდან

Google Fonts-ის მოთხოვნის შედეგი შესრულებულია IE10-დან

Polyfill.io ბრაუზერს აძლევს მხოლოდ მისთვის საჭირო პოლიფილებს. ეს კეთდება შესრულების მიზეზების გამო.

მაგალითად, მოდით შევხედოთ რა მოხდება, თუ თქვენ შეასრულებთ შემდეგ მოთხოვნას სხვადასხვა ბრაუზერებიდან: https://polyfill.io/v3/polyfill.js?features=default

IE10-დან შესრულებული ასეთი მოთხოვნის საპასუხოდ, მიიღება 34 KB მონაცემები. და მასზე პასუხი, შესრულებული Chrome-დან, ცარიელი იქნება.

გაბრაზებული: კონფიდენციალურობის ზოგიერთი მოსაზრება

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

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

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

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

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

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

შედეგები

თუ მალე აპირებთ მესამე მხარის რესურსების თვითჰოსტინგის განხორციელებას, ნება მომეცით მოგცეთ რამდენიმე რჩევა:

• განათავსეთ თქვენი ყველაზე მნიშვნელოვანი JS ბიბლიოთეკები, შრიფტები და CSS ფაილები. ეს შეამცირებს საიტის უკმარისობის ან მუშაობის დეგრადაციის რისკს, რადგან საიტისთვის სასიცოცხლოდ მნიშვნელოვანი რესურსი მიუწვდომელია მესამე მხარის სერვისის შეცდომის გამო.
• სანამ მესამე მხარის რესურსებს CDN-ზე ქეშირებთ, დარწმუნდით, რომ მათი ფაილების დასახელებისას გამოყენებულია რაიმე სახის ვერსიების სისტემა, ან შეგიძლიათ მართოთ ამ რესურსების სასიცოცხლო ციკლი CDN ქეშის ხელით ან ავტომატურად გადაყენებით, ახალი ვერსიის გამოქვეყნებისას. სცენარი.
• იყავით ძალიან ფრთხილად თქვენი CDN, პროქსი სერვერისა და ქეშის პარამეტრებზე. ეს საშუალებას მოგცემთ თავიდან აიცილოთ თქვენი პროექტის ან სათაურების ქუქიების გაგზავნა Client-Hints მესამე მხარის მომსახურება.

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

წყარო: www.habr.com