През последните години все повече платформи за оптимизация на фронтенд проекти предлагат възможности за самостоятелно хостинг или проксиране на външни ресурси. 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, може да не са подходящи за някои външни ресурси. Например, такива ресурси могат да използват технология за проверка на потребителския агент (user agent sniffing, adaptive serving), за да предоставят на определени браузъри версии на материалите, оптимизирани специално за тях. Тези технологии, за да определят възможностите на браузъра, разчитат на регулярни изрази или на база данни, в която са събрани данни за 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 Кб данни. А отговорът на същото запитване, извършено от Chrome, ще бъде празен.
Зловещо: някои съображения за поверителността
Тази точка е последна по ред, но не и по важност. Поговорим за това, че самостоятелното хостване на външни ресурси на основния домейн на проекта или на неговите поддомейни може да застраши поверителността на потребителите и да има негативно въздействие върху основния уеб проект.
Ако вашата CDN система е неправилно конфигурирана, всичко може да завърши с това, че ще изпращате кукита на домейна си на трета страна. Ако на ниво CDN не бъде организирана правилна филтрация, то вашите сесийни кукита, които обикновено не могат да се използват в JavaScript (с атрибут httponly), могат да бъдат изпратени на чужд хост.
Така може да се случи с тракери като Eulerian или Criteo. Външните тракери могат да поставят уникален идентификатор в куки. Те, ако са били част от материалите на сайтовете, могат да прочетат идентификатора по собствено усмотрение, докато потребителят взаимодействат с различни уеб ресурси.
В днешно време повечето браузъри включват защита срещу подобно поведение на тракерите. В резултат на това, сега тракерите използват технологията , маскирайки се като свои собствени скриптове на различни проекти. По-точно, тракерите предлагат на собствениците на сайтове да добавят в настройките си CNAME за определен домейн, адресът на който обикновено изглежда като произволна комбинация от символи.
Макар и да не се препоръчва кукитата на уебсайта да бъдат достъпни за всички поддоменови имена (например — *.website.com), на много сайтове това се прави. В такъв случай подобни кукита автоматично се изпращат на замаскиран външен тракер. В резултат — за никаква поверителност не може да се говори.
Освен това, същото се случва и с HTTP заглавията , които се изпращат само на основния домейн, тъй като те могат да бъдат използвани за създаване на потребителя. Уверете се, че използваната от вас CDN услуга правилно филтрира подобни заглавия.
Резюме
Ако планирате да внедрите самостоятелен хостинг на външни ресурси в близко бъдеще, позволете да ви дам няколко съвета:
- Хоствайте най-важните си JS библиотеки, шрифтове и CSS файлове. Това ще намали риска от недостъпност на сайта или спад в неговата производителност в резултат на това, че ресурс, жизненоважен за работата на сайта, е недостъпен по вина на външна услуга.
- Преди да кеширате външни ресурси в CDN, уверете се, че имената на файловете им следват система за версиониране, или че можете да управлявате жизнения цикъл на тези ресурси, ръчно или автоматично, чрез премахване на кеша в CDN при публикуване на нова версия на скрипта.
- Обърнете особено внимание на настройките на CDN, прокси сървъра и кеша. Това ще ви предпази от изпращане на бисквитки на вашия проект или заглавия
Client-Hintsна външни услуги.
Уважаеми читатели! Разполагате ли на своите сървъри чужди материали, които са изключително важни за работата на вашите проекти?
Източник: habr.com
