🥇[Не] використовуйте CDN

Практично у будь-якій статті чи інструменті для оптимізації швидкості сайтів є скромний пункт «використовуйте CDN». Взагалі, CDN – це content delivery network чи мережу доставки контенту. Ми в компанії «Метод Лаб» часто зустрічаємося з питаннями клієнтів на цю тему, деякі самостійно включають CDN. Мета цієї статті розібратися, що може дати CDN з точки зору швидкості завантаження сайту, які проблеми можуть виникати і в яких випадках використання CDN є виправданим.

Обведені на зображенні затримки викликані використанням CDN.

Трохи історії

Як і багато технологій, CDN з'явилися за потребою. Під час розвитку інтернет-каналів у користувачів Мережі з'явилися сервіси онлайн-відео. Природно, що відеоконтент вимагає на порядки більшої пропускної спроможності в порівнянні зі звичайним контентом сайтів (картинки, текст, CSS або JS-код).

При спробі паралельної трансляції відео-потоку безлічі клієнтів з одного сервера вузьким місцем, швидше за все, стане інтернет-канал сервера. Зазвичай, досить кілька тисяч потоків, щоб забити типовий канал сервера. Звичайно, можуть бути й інші обмеження ресурсів, але зараз вони не важливі. Також важливо, що розширити канал сервера надто дорого (а іноді й неможливо) та й недоцільно. Навантаження на канал при трансляціях матиме циклічний характер.

Проблему обмеження каналу окремого сервера добре вирішує CDN. Клієнти не підключаються безпосередньо до сервера, а до вузлів мережі CDN. В ідеальній ситуації сервер віддає один потік вузлу CDN, а далі мережа використовує власні ресурси для доставки цього потоку безлічі користувачів. З точки зору економіки ми платимо тільки за фактично спожиті ресурси (це може бути пропускна спроможність або трафік) та отримуємо відмінну масштабованість нашого сервісу. Використання CDN для доставки важкого контенту цілком виправдано та логічно. Хоча варто зауважити, що найбільші гравці в цій галузі (наприклад, Netflix) будують свої CDN замість використання великих комерційних CDN (Akamai, Cloudflare, Fastly і т.д.)

У міру розвитку Інтернету, самі веб-програми стали складніше і важче. На перший план вийшла проблема швидкості завантаження. Ентузіасти швидкості сайтів досить швидко вивели кілька основних проблем, що призводили до повільного завантаження сайтів. Однією з них були затримки мережі (RTT — round trip time або час ping). Затримки впливають на безліч процесів у завантаженні сайту: встановлення TCP-з'єднання, запуск TLS-сесії, завантаження кожного окремого ресурсу (картинки, JS-файлу, HTML-документу тощо)

Проблема ускладнювалася тим, що при використанні проколу HTTP/1.1 (до появи SPDY, QUIC і HTTP/2 це був єдиний варіант) браузери відкривають не більше 6 TCP-з'єднань до одного хоста. Все це призводило до простого з'єднання та неефективного використання пропускної спроможності каналу. Проблема частково вирішувалася доменним шардингом – створенням додаткових хостів для подолання ліміту кількість сполук.

Тут з'являється друга здатність CDN – скорочення затримок (RTT) з допомогою великої кількості точок і близькості вузлів до користувача. Відстань тут грає вирішальну роль: швидкість світла обмежена (близько 200 000 км/сек в оптоволокні). Значить, кожна 1000 км шляху додає 5 мс затримок або 10 мс RTT. Це мінімальні витрати часу на передачу, оскільки ще є затримки на проміжному обладнанні. Оскільки CDN зазвичай вміє кешувати об'єкти на серверах, ми можемо виграти від завантаження таких об'єктів через CDN. Необхідні умови для цього: наявність об'єкта в кеші близькість точки CDN до користувача порівняно із сервером веб-додатку (origin server). Важливо розуміти, що географічна близькість вузла CDN не гарантує низьких затримок. Маршрутизація між клієнтом та CDN може бути побудована таким чином, що клієнт підключатиметься до хоста в іншій країні, а можливо, і на іншому континенті. Тут вступають у дію взаємовідносини операторів зв'язку та сервісу CDN (піринг, наявність стиків, участь у IX тощо) та політика маршрутизації трафіку самої CDN. Наприклад, Cloudflare при використанні двох початкових планів (безкоштовного та дешевого) не гарантує віддачі контенту з найближчого вузла – вибір хоста буде здійснюватися для досягнення мінімальної вартості.

