Чому сайт повільний? Що лагодити першим для Core Web Vitals

Сайт здається повільним, коло в PageSpeed червоне, і в кожного в кімнаті свій винуватець. Ось порядок, у якому працюємо ми: спершу те, що бачать реальні відвідувачі, потім зображення, шрифти, сторонні скрипти, зсуви макета і час відповіді сервера. Заодно розберемо, що означає оцінка, скільки займає кожне виправлення і що ми змінили на власному сайті.

КОРОТКО

Що лагодити першим

Почніть із того, що реальні відвідувачі бачать на телефонах: відкрийте звіт Core Web Vitals у Search Console і подивіться, яка з трьох метрик не проходить. На більшості сторінок завантаження визначає зображення, тому перше завдання це найбільше зображення на першому екрані, потім шрифти, сторонні скрипти і зсуви макета. Сервер у цьому списку йде останнім, якщо тільки він сам не з'їдає більшу частину очікування; тоді він стає першим.

Цей порядок випливає з даних. У Web Almanac від HTTP Archive (дані липня 2025 року) усі три Core Web Vitals були в зеленій зоні у 48% мобільних сайтів і 56% десктопних. Найслабше на телефонах завантаження: добрий Largest Contentful Paint (LCP) у 62% мобільних сайтів, проти 77% за Interaction to Next Paint (INP) і 81% за Cumulative Layout Shift (CLS). А на 76% мобільних сторінок елемент, який вимірює LCP, це зображення.

Лагодьте те, що відчувають відвідувачі, а не те, що друкує тест.

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

РЕАЛЬНІ ВІЗИТИ

Спершу польові дані

Польові дані це те, що реальні користувачі Chrome отримали за попередні 28 днів; вони зібрані в Chrome UX Report (CrUX). З нього читають і звіт Core Web Vitals у Search Console, і верхній блок PageSpeed Insights. Чим це відрізняється від лабораторного тесту, розказано у статті 3D на живому сайті: наш експеримент із three.js і що побачив Google. Щоб вирішити, що лагодити, найважливіші три деталі.

Звіт судить групи, і за найгіршою метрикою. Search Console об'єднує адреси зі схожим досвідом у групу, і група отримує статус своєї найслабшої метрики: добрий INP при поганому CLS читається як погано. Це вказує на шаблон: коли 4 000 карток товару не проходять разом, одне виправлення лагодить їх усі.

Цифра описує повільніших відвідувачів. Google показує 75-й процентиль, окремо для телефонів і комп'ютерів: три візити з чотирьох були щонайменше такими швидкими. Прискорення сторінки для людей із новими телефонами на офісному Wi-Fi може його й не зрушити.

У даних є сліпі зони. CrUX збирає дані з Chrome на комп'ютерах і на Android. Chrome на iOS, застосунки Android із WebView та інші браузери на Chromium, наприклад Edge, виключені (Chrome for Developers, перевірено в листопаді 2026 року), а Safari взагалі окремий браузер. У жовтні 2026 року в Україні на iOS припадало близько 39% мобільного ринку (StatCounter), тож цей звіт може не бачити кожного третього телефона, а то й більше: у вашої аудиторії частка iPhone може бути вищою. Сайти нижче нерозкритого порога популярності не мають даних CrUX узагалі.

Ліки від обох прогалин одні: вимірювати власних відвідувачів. Від версії Safari 26.2 (грудень 2025 року) Safari віддає API для LCP та INP (WebKit). Відкрита бібліотека Google web-vitals, близько 3 КБ, може надсилати ці цифри з реальних сесій у вашу аналітику; CLS лишається тільки в Chromium.

Потім зіставте побачене з підозрюваними:

Пороги взято з web.dev (перевірено в листопаді 2026 року). Одне рішення за вас не ухвалить жоден інструмент: які шаблони йдуть першими. Для магазину це товар, категорія й оформлення замовлення; для бізнесу, що продає через заявки, сторінка послуги і форма. Ми читаємо бізнес раніше за звіт: повільна сторінка без замовлень може зачекати, а трохи швидша, на якій тримається виручка, чекати не може.

ОЦІНКА

Що означає оцінка

Число в колі це оцінка Lighthouse за одним симульованим завантаженням на телефоні середнього рівня з фіксованою мережею. Її поточні ваги, як їх описує Chrome: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% і Speed Index 10%. INP у ній немає, бо під час лабораторного прогону ніхто не натискає на екран. Його заміняє Total Blocking Time, і web.dev прямо пише: це розумна заміна для лабораторії, але не рівноцінна.

Оцінка дає повторюваний список проблем однієї сторінки в жорстких умовах і чесне порівняння «до і після». Багато чого вона залишає поза кадром:

