По-бърз WordPress – стъпка по стъпка.

Защо скоростта има значение

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

Google също измерва това и оценява страниците, наред с друго, по Core Web Vitals: колко бързо се появява най-важното съдържание (LCP), колко бързо страницата реагира на действия (INP) и дали нещо се измества при зареждане (CLS). Бързата страница е не само по-приятна, но и по-лесно се намира.

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

Преди да преустройвате нещо, Ви трябва изходна стойност. Безплатен и показателен инструмент е PageSpeed Insights на Google: въведете адреса и гледайте стойностите за мобилни устройства – те почти винаги са по-лоши и са решаващи за Google.

• Измервайте няколко пъти и не само началната страница. Подстраница с големи изображения или формуляр често се държи съвсем различно.
• Обърнете внимание на времето за отговор на сървъра (Time to First Byte). Ако е високо, причината е в сървъра или в плъгин, който изчислява много при всяко зареждане – тогава оптимизатор на изображения няма да помогне.
• Променяйте винаги само едно нещо и след това измервайте отново. Иначе няма да знаете какво е помогнало.

Основата: хостингът

И най-добрият плъгин не прави претоварения сървър бърз. Решаващи са три неща:

• Актуален PHP. PHP 8 обработва WordPress значително по-бързо от стария PHP 7. Много сайтове от удобство все още работят на остаряла версия.
• Достатъчно памет и време за изпълнение. Page builder-ите и магазините се нуждаят от повече от оскъдните стойности при някои доставчици; стане ли тясно, зареждането прекъсва или се влачи.
• Кратък път. Ако сървърът и посетителите са в една и съща държава, всяка заявка пристига по-бързо.

При нас уебсайтовете работят на NVMe SSD в Германия, с до 1 024 MB PHP памет на заявка, а версията на PHP задавате сами за всеки домейн в Клиентския център.

Изображенията: най-честата спирачка

Снимка направо от фотоапарата лесно достига 5 MB – а се показва в плочка с ширина 600 пиксела. Точно такива изображения правят бавни повечето бавни страници.

• Намалете ги преди качване. За уебсайт рядко са нужни повече от 2000 пиксела ширина.
• Използвайте модерни формати. WordPress поддържа WebP; файловете са значително по-малки от JPEG при същото качество.
• Lazy Loading зарежда изображенията едва когато попаднат в полезрението при превъртане. WordPress го прави сам – освен за първото голямо изображение най-горе, то трябва да се появи веднага.

Кеш: страниците да не се изграждат всеки път наново

Без кеш WordPress сглобява всяка страница наново от базата данни при всяко зареждане. Плъгинът за кеш съхранява готовия резултат и го доставя директно – често най-голямата отделна печалба.

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

При нас инсталацията с 1 клик по желание настройва и кеша на страниците, а в Клиентския център го изчиствате, включвате или изключвате – без да влизате в WordPress. За магазини съзнателно го пропускаме: кеш на страниците, който не познава количката, иначе показва на посетителите чужди колички.

Разчистете плъгините и темите

Не броят на плъгините забавя, а отделни тежки плъгини. Слайдер на всяка страница, три плъгина за статистика, page builder, който за всяка страница зарежда стотици килобайта скриптове – всичко това се натрупва.

• Деактивирайте пробно плъгините един по един и измервайте. Виновникът бързо се откроява.
• Безплатният плъгин Query Monitor показва кой плъгин колко заявки към базата данни създава.
• Това, което вече не Ви трябва, изтрийте – деактивираният плъгин остава на сървъра и все пак трябва да се обновява.

Почистете базата данни

С годините се натрупва доста: стотици редакции на всяка публикация, остатъци от изтрити плъгини, изтекли временни кешове. Плъгин за почистване премахва това с няколко клика. Преди това направете резервно копие – изтритото от база данни се връща само от резервното копие.