Багато провідних інтернет-компаній привертають інтерес громадськості (веб-розробників та власників сервісів) до теми швидкості завантаження та роботи сайтів. Серед цих компаній Yahoo (інструмент Yslow), AOL (WebPageTest) та Google (сервіс Page Speed Insights), які розробляють свої рекомендації щодо прискорення сайтів (насамперед вони стосуються клієнтської оптимізації). Пізніше з'являються нові засоби тестування швидкості сайтів, які також дають поради щодо збільшення швидкості сайтів. У кожному з цих сервісів або плагінів є постійна рекомендація «Використовуйте CDN». Як пояснення ефекту CDN зазвичай вказується скорочення мережних затримок. На жаль, не всі готові розбиратися в тому, як досягається ефект прискорення від CDN і як його можна виміряти, тому рекомендація приймається на віру і використовується як постулат. Насправді далеко не всі CDN однаково корисні.

Використання CDN сьогодні

Для оцінки корисності застосування CDN їх слід класифікувати. Що можна зустріти зараз на практиці (приклади в дужках, звичайно ж, не вичерпні):

Безкоштовні CDN для роздачі JS-бібліотек (MaxCDN, Google. Yandex).
CDN сервісів з клієнтської оптимізації (наприклад, Google Fonts для шрифтів, Cloudinary, Cloudimage для картинок).
CDN для статики та оптимізації ресурсів у CMS (є в Бітріксі, WordPress та інших).
CDN загального призначення (StackPath, CDNVideo, NGENIX, Мегафон).
СDN для прискорення сайтів (Cloudflare, Imperva, Айрі).

Ключова відмінність цих типів складається з наступного: яка частина трафіку проходить через CDN. Типи 1-3 - це доставка тільки частини контенту: від одного запиту до декількох десятків (зазвичай картинок). Типи 4 та 5 це повне проксування трафіку через CDN.

Насправді це означає кількість підключень, які використовуються для завантаження сайту. При використанні HTTP/2 ми використовуємо одне TCP-підключення до хоста для обробки будь-якої кількості запитів. Якщо ми розділяємо ресурси на основний хост (origin) і CDN, необхідно розводити запити по кількох доменам і створювати кілька ТСР-соединений. У найгіршому випадку це: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. У цій формулі не враховуються затримки в мобільних мережах на активацію радіоканалу пристрою (якщо він не був активний) і затримки на стільниковій вежі.

Ось як це виглядає на водоспаді завантаження сайту (виділено затримки для підключення до CDN при RTT 150 мс):

Якщо CDN покриває весь трафік сайту (крім сторонніх сервісів), ми можемо використовувати єдине TCP-з'єднання, економлячи затримки на підключенні до додаткових хостів. Звичайно, це стосується HTTP/2-з'єднань.

Подальші відмінності визначаються функціональністю конкретної CDN – для першого типу це лише хостинг статичного файлу, для п'ятого це зміна кількох типів контенту сайту з метою оптимізації.

Можливості CDN щодо прискорення сайту

Давайте опишемо повний спектр можливостей CDN щодо прискорення сайтів, не зважаючи на функціональність окремих типів CDN, а потім подивимося, що з цього реалізовано в кожному з них.

1. Стиснення текстових ресурсів

Найбільш базова можливість та зрозуміла можливість, проте часто реалізована погано. Наявність стиснення декларують всі CDN як свою фічу на прискорення. Але якщо подивитись докладніше, то з'ясовуються недоробки:

можуть використовуватися низькі ступені для динамічного стиснення – 5-6 (наприклад, для gzip максимум – 9);
у статичному стиску (файли в кеші) не використовуються додаткові можливості (наприклад, zopfi або brotli зі ступенем 11)
немає підтримки ефективного стиснення brotli (економія приблизно 20% порівняно з gzip).

