SEO-Studio
WEBІнтернет-магазини

Кейс SEO-Studio: прискорення WooCommerce-магазину All-Tex (WordPress + Woodmart)

Для оптового магазину тканин all-tex.ua розібрали важкий стек Woodmart + Elementor + LiteSpeed + Cache Enabler і підняли мобільний PageSpeed з ~64 до 94 — зі збереженням відео…

Кейс SEO-Studio: прискорення WooCommerce-магазину All-Tex (WordPress + Woodmart)

Для оптового інтернет-магазину тканин all-tex.ua ми розібрали «важкий» WordPress-стек (Woodmart, Elementor, LiteSpeed, Cache Enabler, WPML, WOOF, Chaty), прибрали типові пастки плагінів оптимізації й підняли швидкість так, щоб сайт і виглядав преміально (відео в хедері, каталог), і стабільно відкривався для Google та покупців.

  • Клієнт: All-Tex — тканини, трикотаж і фурнітура оптом
  • Ніша: B2B / оптовий e-commerce (швейне виробництво)
  • Сайт: https://all-tex.ua/ (+ /ru/ WPML)
  • Платформа: WordPress + WooCommerce + Woodmart + Elementor
  • Роботи: аудит PageSpeed → кеш і CSS/JS → WebP і медіа → LCP/CLS → стабілізація після інцидентів → супровід
  • Категорія: WEB / Прискорення сайту на WordPress
PageSpeed Insights all-tex.ua після оптимізації — Performance 94 (mobile)
PageSpeed Insights після оптимізації: Performance 94 на mobile

Завдання

Магазин уже продавав, але мобільний PageSpeed тримався в червоній зоні: Performance ~64, LCP понад 11 с, десятки render-blocking CSS, важкий hero-відеофайл і хаотична поведінка плагінів кешу.

  • Прискорити головну й каталог без «вбивства» дизайну (відеофон, банери, картки товарів).
  • Не зламати WooCommerce, WPML (UK/RU) і фільтри товарів.
  • Зробити так, щоб оптимізації не відкочувались після кожного purge кешу.
  • Закласти безпечний процес для WebP — без класичної помилки «конвертували → видалили → каталог порожній».

З чим стартували

Типовий «дорослий» Woo-магазин на nginx-хостингу:

  • ~90+ CSS у <head>, поки LiteSpeed combine не зібраний або «не бачить» мобільний HTML.
  • LiteSpeed Cache увімкнений «як у туторіалі», але без QuicCloud Critical CSS.
  • Поруч Cache Enabler — саме він дає теплий TTFB ~10–20 ms після прогріву.
  • Elementor тягне фонове MP4 ~81 MB у хедері.
  • WOOF і Chaty вантажать CSS/JS навіть на головній, де їх немає в UI.
  • Медіатека з десятками тисяч JPG; «галочка WebP» у LiteSpeed майже нічого не давала без файлів на диску.

Це не лише «повільний хостинг». Це конфлікт інструментів: кожен окремо корисний, разом — мінне поле.

Типові пастки плагінів (і як проявились)

LiteSpeed: «увімкни все» ≠ швидкість

  • CSS Async / UCSS без critical CSS → сторінка спочатку «гола», потім стрибає (CLS 0.6–1.0). Відкотили.
  • CSS Combine інколи «не збирав» мобільний HTML або HTML у Cache Enabler тримав старий hash CSS → 404.
  • JS Delayed до кліку добре для TBT, але ламав Elementor-відео. Повернули Deferred.
  • WebP replace чекає файли photo.jpg.webp. Немає файлів — галочка є, виграшу нуль.

Висновок: LiteSpeed треба налаштовувати під хостинг і тему, а не копіювати скріншоти з YouTube.

