Core Web Vitals: CLS, LCP и FID – какво означават и защо са важни за SEO?

Какво представляват Core Web Vitals?

Core Web Vitals са група метрики на Google, които измерват скоростта на зареждане, интерактивността и визуалната стабилност на уеб страница, гледани през очите на реалния потребител. Те са част от по-широкия сигнал “Page Experience”, който Google въвежда в класирането през юни 2021 г.

Важно е да ги поставим в контекст. Core Web Vitals са един от многото сигнали за класиране и не заместват качественото и релевантно съдържание. При две страници с подобно съдържание и авторитет обаче по-бързата и по-стабилна често печели. Освен това добрите показатели намаляват процента на напускане, подобряват удовлетвореността и увеличават конверсиите, особено в онлайн магазини, където всяка секунда забавяне струва продажби.

Трите основни метрики

Google оценява страницата по 75-ия процентил от реалните посещения, разделени по мобилни и десктоп устройства. За да получите оценка "добро", поне 75% от посещенията трябва да отговарят на прага. Това означава, че не е достатъчно страницата да е бърза на вашия лаптоп с оптичен интернет, а трябва да работи добре и на среден телефон с мобилна мрежа.

1. Largest Contentful Paint (LCP)

LCP измерва времето, за което най-големият видим елемент в началния екран (viewport) се зарежда. Обикновено това е главно изображение (hero), снимка на продукт, видео постер или голям текстов блок.

Добри стойности: под 2.5 секунди.

Какво го забавя

• Бавен сървър и високо време за отговор (TTFB)
• Големи, некомпресирани или неоптимизирани изображения
• Блокиращ рендването CSS и JavaScript
• Късно откриване на LCP елемента от браузъра (например изображение, зададено като CSS background или зареждано с JavaScript)
• Lazy loading, приложен по погрешка на главното изображение
• Липса на кеширане и на CDN
• Уеб шрифтове, които забавят показването на текстовия LCP елемент

Как да го подобрим

Оптимизирайте сървъра и TTFB. LCP не може да е бърз, ако самият HTML пристига бавно.

• Използвайте качествен хостинг с актуална версия на PHP, OPcache и HTTP/2 или HTTP/3.
• Внедрете кеширане на пълни страници (page cache) и object cache (Redis или Memcached) за динамични сайтове.
• Оптимизирайте бавните заявки към базата данни.
• В WordPress/WooCommerce ограничете броя на плъгините, които изпълняват тежки заявки при всяко зареждане, и изключете страниците за количка и плащане от кеша.

Оптимизирайте изображенията.

• Компресирайте изображенията и ги конвертирайте в съвременни формати като WebP или AVIF.
• Оптимизирайте размерите. Ако изображението се показва в 500x500 пиксела, а подавате файл с 1500x2000 пиксела, това са излишни пиксели и ненужен товар. Решението е атрибутът srcset заедно със sizes, които описват кой файл да се зареди при коя резолюция.

html

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="800" height="800"
  alt="Описание на продукта"
  fetchpriority="high">

Дайте приоритет на LCP елемента.

• Добавете fetchpriority="high" на главното изображение, за да го заредите по-рано.
• Не прилагайте loading="lazy" на изображения в началния екран. Това е една от най-честите причини за слаб LCP.
• Ако изображението е зададено като CSS background, използвайте <link rel="preload" as="image"> или го преместете в <img> елемент.

Използвайте lazy loading само за изображения под прегъвката.

• Най-простият начин е нативният атрибут loading="lazy".
• За по-фин контрол, например с плейсхолдър, използвайте Intersection Observer API.

Намалете блокиращите ресурси.

• Вградете критичния CSS (critical CSS) директно в страницата и заредете останалото асинхронно.
• Добавете defer или async на скриптовете, които не са нужни за първоначалното рендване.
• Минимизирайте и обединявайте файловете разумно (при HTTP/2 прекаленото обединяване не е задължително).

Подгответе връзките и шрифтовете.

• preconnect към критични външни домейни (CDN, шрифтове).
• preload за основните шрифтове и за LCP изображението.
• Хоствайте шрифтовете локално вместо да зависите от външна заявка, когато е възможно.

Използвайте CDN. Услуга като Cloudflare сервира снимки и скриптове от най-близкия до потребителя сървър и намалява забавянето. Освен това може да кешира и самия HTML и да компресира с Brotli.

2. Interaction to Next Paint (INP) – наследникът на FID

Важна актуализация: от 12 март 2024 г. метриката INP официално замени First Input Delay (FID) като Core Web Vital. Затова при оптимизация и в отчетите на Google днес се ориентираме към INP, а не към FID.

Каква е разликата? FID измерва само забавянето преди браузърът да започне да обработва първото взаимодействие. INP е много по-строга и по-реалистична метрика. Тя следи всички клик, тап и клавиатурни взаимодействия през целия живот на страницата и отчита почти най-лошото от тях. Измерва цялото време от действието на потребителя до следващото визуално обновяване на екрана, включително:

1. забавянето на входа (input delay),
2. времето за изпълнение на обработчиците на събития (processing time),
3. времето за изобразяване на резултата (presentation delay).

Добри стойности: под 200 ms. (За стария FID прагът беше 100 ms.)

Какво го влошава

• Обемна JavaScript логика, която блокира главния thread (long tasks над 50 ms)
• Тежки скриптове на трети страни: чат уиджети, тракинг пиксели, рекламни скриптове, A/B тестове
• Лошо структурирани събития и прекалено много слушатели
• Прекалено голям DOM (хиляди елементи), който прави всяка промяна скъпа
• Тежки операции в обработчиците на кликове, например синхронни изчисления или принудителни layout преизчисления (layout thrashing)
• Големи фреймуърк обновявания на целия интерфейс при малка промяна

Как да го подобрим

Намалете и отложете JavaScript.

• Премахнете ненужния код и неизползваните библиотеки.
• Отложете по-маловажните скриптове за по-късно зареждане, например след първото взаимодействие или когато браузърът е свободен.
• Разделете JavaScript-а на по-малки части (code splitting) и зареждайте само нужното за конкретната страница.

Разбийте дългите задачи.

• Всяка задача над 50 ms блокира реакцията на страницата. Разделяйте я на по-малки парчета и давайте "въздух" на браузъра.
• Използвайте scheduler.yield() там, където се поддържа, или setTimeout(…, 0) като по-широко съвместим вариант.
• Използвайте requestIdleCallback за неважни действия.

js

