Son illərdə qabaqcıl layihələri optimallaşdırmaq üçün getdikcə daha çox platforma üçüncü tərəfin resurslarını öz-özünə yerləşdirmək və ya proxy etmək üçün imkanlar təklif edir. Akamai təyin etməyə imkan verir öz-özünə yaradılan URL-lər üçün. Cloudflare Edge Workers texnologiyasına malikdir. Fasterzine bilər Səhifələrdəki URL-lər saytın əsas domenində yerləşən üçüncü tərəf resurslarına işarə edir.
Layihənizdə istifadə olunan üçüncü tərəf xidmətlərinin çox tez-tez dəyişmədiyini və onların müştərilərə çatdırılması prosesinin yaxşılaşdırıla biləcəyini bilirsinizsə, o zaman yəqin ki, bu cür xidmətlərin proksiləşdirilməsi haqqında düşünürsünüz. Bu yanaşma ilə siz bu resursları istifadəçilərinizə çox yaxşı şəkildə yaxınlaşdıra və müştəri tərəfində onların keşləşdirilməsinə daha tam nəzarət edə bilərsiniz. Bu, əlavə olaraq, istifadəçiləri üçüncü tərəf xidmətinin "qəzasından" və ya onun fəaliyyətinin pisləşməsindən yaranan problemlərdən qorumağa imkan verir.
Yaxşı: Təkmilləşdirilmiş performans
Başqasının resurslarını öz-özünə yerləşdirmək performansı çox açıq şəkildə yaxşılaşdırır. Brauzerin yenidən DNS-ə daxil olmasına ehtiyac yoxdur, o, TCP bağlantısı qurmağa və üçüncü tərəf domenində TLS əl sıxma həyata keçirməyə ehtiyac duymur. Aşağıdakı iki rəqəmi müqayisə edərək, başqasının resurslarının öz-özünə yerləşdirilməsinin performansa necə təsir etdiyini görə bilərsiniz.
Üçüncü tərəf resursları xarici mənbələrdən endirilir ( )
Üçüncü tərəf resursları saytın qalan materialları ilə eyni yerdə saxlanılır ( )
Vəziyyət həmçinin brauzerin əsas domenlə artıq qurulmuş HTTP/2 bağlantısından verilənlərin multipleksləşdirilməsi və prioritetləşdirilməsi imkanından istifadə etməsi ilə də yaxşılaşır.
Əgər üçüncü tərəfin resurslarına sahib deyilsinizsə, onlar əsasdan fərqli bir domendən yüklənəcəyinə görə onlara üstünlük verilə bilməz. Bu, onların müştərinin bant genişliyi üçün bir-biri ilə rəqabət aparmasına səbəb olacaq. Bu, ideal şəraitdə əldə edilə biləndən daha uzun bir səhifə yaratmaq üçün kritik məzmunun yükləmə vaxtlarına səbəb ola bilər. bütün bunları çox yaxşı izah edən HTTP/2 prioritetləri haqqında danışın.
Ehtimal etmək olar ki, xarici resurslara keçidlərdə atributlardan istifadə edilir preconnect problemin həllinə kömək edəcək. Bununla belə, müxtəlif domenlərə bu bağlantıların çoxu varsa, o, həqiqətən də ən vacib anda kommunikasiya xəttini həddindən artıq yükləyə bilər.
Üçüncü tərəf resurslarını özünüz yerləşdirirsinizsə, bu resursların müştəriyə tam olaraq necə verildiyinə nəzarət edə bilərsiniz. Məhz, biz aşağıdakılardan danışırıq:
- Siz hər bir brauzerə ən uyğun olan məlumatların sıxılma alqoritmindən istifadə olunduğundan əmin ola bilərsiniz (Brotli/gzip).
- Ən məşhur provayderlərlə belə, adətən çox da uzun olmayan resurslar üçün keşləmə vaxtını artıra bilərsiniz (məsələn, GA etiketi üçün müvafiq dəyər 30 dəqiqəyə təyin edilib).
Siz hətta müvafiq məzmunu keşləmə idarəetmə strategiyanıza (URL hashləri, versiyaların yaradılması və s.) daxil etməklə mənbə üçün TTL-ni, məsələn, bir ilə qədər uzada bilərsiniz. Bu barədə aşağıda danışacağıq.
▍Üçüncü tərəf xidmətlərinin işində fasilələrə və ya onların bağlanmasına qarşı qorunma
Üçüncü tərəf resurslarının öz-özünə yerləşdirilməsinin digər maraqlı cəhəti odur ki, o, üçüncü tərəf xidmətlərinin kəsilməsi ilə bağlı riskləri azaltmağa imkan verir. Fərz edək ki, istifadə etdiyiniz üçüncü tərəf A/B test həlli səhifənin baş hissəsində yüklənən bloklama skripti kimi həyata keçirilir. Bu skript yavaş-yavaş yüklənir. Müvafiq skript yüklənməsə, səhifə boş olacaq. Yükləmək çox uzun çəkirsə, səhifə uzun gecikmə ilə görünəcək. Və ya fərz edək ki, layihə üçüncü tərəfin CDN resursundan endirilmiş kitabxanadan istifadə edir. Təsəvvür edək ki, bu resurs uğursuzluqla üzləşib və ya müəyyən bir ölkədə bloklanıb. Belə bir vəziyyət saytın məntiqinin pozulmasına gətirib çıxaracaq.
Bəzi xarici xidmətlər mövcud olmadıqda saytınızın necə işlədiyini öyrənmək üçün SPOF bölməsindən istifadə edə bilərsiniz .
webpagetest.org saytında SPOF bölməsi
▍Browserlərdə materialların keşləşdirilməsi ilə bağlı problemlər necədir? (işarə: bu bir mifdir)
Düşünə bilərsiniz ki, ictimai CDN-lərdən istifadə avtomatik olaraq daha yaxşı resurs performansına gətirib çıxaracaq, çünki bu xidmətlər kifayət qədər yüksək keyfiyyətli şəbəkələrə malikdir və bütün dünyada yayılır. Ancaq əslində hər şey bir az daha mürəkkəbdir.
Tutaq ki, bir neçə fərqli saytımız var: website1.com, website2.com, website3.com. Bu saytların hamısı jQuery kitabxanasından istifadə edir. Biz onu CDN-dən istifadə edərək onlara bağlayırıq, məsələn - googleapis.com. Brauzerin kitabxananı bir dəfə endirib keşləməsini və sonra onu hər üç saytda istifadə etməsini gözləyə bilərsiniz. Bu, şəbəkədəki yükü azalda bilər. Ola bilsin ki, bu, hardasa pula qənaət etməyə və resursun işini yaxşılaşdırmağa kömək edəcək. Praktik baxımdan hər şey fərqli görünür. Məsələn, Safari adlı bir xüsusiyyət var : Kesh sənədin mənbəyinə və üçüncü tərəf resursunun mənbəyinə əsaslanan ikili açarlardan istifadə edir. bu mövzuda yaxşı məqalə.
köhnə tədqiqatlar и , eləcə də daha yeni Paul Calvano, resursların gözlədiyimiz qədər brauzer keşlərində saxlanmadığını göstərir: “Layihənin öz və üçüncü tərəf resurslarının keşləmə vaxtı arasında ciddi boşluq var. Söhbət CSS və veb şriftlərindən gedir. Məhz, yerli şriftlərin 95%-nin bir həftədən çox, üçüncü tərəf şriftlərinin 50%-nin isə bir həftədən az bir keş ömrü var! Bu, veb tərtibatçılarına şrift fayllarını özləri yerləşdirmək üçün əsaslı səbəb verir!”
Nəticə etibarı ilə, əgər siz başqalarının məzmununa sahib olsanız, brauzerin keşləşdirilməsi nəticəsində yaranan heç bir performans problemini görməyəcəksiniz.
İndi üçüncü tərəfin özünü hostinqinin güclü tərəflərini əhatə etdikdən sonra, bu yanaşmanın yaxşı tətbiqini pisdən necə ayırmaq barədə danışaq.
Pis: Şeytan təfərrüatlardadır
Üçüncü tərəf resurslarının öz domeninizə daşınması, bu cür resursların düzgün yaddaşda saxlanmasını təmin etmədən avtomatik olaraq həyata keçirilə bilməz.
Burada əsas problemlərdən biri keşləmə vaxtıdır. Məsələn, versiya məlumatı bu kimi üçüncü tərəf skript adlarına daxil edilir: jquery-3.4.1.js. Belə bir fayl gələcəkdə dəyişməyəcək və nəticədə bu, onun önbelleğe alınması ilə bağlı heç bir problem yaratmayacaq.
Fayllarla işləyərkən bəzi versiya sxemlərindən istifadə edilmədikdə, fayl adı dəyişməz qaldıqda məzmunu dəyişən keşlənmiş skriptlər köhnələ bilər. Bu, ciddi problem ola bilər, çünki o, məsələn, müştərilərin mümkün qədər tez qəbul etməli olduğu skriptlərə avtomatlaşdırılmış təhlükəsizlik yamaqlarının əlavə edilməsinə imkan vermir. Tərtibatçı keşdəki bu cür skriptləri yeniləmək üçün səy göstərməli olacaq. Bundan əlavə, bu, keşdən müştəridə istifadə olunan kodun layihənin server hissəsinin tərtib olunduğu kodun ən son versiyasından fərqli olması səbəbindən tətbiq uğursuzluqlarına səbəb ola bilər.
Düzdür, tez-tez yenilənən materiallardan danışırıqsa (etiket menecerləri, A/B testi üçün həllər), onda CDN alətlərindən istifadə edərək onların keşləşdirilməsi həll edilə bilən, lakin daha mürəkkəb bir işdir. Teq idarəetmə həlli olan Commanders Act kimi xidmətlər yeni versiyaları dərc edərkən webhooks istifadə edir. Bu, sizə CDN-də keşi silməyə məcbur etmək və ya daha yaxşısı, hash və ya URL yeniləməsini məcbur etmək imkanı verir.
▍Müştərilərə materialların uyğunlaşdırılmış şəkildə çatdırılması
Bundan əlavə, keşləmə haqqında danışarkən, CDN-də istifadə edilən keşləmə parametrlərinin bəzi üçüncü tərəf resursları üçün uyğun olmaya biləcəyini nəzərə almalıyıq. Məsələn, bu cür resurslar həmin brauzerlər üçün xüsusi olaraq optimallaşdırılmış məzmun versiyaları ilə xüsusi brauzerlərə xidmət etmək üçün istifadəçi agenti iyləmə (adaptiv xidmət) texnologiyasından istifadə edə bilər. Bu texnologiyalar brauzerin imkanlarını müəyyən etmək üçün müntəzəm ifadələrə və ya HTTP başlıq məlumat bazasına əsaslanır. User-Agent. Hansı brauzerlə məşğul olduqlarını bildikdən sonra ona bunun üçün hazırlanmış materialları verirlər.
Burada iki xidməti xatırlaya bilərsiniz. Birincisi googlefonts.com-dur. İkincisi polyfill.io-dur. Google Fonts xidməti brauzerin imkanlarından asılı olaraq müəyyən bir resurs üçün müxtəlif CSS kodları təqdim edir (istifadə edərək woff2 resurslarına keçidlər verir). unicode-range).
Budur, müxtəlif brauzerlərdən edilən bir neçə Google Şrift sorğusunun nəticələri.
Chrome-dan Google Şrift sorğusunun nəticəsi
IE10-dan icra edilən Google Fonts sorğusunun nəticəsi
Polyfill.io brauzerə yalnız ehtiyac duyduğu polifillləri verir. Bu, performans səbəbləri ilə edilir.
Məsələn, müxtəlif brauzerlərdən aşağıdakı sorğunu yerinə yetirsəniz nə baş verdiyinə nəzər salaq:
IE10-dan icra edilən belə bir sorğuya cavab olaraq 34 KB məlumat alınacaq. Və ona Chrome-dan verilən cavab boş olacaq.
Qəzəbli: Bəzi məxfilik mülahizələri
Bu nöqteyi-nəzərdən sonuncu, lakin vacib deyil. Məsələ burasındadır ki, layihənin əsas domenində və ya onun subdomenində üçüncü tərəf resurslarının öz-özünə yerləşdirilməsi istifadəçilərin məxfiliyinə təhlükə yarada bilər və əsas veb layihəyə mənfi təsir göstərə bilər.
CDN sisteminiz düzgün konfiqurasiya edilməyibsə, siz domeninizin kukilərini üçüncü tərəf xidmətinə göndərə bilərsiniz. CDN səviyyəsində lazımi filtrləmə təşkil edilməyibsə, adətən JavaScript-də istifadə edilə bilməyən sessiya kukiləri httponly), xarici hosta göndərilə bilər.
Eulerian və ya Criteo kimi izləyicilərlə məhz bu baş verə bilər. Üçüncü tərəf izləyiciləri kukidə unikal identifikator təyin etmiş ola bilər. Əgər onlar sayt materiallarının bir hissəsi olsaydılar, istifadəçi müxtəlif veb resursları ilə işləyərkən identifikatoru öz mülahizələri ilə oxuya bilərdilər.
Bu günlərdə əksər brauzerlər bu tip izləyici davranışına qarşı qorunma daxildir. Nəticədə izləyicilər indi texnologiyadan istifadə edirlər , müxtəlif layihələr üçün öz skriptləri kimi maskalanır. Məhz, izləyicilər sayt sahiblərinə ünvanı adətən təsadüfi simvol dəstinə bənzəyən müəyyən bir domen üçün parametrlərinə CNAME əlavə etməyi təklif edir.
Veb sayt kukilərini bütün subdomenlərə (məsələn - *.website.com) əlçatan etmək tövsiyə olunmasa da, bir çox saytlar bunu edir. Bu halda, bu cür kukilər avtomatik olaraq maskalanmış üçüncü tərəf izləyicisinə göndərilir. Nəticədə, biz artıq heç bir məxfilik haqqında danışa bilmərik.
Eyni şey HTTP başlıqları ilə də baş verir , yalnız əsas domenə göndərilir, çünki onlar yaratmaq üçün istifadə edilə bilər istifadəçi. İstifadə etdiyiniz CDN xidmətinin bu başlıqları düzgün filtrlədiyinə əmin olun.
Nəticələri
Tezliklə üçüncü tərəf resurslarının öz-özünə hostinqini həyata keçirməyi planlaşdırırsınızsa, icazə verin sizə bəzi məsləhətlər verim:
- Ən vacib JS kitabxanalarınızı, şriftlərinizi və CSS fayllarınızı yerləşdirin. Bu, üçüncü tərəf xidmətinin təqsiri üzündən sayt üçün həyati əhəmiyyət kəsb edən resursun əlçatmaz olması səbəbindən saytın uğursuzluğu və ya performansın aşağı düşməsi riskini azaldacaq.
- Üçüncü tərəf resurslarını CDN-də keşləməzdən əvvəl, onların fayllarının adlandırılması zamanı hansısa versiya sisteminin istifadə olunduğundan və ya yeni versiyasını dərc edərkən CDN keşini əl ilə və ya avtomatik sıfırlamaqla bu resursların həyat dövrünü idarə edə bildiyinizə əmin olun. ssenari.
- CDN, proxy server və keş parametrlərinizlə bağlı çox diqqətli olun. Bu, layihənizin və ya başlıqlarınızın kukilərin göndərilməsinin qarşısını almağa imkan verəcək
Client-Hintsüçüncü tərəf xidmətləri.
Hörmətli oxucular! Layihələrinizin işləməsi üçün son dərəcə vacib olan digər insanların materiallarını serverlərinizdə yerləşdirirsinizmi?
Mənbə: www.habr.com