Cache Enabler: швидкий TTFB і підступні деталі

  • Після purge треба прогрівати URL з Accept: text/html — звичайний curl */* часто обходить кеш.
  • HTML у кеші може тримати старі шляхи до CSS, поки не зробиш purge + warm.
  • На цій зв’язці теплий TTFB — 10–20 ms; холодний PHP після purge — близько 2 с (нормально для важкого Woo).

Elementor + відео ~81 MB

Файл у data-settings стартував під час парсу й бив по LCP. Вирізати відео з HTML — мертвий хедер; Delayed JS — смикання.

Рішення: прибрали URL з background_video_link у HTML, підставляємо src легким скриптом після first paint, граємо після canplay. Візуал лишився, PSI перестав тягнути 81 MB у критичний шлях.

WOOF, Chaty, WPML

  • WOOF — dequeue глобальних стилів/скриптів на сторінках без фільтра.
  • Chaty — settings у окремий data-no-optimize скрипт + excludes у LiteSpeed.
  • WPML — окремий lang= у Woodmart AJAX і серверний switch, щоб «Load more» не тягнув іншу мову через sticky cookie.

WebP: найдорожча помилка

Класика індустрії: «конвертували все й видалили JPG» → частина метаданих не збігається з диском → дірки в каталозі. У нас був саме такий інцидент.

Відновили оригінали з бекапу; далі — контрольована генерація WebP без видалення JPG, поки URL зелені; правка sizes[], де mime уже webp, а розширення лишилось .jpg; архів зайвих JPG на FTP; чистка дублікатів LiteSpeed *.jpg.webp (~2 GB).

Підсумок: вітрина на WebP, 8000+ attachments image/webp, на ключових сторінках 0 посилань на .jpg.

LCP: не той файл і не той розмір

У preload був один банер, а LCP — повний fabric-photo-22.webp (~67 KB) замість -400x267.webp (~10 KB). Виправили буфер головної: src = mid-size WebP, preload збігається з LCP, srcset ≤430w, логотипи без fetchpriority=high.

Що зробили по шарах

1. Кеш і критичний шлях

  • Безпечний набір LiteSpeed: minify + combine CSS/JS, HTML minify, JS Deferred (не Delayed), font-display swap.
  • css_async — OFF свідомо: швидкість без «танцюючого» layout.
  • Cache Enabler як page cache + прогрів після кожного purge.
  • З ~87 CSS у head → 1 combined файл.

2. Треті скрипти

WOOF/Chaty — лише там, де потрібні; GTM без конфліктів із defer; прибрані дублі Google Fonts і зайві preconnect.

3. Медіа й LCP

Контрольована WebP-міграція, коректний preload LCP, відео після first paint без ривків.

4. SEO «в додачу»

Паралельно: H1/meta, подвійні H1 у категоріях, canonical/hreflang, UK/RU тексти інтерфейсу, LLMs.txt.

Результат

До (mobile PSI):

  • Performance ~64
  • LCP ~11.4 с
  • Десятки render-blocking CSS
  • MP4 ~81 MB у критичному шляху
  • Помилки плагінів у консолі

Після:

  • Performance 94 (mobile lab)
  • Accessibility 92 · Best Practices 96 · SEO 100
  • TTFB з кешу ~10–20 ms
  • 1 combined CSS замість ~87
  • Каталог/головна на WebP
  • Відео в хедері залишилось, але більше не валить LCP
Повторний прогін PageSpeed Insights all-tex.ua — Performance 94
Контрольний прогін PSI: стабільні зелені метрики на mobile

Ми свідомо не вмикали async CSS «ради галочки 95+», якщо це ламало CLS. Для бізнесу важливіші стабільний TTFB, WebP, живий каталог і відсутність 404 по CSS після оновлень — і саме це дало 94 без танцюючого layout.

Чому кейс показовий

  1. Плагіни швидкості конфліктують один з одним сильніше, ніж «повільний PHP».
  2. Async CSS без critical CSS — короткий шлях до CLS і скарг «сайт стрибає».
  3. WebP з видаленням оригіналів без перевірки метаданих = ризик зупинити продажі.
  4. Кеш HTML треба вміти чистити й прогрівати — інакше Google бачить учорашню версію.
  5. Красивий хедер з відео і зелений PageSpeed можна помирити — ручним контролем життєвого циклу відео, а не галочкою «Remove unused JS».

Стек і роль SEO-Studio

  • Аудит і пріоритезація (LCP, TBT, CLS, TTFB).
  • Налаштування LiteSpeed + Cache Enabler під nginx.
  • Доопрацювання child-теми Woodmart (буфери HTML, dequeue, відео, WPML AJAX).
  • Безпечна WebP-стратегія й відновлення після інциденту з медіа.
  • Контроль після кожної правки: HTTP 200, TTFB, обгортки теми, відсутність critical error.

Сайт клієнта: all-tex.ua
Послуга: Прискорення сайту на WordPress

Потрібен подібний аудит?

Якщо у вас WordPress + WooCommerce + «важка» тема й кілька плагінів кешу — не вмикайте всі галочки підряд. Ми розберемо стек, приберемо конфлікти й прискоримо сайт так, щоб не зламати продажі й дизайн.

Замовити аудит швидкості →