async function processItems(items) {
  for (const item of items) {
    handle(item);
    // Даваме шанс на браузъра да обработи входа на потребителя
    if (globalThis.scheduler?.yield) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

Изнесете тежките изчисления. Използвайте Web Workers за обработка на данни извън главния thread.

Дайте незабавна визуална обратна връзка. Покажете спинър, смяна на състояние на бутона или друга реакция веднага, а тежката работа извършете след това. Така потребителят усеща бързина, а INP се подобрява.

Ограничете скриптовете на трети страни.

• Одитирайте какво се зарежда и премахнете ненужното.
• Зареждайте тежките уиджети (чат, карти, видеа) при взаимодействие, а не при зареждане на страницата.

Поддържайте малък DOM. Стремете се към по-малко и по-прости елементи. За дълги списъци използвайте виртуализация или CSS свойството content-visibility: auto.

Оптимизирайте слушателите. Използвайте делегиране на събития, пасивни слушатели ({ passive: true }) за scroll и touch и избягвайте ненужни обработчици.

3. Cumulative Layout Shift (CLS)

CLS измерва неочакваните премествания на елементи, докато страницата се зарежда или използва, например когато бутонът "Купи" подскочи, защото над него се е заредила реклама, и потребителят кликне на грешното място. Метриката е безразмерна и се изчислява от размера на засегнатата област и разстоянието на преместването.

Добри стойности: под 0.1.

Какво го причинява

• Изображения, видеа и iframe-ове без зададени размери
• Динамични шрифтове, които променят размера на текста при зареждане (FOUT/FOIT)
• Реклами, банери, cookie съобщения и други елементи, вмъквани без резервирано място
• Съдържание, добавено динамично над вече показаното
• Анимации, които използват свойства като top, left, height вместо transform

Как да го подобрим

Диагностицирайте проблема.

• Заредете сайта при бавна мрежа (throttling в DevTools) и наблюдавайте кои елементи се преместват.
• В Chrome DevTools, в панела Performance, можете да видите точните “Layout Shift” събития и засегнатите елементи.

Задавайте размери на медията.

• Използвайте width и height на изображенията и видеата. Съвременните браузъри изчисляват съотношението на страните и резервират място преди зареждането.
• Алтернативно използвайте CSS свойството aspect-ratio.

css

img { max-width: 100%; height: auto; }
.video-wrap { aspect-ratio: 16 / 9; }

Оптимизирайте шрифтовете.

• Използвайте font-display: swap (или optional) за уеб шрифтове.
• Заредете предварително (preload) основните шрифтове.
• Подберете резервен шрифт със сходни размери и настройте size-adjust, ascent-override и descent-override, за да намалите скока при смяната.

Резервирайте място за динамичните елементи. Ако един div няма зададена височина и първоначално е с 0px, а по-късно JavaScript добави съдържание вътре, той ще промени височината си и ще избута следващите елементи. Задайте min-height или фиксирано място за:

• рекламни блокове,
• банери и cookie съобщения (още по-добре е да се показват като наслагване, а не да избутват съдържанието),
• уиджети, ревюта, свързани продукти, динамични цени.

Избягвайте вмъкване на съдържание над вече видимото, освен ако не е в отговор на действие на потребителя.

Анимирайте с transform и opacity вместо със свойства, които предизвикват преизчисляване на оформлението.

Допълнителни метрики, които помагат

Освен трите основни, следните метрики помагат за диагностика:

• TTFB (Time to First Byte) – времето до първия байт от сървъра. Висок TTFB почти винаги води до слаб LCP.
• FCP (First Contentful Paint) – кога се появява първото съдържание. Показва колко бързо потребителят вижда, че нещо се случва.
• TBT (Total Blocking Time) – лабораторна метрика, която корелира с интерактивността и се използва в Lighthouse като заместител на INP.

Лабораторни и реални данни

Това е най-често срещаният източник на объркване при измерването.

• Лабораторни данни (lab data) идват от симулирано зареждане в контролирана среда, например Lighthouse. Подходящи са за диагностика и тестване на промени, но не отразяват реалните потребители. Lighthouse не измерва INP директно, защото няма реално взаимодействие.
• Реални данни (field data / RUM) идват от истински посетители чрез Chrome User Experience Report (CrUX). Именно те се използват от Google за оценка на страницата.

Практическият подход е да откривате проблемите с реалните данни и да ги отстранявате и тествате с лабораторните.

Как да измерим Core Web Vitals?

• Google Search Console – отчетът Core Web Vitals показва групи от страници със състояние "Добро", "Нуждае се от подобрение" и "Лошо" въз основа на реални данни.
• Google PageSpeed Insights – показва реални данни от CrUX (когато има достатъчно трафик) и лабораторен анализ от Lighthouse с конкретни препоръки.
• Lighthouse в Chrome DevTools – лабораторен одит, подходящ при разработка.
• Chrome DevTools, панел Performance – детайлен анализ на long tasks, layout shifts и LCP елемента.
• Web Vitals Chrome Extension – показва метриките в реално време, докато разглеждате страница.
• Библиотеката web-vitals (JavaScript) – събира реални данни от вашите потребители и ги изпраща към вашата аналитика, например Google Analytics 4.
• CrUX Dashboard и CrUX API – исторически данни и сравнение с конкуренцията.
• WebPageTest – задълбочен анализ на водопада на заявките от различни локации и устройства.

js

import { onLCP, onINP, onCLS } from 'web-vitals';

function send(metric) {
  // Изпратете към вашата аналитика
  navigator.sendBeacon('/analytics', JSON.stringify(metric));
}

onLCP(send);
onINP(send);
onCLS(send);

Съвети за WordPress и WooCommerce

Тъй като голяма част от сайтовете са на WordPress, ето най-честите практически стъпки:

1. Кеширане: използвайте плъгин или сървърно кеширане за пълни страници и добавете object cache.
2. Изображения: автоматична конвертация в WebP/AVIF, правилни srcset размери (WordPress ги генерира) и изключване на lazy loading за главното изображение.
3. Плъгини и тема: премахнете ненужните плъгини. Всеки допълнителен CSS и JS файл натоварва страницата. Зареждайте скриптовете само там, където са нужни (например скриптовете на форми за контакти само на страницата с формата).
4. Page builders: тежките билдъри често генерират голям DOM и излишен CSS/JS. Оценете дали са необходими.
5. Скриптове на трети страни: чат, пиксели и тракинг код да се зареждат отложено или чрез мениджър на тагове с разумни правила.
6. WooCommerce: оптимизирайте страниците на продукти и категории, избягвайте тежки уиджети и резервирайте място за динамични елементи като цена, наличност и мини количка.
7. База данни: почиствайте ревизии, преходни (transient) записи и ненужни autoload опции.

Препоръчителен процес на оптимизация

1. Проверете отчета в Search Console и намерете групите страници с проблеми.
2. Определете коя метрика е слабата (LCP, INP или CLS) и на какво устройство.
3. Диагностицирайте причината с PageSpeed Insights и DevTools.
4. Приложете една промяна наведнъж и измерете резултата.
5. Следете реалните данни. Те се обновяват с около 28-дневно забавяне, затова резултатите се виждат постепенно.
6. Включете мониторинг, за да не се влоши производителността при нови функции.

Често срещани грешки

• Оптимизиране само за резултата в Lighthouse, а не за реалните потребители.
• Тестване само на бърза десктоп машина и бърза връзка.
• Lazy loading на всички изображения, включително на главното.
• Добавяне на нови скриптове и плъгини без измерване на въздействието.
• Игнориране на мобилната версия, която обикновено е по-слабата и по-важната за класирането.

Заключение

Core Web Vitals са основен компонент на потребителското изживяване (UX) и от SEO стратегията. Оптимизацията на LCP, INP и CLS не само подобрява позициите в търсачките, но и задържа повече потребители и увеличава конверсиите. Започнете с измерване на реалните данни, адресирайте най-слабата метрика и подобрявайте постоянно, защото производителността не е еднократна задача, а непрекъснат процес.

Разбери защо сайтът ти не расте – безплатен цялостен одит

SEO, AIO (видимост в AI търсачки), дизайн/UX и потенциал за реклами — в един безплатен анализ.

Получи безплатния си анализ Без ангажимент. Отговор до 48 часа.