7 съвета за подобряване на скоростта на уебсайта ви през 2024 г

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

Готови ли сте да направите уебсайта си бърз? Ето седем съвета, които ще ви помогнат да анализирате скоростта на сайта си и да идентифицирате потенциални оптимизации.

1. Анализирайте водопада на мрежовите заявки за вашия уебсайт

Визуализацията на водопада от заявки може да ви покаже какво точно се случва при отваряне на вашия уебсайт. Например:

• Какви ресурси се изтеглят?
• Кога започват да се зареждат ресурсите и колко време отнема всяка заявка?
• Как това се съотнася с това, което посетителите виждат, докато уебсайтът се зарежда?

Тази информация може да послужи като основа за определяне на оптимизациите с най-голямо въздействие. Можете да стартирате безплатен тест за скоростта на страницата на вашия уебсайт, за да генерирате изглед на водопада.

Водните водопади на заявките предоставят много подробности и могат да изглеждат смущаващо. Нека да разбием какво точно трябва да търсите.

За да разтълкувате водопада, потърсете три ключови етапа в процеса на зареждане на уебсайта:

Освен ако няма пренасочвания, HTML документът ще бъде първата заявка във водопада. Преди етапа TTFB не могат да започнат да се зареждат никакви други ресурси и не може да се види никакво съдържание. Следователно TTFB на вашия сървър представлява минимална стойност за оценките FCP и LCP.

След това ще потърсим блокиращи визуализацията заявки. Това са заявки за важни допълнителни ресурси, които трябва да се заредят, преди съдържанието на страницата да стане видимо.

В този пример можем да видим, че има четири блокиращи визуализацията заявки за CSS стилове. След като тези файлове приключат зареждането, можем да видим първото съдържание, което се появява във филмовата лента за визуализация в горния десен ъгъл.

За да оптимизирате FCP, можете да:

Например в примера по-горе виждаме, че файлът app.css е голям над 100 килобайта. Изтеглянето му може да отнеме известно време, особено при по-бавни мобилни връзки за данни.

За да ускорите заявките, ще трябва да погледнете и към какви сървъри се свързва браузърът при отваряне на страницата. Необходима е нова връзка за всеки нов домейн, от който се зарежда даден ресурс, а установяването на всяка нова връзка със сървър отнема известно време.

Можете да идентифицирате сървърните връзки във водопада, като търсите три малки правоъгълника пред основната заявка. Тези правоъгълници представляват мрежовите обиколки, необходими за DNS проверката, TCP връзката и SSL връзката.

Накрая ще разгледаме етапа LCP. Ако най-големият елемент на съдържанието е изображение, това обикновено може да се види ясно, като се търси значката „LCP“ в изгледа на водопада.

След като изображението LCP бъде изтеглено, браузърът бързо започва да актуализира страницата и да показва изображението. Можете да видите метриката LCP, отбелязана с червена линия в изгледа на водопада.

За да се улесни анализът на данните от водопада на заявките, много инструменти за производителност като DebugBear включват и автоматични препоръки за скоростта на страницата.

2. Заредете първо най-важното съдържание

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

В примера по-горе мързеливото зареждане се прилага към изображението LCP. Това означава, че браузърът няма да даде приоритет на този ресурс. След като страницата започне да се визуализира, браузърът осъзнава, че изображението всъщност е важно, и приоритетът на заявката се променя.

В резултат на това изображението започва да се зарежда едва със закъснение, а в този момент другите заявки също използват честотната лента на мрежата. Можем да видим това, като погледнем тъмносините линии в заявката вътре във водопада. Тъмносините линии показват кога се получават данните за отговор за всяка заявка.

За да гарантирате, че дадено LCP изображение е приоритизирано, можете да:

• Уверете се, че не е мързеливо заредено.
• Използвайте атрибута fetchpriority, за да го маркирате като много важно.
• Обмислете използването на таг за предварително зареждане, за да помогнете на браузъра да зареди изображението по-рано.

3. Намалете размера на изтегляне на ключови заявки в началото

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

Например тази снимка на екрана показва голям CSS файл:

