Публикувано: Обновено:
Бавен сайт губи посетители, преди те да видят съдържанието. Google мери това с три показателя, наречени Core Web Vitals. В тази статия обясняваме какво измерва всеки от тях, кои стойности са добри и какво правим в WordPress, за да ги подобрим.
Core Web Vitals са три показателя на Google за реалното потребителско преживяване (user experience): LCP за скоростта на зареждане, INP за отзивчивостта и CLS за визуалната стабилност. Добрите стойности са LCP до 2,5 секунди, INP до 200 милисекунди и CLS до 0,1.
Пишем от опита на екипа на CreateWeb: правим и поддържаме сайтове с WordPress от 2018 г. В статията няма измислени статистики. Праговете и правилата са от документацията на Google.
Какво представляват Core Web Vitals и кои показатели включват
Core Web Vitals са подмножество от Web Vitals, което важи за всяка уеб страница. Включват три показателя: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) и Cumulative Layout Shift (CLS).
Google описва Web Vitals като набор от показатели за качеството на страниците. Core Web Vitals са тези от тях, които се отнасят до всяка страница и се мерят при реални потребители (web.dev, Web Vitals). На английски всеки отделен показател се нарича core web vital, а общото име на набора е Core Web Vitals.
| Показател | Какво мери | Въпрос, на който отговаря |
|---|---|---|
| LCP (Largest Contentful Paint) | кога се показва най-големият елемент в първия екран | Колко бързо виждам основното съдържание? |
| INP (Interaction to Next Paint) | колко бързо страницата реагира на клик, докосване или натиснат клавиш | Реагира ли страницата, когато я ползвам? |
| CLS (Cumulative Layout Shift) | колко се местят елементите, докато страницата се зарежда | Подскача ли текстът под пръста ми? |
Най-големият елемент при LCP обикновено е основната снимка, видеото или голям блок текст в горната част на страницата. При INP се гледат всички взаимодействия по време на посещението, а резултатът е едно от най-бавните. CLS събира изместванията, които стават без действие от потребителя.
Има и помощни показатели. Time to First Byte (TTFB) мери колко бързо сървърът връща първия байт. First Contentful Paint (FCP) мери кога се показва първото нещо на екрана. Те не влизат в трите основни показателя, но помагат да се открие защо LCP е бавен.
Защо са важни Core Web Vitals и как влияят на SEO класирането
Google казва, че Core Web Vitals се ползват от системите му за класиране. Те са част от page experience, но не гарантират първа позиция: Google показва най-подходящото съдържание за търсенето, дори когато преживяването на страницата е по-слабо.
В документацията за page experience Google пише три неща, които са важни за всеки собственик на сайт (Google Search Central, Page experience):
- тези показатели се използват от системите за класиране;
- добрите резултати в Search Console или в други инструменти не гарантират, че страницата ще е на върха в Google;
- Google винаги търси най-подходящото съдържание за търсенето, дори ако page experience е под нивото.
Какво значи това на практика? Бърз сайт със слабо съдържание няма да изпревари полезна, но малко по-бавна статия. Когато две страници са сходни по съдържание, скоростта и стабилността стават фактор. Важен е и потребителят: ако страницата зарежда бавно или бутонът се мести, посетителят си тръгва, преди да прочете офертата.
Затова гледаме на скоростта като на част от техническото SEO. Тя е основа, върху която съдържанието работи. Как се подреждат останалите технически проверки, описваме в статията техническо SEO за WordPress.
Какви са добрите стойности за Core Web Vitals
Добра стойност е LCP до 2,5 секунди, INP до 200 милисекунди и CLS до 0,1. Страницата минава, когато 75% от посещенията са в зелената зона, отделно за мобилни устройства и за компютър.
| Показател | Добро | Нужно е подобрение | Слабо |
|---|---|---|---|
| LCP | до 2,5 s | от 2,5 до 4 s | над 4 s |
| INP | до 200 ms | от 200 до 500 ms | над 500 ms |
| CLS | до 0,1 | от 0,1 до 0,25 | над 0,25 |
LCP и INP се мерят във време, а CLS резултатът (CLS score) е число без мерна единица. Правилото за 75-ия персентил е важно. Не е достатъчно страницата да е бърза на вашия компютър. Поне 3 от всеки 4 зареждания при реални потребители трябва да са в добрата зона. Ако повечето ви посетители са на телефони с мобилни данни, точно те определят резултата.
Резултатът (score) за целия сайт е сбор от отделните страници. Една бавна категория в онлайн магазин може да тегли надолу всички страници със същия шаблон.
Как да измеря и проверя Core Web Vitals на сайта си
Най-лесно е с PageSpeed Insights: въвеждате адреса и виждате полевите данни от реални потребители и лабораторен тест с Lighthouse. За целия сайт ползвайте отчета Core Web Vitals в Google Search Console.
Инструментите, които ползваме, и за какво служи всеки:
| Инструмент | Данни | Кога го ползваме |
|---|---|---|
| PageSpeed Insights | полеви (CrUX) + лабораторни (Lighthouse) | бърза проверка на конкретна страница |
| Google Search Console | полеви, групирани по сходни адреси | общ поглед върху сайта и проблемни шаблони |
| Chrome DevTools | лабораторни, в браузъра | търсене на точната причина за проблем |
| Lighthouse | лабораторни, с оценка (score) от 0 до 100 | тест преди и след промяна |
Как да проверите една страница стъпка по стъпка:
- Отворете PageSpeed Insights и въведете адреса на страницата.
- Изберете „Мобилни“. Повечето проблеми се виждат първо там.
- Погледнете горната част: ако има полеви данни, те показват реалните LCP, INP и CLS.
- Слезте до диагностиката на Lighthouse. Там е списъкът с конкретни причини.
- Повторете теста след всяка промяна, за да видите ефекта.
Ако сайтът е нов или има малко посещения, полевите данни може да липсват. Тогава остава лабораторният тест, докато Google събере достатъчно информация от реални потребители. Други инструменти за анализ сравняваме в статията SEO анализ на сайт.
Каква е разликата между полеви и лабораторни данни за Core Web Vitals
Полевите данни идват от реални посещения в Chrome за последните 28 дни. Лабораторните са един тест в контролирани условия. Google оценява сайта по полевите данни, а лабораторните помагат да откриете причината.
Полевите данни се събират в Chrome User Experience Report (CrUX). Това е публичният набор от данни на Google за реалните посещения в Chrome. От него идват полевите числа в PageSpeed Insights и в отчета на Search Console.
Лабораторният тест (Lighthouse) зарежда страницата веднъж, със симулирано устройство и мрежа. Той дава оценка (score) за производителност и списък с препоръки. Тази оценка е отделна от полевите показатели. Възможно е да имате 70 в Lighthouse и добри полеви данни, или обратното.
Още една разлика: лабораторният тест не може да измери INP, защото няма реален потребител, който да кликва. Вместо това Lighthouse показва Total Blocking Time (TBT), което е полезен заместител за проблемите с JavaScript.
| Полеви данни | Лабораторни данни | |
|---|---|---|
| Източник | реални потребители (CrUX) | симулиран тест (Lighthouse) |
| Период | последните 28 дни | един момент |
| INP | да | не (вместо него TBT) |
| За какво | оценка на сайта | откриване на причината |
Как да подобря LCP, INP и CLS
LCP се подобрява с бърз сървър, кеширане и лека основна снимка. INP се подобрява с по-малко JavaScript и по-малко плъгини. CLS се подобрява със зададени размери на снимките и резервирано място за банери и реклами.
LCP (зареждане). Най-честите причини за бавен LCP са бавният сървър и тежката основна снимка.
- Проверете TTFB. Ако сървърът отговаря бавно, всичко след това закъснява.
- Включете кеширане на страниците, за да не се генерират наново при всяко посещение.
- Компресирайте основната снимка и я качете в WebP или AVIF.
- Не зареждайте основната снимка мързеливо (lazy load). Тя трябва да се зарежда първа.
- Махнете слайдерите в първия екран, ако не са нужни.
Как да намалите размера на снимките без видима загуба, показваме в статията компресиране на снимки.
INP (отзивчивост). Бавният INP почти винаги идва от JavaScript, който заема браузъра.
- Махнете плъгините, които не ползвате.
- Отложете скриптовете на чат, анализи и социални мрежи, докато потребителят не взаимодейства със страницата.
- Проверете дали менюто, филтрите и формите не зареждат тежки библиотеки.
- Тествайте на по-слаб телефон, защото там проблемът се вижда най-ясно.
CLS (стабилност). Изместванията идват от елементи, които се появяват, без да им е запазено място.
- Задавайте ширина и височина на снимките и видеата.
- Резервирайте място за банери за бисквитки, реклами и вградени елементи.
- Заредете шрифтовете така, че текстът да не скача при смяна на шрифта.
- Не вмъквайте съдържание над вече показаното, освен след действие на потребителя.
Как да подобрите Core Web Vitals на WordPress сайт
В WordPress най-голям ефект имат хостингът, плъгинът за кеширане, леката тема и броят на плъгините. Започнете от сървъра и кеша, после снимките и чак след това фините настройки на скриптовете.
Последователността, в която работим:
- Хостинг. Бавният сървър не се поправя с плъгин. Какво да гледате при избора, описваме в статията избор на хостинг.
- Кеширане. Плъгинът за кеширане и оптимизация обединява кеша, отлагането на скриптове и мързеливото зареждане. На createweb.bg ползваме FlyingPress. Сравнение с WP Rocket и LiteSpeed Cache имаме в статията плъгин за скорост на WordPress.
- Тема. Леката тема зарежда по-малко CSS и JavaScript. Тежките теми с много вградени функции често зареждат код, който страницата не ползва.
- Конструктор на страници. Ако ползвате конструктор, ползвайте само един и чистете неизползваните секции. Как избираме, разказваме в статията за конструктор на страници.
- Плъгини. Всеки плъгин може да добави скриптове на всяка страница. По-малко плъгини значи по-малко код. Как да преценявате кои да останат, обясняваме в статията какво е плъгин.
- Снимки и шрифтове. WebP или AVIF, правилни размери, шрифтове само в нужните дебелини.
- Външни скриптове. Чат, карти, видео и пиксели за реклами се зареждат при нужда.
Целта е по-добро user experience за посетителя. По-високият score в Lighthouse идва като следствие. След всяка стъпка правим тест в PageSpeed Insights и пазим резултатите. Така се вижда коя промяна е помогнала и коя не. Преди по-големи промени правим резервно копие, защото агресивните настройки за оптимизация понякога чупят меню или форма.
Какво замени показателя First Input Delay (FID)
От 12 март 2024 г. INP замени FID като показател за отзивчивост. FID мереше само забавянето при първото взаимодействие, а INP гледа взаимодействията през цялото посещение.
FID беше първият показател за отзивчивост. Той мереше колко време минава от първия клик до момента, в който браузърът започне да го обработва. Проблемът беше, че голяма част от сайтовете минаваха лесно, а реалното усещане при следващите кликове оставаше невидимо.
INP мери пълното време от взаимодействието до следващото рисуване на екрана, за всички кликове, докосвания и натискания на клавиш. Затова сайтове, които бяха зелени по FID, може да са жълти или червени по INP. Ако сте оптимизирали сайта преди 2024 г., струва си да проверите отново.
Как да разчитам отчета за Core Web Vitals в Google Search Console
Отчетът Core Web Vitals report в Search Console групира сходни адреси и ги показва като „Добри“, „Нуждаят се от подобрение“ и „Лоши“, отделно за мобилни устройства и за компютър. Започнете от групите с най-много адреси.
Как да го четете:
- Отворете Search Console и изберете „Core Web Vitals“ от лявото меню.
- Изберете „Мобилни“ или „Компютър“.
- Отворете проблема, например „LCP проблем: над 2,5 s (мобилни)“.
- Вижте групата адреси и примерните страници в нея.
- Тествайте примерна страница в PageSpeed Insights и намерете причината.
- След поправката натиснете бутона за потвърждаване на корекцията (Validate fix).
Отчетът работи с полеви данни, затова промените се виждат със закъснение. Google трябва да събере нови данни за 28-дневния период. Ако даден адрес няма достатъчно посещения, той не се показва.
Групите са важни за WordPress сайтове. Страниците с един и същ шаблон, например всички публикации в блога, обикновено имат един и същ проблем. Една поправка в шаблона оправя всички. Как да ползвате останалите отчети, описваме в статията Google Search Console.
Колко често трябва да следя Core Web Vitals на сайта си
Проверявайте отчета в Search Console поне веднъж месечно и задължително след всяка по-голяма промяна: нова тема, нов плъгин, редизайн или смяна на хостинг.
Ритъмът, който препоръчваме:
- Веднъж месечно: преглед на отчета в Search Console.
- След всяка промяна: тест в PageSpeed Insights на началната страница и на една страница от всеки основен шаблон.
- След обновяване на плъгини и тема: бърза проверка дали някой показател не се е влошил.
- При спад в трафика: проверка на скоростта като една от възможните причини.
Скоростта не се оправя веднъж завинаги. Новите плъгини, снимки и скриптове постепенно я влошават. Затова проверката на показателите е част от редовната поддръжка на WordPress сайт.
Как влияят Core Web Vitals на мобилното SEO
Google индексира сайтовете основно по мобилната им версия, а Core Web Vitals се оценяват отделно за мобилни устройства и за компютър. Затова мобилните резултати обикновено са по-важни и по-трудни за постигане.
Телефоните имат по-слаб процесор и често по-бавна връзка, затова user experience там страда първо. Един и същ сайт може да има добър INP на компютър и слаб на телефон, защото JavaScript се изпълнява по-бавно. По същата причина тежката основна снимка удря LCP по-силно на мобилни.
Какво да проверите на мобилни:
- размера на основната снимка, която се зарежда на малкия екран;
- банера за бисквитки, който често мести съдържанието и влошава CLS;
- менюто и попъпите, които зареждат допълнителен код;
- шрифтовете и иконите, които се зареждат отвън.
Често задавани въпроси
Кратки отговори на въпросите, които ни задават най-често за трите показателя.
Какво са Core Web Vitals?
Три показателя на Google за реалното преживяване на страницата: LCP за зареждане, INP за отзивчивост и CLS за визуална стабилност.
Влияят ли Core Web Vitals на класирането в Google?
Да, Google казва, че се ползват от системите за класиране. Подходящото съдържание обаче остава по-важно, а добрите резултати не гарантират първа позиция.
Каква оценка в PageSpeed Insights е добра?
Оценката (performance score) на Lighthouse от 0 до 100 е ориентир. Google оценява сайта по полевите данни: LCP до 2,5 s, INP до 200 ms и CLS до 0,1 за 75% от посещенията.
Защо PageSpeed Insights показва различни резултати при всеки тест?
Лабораторният тест зависи от натоварването на сървъра и мрежата в момента. Полевите данни са средни за 28 дни и се променят бавно.
Колко време отнема да се види подобрение в Search Console?
Полевите данни обхващат последните 28 дни. Затова пълният ефект от промяната се вижда след около 4 седмици.
Кой плъгин подобрява Core Web Vitals в WordPress?
Плъгините за кеширане и оптимизация (FlyingPress, WP Rocket, LiteSpeed Cache) помагат най-много. Те не компенсират бавен хостинг или тежка тема.
Има ли смисъл да ги следя, ако сайтът има малко посещения?
Да. Дори без полеви данни бавната страница губи посетители. Ползвайте лабораторния тест, докато Google събере данни от реални потребители.
Заключение: започнете от сървъра и мерете след всяка промяна
Трите показателя мерят зареждането, отзивчивостта и стабилността при реални потребители. В WordPress най-голям ефект имат хостингът, кеширането, леката тема и малкото плъгини, а резултатът се проверява в PageSpeed Insights и Search Console.
Нашето мнение е, че Core Web Vitals трябва да се мислят при изработката, преди сайтът да е пуснат. Тогава изборът на хостинг, тема и плъгини е евтин. След пускането всяка поправка струва повече време.
Ако планирате нов сайт, вижте как работим при изработка на уеб сайт. Ако искате проверка на съществуващ, вижте услугата анализ на уебсайт или пишете ни.