• Досвід відвідувачів. Лабораторний прогін починається з холодного кешу, зазвичай пропускає зсуви під час прокручування і не бачить справжнього натискання (web.dev).
• Ранжування. Google рекомендує добрі Core Web Vitals для успіху в пошуку, пише, що вони не гарантують верхніх позицій, і що єдиного сигналу page experience не існує.
• Стабільність. Документація Chrome називає A/B-тести, змінну рекламу й мережеві маршрути серед причин, через які оцінка гуляє від прогону до прогону.

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

У жовтні 2026 року наша головна отримала 32 на мобільному, бо тестова машина не має відеочипа і малює нашу 3D-сцену програмно; після змін, описаних у статті про 3D на живому сайті, стало 78. Тестовий браузер може навіть створити проблему, якої немає в жодного відвідувача: Lighthouse розтягує вікно на всю висоту сторінки заради повного скриншота, і полотно, прив'язане до висоти вікна, виросло до 16 000 пікселів, поки ми його не обмежили. Сторінки наших статей отримали 75 на мобільному 25 жовтня 2026 року. Це помаранчева зона, і ми пишемо про це, бо оцінка для нас робочий інструмент.

ЗОБРАЖЕННЯ

Почніть із зображень

Із зображеннями два окремі завдання.

Завдання перше: те єдине зображення, яке вимірює LCP. web.dev ділить LCP на чотири частини: час до першого байта, затримка початку завантаження ресурсу, тривалість його завантаження і затримка малювання елемента, з орієнтиром приблизно 40%, менше 10%, приблизно 40% і менше 10%. Обидві затримки мають прямувати до нуля, а LCP breakdown в інструментах Chrome покаже ваші. На багатьох сторінках зображення просто починає завантажуватися занадто пізно, з однієї з трьох причин:

• Воно завантажується ліниво. Приблизно від 16% до 17% сторінок роблять так зі своїм зображенням LCP (Web Almanac, 2025), а web.dev просить не робити цього ніколи.
• Браузер знаходить його пізно, бо воно лежить у фоні CSS або у скрипті слайдера. Тоді потрібен preload із високим пріоритетом.
• Браузеру ніхто не сказав, що воно важливе. Лише 17,3% мобільних сторінок ставлять на нього fetchpriority="high".

Виправлення може зайняти один рядок: <img src="cover.jpg" alt="..." width="1802" height="873" fetchpriority="high">. Саме так виводиться обкладинка на сторінках наших статей. Високий пріоритет давайте одному-двом зображенням, не більше: як зазначає web.dev, далі він перестає допомагати.

Перше завдання це одне зображення, а не всі одразу.

Завдання друге: все інше. Середня (медіана) мобільна головна несе 911 КБ зображень, це її найбільший тип вмісту (Web Almanac, липень 2025 року). Про кожне зображення спитайте, чи потрібне воно цьому відвідувачу зараз і в такому розмірі.

Наш блог навчив нас обох половин цього питання. У його рядках є прев'ю при наведенні: зображення, яке з'являється поруч із посиланням, коли на нього навели мишу. Раніше вони завантажувалися разом зі сторінкою. 17 жовтня 2026 року ми це змінили: зображення запитується, лише коли вказівник дійшов до посилання, телефони його не просять зовсім, а зображення всередині тексту статей отримали ліниве завантаження. Вага зображень під час першого показу впала з 2,9 МБ до 0,4 МБ на блозі і приблизно з 5 МБ до 0,25 МБ на одній довгій статті.

Потім виправлення показало свою ціну: прев'ю приходили із запізненням, і блог пригальмовував під мишею. Це були оригінали від 230 до 250 КБ для маленького віконця. Тепер це копії шириною 720 пікселів, близько 50 КБ (два приклади, перевірено 2 листопада 2026 року: 233 КБ проти 54 КБ, 249 КБ проти 47 КБ), і на широких екранах із мишею кожна завантажується, коли її рядок наближається.

Самі зображення на нашому сайті ніколи не перетискаються: таке наше правило для робіт студії. Менші копії для менших вікон дали економію близько 80% і не торкнулися оригіналів. Сильніше стиснення і нові формати цілком законні інструменти, і для великого каталогу вони можуть бути правильним вибором; вирішувати має той, кому важливий зовнішній вигляд.

ШРИФТИ

Шрифти: дешево і забуто

87% мобільних сторінок використовують вебшрифт (Web Almanac, 2025), і шкодять шрифти двома способами. Приблизно на 24% мобільних сторінок елемент LCP це текст, тож пізній шрифт може затримати головну метрику. А шрифт, що прийшов, здатен зсунути макет: навіть невидимий текст спочатку верстається запасним шрифтом, і підміна рухає вміст (web.dev).

Браузер завантажує шрифт, лише коли його запитують стилі, тому шрифт, оголошений у зовнішній таблиці стилів, виявляється пізно. Звичайне лікування:

