Швидкість сайту давно не варто оцінювати лише за відчуттям «відкривається швидко» або за одним балом у PageSpeed Insights. Google дивиться на сторінку ширше: через Core Web Vitals — ключові показники якості сторінки, які відображають реальний користувацький досвід. Для SEO це важливо, але без спрощень: хороша швидкодія і page experience можуть допомогти сайту, проте самі по собі не замінюють релевантний контент, структуру і корисність сторінки.

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

Сьогодні проблему швидкості краще розбирати не загалом, а по метриках: що саме гальмує появу головного елемента, що затримує реакцію після кліку і що ламає стабільність верстки. Тому в центрі уваги вже не абстрактна «швидкість завантаження», а LCP, INP, CLS, важкі ресурси над першим екраном, JavaScript, шрифти, сторонні скрипти, блоки реклами, iframe та інші елементи, які реально впливають на досвід користувача.

Швидкість сайту, PageSpeed Insights і Core Web Vitals — ілюстрація до статті

Які метрики важливі зараз

На момент оновлення цієї статті Google орієнтується на три основні метрики Core Web Vitals :

  • LCP — Largest Contentful Paint, тобто час появи найбільшого видимого елемента в межах першого екрана. Хорошим вважається значення до 2,5 секунди.
  • INP — Interaction to Next Paint, тобто швидкість реакції сторінки на взаємодію користувача. Хороший рівень — до 200 мс.
  • CLS — Cumulative Layout Shift, тобто стабільність верстки під час завантаження. Хороший показник — до 0,1.

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

З чого починати перевірку

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

  1. Польові дані — реальна поведінка сторінки у користувачів. Якщо вони доступні, PageSpeed Insights показує їх із Chrome UX Report.
  2. Лабораторні дані — контрольований тест Lighthouse, який допомагає локалізувати проблему, але не є заміною реального досвіду.

Для робочої діагностики зазвичай достатньо такої послідовності: спочатку перевірити URL у PageSpeed Insights, потім подивитися звіт Core Web Vitals у Google Search Console , а вже після цього розбирати конкретні причини в DevTools, Lighthouse або в межах технічного SEO-аудиту сайту .

Варто враховувати і ще один практичний момент: у Search Console проблеми часто показуються не для однієї конкретної сторінки, а для групи схожих URL. Тому такий звіт краще читати як сигнал по типу сторінок, а не як ізольований збій на одній адресі.

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

Що найчастіше псує LCP

LCP найчастіше ламається не через «повільний сайт загалом», а через конкретний великий елемент на першому екрані. У комерційних сторінок це зазвичай hero-image, великий банер, заголовок із вебшрифтом або головний контентний блок, який браузер знаходить занадто пізно.

Тут є важливий нюанс: найбільшим елементом сторінки не завжди виявляється те, що очікує власник сайту. Інколи це справді банер, а інколи — великий заголовок, текстовий блок або інший елемент першого екрана. Саме тому ситуація «оптимізували картинку, а LCP майже не змінився» трапляється набагато частіше, ніж здається.

Один із найтиповіших промахів — коли головне зображення на першому екрані завантажується через lazy loading. Для LCP це погана практика: сторінка відкладає завантаження саме того елемента, який повинен з’явитися першим. Якщо велике зображення реально є головним елементом сторінки, його потрібно завантажувати пріоритетно, а не відкладати. Це прямо підкреслюється і в рекомендаціях web.dev щодо LCP .

Що зазвичай допомагає для LCP:

  • не lazy-load’ити головне зображення першого екрана;
  • віддавати його через звичайний <img> , а не ховати за data-src чи JavaScript;
  • стискати зображення без втрати змісту і віддавати сучасні формати там, де це доречно;
  • не змушувати браузер відкривати головний ресурс занадто пізно через важкі CSS або JS;
  • за потреби використовувати preload для критичного зображення або шрифту, якщо браузер знаходить їх із затримкою.

Якщо сайт працює на старій темі, шаблоні або конструкторі, проблема часто глибша, ніж просто картинка на сторінці. Інколи повільний LCP — це наслідок того, як загалом побудована сторінка ще на етапі розробки сайту : важкий перший екран, зайві бібліотеки, фонова картинка замість нормального <img> , заплутаний CSS або затримка через шрифти.

Як покращити INP

INP просідає тоді, коли сторінка повільно реагує на дію користувача: клік, тап, відкриття меню, запуск фільтра, перемикання вкладки, заповнення форми. У більшості випадків проблема не в сервері, а в main thread браузера — основному потоці, який зайнятий довгими JavaScript-задачами.

На практиці слабкий INP найчастіше пов’язаний із такими речами:

  • важкі JS-бандли, які довго парсяться й виконуються;
  • надмірна кількість сторонніх скриптів — чати, трекери, віджети, A/B-сервіси, попапи;
  • складні обробники подій на кнопках, фільтрах, формах і меню;
  • великий DOM або часті перерахунки верстки після взаємодії користувача;
  • довгі задачі, які блокують сторінку на сотні мілісекунд.

Тому класична порада «підключіть async і defer» сама по собі вже не вирішує проблему. Так, defer і async корисні для неблокуючих сценаріїв, але якщо на сторінці залишається важкий JavaScript, слабкий INP нікуди не зникне. Тут доводиться чистити зайві скрипти, розбивати довгі задачі, відкладати нефункціональні модулі і перевіряти, що саме відбувається після кліку або тапу.

Як зменшити CLS

CLS — це про стрибки верстки. Саме через нього кнопка може «поїхати» вниз у момент, коли користувач уже тягнеться до неї, а текст раптом зміщується після завантаження банера, iframe або шрифту. Для контентного та комерційного сайту це не дрібниця, а реальна проблема користувацького досвіду.

Найчастіші причини поганого CLS добре відомі:

  • зображення без заздалегідь визначених розмірів;
  • рекламні блоки, embeds та iframe без зарезервованого місця;
  • динамічно вставлений контент над уже видимою частиною сторінки;
  • вебшрифти, які змінюють розмір або ширину тексту після підвантаження.

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

Окремо варто перевірити, чи не блокуються CSS, JS або зображення в robots.txt . Такі помилки не завжди стають головною причиною просідання метрик, але можуть ламати коректне відтворення сторінки та її аналіз пошуковими системами.

Що ще реально впливає на швидкодію

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

  1. Критичні ресурси над першим екраном. Якщо сторінка не може швидко намалювати перший екран через великий CSS, важкі шрифти або заплутаний ланцюг ресурсів, LCP майже завжди страждає.
  2. Невикористані CSS і JS. Старі теми, CMS-плагіни й універсальні шаблони часто тягнуть код, який не потрібен конкретній сторінці, але все одно блокує або ускладнює рендеринг.
  3. Кешування і стиснення. Довгий cache lifetime для статичних файлів, Brotli або Gzip, а також коректні заголовки кешу не виправлять погану архітектуру, але часто дають помітний виграш.
  4. Сервер і TTFB. Повільна відповідь сервера теж шкодить, особливо якщо вона затримує віддачу HTML. Але в сучасних проектах TTFB — це лише частина картини, а не єдине джерело проблеми.
  5. CDN. CDN корисний, якщо сайт має широку географію трафіку або важкі статичні ресурси. Але CDN не прибере довгі JS-задачі, не стабілізує CLS і не зробить легшим перевантажений перший екран.
  6. Сторонні сервіси. Саме вони часто «з’їдають» і LCP, і INP, і CLS одночасно: чати, віджети, пікселі, сторонні форми, відеовставки, рекомендаційні блоки.

Хороше покращення швидкодії зазвичай починається не з «магічного плагіна», а з чистки зайвого: непотрібних скриптів, дубльованих бібліотек, надмірних стилів, важких банерів, фонових зображень у першому екрані і будь-яких модулів, які не впливають на конверсію, але уповільнюють сторінку для всіх.

Аналіз продуктивності сторінки: LCP, INP, CLS та технічні причини просідання

Що часто роблять неправильно

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

  • не зводити всю оптимізацію до одного балу в PageSpeed Insights;
  • не писати, що швидкість сама по собі гарантує високі позиції в Google;
  • не lazy-load’ити LCP-зображення тільки тому, що «так радять для всіх картинок»;
  • не лікувати INP лише атрибутами async і defer , якщо сторінка перевантажена JavaScript;
  • не ігнорувати CLS, бо візуальні стрибки часто б’ють по UX сильніше, ніж кілька десятих секунди в лабораторному тесті;
  • не сподіватися, що CDN або кеш автоматично вирішать проблеми важкого шаблону, поганого DOM і сторонніх віджетів.

Як виглядає нормальний робочий план

Якщо відкинути красиві презентації й дивитися на реальний процес, то він зазвичай виглядає так:

  1. Перевірити польові дані й зрозуміти, яка метрика просідає — LCP, INP чи CLS.
  2. Знайти конкретний елемент або сценарій, що псує метрику.
  3. Окремо перевірити мобільну версію, бо саме там проблеми часто проявляються сильніше.
  4. Почистити перший екран, JavaScript, сторонні скрипти, шрифти, банери та нестабільні блоки.
  5. Повторно звірити результат у PageSpeed Insights, Search Console і за потреби у власному RUM-моніторингу.

Такий підхід майже завжди ефективніший, ніж нескінченно «добивати бал» і переслідувати дрібні аудити, які не мають реального впливу на досвід користувача. Якщо потрібно окремо подивитися на технічні підходи до покращення метрик, корисно звірити їх і з практичними рекомендаціями web.dev щодо Core Web Vitals .

Висновок

Покращення швидкості сайту сьогодні — це вже не історія про абстрактне «зробити сторінку легшою». Це робота з конкретними метриками Core Web Vitals і конкретними технічними причинами, через які користувач бачить повільний перший екран, відчуває затримку після кліку або стикається зі стрибками верстки.

Для LCP потрібно швидше показати головний елемент сторінки. Для INP — розвантажити JavaScript і main thread. Для CLS — стабілізувати макет ще до завантаження всіх блоків. А вже потім мають сенс кеш, CDN, стиснення, дрібні аудити і косметичні правки.

Коли сайт старий, шаблон перевантажений або проблема сидить глибше, ніж у кількох картинках і скриптах, локальні правки не завжди дають потрібний результат. У таких випадках краще дивитися на швидкодію як на частину ширшої технічної оптимізації, SEO-аудиту й архітектури сайту, а не як на окремий пункт у чек-листі.