Швидкість як конкурентна перевага: чому Core Web Vitals вирішують більше, ніж дизайн

Про швидкість сайту зазвичай згадують останньою. Спочатку дизайн, потім контент, потім «треба б прискорити». Насправді порядок зворотний: сторінка, яка не відкрилася, не має ні дизайну, ні контенту. Людина просто не дочекалася.

Core Web Vitals – це спроба Google виміряти не абстрактні секунди, а те, що людина відчуває: коли з’явилося головне, чи реагує сторінка на дотик, чи не стрибає верстка під пальцем.

Три метрики і їхні межі

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

LCP: що насправді гальмує

У 90% випадків найбільший елемент – це або велике зображення, або заголовок першого екрана. Причини затримки майже завжди з короткого списку:

• Важке зображення без сучасного формату. JPEG на 1,5 МБ там, де WebP дав би 200 КБ при тій самій якості.
• Ліниве завантаження на першому екрані. Атрибут loading="lazy" на головній картинці відкладає саме те, що треба показати першим.
• Шрифти, які блокують текст. Без font-display: swap заголовок чекає завантаження шрифту.
• Повільна відповідь сервера. Якщо сервер думає секунду, далі вже нічого не врятує.
• Відео на першому екрані. Красиво і дорого з погляду секунд.

INP: чому сторінка «залипає»

INP замінив FID і вимірює не першу реакцію, а найгіршу за весь сеанс. Це чесніша метрика: людина запам’ятовує саме той момент, коли натиснула й нічого не сталося.

Причина майже завжди одна – довгі задачі в JavaScript. Коли скрипт рахує щось 300 мілісекунд, браузер у цей час не може обробити натискання. Типові винуватці: важкі сторонні скрипти, обробники на кожен піксель прокрутки, синхронні обчислення при кліку, кілька систем аналітики одночасно.

CLS: стрибки верстки

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

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

Правило просте: усе, що з’явиться пізніше, має заздалегідь займати місце.

Лабораторні дані проти реальних

Це джерело плутанини. Інструменти на кшталт Lighthouse дають лабораторний прогін: один запуск, стабільні умови, симуляція. Google для ранжування використовує польові дані – реальні візити реальних людей на реальних пристроях.

Тому зелений Lighthouse і провалені Core Web Vitals у Search Console – нормальна ситуація. Лабораторні дані годяться для пошуку причин, польові – для оцінки стану. Орієнтуватися треба на другі.

Що це дає бізнесу

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

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

Порядок робіт, який дає результат

1. Подивіться польові дані. Search Console, розділ Core Web Vitals. Це відправна точка, а не Lighthouse.
2. Знайдіть найгірший шаблон сторінки. Зазвичай проблема не на всьому сайті, а на одному типі сторінок.
3. Почніть із зображень. Сучасні формати, правильні розміри, ніякого lazy на першому екрані. Найдешевший виграш.
4. Приберіть зайві сторонні скрипти. Порахуйте, скільки їх насправді і чи всі потрібні.
5. Задайте розміри всім блокам, що завантажуються пізніше. CLS лікується за один день.
6. Поверніться до польових даних через 28 днів. Раніше зміни не встигнуть накопичитися.

Помилки, які зустрічаються найчастіше

• Гонитва за сотнею балів у Lighthouse. Різниця між 85 і 98 балами часто не помітна користувачеві, а часу забирає більше, ніж усе решта.
• Плагін замість причини. Кеш-плагін приховає симптом, але не прибере три мегабайти зображень.
• Оптимізація без вимірювання до. Без базових цифр неможливо сказати, що допомогло.
• Тестування тільки на десктопі. Основні втрати завжди на мобільних.

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