Раз на кілька років з'являється технологія, яку продають як універсальне прискорення сайту. Зараз це edge — віддача контенту й частина обчислень із вузлів, розкиданих ближче до відвідувача. Механізм робочий, він докладно описаний у документації Cloudflare і Vercel, і в певних задачах різницю видно неозброєним оком.
Проблема починається там, де edge пропонують замість інженерії. Бізнес платить за міграцію, а сайт гальмує з причини, якої розподілена мережа взагалі не торкається. Нижче розберу, з чого складається затримка, що з неї знімає edge, що залишається на місці, і як перевірити власний сайт за пів години без підрядника.
З чого складається пауза між кліком і контентом
Час від натискання до появи тексту — це сума кількох незалежних доданків.
Мережа. Сигнал іде до сервера й назад. Київ — Франкфурт це десятки мілісекунд, Київ — Вірджинія вже сотні. На мобільному зверху лягає затримка радіоканалу, тому один і той самий сайт із домашнього Wi-Fi і з 4G у метро відчувається по-різному.
Сервер. Скільки часу займає зібрати HTML: запити до бази, версія PHP, налаштування nginx, наявність кешу сторінки. Ця частина видно як TTFB — час до першого байта.
Браузер. Вага документа, скрипти, шрифти, зображення. Навіть коли перший байт прийшов за 150 мс, до першого екрана може бути ще секунда, якщо в шапці висять сто з гаком картинок без відкладеного завантаження.
Edge працює з першим доданком і, за умови кешування, з другим. Третій він не чіпає ніяк.
Що розподілена мережа справді знімає
Перше — фізичну відстань. Якщо аудиторія в Польщі, Німеччині чи США, а сервер у Києві, кожен запит платить за дорогу туди й назад. Вузол у регіоні відвідувача цю дорогу скорочує, і це не питання віри: різницю видно в тому ж TTFB, знятому з різних локацій.
Друге — навантаження на джерело. Закешовану сторінку віддає вузол, ваш сервер її не бачить. На піках трафіку це рятує від падіння, бо частина запитів просто не доходить до бекенду.
Третє — статику. Зображення, CSS, шрифти добре живуть на краю мережі: віддаються стисненими, конвертуються у сучасні формати на льоту, кешуються надовго. Це найдешевша і найпередбачуваніша частина ефекту.
Чого edge не робить
Тут починається чесна частина, якої зазвичай немає в презентаціях.
Динаміку не кешують. Кошик, чекаут, особистий кабінет, персональні ціни для оптовика — усе це рахується щоразу заново. Вузол може наблизити з'єднання, але не може віддати чужий кошик із кешу. Якщо ваш чекаут повільний, він таким і залишиться.
Повільний бекенд залишається повільним. Ми міряли магазин садової техніки з каталогом на 55 321 URL: TTFB 840,5 мс, HTML 454,5 КБ, на сервері PHP 7.3.33 — версія без підтримки з грудня 2021 року (наш вимір, 31.07.2026). Мережа вузлів тут не рятує: сторінка стільки генерується. Дивитися тут треба на версію PHP і кеш на боці сайту, а не на мережу вузлів.
Швидкість не створює попит. Це межа, яку варто проговорити вголос. Якщо ціна вища за ринок, товару немає в наявності або людина прийшла не за тим — сайт, що вантажиться за 200 мс, просто швидше покаже їй причину піти. Швидкість прибирає технічну втрату тих, хто не дочекався першого екрана. Привабливість пропозиції вона не змінює.
TTFB — це не весь досвід відвідувача. Ми міряємо серверну частину ззовні. Реальний час до інтерактивності залежить ще від пристрою, мережі й ваги медіа, і побачити його можна тільки в польових даних.
Наші заміри: швидкість — це інженерія конкретного проєкту
Під час аудиту портфоліо ми зняли однакові метрики з бойових сайтів, які вели або ведемо (наші виміри, 31.07–01.08.2026). Кілька цифр пояснюють тезу краще за будь-яку презентацію.
| Тип бізнесу | TTFB | Контекст |
|---|---|---|
| Магазин натуральної косметики | 126,3 мс | HTML 196,3 КБ, 81 товарна сторінка |
| SaaS-платформа | 220,6 мс | HTML 141 КБ |
| Виробник вогнестійких панелей | 244 мс | 164 URL у карті сайту, жодного дубля |
| Магазин тактичного спорядження | 413,8 мс | каталог 54 302 товари |
| Роздрібний магазин білизни, головна | 1 544,6 мс | картка товару того ж сайту — 391,4 мс |
Два останні рядки цікаві найбільше. Магазин тактичного спорядження з каталогом на 54 тисячі товарів віддає перший байт за 414 мс — розмір каталогу не зобов'язує сайт бути повільним. А в магазині білизни головна вчетверо повільніша за власну картку товару, і причина знайшлася в заголовках відповіді: сторінка віддається з no-store, no-cache, тобто збирається наново на кожен запит. Це лікується налаштуванням кешу, а не переїздом на edge. Там же на головній знайшлися 118 тегів <img>, з яких жоден не мав loading="lazy".
І найпоказовіше: магазин косметики з TTFB 126 мс і роздрібний магазин білизни з TTFB 1 545 мс стоять на одній платформі — OpenCart. Різниця у дванадцять разів усередині однієї CMS.
Для орієнтиру: документація web.dev вважає добрим TTFB до 800 мс, а порогом доброго LCP — 2,5 секунди. Це технічні пороги Google, а не обіцянка результату.
Як перевірити свій сайт самому
Виміряйте TTFB, а не відчуття
curl -w "%{time_starttransfer}\n" -o /dev/null -s https://ваш-сайт.ua/
Запустіть 5–7 разів і візьміть медіану: одиничний замір нічого не означає, бо може впіймати холодний кеш або випадковий сплеск. Повторіть для сторінки категорії й картки товару. Якщо головна суттєво повільніша за внутрішні сторінки, шукайте кеш, а не новий хостинг.
Подивіться заголовки відповіді
curl -sI https://ваш-сайт.ua/ | grep -iE 'cache-control|age|x-cache|cf-cache-status'
no-store або no-cache на публічній сторінці каталогу означає, що сервер щоразу збирає її з нуля. Якщо CDN уже стоїть, але age завжди 0, а статус кешу показує MISS — ви платите за мережу, яка нічого не кешує. Це найчастіша знахідка на сайтах, де edge «вже підключений».
Порахуйте вагу першого екрана
curl -s https://ваш-сайт.ua/ | wc -c
curl -s --compressed -o /dev/null -w "%{size_download}\n" https://ваш-сайт.ua/
Різниця між цими числами покаже, чи ввімкнено стиснення. Далі порахуйте теги <img> без loading="lazy" — відкладене завантаження зменшує обсяг даних, який мобільний браузер тягне до першого екрана, і не коштує нічого, крім атрибута в шаблоні.
Подивіться польові дані
Лабораторний тест міряє ваш канал і ваш ноутбук. PageSpeed Insights у блоці з даними CrUX показує реальних відвідувачів за останні 28 днів — саме на ці цифри дивиться Google. Якщо блок порожній, трафіку на сторінку замало для звіту, і залишається лабораторний вимір із поправкою на це.
Як зрозуміти, чи взагалі допомогло
Найтиповіша сцена після будь-якої оптимізації — суперечка, чи стало краще. Без аналітики це неможливо перевірити, рішення ухвалюються за відчуттями. У магазині систем поливу, який ми аудитували, не встановлено жодного лічильника: ні GA4, ні GTM, ні пікселя. Там прискорення сайту не можна ані підтвердити, ані спростувати, бо міряти нічим.
Тому порядок дій такий: спочатку коректно налаштовані події конверсії, потім зміни, потім порівняння періодів. І чесна поправка: лічильник сам собою нічого не покращує, він лише дає можливість побачити. GA4 показує тенденцію, а не бухгалтерську істину — блокувальники, режим згоди й обмеження браузерів на cookie з'їдають частину даних, і зводити ці цифри з касою треба свідомо.
Ще один нюанс, який спливає саме після підключення CDN: закешовані запити перестають доходити до вашого сервера, і логи бекенду більше не показують повної картини. Якщо ви розбираєте, як сайт обходять пошукові боти, дивитися треба логи з боку мережі. Заодно варто перевірити зв'язку robots.txt і карти сайту — типова поломка виглядає так: у robots оголошено sitemap.xml, а сам файл віддає 404. Ми зустріли це на трьох проєктах вибірки.
Коли edge доречний, а коли гроші краще витратити інакше
Розподілена мережа виправдана, якщо аудиторія географічно розкидана, у трафіку бувають різкі піки або сайт переважно контентний і добре кешується. Для інтернет-магазину з українськими покупцями й сервером у Європі виграш від географії буде скромним — там більше дадуть кеш сторінок, свіжа версія PHP, індекси в базі та робота із зображеннями.
Найчесніша послідовність виглядає нудно: виміряти, знайти вузьке місце, полагодити найдешевше з дорогих, виміряти знову. Наскільки це вплине саме на ваші продажі — залежить від ніші, ціни й поточного стану сайту. Назвати тут відсоток означало б його вигадати.
Якщо потрібен ринковий орієнтир: Google і Deloitte у звіті «Milliseconds Make Millions» (2020) зафіксували, що покращення швидкості мобільного сайту на 0,1 с корелювало з приростом конверсії в рітейлі близько 8,4%. Це середнє по вибірці ритейлерів у тому дослідженні, а не прогноз для вашого сайту.
Коротко
Edge скорочує відстань і знімає навантаження з сервера. Він не пришвидшує генерацію сторінки, не кешує персоналізовані дані й не рятує від застарілого бекенду. Перед тим як платити за міграцію, зніміть TTFB головної, категорії й картки товару, подивіться заголовки кешу й вагу документа. Вузьке місце частіше виявляється дешевшим, ніж здавалося.
Якщо хочете, щоб ці заміри зняли ми — напишіть на hello@lionex.com.ua, покажемо цифри до будь-яких пропозицій.
