В последните години все повече платформи за оптимизация на фронтенд проекти предлагат възможности за самостоятелно хостване или проксиране на външни ресурси. 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
