През последните години все повече и повече платформи за оптимизиране на front-end проекти предлагат възможности за самостоятелно хостване или проксииране на ресурси на трети страни. 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 на .
Раздел SPOF на webpagetest.org
▍Какво ще кажете за проблемите с кеширането на материали в браузърите? (подсказка: това е мит)
Може би си мислите, че използването на публични CDN автоматично ще доведе до по-добро представяне на ресурсите, тъй като тези услуги имат доста висококачествени мрежи и са разпространени по целия свят. Но всъщност всичко е малко по-сложно.
Да приемем, че имаме няколко различни сайта: website1.com, website2.com, website3.com. Всички тези сайтове използват библиотеката jQuery. Ние го свързваме с тях чрез CDN, например - googleapis.com. Можете да очаквате браузърът да изтегли и кешира библиотеката веднъж и след това да я използва във всичките три сайта. Това може да намали натоварването на мрежата. Може би това ще ви позволи да спестите пари някъде и да помогнете за подобряване на ефективността на ресурсите. От практическа гледна точка всичко изглежда различно. Например, Safari има функция, наречена : Кешът използва двойни ключове въз основа на източника на документа и източника на ресурса на трета страна. добра статия по тази тема.
стари изследвания и , както и по-нови Пол Калвано, показват, че ресурсите не се съхраняват в кеш паметта на браузъра толкова дълго, колкото бихме могли да очакваме: „Има сериозна разлика между времето за кеширане на собствените ресурси на проекта и ресурсите на трети страни. Говорим за 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 дава на браузъра само полифилите, от които се нуждае. Това се прави от съображения за производителност.
Например, нека да разгледаме какво се случва, ако изпълните следната заявка от различни браузъри:
В отговор на такава заявка, изпълнена от IE10, ще бъдат получени 34 KB данни. И отговорът на него, изпълнен от Chrome, ще бъде празен.
Ядосан: Някои съображения за поверителност
Тази точка е последна по ред, но не на последно място важна. Въпросът е, че самостоятелното хостване на ресурси на трети страни в основния домейн на проекта или в неговия поддомейн може да застраши поверителността на потребителите и да повлияе негативно на основния уеб проект.
Ако вашата CDN система не е конфигурирана правилно, може да се окаже, че изпращате бисквитките на вашия домейн до услуга на трета страна. Ако правилното филтриране не е организирано на ниво CDN, вашите сесийни бисквитки, които обикновено не могат да се използват в JavaScript (с httponly), могат да бъдат изпратени до чужд хост.
Точно това може да се случи с тракери като Eulerian или Criteo. Проследяващите трети страни може да са задали уникален идентификатор в бисквитката. Ако бяха част от материалите на сайта, те можеха да прочетат идентификатора по свое усмотрение, докато потребителят работеше с различни уеб ресурси.
В наши дни повечето браузъри включват защита срещу този тип поведение на тракера. В резултат на това тракерите вече използват технология , маскирани като собствени сценарии за различни проекти. А именно тракерите предлагат на собствениците на сайтове да добавят CNAME към настройките си за определен домейн, чийто адрес обикновено изглежда като произволен набор от знаци.
Въпреки че не се препоръчва бисквитките на уебсайта да са достъпни за всички поддомейни (например - *.website.com), много сайтове правят това. В този случай такива бисквитки автоматично се изпращат до скрит инструмент за проследяване на трета страна. В резултат на това вече не можем да говорим за поверителност.
Освен това същото се случва с HTTP заглавките , които се изпращат само до основния домейн, тъй като могат да се използват за създаване потребител. Уверете се, че CDN услугата, която използвате, филтрира правилно тези заглавки.
Резултати от
Ако планирате скоро да приложите самостоятелно хостване на ресурси на трети страни, позволете ми да ви дам няколко съвета:
- Хоствайте вашите най-важни JS библиотеки, шрифтове и CSS файлове. Това ще намали риска от повреда на сайта или влошаване на производителността поради недостъпен ресурс от жизненоважно значение за сайта поради грешка на услуга на трета страна.
- Преди да кеширате ресурси на трети страни в CDN, уверете се, че се използва някакъв вид система за управление на версиите, когато наименувате техните файлове, или че можете да управлявате жизнения цикъл на тези ресурси чрез ръчно или автоматично нулиране на CDN кеша при публикуване на нова версия на скриптът.
- Бъдете много внимателни относно настройките на CDN, прокси сървъра и кеша. Това ще ви позволи да предотвратите изпращането на бисквитки към вашия проект или заглавки
Client-Hintsуслуги на трети страни.
Уважаеми читатели! Хоствате ли на вашите сървъри материали на други хора, които са изключително важни за работата на вашите проекти?
Източник: www.habr.com