Модул 6 · 6.1

Какво прави един сайт бавен и как се измерва това?

Модул 6: Скорост · Време за четене: 9 минути

Учебна цел: След този урок ще можете да измервате къде отива времето и да разпознавате разликата между бавност на сървъра и бавност в браузъра.

Ключови понятия: TTFB, Core Web Vitals (LCP, INP, CLS), лабораторни данни, полеви данни, PageSpeed Insights, раздел „Мрежа“, компресия, външни скриптове, лимити на хостинг пакета, 503

Първо измерване, после настройки

"Сайтът е бавен" може да има десет различни причини. Който без измерване едновременно активира разширение за кеширане, разширение за оптимизация на изображения и по-голям пакет, после не знае какво е помогнало, и има три неща повече за следене. Затова винаги започвайте с три въпроса (същите като в ръководството на Вашия хостинг доставчик):

Всичко е бавно, или само администрацията? Бавна администрация с бърза предна част сочи към разширения, които вършат много работа в администрацията, или към ботове, които атакуват страницата за вход.
Винаги, или в определени моменти? Само в натоварени часове или когато се изпълнява планирана задача: тогава Вашият пакет достига своите граници.
При всички, или само при Вас? Опитайте от телефона си през 4G или 5G, или помолете някой друг. Ако е бавно само при Вас, причината е във Вашата връзка или VPN.

Две половини: сървър и браузър

Времето, което изчаква посетителят, се състои от две части (урок 1.2):

Сървърът изготвя HTML: уеб сървър, PHP, разширения, база данни. Това виждате като TTFB (time to first byte), времето до първия байт от отговора. web.dev посочва като общо правило, че повечето сайтове трябва да се стремят към TTFB от 0,8 секунди или по-малко.
Браузърът чете този HTML и след това извлича всичко, което е в него: стилови листове, скриптове, шрифтове, изображения, видео, кодове за анализ, чат джаджи. Едва когато достатъчно от това е пристигнало, посетителят вижда нещо.

Висок TTFB се решава от страна на сървъра: кеширане (урок 6.2), по-малко или по-леки разширения, по-нова версия на PHP, подредена база данни (урок 6.3) или повече изчислителна мощност. Нисък TTFB с все пак бавна страница сочи към страната на браузъра: твърде големи изображения, твърде много скриптове, външни компоненти.

Core Web Vitals

Google измерва изживяването на посетителите с три показателя, Core Web Vitals:

Измерване	Какво измерва	Добро е когато
LCP (Largest Contentful Paint)	Колко бързо се вижда най-голямото парче съдържание (често голямата снимка или заглавието)	2,5 секунди или по-малко
INP (Interaction to Next Paint)	Колко бързо реагира страницата, когато кликнете, докоснете или напишете нещо	200 милисекунди или по-малко
CLS (Cumulative Layout Shift)	Колко се измества страницата по време на зареждане	0,1 или по-малко

INP замени през март 2024 г. по-старото измерване FID. Google използва тези показатели, наред с другото, при класирането на резултатите от търсенето, но най-важната причина да ги подобрите е проста: посетителите напускат при бавна или скачаща страница.

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

Има два вида измервания и те дават различни стойности:

Лабораторни данни: тест в един момент, от едно място, със симулиран телефон и връзка. Полезни за сравнение (преди и след промяна), но не е реален посетител.
Полеви данни: измервания при реални посетители с Chrome, за последните 28 дни. Това е реалното изживяване на посетителите. Малките сайтове често имат твърде малко посетители за полеви данни.

PageSpeed Insights (pagespeed.web.dev) показва и двете: отгоре полевите данни (ако има такива), отдолу лабораторен тест с резултат и конкретни препоръки. Не гледайте сляпо на резултата от 0 до 100. Разгледайте компонентите: лош ли е LCP, защото сървърът е бавен (TTFB), или защото голямата снимка е 3 МБ?

