Само-домаќин на ресурси од трети страни: добри, лоши, грди

Во последниве години, сè повеќе платформи за оптимизирање на проекти од предниот дел нудат можности за само-хостинг или прокси ресурси од трети страни. Akamai ви овозможува да поставите специфични параметри за само-генерирани URL-адреси. Cloudflare има технологија Edge Workers. Фастерзин може препишуваат УРЛ-адреси на страниците така што тие укажуваат на ресурси од трети страни лоцирани на главниот домен на страницата.

Ако знаете дека услугите од трети страни што се користат во вашиот проект не се менуваат многу често и дека процесот на нивно доставување до клиентите може да се подобри, тогаш веројатно размислувате за прокси такви услуги. Со овој пристап, можете многу добро да ги приближите овие ресурси до вашите корисници и да стекнете поцелосна контрола врз нивното кеширање на страната на клиентот. Ова, дополнително, ви овозможува да ги заштитите корисниците од проблеми предизвикани од „падот“ на услуга од трета страна или деградација на нејзините перформанси.

Добро: подобрени перформанси

Само-домаќинството на туѓи ресурси ги подобрува перформансите на многу очигледен начин. Прелистувачот не треба повторно да пристапува до DNS, не треба да воспоставува TCP конекција и да врши TLS ракување на домен од трета страна. Можете да видите како само-хостирањето на туѓи ресурси влијае на перформансите со споредување на следните две бројки.

Ресурсите од трета страна се преземаат од надворешни извори (преземено од оттука)

Ресурсите од трета страна се складираат на истото место како и останатите материјали на страницата (преземени од оттука)

Ситуацијата е подобрена и со тоа што прелистувачот ќе ја користи можноста за мултиплексирање и приоритизирање на податоците од HTTP/2 конекцијата која веќе е воспоставена со главниот домен.

Ако не хостирате ресурси од трета страна, тогаш бидејќи тие ќе бидат вчитани од домен различен од главниот, не може да им се даде приоритет. Ова ќе предизвика тие да се натпреваруваат едни со други за пропусниот опсег на клиентот. Ова може да резултира со време на вчитување на содржината која е важна за изградба на страница која е многу подолга од она што би било остварливо во идеални околности. тука е разговор за приоритизација на HTTP/2 што многу добро го објаснува сето ова.

Може да се претпостави дека употребата на атрибути во врски до надворешни ресурси preconnect ќе помогне во решавањето на проблемот. Меѓутоа, ако има премногу од овие врски до различни домени, тоа всушност може да ја преоптовари комуникациската линија во најклучниот момент.

Ако самите ги хостирате ресурсите на трети лица, можете да контролирате како точно овие ресурси му се даваат на клиентот. Имено, станува збор за следново:

• Може да се осигурате дека се користи алгоритмот за компресија на податоци што најмногу одговара на секој прелистувач (Brotli/gzip).
• Можете да го зголемите времето на кеширање за ресурсите кои обично не се особено долги, дури и кај најпознатите провајдери (на пример, соодветната вредност за ознаката GA е поставена на 30 минути).

Можете дури и да го продолжите TTL за ресурс на, да речеме, една година со инкорпорирање на релевантна содржина во вашата стратегија за управување со кеширање (хешови на URL, верзии итн.). Ќе зборуваме за ова подолу.

▍Заштита од прекини во работењето на услуги од трети лица или нивно исклучување

Друг интересен аспект на самодомаќинувачките ресурси на трети страни е тоа што ви овозможува да ги ублажите ризиците поврзани со прекините на услугите од трети страни. Да претпоставиме дека решението за тестирање A/B од трета страна што го користите е имплементирано како скрипта за блокирање што се вчитува во главниот дел на страницата. Оваа скрипта полека се вчитува. Ако соодветната скрипта не се вчита, страницата ќе биде празна. Ако е потребно многу долго време за да се вчита, страницата ќе се појави со долго задоцнување. Или, да претпоставиме дека проектот користи библиотека преземена од CDN ресурс од трета страна. Да замислиме дека овој ресурс доживеа неуспех или беше блокиран во одредена земја. Таквата ситуација ќе доведе до нарушување на логиката на страницата.

За да дознаете како функционира вашиот сајт кога некоја надворешна услуга е недостапна, можете да го користите делот SPOF за webpagetest.org.

Секцијата SPOF на webpagetest.org

▍Што е со проблемите со кеширањето на материјалите во прелистувачите? (навестување: тоа е мит)