• Віддавайте тільки WOFF2.
• Робіть preload одного-двох накреслень, потрібних першому екрану, і не більше: preload забирає канал в інших ресурсів.
• Обирайте font-display свідомо: swap показує текст одразу і ризикує стрибком, optional уникає стрибка і може пропустити шрифт, якщо він запізнився.
• Підганяйте запасний шрифт через size-adjust, щоб підміна рухала менше.
• На сайті з кирилицею і латиницею розбийте великі гарнітури на набори і підключайте через unicode-range, якщо ліцензія дозволяє: браузер завантажить тільки потрібний алфавіт.

Ми робимо preload двох накреслень на кожній сторінці, SF Pro Regular і Semibold, у WOFF2 з font-display: swap. Найкраща знахідка виявилася дрібнішою. Спливне вікно «Поділитися» використовувало накреслення Black для підписів, і лише через це браузер завантажував файл шрифту Black на кожній сторінці. Підписи перевели на Semibold, і завантаження зникло. Подивіться, які файли шрифтів сторінка завантажує насправді.

СТОРОННІ СКРИПТИ

Скрипти й повільні натискання

Щонайменше 90% сторінок використовують сторонні сервіси, і медіанна сторінка на мобільному робить 79 сторонніх запитів (Web Almanac, 2025). У 2025 році медіанний Total Blocking Time на мобільних виріс на 58%, з 1 209 до 1 916 мілісекунд, тоді як web.dev просить менше 200. Не все це приходить від сторонніх сервісів, але ми дивимося туди насамперед: щоб прибрати тег, не треба переписувати продукт.

Механізм такий: браузер обробляє натискання в основному потоці, і взаємодія складається з трьох частин: затримка введення, обробка і затримка малювання. Завдання понад 50 мілісекунд вважається довгим, а натискання, що потрапило на нього, чекає в черзі. Тег аналітики, віджет чату й теплова карта окремо здаються дрібницею; разом вони заповнюють цю чергу.

Це радше управлінське завдання, ніж технічне: кожен тег поставили не просто так, а прибирати його ніхто не відповідає. Наш порядок:

1. Перелічіть усі теги з трьома відповідями: хто його просив, яке рішення він живить і коли хтось востаннє дивився його дані. Теги без відповідей ідуть до керівника маркетингу.
2. Ставте на паузу або видаляйте, але не блокуйте. За рекомендацією Google призупинений або видалений тег іде з контейнера, а тег, заблокований винятком у тригері, лишається в коді.
3. Запускайте необов'язкове після Window Loaded. Момент завантаження самого менеджера тегів може важити не менше.
4. Придивіться до тегів Custom HTML. Більшість інструментів приписує їхню роботу менеджеру тегів. web.dev повідомляє про зв'язок між розміром контейнера і гіршим INP; медіанний контейнер важить близько 50 КБ.
5. Запускайте віджети на вимогу. Вікно чату може завантажуватися після першого натискання на його кнопку.

Те саме стосується вашого власного коду. Аудіограф для фонового звуку на нашій головній коштував близько 0,3 секунди під час завантаження; тепер він будується при першому дотику, кліку або натисканні клавіші.

ЗСУВИ МАКЕТА

Щоб сторінка не стрибала

CLS єдина метрика, де комп'ютери гірші за телефони: у зеленій зоні 72% десктопних сайтів проти 81% мобільних (Web Almanac, 2025). Лабораторія бачить її найгірше: зсуви в межах 500 мілісекунд після натискання пробачаються, а прокручуванню й наведенню такого пробачення немає, тож блок, який стрибає під час прокручування, іде вам у мінус і може взагалі не з'явитися в тесті завантаження.

Більшість причин цілком звичайні. На 62% мобільних сторінок є хоча б одне зображення без розмірів, тому браузер виділяє йому нульову висоту і рухає все, коли воно приходить; лікується атрибутами width і height або властивістю aspect-ratio в CSS. Рекламі, вбудованим блокам і iframe потрібне зарезервоване місце через min-height або aspect-ratio. Анімації краще будувати на transform: рух через top або left вважається зсувом, а translate ні (web.dev).

Легко проґавити блок, який скрипт будує вже після першого малювання. У нас таких було два. На телефонах скрипт збирав зміст кожної статті із заголовків і штовхав текст униз: CLS 0,19 на сторінках статей. Панель розділів блогу вже після малювання вирішувала, чи вмістяться посилання в один рядок, чи потрібні дві колонки: CLS 0,5.

Обидва виправлення перенесли рішення на раніший час. Тепер зміст одразу малює сервер в HTML, а скрипт його лише підхоплює: з 0,19 до 0. Кілька рядків вбудованого скрипта одразу після панелі вирішують її вигляд до першого малювання: з 0,5 до 0. Перше виправлення має постійну ціну: правила збирання змісту тепер живуть у двох місцях, на сервері й у скрипті, і змінювати їх треба разом.