Тествайте винаги по няколко пъти (стойностите варират) и тествайте и обикновена страница, не само началната.

Сами проверете с браузъра

Инструментите за разработчици на Вашия браузър (F12) показват какво наистина се случва:

Раздел „Мрежа“: презаредете страницата с изключен кеш (отметка „Disable cache“). Виждате всеки зареден файл, колко голям е и колко е отнело. Сортирайте по размер: най-големите файлове често са изображения. Сортирайте по домейн: колко идва от други страни (шрифтове, кодове за анализ, видеа)?
Първата заявка (самият HTML): кликнете върху нея, раздел „Timing“. „Waiting for server response“ е TTFB.
Хедъри на тази първа заявка: има ли компресия (content-encoding: br или gzip) и дали страницата е дошла от кеш (урок 6.2)?

Обичайните виновници

На практика бавността при WordPress обикновено се дължи на едно от следните:

Липса на кеш на страниците: всяка страница се генерира наново при всяко посещение (урок 6.2).
Твърде много или тежки разширения, особено разширения, които при всяка заявка извикват външни услуги или извършват тежки заявки към базата данни (урок 5.3).
Големи изображения: снимка от 5 МБ от телефон на началната страница (урок 4.4 и 6.3).
Тежка тема или конструктор на страници, който зарежда много скриптове и стилови листове на всяка страница (урок 5.1).
Външни компоненти: шрифтове, видеа, чат джаджи, кодове за анализ, бутони за социални мрежи от други страни. Всеки е връзка към друг сървър, който може да е бавен.
Стара версия на PHP (урок 8.4).
Разхвърляна база данни: хиляди ревизии, спам, таблици с логове от разширения (урок 6.3).
Ботове: crawler-и, AI crawler-и и опити за вход заемат Вашия пакет (урок 7.3).
Пакетът достига своите граници: твърде малко изчислителна мощност (CPU), процеси или памет за трафика.

Границите на Вашия пакет

При споделен хостинг всеки пакет получава фиксирана част от сървъра: изчислителна мощност, памет, скорост на диска и определен брой едновременни процеси. Ако Вашият сайт използва повече, той бива забавян или посетителите получават съобщение за грешка 503 (Service Unavailable, при някои хостинг доставчици „Resource Limit Is Reached“). При DirectAdmin с CloudLinux това виждате в Resource Usage (с „faults“, ако Вашият сайт е бил забавян), а с X-Ray виждате за всяка страница кое разширение или заявка отнема времето. Други хостинг доставчици имат подобни прегледи, понякога само по заявка.

По-голям пакет помага, ако Вашият сайт действително се нуждае от повече (натоварен онлайн магазин). Той не решава лошо настроен сайт: проблемът тогава се връща по-късно. Първо потърсете причината.

Обобщение

Измервайте първо: всичко или само администрацията, винаги или понякога, всички или само Вие.
TTFB е страната на сървъра (стремете се към 0,8 секунди или по-малко); останалото е това, което зарежда браузърът.
Core Web Vitals: LCP (2,5 с), INP (200 мс) и CLS (0,1); INP замени FID през 2024 г.
PageSpeed Insights показва полеви данни и лабораторни данни; разделът „Мрежа“ показва какво наистина се зарежда.
Повечето бавност се дължи на липса на кеш, тежки разширения, големи изображения и външни компоненти; по-голям пакет е едва последната стъпка.

Тест

Задача

Задача A6.1: Измерете Вашето TTFB и компресия. Въведете адреса на Вашия сайт и, ако желаете, една обикновена страница (например Вашата страница за контакти). Програмата изисква всяка страница три пъти без бисквитки и показва средния TTFB, размера на HTML и дали сървърът изпраща HTML компресиран (content-encoding gzip или br). Сравнете резултата с тест в PageSpeed Insights и запишете какво Ви прави впечатление.

Допълнително четене

Тези статии описват стъпките в панелите на WebOké; в други панели работят по подобен начин.

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг