Бавен WooCommerce магазин: 15 причини и как да ги оправите

„Сайтът зарежда бавно“ е най-честото оплакване, с което собственици на WooCommerce магазини ни търсят. Почти винаги следва второ изречение: „Сложихме плъгин за кеш, но не помогна.“ Причината е, че бавният WooCommerce рядко има една причина. Количката, checkout-ът и профилът не могат да се кешират като обикновена страница, базата данни расте с всяка поръчка, а всеки плъгин добавя заявки.

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

Накратко:

• Скоростта на WooCommerce се мери поотделно за начална страница, категория, продукт, количка и checkout, защото последните две не се кешират.
• Най-честите причини за бавен WooCommerce са слаб споделен хостинг, липса на обектен кеш, тежка тема с page builder и прекалено много плъгини.
• Времето до първия байт (TTFB) показва проблем в сървъра и базата данни, а лошите Core Web Vitals при добър TTFB показват проблем в темата, изображенията и скриптовете.
• Включването на HPOS, почистването на автоматично зарежданите опции и ограничаването на cart fragments често дават ускорение без смяна на хостинга.

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

Преди да променяте каквото и да било, запишете изходна точка. Иначе няма да знаете какво е помогнало.

Инструмент	Какво показва	Кога да го ползвате
PageSpeed Insights	Реални данни от потребители (ако има достатъчно) и лабораторен тест	За Core Web Vitals по страници
Search Console → Core Web Vitals	Групи страници с проблеми	За цялостна картина
Query Monitor (плъгин)	Бавни заявки към базата, плъгини, hooks	За диагностика в админа
Инструменти за разработчици на браузъра	TTFB, размер и брой файлове	За бърза проверка

Тествайте пет типа страници: начална, категория с много продукти, продукт с варианти, количка с продукт и checkout. Ако TTFB е над около 600–800 ms, проблемът е преди всичко в сървъра. Ако TTFB е нисък, но страницата се „рисува“ бавно, гледайте темата и скриптовете. Значението на метриките е обяснено в статията за Core Web Vitals.

Сървър и хостинг (причини 1–4)

1. Слаб споделен хостинг

Евтиният споделен хостинг е достатъчен за визитка, но магазин с хиляди продукти и филтри изисква повече процесорно време и памет. Признак: TTFB е висок дори на кеширани страници в натоварени часове. Решение: хостинг, оптимизиран за WooCommerce, или VPS. Подробно сравнение има в статията за хостинг за WooCommerce.

2. Стара версия на PHP

Всяка нова версия на PHP е по-бърза от предишната. Проверете в Инструменти → Здраве на сайта коя версия ползвате и преминете на поддържана от WooCommerce версия – първо на тестово копие.

3. Няма обектен кеш

Без Redis или Memcached WordPress пита базата данни за едно и също стотици пъти на страница. Обектният кеш помага точно там, където page cache не работи – в количката, checkout-а и админа. Много хостинги го предлагат с едно включване.

4. Липсва page cache или е настроен грешно

Страниците на продукти и категории трябва да се кешират. Количката, checkout-ът и „Моят профил“ – не. Ако плъгинът за кеш изключва твърде много или кешира количката, получавате или бавен сайт, или грешни колички.

Тема, плъгини и скриптове (причини 5–9)

5. Тежка тема и page builder

Многофункционалните теми с вграден page builder зареждат CSS и JavaScript за десетки модули, които не ползвате. На мобилен телефон това е основната причина за лош LCP. Решение: лека тема, съвместима с блоковия редактор, или изчистване на неизползваните модули.

6. Прекалено много плъгини

Важен е не броят, а какво правят. Един плъгин за „свързани продукти“, който прави тежка заявка на всяка страница, вреди повече от десет малки. С Query Monitor вижте кои плъгини добавят най-много време и потърсете по-леки алтернативи.

7. Cart fragments

WooCommerce изпраща AJAX заявка (wc-ajax=get_refreshed_fragments), за да обнови иконата на количката. При някои теми това става на всяка страница и заобикаля кеша. В новите версии поведението е подобрено, но проверете в мрежовия раздел на браузъра дали заявката се изпълнява и колко време отнема.

8. Външни скриптове

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

9. Неоптимизирани изображения

Снимки от 3–4 MB, качени директно от фотоапарата. Решение: WebP или AVIF, правилни размери, lazy loading за всичко под първия екран – но не и за главната снимка на продукта.

База данни (причини 10–13)

10. Подути autoload опции

Таблицата wp_options съдържа настройки, които се зареждат на всяка заявка. Изтрити плъгини често оставят там мегабайти данни. Проверете общия размер на autoload опциите (Здраве на сайта в новите версии на WordPress предупреждава при голям размер) и почистете остатъците.

11. Поръчките не са в HPOS

High-Performance Order Storage съхранява поръчките в собствени таблици вместо в общите таблици за публикации. За нови магазини е включено по подразбиране от версия 8.2 на WooCommerce, но старите магазини често още работят по стария начин. Миграцията се прави от WooCommerce → Настройки → Разширени → Функции, след проверка за съвместимост на плъгините.

12. Хиляди задачи в Action Scheduler

В Инструменти → Scheduled Actions може да има стотици хиляди изпълнени или неуспешни задачи от плъгини за имейли, синхронизация и абонаменти. Почистете старите и намерете плъгина, който генерира неуспешни задачи.

13. WP-Cron на всяко посещение

По подразбиране WordPress изпълнява планирани задачи при посещение на потребител. При магазин с импорт на наличности това забавя случайни посетители. Решение: изключете WP-Cron в wp-config.php и го пускайте със системен cron на всеки няколко минути.

Функционалности на магазина (причини 14–15)

14. Филтри и търсене

Филтрите по атрибути при хиляди продукти генерират тежки заявки. Използвайте плъгин за филтри, който индексира данните предварително, и ограничете броя на комбинациите. Вградената търсачка на WordPress също не е създадена за големи каталози – помислете за специализирано търсене.

15. Куриерски и платежни плъгини в checkout-а

Плъгините за Еконт и Спиди зареждат списъци с офиси и изчисляват цена на доставка чрез API на куриера. Ако това става при всяко зареждане, без кеширане на списъците, checkout-ът забавя точно в най-важния момент. Проверете колко време отнемат външните заявки в Query Monitor и дали плъгинът кешира офисите. Повече за настройката има в статията за Еконт за WooCommerce.

Ред на действие: от какво да започнете

1. Направете пълно копие и тестова среда (staging).
2. Запишете метриките на петте типа страници.
3. Обновете PHP, включете обектния кеш и проверете page cache – най-голям ефект за най-малко работа.
4. Включете HPOS и почистете базата (autoload, Action Scheduler, transients).
5. Изключете плъгините един по един на тестовата среда и измервайте.
6. Оптимизирайте изображенията и отложете външните скриптове.
7. Едва ако TTFB остане висок – сменете хостинга.
8. Измерете отново и сравнете с изходната точка.

Ако след всичко това магазинът пак е бавен, проблемът обикновено е архитектурен – твърде тежка тема или функционалност, построена с плъгини, вместо с код. Тогава понякога е по-евтино да направите нов магазин, отколкото да оптимизирате стария. Сравнение на платформите има в статията Shopify или WooCommerce.

Често задавани въпроси

Ако искате някой да намери конкретните причини във вашия магазин, а не да гадае, вижте как работим по WooCommerce магазини – започваме с измерване и ви казваме какво ще помогне, преди да променяме каквото и да е.