Защо скоростта на сайта има значение (и какво забавя вашия)

Хората, които правят един сайт, рядко усещат колко е бавен. Отварят го на офис интернет, на нов лаптоп, с половината файлове вече кеширани. Клиентът го отваря за първи път на телефон от средния клас при слаб сигнал. Това са два различни сайта и значение има само вторият.

Скоростта влияе на две неща. Посетителите, които чакат, си тръгват, преди да видят офертата ви. А Google използва сигналите за изживяване на страницата, включително скоростта на зареждане, в системите си за класиране, макар и с ясна граница, до която ще стигнем.

Какво точно измерва Google

Показателите на Google за скорост и изживяване се наричат Core Web Vitals. Те са три, а текущите прагове за „добро“ според web.dev са:

• Largest Contentful Paint (LCP), до 2,5 секунди. Колко време минава, докато се появи основното съдържание, обикновено голямото изображение или заглавието.
• Interaction to Next Paint (INP), до 200 милисекунди. Колко бързо реагира страницата, когато някой докосне или кликне. INP замени First Input Delay на 12 март 2024 г., така че всяко ръководство, което още говори за FID, е остаряло.
• Cumulative Layout Shift (CLS), до 0,1. Колко подскача оформлението по време на зареждане. Класическият пример е бутонът, който се измества точно когато го натискате.

Всеки се оценява при 75-ия процентил на реалните посещения, отделно за мобилни и за компютри. На практика три от всеки четири посещения трябва да са в прага, не само вашите.

За класирането нека сме точни. Google казва, че Core Web Vitals се използват от системите му за класиране, но също така, че добрите резултати не гарантират челни позиции и че Google винаги се стреми да показва най-подходящото съдържание, дори ако изживяването на страницата е слабо. Скоростта помага най-много, когато няколко страници са еднакво подходящи. Тя няма да спаси страница, която не отговаря на търсенето, а бърз сайт без полезно съдържание няма да се класира.

Как да четете PageSpeed Insights

Пуснете най-важните си страници през PageSpeed Insights, не само началната. Ще видите два раздела, които често не си съвпадат, и това обърква хората:

• Данните от реални потребители най-горе идват от истински потребители на Chrome за последните 28 дни (документацията на Google). Така реалните посетители са изживели страницата. Сайтове с малко трафик може да нямат достатъчно данни, за да се покажат.
• Лабораторните данни отдолу идват от едно симулирано зареждане от Lighthouse, на емулиран телефон от средния клас със забавена връзка. Те са за откриване на проблеми. Оценката от 0 до 100 е от този раздел.

Ако реалните данни казват, че LCP е наред, лабораторна оценка 70 не е спешен случай. Ако реалните данни казват, че е слаб, диагностиката в лабораторния раздел ще ви каже защо. За поглед върху целия сайт отчетът Core Web Vitals в Google Search Console групира страниците ви по състояние.

Какво забавя сайтовете и как се поправя всяко

Бавно основно съдържание (LCP)

• Прекалено големи изображения. Снимка направо от телефона може да е няколко мегабайта, когато на страницата ѝ трябва малка част от това. Оразмерете я до размера, в който се показва, използвайте модерни формати като WebP или AVIF и давайте на телефоните по-малки версии, отколкото на компютрите.
• Главното изображение се зарежда отложено. Отложеното зареждане (lazy loading) е добро за изображенията по-надолу. При главното то забавя точно това, което LCP измерва. Съветът на web.dev е категоричен: никога не зареждайте отложено LCP изображението.
• Бавен отговор от сървъра. При евтин, претоварен хостинг или сайт, който сглобява всяка страница от нулата при всяко посещение, браузърът чака, преди да получи каквото и да било. Кеширането на страници и CDN помагат. Както и по-добрият хостинг.

Бавна реакция при докосване (INP)

Проблемите с INP обикновено идват от JavaScript, който държи заета основната нишка на браузъра, макар че много голяма и сложна страница също може да се прерисува бавно (web.dev). Всеки чат прозорец, проследяващ пиксел, слайдер плъгин и page builder добавя скрипт. Направете списък на това, което се зарежда на страницата, и махнете всичко, което никой не би забелязал. За останалото се запитайте дали трябва да се зарежда веднага, или може да изчака, докато страницата стане използваема.

Подскачащо оформление (CLS)

• Изображения и видео без размери. Задайте width и height, за да резервира браузърът място, преди файлът да пристигне (web.dev).
• Банери, вградено съдържание и банери за бисквитки, които избутват съдържанието. Резервирайте им място предварително или ги показвайте върху страницата.
• Уеб шрифтове, които се сменят късно и пренареждат текста. Заредете предварително основния шрифт и изберете резервен шрифт с подобни пропорции.

Откъде да започнете

1. Отворете PageSpeed Insights за трите си най-важни страници и запишете кои от трите показателя не минават в реалните данни.
2. Работете върху проблемния показател с подходящия списък по-горе, като започнете от това, което диагностиката показва като най-голямо подобрение.
3. Изчакайте 28-дневните реални данни да наваксат, преди да решите дали е помогнало.

Не ви трябва перфектна лабораторна оценка. Трябват ви трите Core Web Vitals в зелено за реалните посетители, особено на телефон. Ако не сте сигурни какво забавя сайта ви, изпратете ни адреса и ще ви кажем какво си струва да се поправи. Скоростта е задължително изискване в сайтовете, които изграждаме, а същите проверки важат и за мобилните устройства, където повечето от тези проблеми се влошават.