PageSpeed 100 зі 100 у 2026: як і навіщо

PageSpeed 100/100 у 2026 = LCP < 2.5с + INP < 200мс + CLS < 0.1. Досягається так: критичний CSS інлайниться в head (не більш ніж 14 КБ), усе інше — defer. Зображення в AVIF/WebP з правильними розмірами та loading="lazy". Шрифти з font-display: swap і preload лише для критичних гліфів. JS-фреймворки замінюються на vanilla або islands-архітектуру де можливо — це знімає 100–300 КБ. Сервер — Brotli + HTTP/2 + immutable cache на рік для статики. На реальних проєктах mobile-метрика піднімається з 40–50 до 95–100 за 5–7 робочих днів, приріст органічного трафіку — 15–35% за 2–4 місяці. Гнатися за 100/100 необов'язково — 90+ на мобільному вже дає максимум ранжувального бонусу. У статті — покроковий план оптимізації, інструменти замірів і 7 типових помилок.

Навіщо взагалі пришвидшувати сайт

Три прагматичні причини – без ідеології «бо Google так сказав».

• SEO-фактор. Google враховує Core Web Vitals як фактор ранжування з 2021. На конкурентних запитах швидкий сайт обходить повільний, за інших рівних умов.
• Конверсія. Кожна +1 секунда завантаження зменшує конверсію на 5-7%. В e-commerce – більше. Прямі втрати грошей.
• Вартість реклами. Google Ads дає знижку на CPC для швидких лендингів і навпаки штрафує повільні. Бюджет – реально впливає.

Core Web Vitals: LCP, INP, CLS

Це три метрики, які Google вимірює в реальних користувачів через Chrome (CrUX-дані). Із 2021 вони – частина алгоритму ранжування.

LCP (Largest Contentful Paint)

За скільки з'являється найбільший елемент на першому екрані – зазвичай головне зображення або великий заголовок. Добре: < 2.5s. Погано: > 4s.

Головні винуватці поганого LCP: важкі hero-картинки без `fetchpriority="high"`, відсутність `preload`, повільний сервер (TTFB), блокувальні скрипти в head.

INP (Interaction to Next Paint)

Замінив FID у 2024. Вимірює, наскільки швидко сторінка реагує на клік/тап/натискання клавіші. Добре: < 200ms. Погано: > 500ms.

Головні винуватці поганого INP: важкий JS на main thread, синхронні обробники подій, довгі ланцюжки `setTimeout`. Це «сучасний» головний біль: навіть якщо сторінка швидко завантажилася, вона може «залипати» на клік через поганий JS.

CLS (Cumulative Layout Shift)

Сума «стрибків» верстки під час завантаження. Коли банер згори підвантажився – і весь текст зсунувся вниз = поганий CLS. Добре: < 0.1. Погано: > 0.25.

Головні винуватці: зображення без зазначеної width/height, шрифти, які змінюють розмір під час підвантаження, рекламні блоки, динамічно вставлювані елементи.

7 головних факторів швидкості

Це базовий чек-лист. У 90% випадків саме ці пункти дають 70-90% приросту PageSpeed.

• Картинки у WebP/AVIF + lazy load. 80% «важкості» сторінок – це картинки. Конвертація PNG/JPG у WebP дає -40-60% за розміром. AVIF ще краще, але підтримка трохи гірша.
• Мініфікація та compression (Brotli). CSS/JS мають бути мініфіковані. Сервер повинен віддавати з Brotli (або хоча б gzip). Cloudflare робить це автоматично.
• Видалити невикористовуваний CSS/JS. Будь-який `bootstrap.css` чи `jquery.js`, якщо не використовується хоча б на 30% – видалити. PurgeCSS + tree-shaking у bundler-і.
• Шрифти з font-display: swap. Без цього користувач бачить білий екран, поки шрифт вантажиться 1-2 секунди. Зі swap – спершу системний шрифт, потім підміняється.
• Preload головного hero-image + preconnect до CDN. `` зменшує LCP на 0.5-1.5 секунди.
• CDN (Cloudflare). Якщо сайт хоститься в одному регіоні, а клієнти з EU – без CDN сторінка вантажиться 3-5 секунд тільки через географію. Cloudflare безкоштовно вирішує цю проблему.
• HTTP/2 чи HTTP/3. Сучасний протокол з мультиплексуванням. Вмикається однією галочкою на хостингу або в Cloudflare. Без нього браузер качає файли послідовно замість паралельного.

План оптимізації за тиждень

Реалістичний графік розгону сайту з 40-50 балів Mobile до 90+:

1. Аудитдень 1
2. Картинкидень 2-3
3. CSS/JSдень 4
4. CDN/HTTPдень 5
5. Фінішдень 6-7

День 1 – аудит. Прогін через PageSpeed Insights + Lighthouse у DevTools. Записуєте поточні LCP/INP/CLS, TBT, розмір сторінки. Це базова точка для замірів. Паралельно – WebPageTest для waterfall-аналізу.

День 2-3 – картинки. Усі JPG/PNG конвертуєте у WebP (масово через `cwebp` CLI чи Squoosh.app). Додаєте атрибути `width`/`height` до всіх `` (боротьба з CLS). Hero-картинку – з `fetchpriority="high"` і preload у ``. Решту – `loading="lazy"`.

День 4 – CSS/JS. Мініфікація (якщо ще не зроблено). Видалення невикористовуваного CSS через PurgeCSS. Скрипти, які не потрібні в першому екрані – з `defer`. Аналітика та лічильники – асинхронно або після `DOMContentLoaded`.

День 5 – CDN і HTTP/3. Підключаєте Cloudflare (якщо ще немає) – безкоштовно, 5 хвилин. Вмикаєте Brotli, HTTP/3, Auto Minify, Rocket Loader (обережно – може ламати JS). Налаштовуєте cache rules для статики (1 рік для assets з hash у назві).

День 6-7 – фініш. Повторний прогін PageSpeed. Точкові виправлення решти проблем: third-party скрипти в iframe, шрифти з font-display, видалення непотрібних preconnect. Фінальний замір. Якщо 90+ Mobile – мету досягнуто.

7 типових помилок

Бачив ці граблі регулярно – у клієнтів з попереднім підрядником або після самостійних спроб.

1. Оптимізувати Desktop, забути про Mobile. Mobile-first indexing з 2019. Google ранжує на основі мобільної версії. Desktop 95 + Mobile 45 = ранжується як 45.
2. Тестувати лише в Lighthouse, не дивитися field-data. Lighthouse – лабораторні дані. Search Console показує реальні CWV у реальних користувачів. Вони можуть відрізнятися.
3. «Допомагає плагін WP-Optimize, ставимо». Плагіни-оптимізатори часто конфліктують, роблять непередбачуване. Краще один грамотно налаштований, ніж три, що «допомагають» один одному.
4. Lazy load hero-картинки. Найбільша помилка. Lazy load для картинки вище fold = збільшення LCP. Lazy load – тільки для картинок нижче першого екрана.
5. Важкі шрифти без preload і font-display. 800-шрифт з підтримкою 5 мов = 200KB. Без font-display: swap – білий екран 1-2 секунди. З preload – LCP скорочується.
6. Third-party скрипти в head. Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... у head синхронно – TBT (Total Blocking Time) їде в червону зону. Перенесення у footer чи асинхронно.
7. Ігнорувати Server-Side performance. TTFB (Time to First Byte) – часто проблема серверного боку: повільний PHP, неоптимізовані SQL-запити, відсутність кешування на сервері. Оптимізація лише клієнта не допоможе, якщо сервер сам віддає за 2 секунди.

Часті запитання