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 + «тяжёлая» тема и несколько плагинов кэша — не включайте все галочки подряд. Мы разберём стек, уберём конфликты и ускорим сайт так, чтобы не сломать продажи и дизайн.

Заказать аудит скорости →