Core Web Vitals обяснени за собственици на сайтове
Core Web Vitals измерват зареждането, отзивчивостта и визуалната стабилност. Какво са LCP, INP и CLS, към какви стойности да се стремите и откъде да започнете.
Core Web Vitals са три измервания, с които Google описва как се усеща една страница от реален посетител: колко бързо се появява основното съдържание, колко бързо реагира страницата, когато някой докосне или щракне, и дали оформлението скача, докато се зарежда. Те са част от сигналите на Google за изживяването на страницата, но по-важната причина да ви интересуват е по-проста. Посетителите напускат бавни, скачащи страници и рядко ви казват защо.
Това ръководство обяснява трите метрики на достъпен език, праговете, които Google публикува, и как да решите какво да поправите първо на обикновен сайт на малка фирма.
Трите метрики накратко
| Метрика | Какво измерва | Добра | Лоша |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Времето до изобразяването на най-големия видим елемент | 2,5 секунди или по-малко | Над 4 секунди |
| INP (Interaction to Next Paint) | Колко време отнема на страницата да реагира визуално след докосване, щракване или натискане на клавиш | 200 милисекунди или по-малко | Над 500 милисекунди |
| CLS (Cumulative Layout Shift) | Колко видимо съдържание се премества неочаквано | 0,1 или по-малко | Над 0,25 |
Стойностите между „добра“ и „лоша“ попадат в диапазон „нуждае се от подобрение“. Google оценява страницата на 75-ия персентил от реалните посещения, което означава, че три четвърти от посетителите ви трябва да получават изживяване на прага или по-добро. Един бърз тест на собствения ви лаптоп не доказва, че страницата преминава.
Largest Contentful Paint: появява ли се страницата?
LCP гледа най-голямото изображение, постер на видео или блок текст на първия екран и записва кога приключва изобразяването му. На повечето сайтове това е главно изображение или голямо заглавие. Бавният LCP обикновено идва от една от четири причини: бавен отговор на сървъра, тежко или зле форматирано изображение, CSS или JavaScript, които блокират изобразяването, или браузър, който открива ключовото изображение твърде късно.
Interaction to Next Paint: реагира ли страницата?
INP замени по-старата метрика First Input Delay през март 2024 г. Докато First Input Delay гледаше само първото взаимодействие и само забавянето преди то да започне, INP отчита взаимодействията през цялото посещение и докладва едно от най-бавните, от въвеждането до изчертаването на следващия кадър. Страниците, които се зареждат бързо, но се усещат лепкави при отваряне на меню или натискане на бутон, обикновено имат проблем с JavaScript: твърде много код се изпълнява едновременно в основната нишка.
Cumulative Layout Shift: стои ли страницата неподвижна?
CLS сумира неочакваното движение на видимите елементи. Усещали сте го, когато сте се канили да докоснете връзка и над нея се е заредил банер, избутвайки връзката надолу. Чести причини са изображения без атрибути за ширина и височина, реклами и вграждания, които се зареждат късно, шрифтове, които се подменят и променят размера на текста, и банери за бисквитки, вмъкнати най-горе на страницата.
Лабораторни данни срещу данни от реални потребители
Има два вида измерване и смесването им води до объркване.
- Данните от реални потребители (field data) идват от истински посетители с истински устройства и мрежи. Google ги събира от потребителите на Chrome и ги показва в PageSpeed Insights и Search Console, когато сайтът ви има достатъчно трафик. Те са това, което се брои при оценката.
- Лабораторните данни (lab data) идват от симулиран тест, като Lighthouse. Те са възпроизводими, което ги прави идеални за отстраняване на грешки, но са едно устройство на една връзка.
Малкият сайт може изобщо да няма данни от реални потребители. В такъв случай ползвайте лабораторни тестове, за да откривате проблеми, и приемайте резултатите като ориентир, а не като присъда.
Откъде да започнете с поправките
- Измерете важните страници. Тествайте началната страница, най-посещаваната целева страница и типична статия или страница на продукт с мобилен профил. Не усредняйте целия сайт.
- Поправете най-слабата метрика първо. Ако LCP е лош, а CLS е наред, работете по LCP.
- Започнете с евтините победи. Компресирайте и преоразмерете главното изображение, задайте размери на изображенията, включете кеширане, обмислете CDN и премахнете добавки или скриптове, които вече не ползвате.
- Тествайте отново след всяка промяна. Променяйте по едно нещо, за да знаете кое е помогнало.
- Изчакайте данните от реални потребители да наваксат. Реалните числа се събират за плъзгащ се период, така че подобренията отнемат няколко седмици, за да се покажат изцяло.
Каква е връзката с хостинга
Core Web Vitals са най-вече за начина, по който е изградена страницата, но хостингът задава основата. Бавният отговор на сървъра забавя всичко след него, което директно вреди на LCP. Претъпканите сървъри, остарелите версии на PHP и липсващото кеширане от страна на сървъра добавят време, преди браузърът да получи първия байт. Добрата front-end работа не може напълно да компенсира бавен back end.
Реалистично очакване
Преминаването и на трите метрики е достойна цел, но не е магически превключвател за класиране. Релевантността на съдържанието все още има далеч по-голямо значение. Мислете за Core Web Vitals като за премахване на триене: те няма да накарат слаба страница да се класира, но бавната, скачаща страница затруднява задържането на посетителите, които вече сте спечелили.
Чести грешки на собствениците на сайтове
- Гонене на перфектен резултат в Lighthouse. Резултат 100 в лабораторен тест не е целта. Целта е преминаване на трите прага за реалните посетители.
- Тестване само на настолен компютър. Повечето оценки се правят на мобилно устройство, а мобилните устройства имат по-бавни процесори и връзки.
- Инсталиране на добавка за скорост и спиране дотам. Добавките могат да помогнат с кеширането и обработката на изображения, но не могат да премахнат главно изображение от 3 MB или дузина маркетингови скриптове.
- Пренебрегване на шаблоните. Страниците, изградени от един и същ шаблон, обикновено споделят едни и същи проблеми, така че поправянето на шаблона поправя много страници наведнъж. Search Console групира подобни URL адреси именно по тази причина.
Водете прост дневник какво сте променили и резултата преди и след. Това спестява налучкване, когато нещо се влоши след обновление на добавка.
Бързите страници започват от сървъра
В Zebra Hosting Cloud всеки план включва контролния панел Plesk, където можете да избирате актуални версии на PHP, а Cloudflare CDN е наличен за хоствани сайтове, за да сервира статичните файлове по-близо до посетителите. Заедно те покриват сървърната страна на уравнението, така че да се съсредоточите върху самата страница. Вижте какво предлага всеки план в прегледа на хостинга.