Когатого разгледаме по-задълбочено, можем да видим, че той съдържа много изображения, които са вградени като текст. Това означава, че зареждането на тези изображения блокира визуализацията, въпреки че те не са важни за страницата и може изобщо да не се използват.

За да намалите размера на файловете, можете:

• Да използвате съвременни формати на изображения като WebP и Avif.
• Използвайте компресия Brotli за текстово съдържание (като HTML, CSS и JavaScript).
• Анализирайте HTML или CSS кода си, за да идентифицирате вградените изображения, шрифтове и данни.

4. Сравнявайте реални потребителски данни с лабораторни данни

Google предоставя реални потребителски данни за повечето уебсайтове като част от своя инструмент PageSpeed Insights. Сравняването на тези данни с резултатите от лабораторния тест Lighthouse може да ви помогне да разберете по-добре какво се случва с вашия уебсайт.

Резултатът от лабораторния тест обикновено отчита по-лоши показатели от данните на реалния потребител. Това е така, защото тестът Lighthouse използва по-бавна мрежова връзка и процесор, отколкото повечето посетители.

Две често срещани причини, поради които резултатите от лабораторните ви тестове са по-бързи от данните на реалните потребители:

• Тестът PageSpeed insights отчита ненадеждни данни.
• Лабораторният тест удря кеша, докато повечето реални потребители изпитват бавни реакции на сървъра.

5. Проверете как се е променила производителността на уебсайта ви с течение на времето

Наборът от данни за реални потребители, който Google предоставя въз основа на доклада за потребителското изживяване в Chrome (CrUX), включва и исторически данни, въпреки че те не се отчитат в PageSpeed Insights. Проучването на промените в производителността на уебсайта ви с течение на времето ви позволява да видите кога е възникнал проблемът и да установите основната причина за него.

За да видите историческите данни на Core Web Vitals за вашия уебсайт, можете да стартирате тест на DebugBear Core Web Vitals и след това да проверите раздела Web Vitals за 25-седмична тенденция.

Всяка стойност на данните от CrUX обхваща подвижен 28-дневен период от време, ако възникне проблем, той постепенно ще се отрази на резултатите ви през следващите четири седмици.

6. Създаване на непрекъснато наблюдение на скоростта на уебсайта

Ако искате да уловите регресиите (т.е. внедрена е промяна, която е оказала отрицателно въздействие върху скоростта на уебсайта) веднага щом се случат, трябва да настроите мониторинг на скоростта на страницата за вашия уебсайт.

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

• Лабораторно тестване: Извършвайте тестове за скорост на страницата по график в контролирана лабораторна среда.
• Мониторинг в реални условия: Вижте как посетителите ви използват вашия уебсайт.

Настройката на мониторинг за вашия уебсайт ще ви предупреди при всяка регресия и след това ще сравни данните преди и след това, за да установи причината за забавянето.

7. Разгледайте показатели извън времето за зареждане

Производителността на уебсайта не е свързана само с първоначалната скорост на зареждане, измерена чрез метриката LCP. Google взема предвид също така колко бързо даден уебсайт реагира на взаимодействията на потребителите, както се измерва с метриката Interaction to Next Paint (INP), която на 12 март стана Core Web Vital.

Докато LCP зависи най-вече от това, което се зарежда по мрежата, INP разглежда обработката на процесора и колко време е необходимо, преди страницата да обработи взаимодействието и да актуализира потребителския интерфейс, за да бъде готова за следващото взаимодействие.

Измерването на INP изисква взаимодействие с потребителя, което затруднява тестването му в лабораторна среда. Съществуват някои лабораторни инструменти за тестване на INP, като например INP Debugger, но те не могат да идентифицират всички възможни взаимодействия на потребителите или да ви кажат с кои елементи потребителите взаимодействат най-често.

За да подобрите Interaction to Next Paint, се нуждаете от данни от реално наблюдение на потребителите (RUM). Тези данни могат да ви кажат:

• Кои страници имат бавен INP?
• С кои елементи взаимодействат потребителите?
• Кои скриптове допринасят за забавянията?

Заключение

За да подобрите скоростта на уебсайта си, първо трябва да разберете какво го забавя. Започнете с безплатен тест за скоростта на страницата.