Как да ускорите WordPress сайт — стъпка по стъпка

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

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

Стъпка 0: Измерете, преди да пипнете каквото и да е

Без начални числа няма как да докажете, че нещо е станало по-добре. Запишете поне:

• Резултата в Google PageSpeed Insights за мобилно и за десктоп — за началната страница, една категория или вътрешна страница и една продуктова страница, ако имате магазин.
• Core Web Vitals — LCP, INP и CLS. Ако сайтът има достатъчно трафик, PageSpeed показва и реални данни от потребители (горната част на отчета). Те са по-важни от лабораторния резултат.
• TTFB — времето до първия байт от сървъра. Показва колко бързо отговаря хостингът, преди браузърът изобщо да започне работа.

Пускайте теста два-три пъти. Резултатът в PageSpeed леко варира между измерванията и едно число не е достатъчно.

Стъпка 1: Сървърът — TTFB под 600 ms

Ако сървърът отговаря за 1,5 секунди, никоя оптимизация в браузъра няма да ви даде добър LCP. Затова започваме от там.

• PHP 8.2 или по-нов. Всяка основна версия на PHP е по-бърза от предишната, а старите версии вече не получават поправки за сигурност. Проверете версията в контролния панел на хостинга.
• Кеш на ниво сървър. Ако хостингът ви е на LiteSpeed, използвайте LiteSpeed Cache. Ако е на Nginx, често има вграден кеш. Сървърният кеш е по-бърз от кеша на PHP плъгин.
• Object cache (Redis или Memcached). Особено за WooCommerce и сайтове с вход на потребители — там страничният кеш не помага за всичко.
• Локацията на сървъра. За аудитория в България сървър в Европа дава по-ниска латентност от сървър в САЩ.

Подробности за избора на хостинг има в статията Хостингът и скоростта на WordPress.

Стъпка 2: Страничен кеш

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

Проверете три неща:

1. Кешът работи и за мобилни посетители (някои настройки правят отделен мобилен кеш, който се изключва по погрешка).
2. Количката, касата и профилът в WooCommerce са изключени от кеша — иначе клиентите виждат чужди колички.
3. Кешът се изчиства автоматично, когато публикувате или промените съдържание.

Сравнение на популярните плъгини има в статията за кеш плъгините.

Стъпка 3: Изображенията

На повечето сайтове, които мерим, най-тежкото нещо на страницата е снимка. И почти винаги именно снимка е LCP елементът — най-голямото нещо в първия екран.

• Модерни формати. AVIF и WebP са значително по-леки от JPEG и PNG при същото видимо качество. WordPress поддържа AVIF от версия 6.5, ако сървърът го поддържа.
• Правилен размер. Снимка 4000 px, показана в кутия от 400 px, е десет пъти по-тежка, отколкото трябва. WordPress прави няколко размера при качване — темата трябва да ги използва чрез srcset.
• Без lazy loading за първата снимка. Мързеливото зареждане е добро за снимките под първия екран, но ако е включено и за главната снимка, то забавя LCP. От WordPress 6.3 ядрото добавя fetchpriority="high" към снимката, която вероятно е LCP — проверете, че темата или плъгин не го премахват.

Повече: AVIF или WebP — изображенията в WordPress.

Стъпка 4: CSS и JavaScript

Типичният WordPress сайт с конструктор на страници и 20–30 плъгина зарежда десетки CSS и JS файлове на всяка страница — включително на страници, където не са нужни.

• Отложете JavaScript (defer), за да не блокира показването на страницата.
• Махнете ненужното. Плъгин за формуляри не трябва да зарежда скриптовете си на всяка страница, а само там, където има формуляр. Слайдер, който се ползва само на началната страница, не трябва да се зарежда в блога.
• Критичен CSS. Стиловете за първия екран се вграждат в <head>, а останалите се зареждат без да блокират.
• Скриптове на трети страни — чат, пиксели, карти, видео. Те често са най-тежкото нещо на страницата. Зареждайте ги при съгласие за бисквитки или при първо взаимодействие.

Тежкият JavaScript е и основната причина за лош INP — сайтът „замръзва“ при клик. Повече в статията за INP.

Стъпка 5: Шрифтовете

Всеки шрифт и всяка дебелина са отделен файл. Три шрифта по четири дебелини означават дванадесет файла преди текстът да изглежда правилно.

• Ограничете се до един-два шрифта и две-три дебелини.
• Хоствайте шрифтовете на собствения сървър вместо от външна услуга — така спестявате връзка към друг домейн.
• Заредете предварително (preload) шрифта, с който е написано главното заглавие.
• Използвайте font-display: swap или optional, за да не стои текстът невидим, докато шрифтът се зарежда.

Стъпка 6: Базата данни

С годините базата на WordPress събира хиляди ревизии на публикации, изтекли временни данни (transients), стари записи от изтрити плъгини и автоматично зареждани настройки. Най-опасни са autoload настройките — WordPress ги зарежда при всяка заявка. Ако са няколко мегабайта, сървърът е по-бавен на всяка страница.

Почистването е безопасно, ако първо направите архив. Ние винаги правим пълен архив на файловете и базата преди да започнем.

Стъпка 7: Измерете отново

Пуснете същите тестове от стъпка 0 при същите условия и сравнете. Ако имате реални данни от потребители (CrUX), те се обновяват постепенно — за 28 дни. Не очаквайте зелените оценки в Search Console да се появят на следващия ден.

Какво не помага толкова, колкото изглежда

• Още един плъгин за оптимизация. Два плъгина, които правят едно и също (два кеша, два минификатора), често се бият и забавят сайта.
• Гонене на 100/100 на всяка цена. Целта е добри Core Web Vitals за реалните потребители. Разликата между 92 и 100 рядко се усеща от посетителя.
• Смяна на темата като първа стъпка. Понякога е нужна, но в повечето случаи сайтът може да стане бърз и без промяна на дизайна.

Кога да го оставите на нас

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

Въпроси и отговори

Колко бърз трябва да е WordPress сайтът?

Целта е LCP до 2,5 секунди, INP до 200 ms и CLS до 0,1 за поне 75% от посещенията. В PageSpeed Insights това обикновено означава резултат над 90 на десктоп и над 80–90 на мобилно.

Трябва ли ми плъгин за кеш, ако хостингът има кеш?

Често не. Ако хостингът има сървърен кеш, той обикновено е по-бърз. Плъгинът е полезен за оптимизация на CSS, JS и изображения, но два страничен кеша едновременно създават проблеми.

Ще се промени ли дизайнът, ако оптимизираме сайта?

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

Автор: екипът на Weber Speed, Русе. Публикувана 15 януари 2025, обновена 5 октомври 2026.