Вирішуйте вигляд блока до першого малювання, а не після нього.

Чесна перевірка: завантажте сторінку на повільному з'єднанні й дивіться. Усе, що з'являється і штовхає сусідів, потребує зарезервованого місця або малювання на сервері.

СЕРВЕР

Коли сервер іде першим

Time to First Byte (TTFB) це час, який браузер чекає перший байт HTML. web.dev пропонує орієнтир 0,8 секунди і вважає поганим усе вище за 1,8; у 2025 році в зеленій зоні були 44% мобільних і 55% десктопних сайтів (Web Almanac). Це не Core Web Vital, але він витрачає той самий бюджет: при TTFB 1,8 секунди на все інше в межах LCP 2,5 секунди лишається 0,7. Ось тоді сервер і стає першим у списку.

Перший вимір свого сайту зробіть із термінала, кілька разів поспіль, звідкись поруч із вашими клієнтами:

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://your-site.example/page

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

Спершу дешеве, і налаштування часто краще за залізо. На одному з наших проєктів тариф хостингу вже пропонував OPcache, кеш скомпільованого коду PHP, але його ніхто не ввімкнув; вмикання скоротило відповідь сервера приблизно з 55 до приблизно 21 мілісекунди. Редиректи всередині свого домену ви можете прибрати самі. Заголовок Server-Timing показує, який крок на сервері забирає час. CDN заслуговує на високий пріоритет, якщо його немає, пише web.dev, як і кешування сторінок.

Будь-яке налаштування швидкості може щось зламати. Перш ніж увімкнути кеш конфігурації Laravel, нам довелося переписати код, який читав налаштування оточення напряму, інакше ці значення стали б порожніми. На закритій тестовій копії одного з наших проєктів кешування маршрутів перетворило кожну сторінку на 404, бо мовні префікси беруться з бази. Тому такі зміни проходять регресію на копії, докладніше у статті Скільки тестування потрібно сайту або застосунку перед запуском?

Повторні візити дають окремий виграш, і PageSpeed його не покаже. Наші CSS і JavaScript кешуються на рік (Cache-Control: max-age=31536000), а адреса кожного файла несе час його зміни, ?v=<час>, тож правка доходить до всіх одразу. Лабораторний тест починається з холодного кешу, тому оцінка цього ніколи не бачить; читач на другій сторінці бачить.

Відстань це фізика. У документації AWS сказано, що регіон поруч із більшістю ваших користувачів знижує затримку, а в її списку немає регіону в Україні, найближчі в Європі. Сервер у США відповідатиме покупцеві в Україні помітно довше, ніж сервер поруч, тому перевірте, де стоїть сайт і чи є CDN із вузлами недалеко від ваших клієнтів.

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

ВАРТІСТЬ

Скільки коштує робота

У таблиці наша приблизна оцінка обсягу інженерної роботи на бізнес-сайті з кількома шаблонами: орієнтир для планування, а не кошторис.

Коли причина в останньому рядку, модернізація сайту починається з аудиту, від $300 для невеликого сайту і від $1 000 для великого, а роботи оцінюються після нього. Якщо ви не впевнені, що проблема взагалі у швидкості, юзабіліті аудит, від $1 500, перевіряє ключові сценарії, зокрема швидкість. Робота лише із сервером це DevOps і хмарна інфраструктура, від $50 до $70 на годину. Утримувати цифри від сповзання назад допомагає підтримка та обслуговування сайтів, від $1 000 на місяць, бо один новий тег або банер може за день скасувати всю роботу. Новий сайт це крайній захід і інший бюджет: у послузі Створення сайтів під ключ корпоративний сайт коштує від $20 000 до $40 000, інтернет-магазин від $25 000. Усі ціни на сторінці цін.

Чи це виправдано? Чистий публічний тест провів Vodafone, опублікований на web.dev у 2021 році: A/B-тест на платному трафіку з двома зовні однаковими сторінками, де LCP на 31% кращий збігся із зростанням продажів на 8%. Це одна компанія й одна сторінка: привід провести власне порівняння, але не прогноз. Ми не обіцяємо позицій або виручки від робіт над швидкістю. Запишіть конверсію шаблону до виправлення і порівняйте після, з поправкою на кампанії та сезон.

Закладіть час на доказ. Польові дані охоплюють 28 днів, тому виправлення видно повністю приблизно за місяць, і перевірка в Search Console теж стежить за 28-денним вікном. Власний скрипт із web-vitals дасть сигнал за лічені дні.

FAQ

Джерела

• web.dev: Web Vitals
• HTTP Archive, Web Almanac 2025: Performance
• HTTP Archive, Web Almanac 2025: Third Parties
• Google Search Central: Understanding page experience
• web.dev: Optimize LCP