Скоростта като конкурентно предимство: защо 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 често е невидима за потребителя, а отнема повече време от всичко останало.
• Плъгин вместо причина. Кеш плъгинът ще скрие симптома, но няма да махне три мегабайта изображения.
• Оптимизация без измерване преди това. Без изходни числа не може да се каже какво е помогнало.
• Тестване само на десктоп. Основните загуби винаги са на мобилни устройства.

Скоростта рядко е главната причина сайтът да не носи заявки. Но тя почти винаги е множител: всичко останало работи по-зле, докато страницата се зарежда четири секунди. Затова е полезно да се започне от нея, а не след редизайна.