Клієнт пише: «сайт гальмує». Відкриваєш із робочого ноутбука — начебто нормально. Відкриваєш із телефона в дорозі — справді гальмує. Слово «повільно» не означає нічого, поки під ним немає числа і місця, де це число зняли.
Нижче — як ми міряємо швидкість, що показали наші заміри 31.07–01.08.2026 на живих сайтах, і які з цих перевірок ви можете зробити самі, без нашої участі й без платних сервісів.
«Повільно» — це кілька різних чисел
Найчастіше в одну купу зсипають речі, які лікуються по-різному.
TTFB (time to first byte) — скільки минає від запиту до першого байта відповіді сервера. Чиста серверна частина: версія PHP, кеш, запити до бази, налаштування nginx. Google у документації web.dev не відносить TTFB до Core Web Vitals, а описує як діагностичну метрику, що підпирає LCP, і називає орієнтир «добре» — до 800 мс.
LCP (largest contentful paint) — момент, коли на екрані з'явився найбільший елемент першого екрана. Офіційний поріг «добре» з тієї ж документації — 2,5 секунди. Сюди вже входить і сервер, і мережа, і вага зображень.
INP (interaction to next paint) — затримка між дією користувача і реакцією інтерфейсу, поріг «добре» 200 мс. Це вже не про завантаження, а про те, чи не гальмують сторінку скрипти після нього.
Сайт може мати чудовий TTFB і провалений LCP, якщо на першому екрані висить банер на два мегабайти. Буває й навпаки: сервер думає секунду, але сторінка легка, і людина цього майже не помічає. Тому перше практичне питання — яке саме число у вас погане.
Чому швидкість має стосунок до грошей
Механізм тут прямий і нудний. Між кліком і появою контенту людина не бачить нічого. Чим довша пауза, тим більша частка відвідувачів закриває вкладку — особливо з мобільного інтернету, де до затримки сервера додається затримка мережі. Той, хто пішов до першого екрана, не побачив ні товару, ні ціни, ні кнопки. Його неможливо конвертувати жодним оффером, знижкою чи текстом, бо він фізично нічого не прочитав.
Швидкість визначає, скільком людям вашу пропозицію взагалі покажуть.
І одразу межа, щоб не було ілюзій. Швидкість не робить пропозицію привабливою. Якщо ціна вища за ринок, товару немає в наявності або людина прийшла не за тим — сайт, що вантажиться за 200 мс, просто швидше покаже їй причину піти. Швидкість прибирає технічну втрату, вона не створює попит. Наскільки це вплине саме на ваші продажі, залежить від ніші, конкуренції й того, наскільки погано зараз.
Що показали наші заміри
Ми зняли зовнішні метрики з живих сайтів, які вели або ведемо: партія на шістнадцять сайтів, заміри 31.07–01.08.2026, із зовнішньої мережі, без доступу до серверів. Порівняння «найлегший — найважчий» нижче стосуються саме цієї партії. Назв клієнтів тут немає — тільки тип бізнесу.
Магазин тактичного спорядження: TTFB 413,8 мс, повне завантаження HTML 511,1 мс. Каталог — 54 302 товари, підтверджені двома незалежними методами: sitemap-індекс на 110 096 URL для двох мов і перехресна перевірка штатним пошуком, розбіжність 0,4%. Вага HTML головної — 421,5 КБ.
Виробник вогнетривких панелей: TTFB 244 мс на головній і 208 мс на каталозі продукції, повне завантаження 429 мс при 528 КБ розмітки.
B2B-каталог запчастин до швейних машин: TTFB 388,1 мс, повне завантаження 419,5 мс, HTML головної 120,2 КБ — третя найлегша розмітка у вибірці.
Магазин садової техніки та запчастин: TTFB 840,5 мс, повне завантаження 997,4 мс, HTML 454,5 КБ. Найповільніший відгук партії — і водночас найбільший каталог: 55 321 товарна сторінка плюс 3 868 категорій.
Висновок із цих чисел простий. Розмір каталогу не зобов'язує сайт бути повільним. П'ятдесят чотири тисячі позицій із відповіддю за 0,41 секунди і п'ятдесят п'ять тисяч позицій із відповіддю за 0,84 секунди стоять на одній і тій самій платформі. Різниця — в інженерії конкретного проєкту.
Найпоказовіший контраст
Два магазини з нашої вибірки працюють на одній OpenCart. Магазин натуральної косметики: TTFB 126,3 мс, повне завантаження 172,4 мс, HTML 196 КБ. Роздрібний магазин нижньої білизни: TTFB 1 544,5 мс.
Різниця у дванадцять разів на однаковій CMS. Це закриває дискусію «наша платформа повільна за природою» — принаймні для OpenCart. Платформа задає стелю можливостей, вона не задає поточну швидкість.
Ще один орієнтир із того ж заміру: клініці пластичної хірургії пошуковому боту віддається повністю пререндерений HTML за 145 мс до першого байта і 178 мс до повного документа — 126 КБ, з яких 24 КБ у gzip.
Де насправді втрачаються секунди
Сервер
Перше, на що ми дивимось на чужому сайті, — версія PHP і наявність кешу. На згаданому магазині садової техніки в момент заміру працював PHP 7.3.33, який не отримує оновлень безпеки з грудня 2021 року. Це питання і безпеки, і продуктивності одночасно: кожна мажорна версія PHP останніх років давала помітний приріст на тому самому коді.
Далі йдуть запити до бази. На каталозі в кілька тисяч товарів один невдалий запит у шаблоні категорії коштує сотні мілісекунд при кожному перегляді — і жодна оптимізація картинок цього не поверне.
Вага розмітки і зображення
Найлегший документ у цій партії — 102,1 КБ (односторінковий сайт консалтингової компанії, TTFB 254 мс). Найважча головна — 751,2 КБ, оптовий магазин білизни. Різниця в сім разів означає рівно стільки ж разів більше даних, які мобільний браузер тягне до першого екрана.
Стиснення недооцінюють постійно. На одному з магазинів садової техніки головна важить 143,6 КБ без стиснення і 22,5 КБ у brotli. Якщо brotli або gzip на сервері не ввімкнені, ви віддаєте вшестеро більше, ніж могли б, і виправляється це налаштуванням, а не переписуванням сайту.
Окремо — відкладене завантаження зображень. У роздрібному магазині садового інструменту 66 з 69 тегів <img> мають loading="lazy" (96%). У магазині засобів самооборони — 154 з 190, тобто 81%. Атрибут підтримують усі актуальні браузери, він додається в шаблон і не вимагає жодних бібліотек.
І перевіряйте не лише головну. У тому ж вимірі сторінка категорії зі ста товарами віддавала 554 КБ HTML при головній у 143,6 КБ. Люди з пошуку заходять саме на категорії й картки товару.
Сторонні скрипти
Кожен лічильник, чат, піксель і віджет — це додаткові запити та додатковий JavaScript, який блокує головний потік. У нашій вибірці трапився сайт із чотирма рекламно-аналітичними лічильниками одночасно.
Гірший випадок — скрипти, які вантажаться і не роблять при цьому нічого. У B2B-каталозі запчастин до швейних машин у розмітці досі підключений gtag.js із конфігом Universal Analytics, який Google остаточно вимкнув 1 липня 2023 року. Три роки цей запит виконується на кожному завантаженні сторінки і три роки не збирає жодних даних.
Мобільний — це і є основний вимір
Google сканує сайти смартфонним Googlebot: те, що бачить телефон, є те, що бачить пошуковик. Одночасно основна частина візитів із пошуку й соцмереж приходить зі смартфонів. Якщо на мобільному ламається фільтр або кнопка «Купити» ховається під клавіатурою, ця частка трафіку не конвертується взагалі — при тому, що вона вже оплачена рекламою або витраченим на SEO часом.
Межа тут така. Наявність мобільного viewport — необхідний мінімум, а не доказ зручності. Ми фіксуємо viewport зовнішнім виміром, а реальний мобільний досвід (чи легко пройти чекаут великим пальцем) перевіряється тільки на живих сесіях. У B2B-каталогах частина закупівельників справді працює з десктопа, і там пріоритет мобільної версії нижчий — це чесніше сказати, ніж продавати мобільну оптимізацію як універсальний пріоритет.
Як перевірити свій сайт за двадцять хвилин
Усе нижче працює з термінала й нічого не коштує.
1. Зніміть TTFB п'ять разів і візьміть медіану. Один замір нічого не доводить: розкид між запусками сягає десятків мілісекунд, тому в наших вимірах медіана бралася саме з п'яти запусків.
for i in 1 2 3 4 5; do
curl -s -o /dev/null \
-w "TTFB %{time_starttransfer}s | всього %{time_total}s | код %{http_code}\n" \
https://ваш-сайт.com.ua/
done
2. Повторіть для сторінки категорії та картки товару. Головна майже завжди найшвидша — вона частіше в кеші й простіша за запитами до бази.
3. Подивіться вагу HTML і чи працює стиснення.
curl -s https://ваш-сайт.com.ua/ | wc -c
curl -s -H "Accept-Encoding: br,gzip" -o /dev/null \
-w "стиснений розмір: %{size_download} байт\n" https://ваш-сайт.com.ua/
Якщо друге число майже дорівнює першому — стиснення не працює, і це найдешевша перемога з усіх можливих.
4. Порахуйте зображення з відкладеним завантаженням.
curl -s https://ваш-сайт.com.ua/ | grep -o '<img' | wc -l
curl -s https://ваш-сайт.com.ua/ | grep -o 'loading="lazy"' | wc -l
5. Відкрийте PageSpeed Insights і дивіться передусім на польові дані. Верхній блок із реальних сесій користувачів (CrUX) показує, що відбувається з живими людьми. Лабораторна частина нижче — симуляція на одній конфігурації: вона корисна для пошуку причин, але не є вироком.
6. Відкрийте DevTools, вкладку Network, відсортуйте за розміром. Ви одразу побачите найважчі файли й усі сторонні домени, які тягне сторінка. Часто там знаходиться забутий віджет із проєкту трирічної давнини.
У якому порядку це чинити
Спершу сервер. TTFB — підлога під усіма іншими метриками: поки сервер думає півтори секунди, оптимізація зображень цього не компенсує. Тут працюють кеш сторінок, свіжа версія PHP, індекси в базі, іноді просто інший тариф хостингу.
Потім зображення й вага розмітки. Це найдешевша частина роботи з найпередбачуванішим ефектом: сучасні формати, реальні розміри замість масштабованих браузером, loading="lazy" у шаблонах.
Далі сторонні скрипти. Проведіть інвентаризацію, вимкніть те, чим ніхто не користується, решту переведіть на відкладене завантаження.
І тільки в кінці — структурні речі: винесення статики, пререндер для ботів, переробка шаблонів. Вони дають найбільше, коштують найдорожче, і братися за них до того, як прибрано просте, сенсу немає.
Як зрозуміти, чи щось змінилось
Без аналітики ви не оптимізуєте нічого — ви тільки здогадуєтесь. Зафіксуйте числа до робіт, збережіть у файл із датою, і після кожної зміни знімайте ті самі метрики тим самим способом. Інакше через місяць у вас буде відчуття «начебто швидше» замість порівняння.
Межа й тут очевидна. Лічильник на сайті нічого не покращує сам по собі, він лише дає можливість побачити. Точність обмежують блокувальники реклами, режим згоди й обмеження браузерів на cookie: GA4 показує тенденцію, а не бухгалтерську істину, і зводити його цифри з касою треба свідомо.
Проблема частіше буває банальнішою. Під час заміру ми знайшли магазин косметики з каталогом на 5 561 товар і TTFB 801,2 мс, де на головній немає жодного лічильника — ні GTM, ні gtag, ні пікселя. Аналітики немає взагалі, тобто перевірити ефект від будь-яких змін там неможливо в принципі. Перш ніж оптимізувати швидкість, переконайтеся, що у вас є чим виміряти результат.
Що варто перевірити заодно
Поки ви вже в терміналі, витратьте ще п'ять хвилин на карту сайту. Сторінка, якої немає в індексі, не принесе жодного відвідувача, скільки б мілісекунд ви не виграли на її завантаженні.
У тому ж вимірі ми знайшли сім сайтів, де /sitemap.xml віддає HTTP 200 з тілом на 0 байт: формально відповідає, фактично не дає боту нічого. Ще на трьох robots.txt посилається на карту, яка віддає 404. Ще на одному карта лежить за нестандартною адресою і генерується 34,2 секунди.
Для контрасту: у виробника вогнетривких панелей 164 URL у карті й жодного дубля, у B2B-каталозі запчастин — 1 992 URL, теж без дублікатів. Різниця між цими станами не в бюджеті, а в тому, чи хтось хоч раз відкрив файл і подивився на нього.
Межа: карта сайту не піднімає позиції й не гарантує індексацію — Google пише про це прямо у своїй документації. Вона робить сторінки видимими для сканування, і не більше.
Усе це перевіряється curl за десять хвилин, а стан карти в очах пошуковика показує розділ Sitemaps у Search Console.
Коротко
Швидкість — це не одне число, і починати треба з питання, яке саме число у вас погане. Розмір каталогу повільність не пояснює: у наших вимірах 54 тисячі товарів віддаються за 0,41 секунди. Платформа теж не пояснює: два магазини на одній OpenCart відрізняються у дванадцять разів.
Виміряйте свій TTFB п'ять разів, подивіться вагу сторінки категорії, порахуйте сторонні скрипти. Цього вистачить, щоб зрозуміти, чи є у вас проблема взагалі. А наскільки її розв'язання відіб'ється на продажах, наперед чесно не скаже ніхто: це залежить від ніші, попиту й від того, що зараз відбувається на сайті крім швидкості.
Якщо після власного заміру числа виглядають погано, а причина неочевидна — напишіть нам, подивимось разом. Що ми робимо з такими сайтами, описано в розділі розробки й підтримки.
