Почему мой сайт WooCommerce такой медленный?
Пошаговая диагностика медленного сайта WooCommerce: хостинг, плагины, раздувание базы данных, кеширование и проблемы, связанные с оформлением заказа, которые большинство руководств упускают из виду.
Медленный магазин WooCommerce — это не единственная проблема — обычно это три или четыре магазина меньшего размера, расположенных друг над другом, и именно поэтому «установка плагина кеширования» сама по себе редко решает проблему. Это диагностическая последовательность, которую мы выполняем, когда клиент говорит, что его магазин работает вяло, в том порядке, который на самом деле позволяет быстрее обнаружить причину.
Прежде чем что-либо исправлять, проведите диагностику
Прежде чем прикасаться к плагинам или хостингу, получите реальные цифры. Запустите свою домашнюю страницу и страницу продукта через Google PageSpeed Insights и обратите особое внимание на две вещи:Время до первого байта (TTFB)и разбивка того, что блокирует рендеринг. TTFB более 600 мс почти всегда указывает на проблему с хостингом или на стороне сервера — никакая внешняя оптимизация не исправит медленный сервер. Если TTFB работает быстро, но страница по-прежнему медленно загружается, проблема, скорее всего, во внешнем интерфейсе: изображениях, скриптах блокировки рендеринга или внедренном плагином CSS/JS.
Эта единственная проверка экономит часы — она сообщает вам, следует ли начать с вашего хоста или стека плагинов, которые представляют собой совершенно разные исправления.
Хостинг: наиболее распространенная причина
WooCommerce запускает PHP при каждом запросе, который касается базы данных — страницы продуктов, корзина и оформление заказа, в частности, являются динамическими, а не статическими, поэтому общий хостинг с ограниченным количеством рабочих мест PHP и распределением ресурсов ЦП затрудняется при любом реальном трафике. Если ваш TTFB постоянно медленный даже на странице без активных тяжелых плагинов, скорее всего, хостинг — это ваш ответ, а не симптом, который нужно обойти.
Что проверить:
- PHP-версия.Старые версии PHP (7.x и ниже) заметно медленнее, чем текущие версии PHP 8.x для того же кода. Убедитесь, что на вашем хостинге установлена текущая версия — часто это бесплатное изменение в один клик на панели управления хостингом.
- Общий и управляемый хостинг WooCommerce.Общий хостинг, оптимизированный для сайтов брошюр, не рассчитан на нагрузку базы данных, которую генерирует WooCommerce. Управляемый хостинг WooCommerce или управляемый хостинг WordPress обычно включает в себя кэширование на уровне сервера и распределение ресурсов, настроенное для этой конкретной рабочей нагрузки.
- Расположение сервера.Если ваши клиенты в основном находятся в одном регионе, а ваш сервер — в другом, этот обратный путь увеличивает реальную задержку, прежде чем CDN сможет помочь.
Аудит плагина: качество важнее количества
«Слишком много плагинов» — реальная причина замедления, но их количество имеет меньшее значение, чем то, что фактически делает каждый плагин при каждой загрузке страницы. Легкий служебный плагин, который запускается только под управлением администратора, ничего не стоит на витрине магазина. Плохо закодированный конструктор страниц или плагин, который запрашивает базу данных при каждом внешнем запросе, тратят вам реальное время на каждой странице, при каждом посещении.
Для аудита:
- Установите Query Monitor (бесплатно) и загрузите самую медленную страницу. Он показывает, какие именно плагины запускают запросы к базе данных, сколько и сколько времени каждый из них занимает.
- Деактивируйте плагины, которые вы не используете активно — старые инструменты SEO, заброшенные конструкторы страниц, дублирующие функции из-за переключения инструментов с течением времени. В большинстве магазинов их несколько.
- Для плагинов, которые вы сохраняете, проверьте, предлагают ли они настройку «отключить во внешнем интерфейсе» или «загружать только при необходимости» — многие популярные плагины по умолчанию загружают свои ресурсы по всему сайту, даже если эта функция используется только на одной странице.
Раздувание базы данных
WordPress и WooCommerce записывают в базу данных гораздо больше, чем думает большинство владельцев сайтов: публикуют изменения при каждом редактировании контента, просроченные временные файлы, которые никогда не очищаются, данные о брошенных корзинах и записи сеансов каждой попытки оформления заказа, завершенной или нет. За год или два необслуживаемая база данных WooCommerce может действительно увеличиться в три раза, а контент не будет приносить никакой постоянной ценности.
Раздутая база данных замедляет каждый запрос, что замедляет каждую страницу — это усугубляется проблемами запросов на уровне плагина, а не существует отдельно от них. Запускайте очистку базы данных (ограничивайте количество редакций публикаций, удаляйте просроченные временные файлы и проверяйте потерянные метаданные) по регулярному графику, а не один раз.
Проблемы, специфичные для WooCommerce, которые пропускают большинство руководств
В общих советах по скорости WordPress не учитываются некоторые особенности работы WooCommerce:
- Фрагменты корзины и оформления заказа.WooCommerce по умолчанию обновляет «фрагменты корзины» через AJAX при каждой загрузке страницы, даже на страницах, на которых не происходит взаимодействия с корзиной — это фоновый запрос, о котором большинство владельцев сайтов не знают. Его можно выборочно отключить или ограничить страницами, которым он действительно нужен.
- Обработка сеансов в базе данных.По умолчанию WooCommerce хранит данные сеанса в базе данных, а не в более быстром хранилище. В магазинах с большим трафиком перенос сеансов на кэширование объектов (Redis или Memcached, если ваш хост предлагает такую возможность) устраняет реальное узкое место.
- Связанные запросы и запросы на дополнительные продажи продуктов.Они запускают нетривиальные запросы к базе данных для расчета рекомендаций «вам также могут понравиться». В больших каталогах без надлежащей индексации это само по себе может существенно замедлить страницы с товарами.
- Полностраничное кеширование конфликтует с оформлением заказа.Страницы оформления заказа и корзины никогда не должны обслуживаться из статического кеша, но слишком широкие конфигурации плагинов кеша иногда все равно кешируют их, что приводит к устареванию данных корзины. Убедитесь, что ваш плагин кеширования явно исключает страницы корзины, оформления заказа и учетной записи.
Кэширование, изображения и исправления последней мили
- Настроить кэширование страницдля всего, кроме корзины, оформления заказа и страниц учетной записи, используйте надежный плагин кеширования или встроенный уровень кеширования вашего хоста.
- Включить кэширование объектов(Redis или Memcached), если ваш хост поддерживает это — это ускоряет динамические запросы, запросы при входе в систему и запросы, специфичные для WooCommerce, в которых само по себе кэширование страниц не помогает.
- Сжатие и изменение размера изображенийперед загрузкой и обслуживайте современные форматы (WebP или AVIF). Фотографии продуктов обычно являются самым крупным ресурсом на любой странице электронной торговли.
- Добавить CDNдля обслуживания статических ресурсов (изображений, CSS, JS) с сервера, географически расположенного ближе к каждому посетителю.
- Отложите или удалите неиспользуемый JavaScript., особенно аналитические и маркетинговые скрипты, загружаемые синхронно в заголовке — это обычные и простые победы, которые часто обнаруживаются при аудите плагинов.
Когда оптимизации становится недостаточно
Иногда все исправления из этого списка применяются, но магазин по-прежнему работает медленнее, чем должен быть — обычно потому, что сама тема тяжелая, стек плагинов несет нагрузку и его нельзя урезать дальше без потери реальной функциональности, или магазин действительно перерос то, что может предоставить WooCommerce на текущем уровне хостинга. В этот момент честный разговор переключается с «оптимизировать WooCommerce» на «является ли WooCommerce по-прежнему подходящей платформой для трафика этого магазина и размера каталога». НашРуководство по оптимизации скорости Shopifyявляется полезной точкой сравнения, если вы взвешиваете это решение, и мы рассмотрим практическую сторону перехода в нашейРуководство по переходу с WooCommerce на Shopify.
Если вы предпочитаете, чтобы кто-то другой провел полную диагностику и исправил то, что она обнаружила,Devmerx отвечает за производительность WordPress— проверка хостинга, аудит плагинов, очистка базы данных и настройка кеширования, ограниченная область действия и фиксированная цена после быстрого просмотра вашего сайта.
Часто задаваемые вопросы
Почему мой сайт WooCommerce внезапно стал работать медленнее после добавления товаров?
Большие каталоги означают большие запросы к базе данных, особенно для фильтрации, поиска и расчетов по сопутствующим продуктам, которые не были оптимизированы для масштабирования. То, что было хорошо при 200 продуктах, может заметно замедлиться при 2000, если ваш хостинг и стек плагинов не были построены с учетом роста.
Действительно ли виртуальный хостинг является основной причиной медлительности WooCommerce?
Это наиболее распространенная причина, которую мы видим, особенно когда TTFB работает медленно даже на страницах с небольшим количеством плагинов. Это не всегда единственная причина — наряду с этим часто встречается раздувание плагинов и базы данных — но обычно хостинг — это первое, что стоит исключить.
Сколько плагинов слишком много для WooCommerce?
Нет фиксированного номера. Сайт с 40 легкими, хорошо закодированными плагинами может превзойти сайт с 10 плохо закодированными. Проверяйте, что на самом деле делает каждый плагин во внешнем интерфейсе, а не ориентируйтесь на определенное количество.
Исправит ли плагин кеширования медленную проверку?
Нет — оформление заказа никогда не должно осуществляться из статического кеша, поскольку оно должно отражать живую корзину и данные сеанса. Плагин кеширования ускоряет работу вашего каталога и страниц контента, а не оформление заказа. Скорость оформления заказа зависит от качества хостинга, обработки сеансов и очистки скриптов.
Когда мне следует рассмотреть возможность полного выхода из WooCommerce?
Когда вы применили исправления хостинга, плагина, базы данных и кэширования, а магазин по-прежнему неэффективен из-за своего трафика и размера каталога, или когда текущая нагрузка по обслуживанию (исправления безопасности, конфликты плагинов, управление сервером) отнимает больше времени, чем оно того стоит по сравнению с управляемой платформой.