Продуктовите страници се отварят бавно, добавянето в количката отнема няколко секунди, а при кампания магазинът започва да връща грешки. Бавният WooCommerce магазин рядко има само една причина, затова първо трябва да разберете кои от обичайните са при Вас.
По-долу са седем от най-честите причини. За всяка обясняваме как да я откриете и как да я оправите. Общите стъпки за кеш, снимки и PHP са в ръководството Как да ускорите WordPress с кеш, по-леки снимки и нов PHP, а тук се спираме на това, което е специфично за онлайн магазина. Накрая обясняваме кога настройките спират да помагат.
Как да разберете защо WooCommerce магазинът е бавен
Започнете с измерване. Пуснете в PageSpeed Insights началната страница, една категория, един продукт и количката, на мобилни, по пет пъти. Как да мерите правилно и защо плащането не се мери там, обясняваме в ръководството Как да измерите скоростта на сайта с PageSpeed Insights.
За магазина има и още една проверка. Отворете продукт в частен прозорец на Chrome, натиснете F12, изберете раздела Network и презаредете. Кликнете първия ред, самата страница, и в раздела Timing вижте реда Waiting, който показва времето до първия байт (TTFB). После добавете продукт в количката и повторете. Ако второто време е много по-дълго, страниците за купувачите с количка не идват от кеша.
Количката и сесията пречат на кеша
Кешът на страниците работи, защото всички посетители виждат едно и също. В магазина това спира да важи, когато някой добави продукт в количката. Тогава WooCommerce му записва бисквитките woocommerce_items_in_cart, woocommerce_cart_hash и wp_woocommerce_session_, за да знае коя количка е негова. Документацията на WooCommerce казва, че Cart, Checkout и My Account (количката, плащането и профилът) трябва да остават извън кеша, и изрежда тези бисквитки като такива, които можете да изключите от кеширането. Колко страници минават покрай кеша след това, зависи от плъгина или сървъра за кеш, затова проверете какво прави Вашият.
Втората част е скриптът cart fragments, който опреснява малката количка в горната част на страницата. Той изпраща към сървъра отделна заявка от тип POST, get_refreshed_fragments, която кешът на страниците не поема. От WooCommerce 7.8 скриптът се зарежда само когато на страницата има уиджета Cart, но продължава да се зарежда, ако темата има вградена малка количка в кода си или ако друг плъгин зависи от него. За да проверите, напишете fragments в полето за филтър на раздела Network и презаредете. Ако видите get_refreshed_fragments, скриптът работи.
WooCommerce препоръчва блока Mini-Cart, който не използва този скрипт. Ако малката количка е част от кода на класическа тема, обновете темата или попитайте разработчика ѝ. Не спирайте скрипта с код навсякъде, ако малката количка разчита на него, защото тя ще спре да се обновява. И проверете дали кешът изключва само Cart, Checkout и My Account, а не целия магазин. Част от заявките на купувачите така или иначе ще остават извън кеша, затова скоростта на PHP и базата (причини 3, 5 и 7) е по-важна за магазина, отколкото за обикновен сайт.
Тежка тема или конструктор на страници
Много теми за магазини имат слайдери, мега менюта, бърз преглед на продукта, списъци с желания и собствен конструктор. Всяка функция добавя стилове и скриптове, понякога на всяка страница, дори да не я използвате. Конструкторите като Elementor добавят и вложени обвивки в HTML кода, които увеличават работата на браузъра. Как става това и какво можете да направите, описваме в ръководството Защо Elementor забавя сайта Ви и какво можете да направите.
За да видите колко тежи темата, направете копие на магазина и на него сменете темата за малко със Storefront или с тема по подразбиране на WordPress. Измерете същите страници. Ако разликата е голяма, тежестта е в темата. В PageSpeed Insights вижте и препоръките Render-blocking requests и Optimize DOM size.
Изключете функциите на темата, които не използвате, и махнете слайдера и видеото от първия екран на мобилни, ако не са нужни. Ако темата остава тежка, сменете я с лека, на копие и с проверка на всяка страница и на цялата поръчка.
Много плъгини и бавни заявки към базата
Магазинът обикновено има повече плъгини от обикновен сайт, за куриерите, плащанията, фактурите, отзивите и маркетинга. Всеки добавя код и заявки към базата, а с времето базата натрупва и неща, които никой не използва. Проверете четири неща.
- Кои плъгини правят най-много заявки. Инсталирайте за малко Query Monitor и отворете бавна страница, докато сте влезли като администратор. Той групира заявките към базата по плъгин и тема и отбелязва бавните и повтарящите се. След проверката го изключете.
- Автоматично зарежданите опции. WordPress зарежда част от настройките на плъгините при всяко отваряне на страница. От версия 6.6 Site Health (Tools, Site Health) ги проверява и показва „Autoloaded options could affect performance“, когато общият им размер надхвърли 800 KB. Сред тях може да има настройки на плъгини, които отдавна сте изтрили. Почистването е за човек, който знае какво трие, защото грешно изтрита опция може да счупи плъгин.
- Стари таблици и временни данни. WooCommerce, Status показва в раздела Database размера на всяка таблица. Таблиците с имена на плъгини, които вече не са инсталирани, най-често са останали след тях. Изтривайте ги само след бекъп и само ако сте сигурни чии са. В WooCommerce, Status, Tools бутонът Clear expired transients чисти изтеклите временни данни.
- Къде се пазят поръчките. От WooCommerce 8.2, излязъл през октомври 2023 г., новите магазини пазят поръчките в отделни таблици, High-Performance Order Storage (HPOS). По-старите магазини може още да ги пазят в таблиците за публикации на WordPress, заедно с продуктите и страниците. Според документацията на WooCommerce отделните таблици означават по-малко операции за четене и запис и по-малко натоварени таблици. Проверете в WooCommerce, Settings, Advanced, Features.
Преминаването към HPOS става на две стъпки. Включвате Enable compatibility mode (synchronizes orders to the posts table), изчаквате синхронизацията във фонов режим и превключвате на High-Performance Order Storage. Ако плъгин не е съвместим, WooCommerce не позволява превключването и показва кой е. Тествайте първо на копие, а докато синхронизацията е включена, връщането назад става веднага.
Неоптимизирани снимки на продуктите
В магазина снимките са навсякъде. На продуктовата страница главната снимка обикновено е най-големият елемент в първия екран и определя LCP. В категориите има десетки миниатюри, а галериите със зуум и лайтбокс зареждат и големите версии.
WooCommerce използва три размера снимки. Големият е за продуктовата страница, средният за категориите, а миниатюрата за количката и галерията. При класическите теми ги настройвате в Appearance, Customize, WooCommerce, Product Images, а при блоковите теми в Appearance, Editor, в съответния шаблон. Качените снимки се преоразмеряват до тези стойности.
Проблемът често е в оригиналите. Снимка от телефон или от доставчик може да е няколко хиляди пиксела и няколко мегабайта. WooCommerce препоръчва оригинал от поне 800 на 800 пиксела за повечето теми, за да не излизат снимките размазани. Повече е нужно само ако темата показва снимките по-големи.
За да откриете проблемните снимки, вижте в PageSpeed Insights препоръките Improve image delivery и LCP request discovery на продукт и на категория. Втората показва дали главната снимка не се открива късно или не се зарежда отложено по погрешка.
Намалете оригиналите до разумен размер и ги качете отново или използвайте плъгин, който ги оптимизира и преобразува в WebP. Ако смените размерите в настройките, пуснете Regenerate shop thumbnails в WooCommerce, Status, Tools, за да се създадат наново и старите миниатюри. Как работят WebP и отложеното зареждане в WordPress, обясняваме в ръководството за ускоряване.
Бавен хостинг или стара версия на PHP
Количката, плащането и профилът никога не идват от кеша, а се сглобяват от PHP и базата при всяко отваряне, затова хостингът се усеща в магазина повече, отколкото в обикновен сайт.
Проверете версиите в WooCommerce, Status, където са PHP version, Database version и WP Memory Limit, и ги сравнете с препоръките на WooCommerce за версия 10.8 и по-нови.
| Какво | Препоръка на WooCommerce |
|---|---|
| PHP | 8.3 или по-нова |
| База данни | MySQL 8.0 или по-нова, или MariaDB 10.6 или по-нова |
| Памет за WordPress | поне 256 MB |
WooCommerce работи и с PHP 7.4 и MySQL 5.6, но документацията му предупреждава, че тези версии вече не се поддържат и могат да изложат сайта на уязвимости. Внимавайте и с PHP 8.2, която според php.net получава поправки за сигурност само до 31 декември 2026 г. Как да смените версията в cPanel, без да счупите сайта, описваме в отделно ръководство.
Ако версиите са наред, а времето до първия байт остава високо, погледнете самия хостинг. Ориентир са TTFB от реалните посетители в PageSpeed Insights, препоръката Document request latency и проверката с количка от началото. Ако тези числа са лоши при нормален трафик, а при кампании магазинът връща грешки, на магазина му трябват повече процесор и памет или собствен сървър, какъвто предлагаме в облачната инфраструктура.
Външни скриптове, пиксели, чатове и отзиви
Рекламните пиксели, скриптовете за анализ, чатът, уиджетите с отзиви и бутоните за социалните мрежи идват от чужди сървъри. Според web.dev такива скриптове добавят заявки, държат зает основния процес на браузъра и могат да забавят показването на страницата. На телефон това се вижда най-вече в TBT и INP.
Отворете в PageSpeed Insights препоръката Third parties. Тя показва външните доставчици и колко тежи всеки. Проверете и в Google Tag Manager дали няма тагове от кампании, които отдавна са приключили.
Махнете всеки скрипт, който не Ви носи нещо конкретно, както съветва и web.dev. За тези, които остават, помолете разработчика да ги зарежда с async или defer, освен ако не са нужни за показването на страницата. Чатът е добър кандидат за фасада, тоест статично копче, което изглежда като чата и зарежда истинския скрипт едва след клик. Документацията на Chrome дава чатовете и видеата като типични примери и предупреждава, че част от функциите им тогава работят чак след клика.
Скриптовете, добавени след пускането, свалят и резултата в PageSpeed Insights. Затова при сайтовете, които правим, проверяваме новите скриптове заедно с клиента, преди да влязат в сайта.
Търсене и филтри в голям каталог без обектен кеш
Формата за търсене на WooCommerce използва стандартното търсене на WordPress. То търси всяка дума в заглавието, краткото описание и съдържанието на продуктите със заявка от вида LIKE '%дума%'. Според документацията на MySQL индексът не помага, когато търсеният текст започва със заместващ знак, затова при голям каталог базата преглежда много редове при всяко търсене.
Филтрите по цвят, размер или цена създават отделен адрес за всяка комбинация. Комбинациите са твърде много, за да са в кеша, и всяка се сглобява наново. Google предупреждава, че роботите обхождат голям брой такива адреси и това струва на сайта много изчислителни ресурси.
WordPress има обектен кеш, който пази резултати от базата, но по подразбиране той живее само докато се зарежда една страница. Постоянният обектен кеш с Redis или Memcached ги пази и за следващите посещения и спестява повтарящите се заявки към базата. Site Health сам препоръчва постоянен обектен кеш („You should use a persistent object cache“), когато в някоя от основните таблици има хиляда или повече реда, например в таблицата с публикации, където са и продуктите.
Проверете в WooCommerce, Status, в раздела Dropin Plugins, дали имате постоянен обектен кеш. Ако там има object-cache.php, кешът е включен. Ако го няма, попитайте хостинга дали предлага Redis или Memcached. Плъгин като Redis Object Cache свързва WordPress с Redis, но самият Redis трябва да работи на сървъра.
При много голям каталог търсенето се изнася в отделен индекс, направен за целта. Адресите на филтрите, които не трябва да се индексират, могат да се спрат за роботите в robots.txt, както описва Google, но това решете с човека, който отговаря за SEO, защото някои филтрирани страници носят посещения.
Кога настройките спират да помагат
Ако сте минали през седемте причини и магазинът пак е бавен на мобилни, или е бърз в спокойни дни, но се срива при кампании и разпродажби, вероятно сте стигнали границата на класическия модел. При него всяка страница, която не е в кеша, минава през PHP и базата данни, които обслужват и количката, и админ панела.
Тогава има смисъл магазинът да се преработи в headless. Купувачите виждат бърза витрина на Next.js, а WooCommerce остава за продуктите и поръчките. В нашия модел Спиди и Еконт са направо в поръчката, поръчките минават през опашка, така че поръчка не се губи, дори WooCommerce да не отговаря в момента, а Kubernetes добавя капацитет, когато трафикът расте. Целта ни е 90+ за скорост и 100 за SEO в PageSpeed Insights.
При преработката на съществуващ магазин продуктите, поръчките и профилите на клиентите остават в WooCommerce, управлявате магазина от същия админ панел, а старите адреси се пренасочват към новите. Как да прецените дали Ви трябва, описваме в ръководството Класически WooCommerce или headless магазин, а как протича самата преработка, в Преработка на WooCommerce магазин в headless.
Чеклист
- Началната страница, категория, продукт и количката са измерени на мобилни, а TTFB е сравнен без количка и с количка.
- Кешът изключва само Cart, Checkout и My Account, а cart fragments се зарежда само там, където е нужен.
- Темата е сравнена с лека тема на копие на магазина.
- Ненужните плъгини са изтрити след бекъп, а Site Health не показва проблем с автоматично зарежданите опции.
- Поръчките са в HPOS таблиците.
- Оригиналите на снимките са с разумен размер, а миниатюрите са създадени наново.
- PHP е 8.3 или по-нова, а паметта е поне 256 MB.
- Всеки външен скрипт има причина да е в магазина.
- При голям каталог има постоянен обектен кеш.
Трябва ли да го правите сами?
Част от проверките отнемат минути, например версиите в WooCommerce, Status или предупреждението в Site Health. За по-сериозните стъпки, като преминаването към HPOS, смяната на темата или почистването на базата, е по-добре да има копие на магазина и човек, който ги е правил и преди. При ускоряването на сайта настройваме кеша, Redis, PHP и базата за натоварването на магазина, мерим преди и след и Ви показваме разликата в цифри. Ако магазинът е стигнал границата на класическия модел, вижте преработката в headless.
Често задавани въпроси
Защо магазинът ми с WooCommerce е бавен?
Бавният магазин с WooCommerce рядко има само една причина. Най-честите са количката и сесията, които пречат на кеша, тежка тема или редактор на страници, твърде много плъгини и бавни заявки към базата, неоптимизирани снимки на продукти, бавен хостинг или стара версия на PHP, външни скриптове и търсене и филтри в голям каталог без постоянен обектен кеш. Започнете с измерване на началната страница, една категория, един продукт и количката в PageSpeed Insights на мобилно.
Защо магазинът се забавя, след като добавя продукт в количката?
Щом някой сложи продукт в количката, WooCommerce слага бисквитките woocommerce_items_in_cart, woocommerce_cart_hash и wp_woocommerce_session_, за да знае коя количка е негова, а колко страници заобикалят кеша след това зависи от плъгина за кеш или сървъра. Проверете с раздела Network в Chrome времето до първия байт на продукт преди и след добавяне в количката. Ако второто е много по-дълго, страниците за купувачи с количка не идват от кеша.
Какво е cart fragments в WooCommerce и забавя ли сайта?
Това е скриптът, който обновява малката количка горе на страницата с отделна POST заявка, get_refreshed_fragments, която кешът на страниците не обслужва. От WooCommerce 7.8 той се зарежда само когато на страницата има уиджета Cart, но се зарежда и ако темата има вградена мини количка или друг плъгин зависи от него. WooCommerce препоръчва блока Mini-Cart, който не ползва този скрипт.
Какво е HPOS и трябва ли да мина на него?
High-Performance Order Storage (HPOS) пази поръчките в отделни таблици, а не в таблиците за публикации на WordPress заедно с продуктите и страниците. Според документацията на WooCommerce това значи по-малко операции за четене и запис и по-малко натоварени таблици, а новите магазини го ползват от WooCommerce 8.2. Проверете в WooCommerce, Settings, Advanced, Features и минете първо с режима за съвместимост, като пробвате на копие на магазина.
Колко големи трябва да са снимките на продуктите в WooCommerce?
WooCommerce препоръчва оригинал поне 800 на 800 пиксела за повечето теми, за да не изглеждат снимките размазани, а повече трябва само ако темата показва снимките по-големи. Снимка от телефон или от доставчик често е широка няколко хиляди пиксела и тежи няколко мегабайта. Намалете оригиналите и ги качете наново, а ако смените размерите в настройките, пуснете Regenerate shop thumbnails в WooCommerce, Status, Tools.
Каква версия на PHP и база данни препоръчва WooCommerce?
За версия 10.8 и по-новите WooCommerce препоръчва PHP 8.3 или по-нова, MySQL 8.0 или по-нова или MariaDB 10.6 или по-нова и поне 256 MB памет за WordPress. Версиите се виждат в WooCommerce, Status. WooCommerce още работи с PHP 7.4 и MySQL 5.6, но документацията му предупреждава, че тези версии са в края на живота си.
Трябва ли ми Redis за магазин с WooCommerce?
При голям каталог с търсене и филтри постоянният обектен кеш с Redis или Memcached пести повтарящи се заявки към базата. Site Health сам го препоръчва, щом някоя от основните таблици, например тази с публикациите, където са и продуктите, има хиляда или повече реда. Дали имате такъв кеш, вижте в WooCommerce, Status, в секцията Dropin Plugins, а ако там няма object-cache.php, попитайте хостинга дали предлага Redis или Memcached.
Кога настройките вече не помагат на бавния магазин?
Когато след всичките седем причини магазинът е още бавен на мобилно или е бърз в тихите дни, но не издържа на кампании и разпродажби. Тогава вероятно сте стигнали границата на класическия модел, в който всяка страница извън кеша минава през PHP и базата. Тогава има смисъл магазинът да се преработи като headless, с витрина на Next.js, а продуктите, поръчките и клиентските акаунти остават в WooCommerce.
Източници
- WooCommerce, Configure caching plugins, Best practices for the use of the cart fragments API, cart-fragments.js, class-wc-cart-session.php
- WooCommerce, High-Performance Order Storage, How to enable HPOS, A large store's guide to enable HPOS
- WooCommerce, Server recommendations, System Status Report, System tools, Fixing blurry product images, product-searchform.php
- WordPress, Options API, disabling autoload for large options, WP_Object_Cache, WP_Query::parse_search(), class-wp-site-health.php
- PHP, Supported Versions
- MySQL 8.4 Reference Manual, Comparison of B-Tree and Hash Indexes
- Google Search Central, Managing crawling of faceted navigation URLs
- web.dev, Load third-party JavaScript
- Chrome for Developers, Lazy load third-party resources with facades, Performance insights, Network features reference
- WordPress.org plugins, Query Monitor, Redis Object Cache