Бавен WordPress сайт – как да откриете виновника

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

Накратко: - Времето до първия байт (TTFB) над 1,8 секунди се счита за лошо, между 0,8 и 1,8 секунди има какво да се подобри (web.dev (Google)). - Панелът Network показва кои заявки са най-бавни и колко от времето е чакане на сървъра (Chrome for Developers (Google)). - Режимът за отстраняване на проблеми на плъгина Health Check изключва другите плъгини само за Вашата сесия, така че посетителите не усещат теста (WordPress.org). - Query Monitor показва кой плъгин или тема товари базата данни (WordPress.org).

Бавен WordPress сайт – откъде идва закъснението

Зареждането на страница е верига от стъпки: DNS търсене, връзка със сървъра, защитена връзка (TLS), обработка на заявката и накрая теглене на файловете. TTFB обхваща всичко до първия получен байт, включително пренасочванията (web.dev (Google)). Затова един медленно работещ плъгин и един претоварен хостинг изглеждат еднакво отвън, но се разпознават по различни признаци.

Първата заявка към сървър винаги е по-бавна, защото плаща за DNS, TCP връзка и TLS договаряне, а следващите заявки използват вече отворената връзка (MDN Web Docs (Mozilla)). Не търсете проблем в една единствена мярка. Направете няколко опита и гледайте най-ниския и най-високия резултат.

Как работи DNS стъпката, е обяснено в материала за DNS.

Измерване в панела Network на браузъра

Отворете сайта в нов прозорец, натиснете F12 и изберете раздела Network. Поставете отметка на Disable cache, за да имитирате посетител, който идва за първи път (Chrome for Developers (Google)). След това презаредете страницата.

В падащото меню Throttling изберете например бърз или бавен 4G, за да видите как сайтът се държи на по-слаба връзка (Chrome for Developers (Google)). Колоната Waterfall показва кога е започнала всяка заявка и колко е продължила; може да я подредите по продължителност, като щракнете с десния бутон върху заглавието на таблицата.

Запишете три числа: колко заявки има, колко е общият размер и коя е най-дългата. Първата заявка в списъка е самата HTML страница и тя е ключът към следващата стъпка.

Какво показва Waiting (TTFB)

Щракнете върху първата заявка, отворете раздела Timing и намерете реда Waiting (TTFB). Той включва едно пътуване по мрежата плюс времето, в което сървърът подготвя отговора (Chrome for Developers (Google)). Ако тук стои голямо число, виновникът е от страната на сървъра (MDN Web Docs (Mozilla)).

Оттук следва нашият извод. Ако Waiting е над 1,8 секунди (web.dev (Google)), няма смисъл да компресирате още снимки, докато не разберете какво изпълнява PHP кодът. Ако Waiting е добро, а страницата все пак се зарежда дълго, проблемът е във файловете: големи изображения, много скриптове, външни шрифтове. За тях вижте материала за по-леки изображения, кеш и CDN.

TTFB не е част от Core Web Vitals, но влияе върху тях, защото всичко останало започва след първия байт (web.dev (Google)). Показателите LCP, INP и CLS са разгледани в отделната статия за Core Web Vitals.

Проверка на плъгините с режима за отстраняване на проблеми

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

Инсталирайте плъгина Health Check & Troubleshooting от каталога на WordPress.org. Към момента на проверката текущата му версия е 1.7.1 и изисква PHP 5.6 или по-нова (WordPress.org). Страницата му предупреждава, че плъгинът не е тестван с последните три основни издания на WordPress, затова го пробвайте първо върху тестово копие, ако имате такова.

Режимът за отстраняване на проблеми дава чиста сесия с изключени плъгини и стандартна тема, която важи само за Вашия потребител, докато не го изключите или не излезете (WordPress.org). Следвайте този ред:

1. Измерете TTFB на началната страница с всички плъгини.
2. Включете режима и измерете отново.
3. Включвайте плъгините по един и измервайте след всеки.

Скокът в Waiting след определен плъгин показва кой го предизвиква. Ако със всичко изключено сайтът пак е бавен, причината е в темата, в PHP настройките или в хостинга. Не разбирате ли основите на системата, прегледайте основите на WordPress.

Query Monitor и натоварването върху базата данни

Режимът за проверка казва кой плъгин е бавен, но не и защо. За това служи Query Monitor. Плъгинът показва заявките към базата, грешките на PHP, куките, заредените скриптове и повикванията към външни API (WordPress.org). Може да групира заявките по плъгин, тема или функция, която ги е пуснала.

Версията, която видяхме при проверката, е 4.1.1, с изискване за PHP 7.4 или по-нова и тествана до WordPress 7.1.4 (WordPress.org). Проверете тези числа на страницата на плъгина, преди да го инсталирате, защото те се променят.

Обърнете внимание на повикванията към външни услуги: Query Monitor показва за всяко от тях кода на отговора, отговорния компонент и отнетото време, и маркира неуспешните заявки (WordPress.org). Плъгин, който чака отговор от външен сървър при всяко зареждане, може да бави цялата страница, без да товари Вашата база. Изключете Query Monitor, когато приключите, защото е диагностичен инструмент, а не постоянна част от сайта.

Когато виновникът е сървърът

Ако TTFB остава висок и при изключени плъгини, събирайте факти, преди да пишете на хостинга: скрийншот от Timing раздела, часа на измерването и резултата от режима за отстраняване на проблеми. Заявката към поддръжката с конкретни числа се решава по-бързо от оплакването „сайтът е бавен“.

Сървърното чакане се състои от работата на PHP и базата, а не само от мрежата (MDN Web Docs (Mozilla)). Попитайте за версията на PHP, лимитите на процеса и наличието на кеш на ниво сървър. Ако отговорите Ви не удовлетворяват, прехвърлянето на сайт на нов хостинг се прави без прекъсване, но само след като имате резервно копие.

Чести грешки при диагностиката

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

Следва смесването на причини: сменяте плъгини и компресирате снимки едновременно и накрая не знаете кое е помогнало. Променяйте по една неща и измервайте след всяка промяна. И не оставяйте диагностичните плъгини активни след теста.

Още днес можете да отворите Network панела, да запишете Waiting (TTFB) на началната страница и да го сравните с границите от 0,8 и 1,8 секунди на web.dev (web.dev (Google)). Подробностите за панела са в документацията на Chrome (Chrome for Developers (Google)), а за ролята на латентността – в MDN (MDN Web Docs (Mozilla)).