У апошнія гады ўсё больш платформаў для аптымізацыі фронтэнд-праектаў прапануюць магчымасці па самастойным хостынгу або праксіраванні іншых рэсурсаў. 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