В останні роки все більше платформ для оптимізації фронтенд-проектів пропонують можливості самостійного хостингу або проксування сторонніх ресурсів. 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, проксі-сервера, кешу. Це дозволить вам не допустити відправлення файлів cookie свого проекту або заголовків
Client-Hintsстороннім сервісам.
Шановні читачі! Чи розміщуєте ви на своїх серверах чужі матеріали, які є надзвичайно важливими для роботи ваших проектів?
Джерело: habr.com