Можеби мислите дека користењето јавни ЦДН автоматски ќе доведе до подобри перформанси на ресурсите, бидејќи овие услуги имаат прилично висококвалитетни мрежи и се дистрибуирани низ целиот свет. Но, сè е всушност малку покомплицирано.

Да речеме дека имаме неколку различни страници: website1.com, website2.com, website3.com. Сите овие страници ја користат библиотеката jQuery. Ние го поврзуваме со нив користејќи CDN, на пример - googleapis.com. Може да очекувате прелистувачот да ја преземе и кешира библиотеката еднаш, а потоа да ја користи на сите три локации. Ова може да го намали оптоварувањето на мрежата. Можеби ова ќе ви овозможи да заштедите пари некаде и да помогнете во подобрување на перформансите на ресурсите. Од практична гледна точка, сè изгледа поинаку. На пример, Safari има функција наречена Интелигентна превенција за следење: Кешот користи двојни клучеви врз основа на изворот на документот и изворот на ресурсот од трета страна. тука е добра статија на оваа тема.

стари студии Јаху и 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 од Chrome

Резултатот од пребарувањето на Google Fonts извршен од IE10

Polyfill.io му дава на прелистувачот само полифилите што му се потребни. Ова е направено од причини за перформанси.

На пример, ајде да погледнеме што се случува ако го извршите следново барање од различни прелистувачи: https://polyfill.io/v3/polyfill.js?features=default

Како одговор на таквото барање извршено од IE10, ќе бидат примени 34 KB податоци. И одговорот на него, извршен од Хром, ќе биде празен.

Лути: Некои размислувања за приватност

Оваа точка е последна по ред, но не и најмалку важна. Поентата е дека само-хостирањето на ресурси од трети страни на главниот домен на проектот или на неговиот поддомен може да ја загрози приватноста на корисниците и негативно да влијае на главниот веб-проект.

Ако вашиот CDN систем не е правилно конфигуриран, може да завршите со испраќање колачиња на вашиот домен на услуга од трета страна. Ако правилното филтрирање не е организирано на ниво на CDN, тогаш колачињата за вашата сесија, кои во нормални услови не можат да се користат во JavaScript (со httponly), може да се испрати до странски домаќин.

Токму тоа може да се случи со тракерите како Eulerian или Criteo. Следачите од трета страна можеби поставиле единствен идентификатор во колачето. Ако тие беа дел од материјалите на страницата, тие можеа да го читаат идентификаторот по нивна дискреција додека корисникот работи со различни веб-ресурси.

Деновиве, повеќето прелистувачи вклучуваат заштита од овој тип на однесување на тракерот. Како резултат на тоа, тракерите сега користат технологија CNAME покритие, маскирани како свои сценарија за различни проекти. Имено, тракерите им нудат на сопствениците на сајтовите да додадат CNAME во нивните поставки за одреден домен, чија адреса обично изгледа како случаен сет на знаци.

Иако не е препорачливо колачињата на веб-локациите да бидат достапни за сите поддомени (на пример - *.website.com), многу сајтови го прават тоа. Во овој случај, таквите колачиња автоматски се испраќаат до прикриен тракер од трета страна. Како резултат на тоа, повеќе не можеме да зборуваме за каква било приватност.

Исто така, истото се случува и со заглавијата на HTTP Клиент-Совети, кои се испраќаат само до главниот домен, бидејќи може да се користат за креирање дигитален отпечаток од прст корисник. Проверете дали услугата CDN што ја користите правилно ги филтрира овие заглавија.

Резултатите од

Ако планирате наскоро да имплементирате само-хостирање на ресурси од трети страни, дозволете ми да ви дадам неколку совети:

• Домаќин на вашите најважни JS библиотеки, фонтови и CSS-датотеки. Ова ќе го намали ризикот од неуспех на локацијата или деградација на перформансите поради недостапниот ресурс од витално значење за локацијата поради грешка на услуга од трета страна.
• Пред да кеширате ресурси од трета страна на CDN, проверете дали се користи некој вид систем за верзии при именувањето на нивните датотеки или дека можете да управувате со животниот циклус на овие ресурси со рачно или автоматско ресетирање на кешот CDN кога објавувате нова верзија на скриптата.
• Бидете внимателни со поставките за CDN, прокси-сервер и кеш. Ова ќе ви овозможи да спречите вашиот проект или заглавија да се испраќаат колачиња Client-Hints услуги од трета страна.

Почитувани читатели! Дали хостирате туѓи материјали на вашите сервери кои се исклучително важни за функционирањето на вашите проекти?

Извор: www.habr.com