Якщо ви використовуєте CDN, варто перевірити ці кілька пунктів: взяти файл, який прийшов з CDN, зафіксувати його розмір у стислому вигляді та перетиснути вручну для порівняння (можна використовувати якийсь онлайн-сервіс з підтримкою brotli, наприклад всжать.рф).

2. Встановлення заголовків клієнтського кешування

Також проста фіча прискорення: поставити заголовки для кешування контенту клієнтом (браузером). Найактуальніший заголовок cache-control, застарілий - expires. Додатково можна використовувати Etag. Головне, щоб max-age у cache-control був досить великим (від місяця і більше), якщо ви готові закешувати ресурс максимально жорстко, можна додати опцію immutable.

CDN можуть занижувати значення max-age, змушуючи користувача частіше завантажувати статику повторно. З чим це пов'язано: з бажанням збільшити трафік у мережі або підвищення сумісності з сайтами, які не вміють скидати кеш – не зрозуміло. Наприклад, значення часу кешування в заголовках Cloudflare за замовчуванням становить 1 годину, що дуже мало для незмінної статики.

3. Оптимізація картинок

Так як CDN бере на себе функції кешування та віддачі картинок, логічно оптимізуватиме їх на стороні CDN і в такому вигляді віддавати користувачам. Відразу обмовимося, ця можливість доступна лише для CDN типів 2, 3 та 5.

Оптимізувати зображення можна різними шляхами: використанням просунутих форматів стиснення (наприклад, WebP), ефективнішими кодувальниками (MozJPEG) або просто очищенням зайвих метаданих.

Загалом є два типи таких оптимізацій: із втратою якості та без втрати якості. CDN зазвичай прагнуть використовувати оптимізацію без втрат – щоб уникнути можливих скарг клієнтів зміну якості картинок. За таких умов виграш буде мінімальним. Насправді часто рівень якості JPEG значно перевищує необхідний і можна сміливо проводити рекомпресію з нижчим показником якості, без шкоди для сприйняття користувачами. З іншого боку, визначити рівень якості та налаштування універсально для всіх можливих веб-застосунків складно, тому CDN використовують більш консервативні налаштування порівняно з тими, які можна застосувати з урахуванням контексту (призначення картинок, тип веб-додатків і т.д.)

4. Оптимізація TLS-з'єднання

Більшість трафіку сьогодні передається TLS-з'єднанням, а це означає, що ми витрачаємо додатковий час на TLS-узгодження. Останнім часом розроблено нові технології прискорення цього процесу. Наприклад, це EC-криптографія, TLS 1.3, кеш сесій і тикети (session tickets), апаратне прискорення шифрування (AES-NI) і т. д. ).

За наявності сучасного софту впровадити такі практики не складно власних потужностях.

Не всі CDN впроваджують найкращі практики по TLS, перевірити це можна шляхом виміру часу TLS-соединения (наприклад в Webpagetest). Ідеально для нової сполуки – 1RTT, 2RTT – середній рівень, 3RTT і більше – погано.

Також слід зауважити, що навіть при використанні TLS на рівні CDN, сервер з нашим веб-додатком також повинен обробляти TLS, але з боку CDN, тому що трафік між сервером та CDN проходить у публічній мережі. У найгіршому випадку ми отримаємо подвійні затримки TLS-підключення (перша до хоста CDN, друга між ним та нашим сервером).

Для деяких застосувань варто звернути увагу на питання безпеки: трафік зазвичай розшифровується на вузлах CDN, а це потенційна можливість для перехоплення трафіку. Варіант роботи без розкриття трафіку зазвичай пропонується у топових тарифних планах за окрему плату.

5. Скорочення затримок підключення

Головна перевага CDN, про яку всі говорять: низькі затримки (менша відстань) між хостом CDN та користувачем. Досягається шляхом створення географічно розподіленої архітектури мережі, у якій хости розташовуються у точках концентрації користувачів (містах, точках обміну трафіком тощо. буд.)

На практиці пріоритети для різних мереж можуть перебувати в конкретних регіонах. Наприклад, російські CDN матимуть більше точок присутності у Росії. Американські насамперед розвиватимуть мережу в США. Наприклад, один з найбільших CDN Cloudflare має лише 2 точки в Росії – Москва та Санкт-Петербург. Тобто максимально ми можемо заощадити близько 10 мс затримки в порівнянні з прямим розміщенням у Москві.

