Плагины WordPress - самый быстрый способ добавить сайту нужную функцию и самый быстрый способ положить его на лопатки. За практику я видел сайты с 60 активными плагинами, которые грузились за секунду, и интернет-магазины с десятью плагинами, которые тормозили на каждой странице. Дело не в цифре, а в том, как выбрать плагины wordpress под конкретную задачу и не тащить на сайт код, который никто не поддерживает. Ниже разбираю, сколько плагинов реально нужно, на что смотреть перед установкой каждого и когда проще заказать кастомную доработку, чем городить очередной модуль ради одной функции.
Сколько плагинов можно ставить на WordPress без потери скорости
Жёсткого лимита нет, и любой совет вида «не больше 20 плагинов» - упрощение. Скорость сайта зависит не от количества установленных модулей, а от того, сколько кода реально выполняется на каждой странице, сколько запросов к базе плагин делает и как часто дёргает внешние API.
На практике я работал с интернет-магазином на WooCommerce, где стояло 34 активных плагина: эквайринг, доставка СДЭК, SEO, кэш, форма обратной связи, аналитика, резервное копирование и десяток мелких утилит. Сайт открывался за 1,2 секунды на мобильном. На другом проекте с 9 плагинами страница грузилась 4 секунды - там стоял платный конструктор страниц, три плагина для слайдеров разных лет установки и один плагин, дублировавший функцию темы.
Ориентир, которым пользуюсь сам:
- для визитки или блога хватает 8-12 плагинов: SEO, кэш, безопасность, форма, резервные копии, оптимизация изображений;
- для интернет-магазина на WooCommerce реалистично 15-25: сюда добавляются эквайринг, доставка, учёт остатков, email-уведомления;
- для сайта с личным кабинетом или интеграциями с CRM счёт может уйти за 30, и это нормально, если каждый плагин закрывает свою задачу и не дублирует соседний.
| Тип сайта | Плагинов в среднем | Обязательные категории |
|---|---|---|
| Визитка, блог | 8-12 | SEO, кэш, безопасность, форма, бэкап |
| Интернет-магазин на WooCommerce | 15-25 | Эквайринг, доставка, учёт остатков, уведомления |
| Сайт с личным кабинетом, CRM-интеграцией | 20-35 | Авторизация, API-коннекторы, кастомные поля |
Как выбирать плагины WordPress по репутации и метрикам каталога
Перед установкой смотрю на карточку плагина в официальном каталоге, а не на первые строчки поиска в Google. Там есть конкретные цифры, а не маркетинг.
Проверяю по порядку:
- дата последнего обновления - если плагин не обновлялся больше 12 месяцев, а тем более больше 2 лет, не ставлю его на прод, даже если функция подходит идеально;
- совместимость с текущей версией WordPress, указанная разработчиком, а не с той, что была год назад;
- количество активных установок: меньше 1000 для типовой задачи вроде формы, попапа или слайдера обычно значит, что плагин плохо протестирован на разных конфигурациях;
- количество отзывов и разброс оценок - 4,8 звезды при 15 отзывах говорит меньше, чем 4,3 звезды при 2000;
- активность в форуме поддержки - отвечает ли автор на вопросы за последние пару месяцев или тема висит без ответа полгода.
Что говорит changelog о качестве кода
Changelog читаю не для галочки. Если в истории версий регулярно встречаются формулировки вроде «security fix» без деталей, это повод насторожиться: значит, уязвимости уже находили, и вопрос в том, насколько быстро автор реагирует в следующий раз. Плагин, где в changelog за год пять записей «minor fixes» и ни одной по существу, обычно просто заброшен и обновляется для галочки в репозитории.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
На что смотреть в коде и правах доступа плагина
Каждый плагин, который пишет в базу, ходит во внешний API или добавляет cron-задачу, увеличивает поверхность для ошибок и атак. Перед установкой на прод открываю код хотя бы поверхностно, если плагин не из числа проверенных временем вроде Yoast, WooCommerce или Wordfence.
Что смотрю:
- обращается ли плагин к внешним серверам и зачем: аналитика, лицензионная проверка, обновления через сторонний CDN;
- пишет ли в wp_options огромные сериализованные массивы - частая причина раздутой базы у конструкторов страниц и SEO-модулей;
- добавляет ли собственные cron-задачи и с какой частотой они запускаются - плагин бэкапа, который проверяет изменения каждые 5 минут, ощутимо грузит хостинг;
- куда сохраняет резервные копии и данные клиентов. Если плагин интеграции с CRM или формой заказа выгружает персональные данные покупателей в зарубежное облако, это прямой риск по 152-ФЗ, поэтому бэкапы и выгрузки с данными клиентов держу только на серверах в России.
Плагины, которые дублируют друг друга и создают конфликты
Самая частая причина тормозов и белых экранов, которую вижу на чужих проектах, это не «слишком много плагинов», а два плагина, решающих одну и ту же задачу.
| Категория | Типичный конфликт | Что делать |
|---|---|---|
| SEO | Yoast SEO и Rank Math одновременно ставят дублирующиеся мета-теги и sitemap | Оставить один, второй удалить полностью, не деактивировать |
| Кэширование | Два кэширующих плагина конфликтуют за один и тот же .htaccess или конфиг Nginx | Один плагин кэша плюс настройки на уровне хостинга |
| Формы | Contact Form 7 и встроенные формы конструктора страниц дублируют скрипты валидации | Выбрать одну систему форм для всего сайта |
| Безопасность | Два security-плагина одновременно сканируют файлы и грузят CPU при каждом запросе | Один плагин безопасности плюс firewall на уровне хостинга |
Деактивированный, но не удалённый плагин - тоже риск: его файлы остаются на сервере и могут содержать уязвимость, даже если код не выполняется. Раз в квартал прохожу по списку установленных плагинов и удаляю всё, что не использовалось больше месяца.
Проверка совместимости перед обновлением платных решений
Платный плагин эквайринга или доставки почти всегда завязан на конкретную версию WooCommerce, а разработчики закрытых решений обновляются медленнее, чем ядро WordPress.
На одном проекте стоял форк плагина эквайринга Т‑Банка для WooCommerce, который два года не обновлялся. После планового обновления WooCommerce до 8.x форма оплаты на мобильных перестала передавать сумму заказа, пришлось откатывать WooCommerce и ставить актуальную версию плагина эквайринга с сайта банка. С тех пор любое крупное обновление сначала прогоняю на staging-копии сайта, а не на проде: клонирую базу и файлы, обновляю там, проверяю оформление заказа и оплату вручную и только потом переношу изменения на боевой сайт.
То же самое с плагином доставки СДЭК: расчёт тарифов завязан на API, который периодически меняет формат ответа, и плагин, не обновлявшийся полгода, начинает молча показывать неверную стоимость доставки в корзине. Проверяю дату последнего релиза перед каждым обновлением WooCommerce, а не только при установке.
Когда плагин не решение и нужна кастомная доработка
Готовый плагин закрывает типовую задачу для тысяч разных сайтов сразу, поэтому в нём всегда есть лишние настройки, хуки и код, которые конкретному проекту не нужны. Если задача узкая, например свой алгоритм расчёта доставки под определённые зоны, нестандартная интеграция с CRM или логика скидок, которую не поддерживает ни один плагин из каталога, универсальное решение либо не справится, либо потребует пять дополнительных плагинов ради одной функции, а это как раз то, что убивает скорость сайта.
В таких случаях я обычно делаю разработку сайта на WordPress под конкретные задачи заказчика вместо установки очередного универсального модуля: пишу код, который делает ровно то, что нужно, без лишних настроек и внешних зависимостей. Это дороже разового плагина за 2 000 рублей, зато не тянет за собой чужой код, который через год перестанут обновлять.
Корпоративный сайт, каталог, блог
Фронтенд + Бэкенд
от 60 000 ₽
Подробнее →Частые вопросы
Сколько плагинов оптимально для интернет-магазина на WordPress?
Для WooCommerce реалистичный диапазон 15-25 плагинов: эквайринг, доставка, SEO, кэш, безопасность, учёт остатков и уведомления. Больше не страшно, если каждый плагин обновляется и не дублирует функцию соседнего, меньше - если приходится жертвовать нужным функционалом ради красивой цифры.
Как проверить плагин на вредоносный код перед установкой?
Для плагинов из официального каталога смотрю дату обновления, количество активных установок и changelog. Для платных решений из закрытых источников открываю файлы плагина через редактор хостинга и ищу подозрительные вызовы вроде eval, base64_decode или обращений к незнакомым доменам. Если сомневаюсь, ставлю плагин сначала на staging-копию сайта и смотрю, какой трафик он генерирует.
Что делать, если после установки плагина сайт стал медленнее?
Сначала измеряю скорость до и после через любой инструмент вроде PageSpeed Insights, чтобы убедиться, что дело именно в новом плагине. Дальше смотрю, сколько запросов к базе добавляет плагин на страницу, и проверяю его cron-задачи. Если замедление подтвердилось и альтернативы у плагина нет, чаще проще написать узкий кастомный скрипт под конкретную функцию, чем оставлять тяжёлый универсальный модуль.
Нужно ли удалять неактивные плагины или достаточно деактивировать?
Деактивация не убирает файлы плагина с сервера, а значит уязвимость в его коде остаётся доступной для сканеров, даже если сам плагин не выполняется. Если плагин не понадобился в течение месяца, удаляю его полностью вместе с настройками, а не оставляю деактивированным про запас.