Більшість західних CDN взагалі не мають точок у Росії. Підключившись до них, ви можете тільки збільшити затримки для вашої російської аудиторії.

6. Оптимізація контенту (мініфікація, структурні зміни)

Найскладніший і найтехнологічніший пункт. Зміна контенту при доставці може бути дуже ризикованою. Навіть якщо взяти мініфікацію: скорочення вихідного коду (за рахунок зайвих прогалин, неважливих конструкцій тощо) може вплинути на його працездатність. Якщо говорити про більш серйозні зміни - перенесення JS-коду в кінець HTML, об'єднання файлів і подібних - ризик порушити функціональність сайту ще вище.

Тому лише деякі CDN із типу 5 займаються цим. Звичайно, автоматизувати всі необхідні для прискорення зміни не вийде – потрібний ручний аналіз та оптимізація. Наприклад, видалення невикористовуваного або дублюючого коду відноситься саме до ручних завдань.

Як правило, всі подібні оптимізації керуються налаштуваннями і найнебезпечніші відключені за умовчанням.

Підтримка прискорювальних можливостей типу CDN

Отже, давайте подивимося, які з потенційних можливостей прискорення надають різні типи CDN.

Для зручності, повторимо класифікацію.

Безкоштовні CDN для роздачі JS-бібліотек (MaxCDN, Google. Yandex).
CDN сервісів з клієнтської оптимізації (наприклад, Google Fonts для шрифтів, Cloudinary, Cloudimage для картинок).
CDN для статики та оптимізації ресурсів у CMS (є в Бітріксі, WordPress та інших).
CDN загального призначення (StackPath, CDNVideo, NGENIX, Мегафон).
СDN для прискорення сайтів (Cloudflare, Imperva, Айрі).

Тепер порівняємо фічі та типи CDN.

Можливість
Тип 1
Тип 2
Тип 3
Тип 4
Тип 5

Стиснення тексту
+–
-
+–
+–
+

Заголовки кешу
+
+
+
+
+

Картинки
-
+–
+–
-
+

TLS
-
-
-
+–
+

затримки
-
-
-
+
+

Контент
-
-
-
-
+

У цій таблиці "+" використовується для індикації повної підтримки, "-" - відсутність, "+-" - часткова підтримка. Звичайно, можливі відхилення від цієї таблиці в реальності (наприклад, якийсь CDN загального призначення впровадить фічі з оптимізації картинок), але для загального уявлення вона корисна.

Підсумки

Сподіваюся, прочитавши цю статтю, у вас з'явиться більш ясна картина щодо рекомендації «використовуйте CDN» для прискорення сайтів.

Як і в будь-якій справі, не можна вірити рекламним обіцянкам будь-якого сервісу. Ефект потрібно вимірювати та перевіряти в реальних умовах. Якщо ви вже використовуєте якийсь CDN, перевірте його щодо ефективності за критеріями, описаними в статті.

Можливо, використання CDN прямо зараз уповільнює завантаження вашого сайту.

Як загальна рекомендація можна зупинитися на наступному: вивчіть свою аудиторію, визначте її географічні рамки. Якщо ваша основна аудиторія зосереджена в радіусі 1-2 тисячі кілометрів, вам не потрібно CDN за основним призначенням - зниження затримок. Натомість, ви можете розмістити свій сервер ближче до користувачів і налаштувати його належним чином, отримуючи більшість оптимізацій, описаних у статті (безкоштовно та постійно).

Якщо ваша аудиторія дійсно географічно розподілена (радіус більше 3000 кілометрів), використання якісної CDN дійсно буде корисним. Однак, потрібно заздалегідь розуміти, що саме зможе прискорити вашу CDN (див. таблицю можливостей та їх опис). Прискорення сайту при цьому все одно залишається комплексним завданням, яке не вирішується підключенням CDN. Крім зазначених оптимізації за бортом CDN залишаються найефективніші засоби прискорення: оптимізація серверної частини, просунуті зміни клієнтської частини (видалення коду, що не використовується, оптимізація процесу рендерингу, робота з контентом, шрифтами, адаптивністю і т.д.)

Джерело: habr.com

[Не] використовуйте CDN