Когда сайт на WordPress начинает тормозить, ломаться после обновлений или пугать разработчика словами «лучше ничего не трогать», одна из первых находок почти всегда одинакова: плагинов слишком много. Сорок, шестьдесят, иногда больше сотни. При этом сама цифра мало что объясняет. Бывают быстрые и стабильные сайты с сорока плагинами и сайты, которые падают от пятнадцати. Много плагинов WordPress становится проблемой, когда никто уже не может сказать, что делает каждый из них, зачем его поставили и что сломается, если его убрать.
Почему дело не в количестве, а в том, что стоит за каждым плагином
Каждый активный плагин добавляет на сайт код, который WordPress загружает при формировании страницы. Одни плагины делают это аккуратно и только там, где нужны. Другие подключают свои скрипты и стили на всех страницах подряд, делают запросы к базе при каждой загрузке или обращаются к внешним сервисам. Кроме того, у каждого плагина свой автор, свой график обновлений и свой взгляд на совместимость с остальными.
Отсюда реальные издержки, которые скрываются за большим списком:
- конфликты при обновлении, когда новая версия одного плагина ломает работу другого;
- лишние скрипты и стили, которые замедляют страницы, хотя нужны на одной-двух из них;
- данные в базе, которые плагины оставляют после себя даже после удаления;
- больше кода, за уязвимостями которого приходится следить.
Отдельно про неактивные плагины. При загрузке страницы WordPress выполняет только активные, поэтому на скорость отключённые плагины не влияют. Но их файлы остаются на сервере и перестают обновляться, а это уже вопрос безопасности. Встроенный инструмент «Здоровье сайта» в разделе «Инструменты» прямо рекомендует удалять неактивные плагины, которые вы не собираетесь использовать.
Поэтому цель чистки звучит так: оставить плагины, каждый из которых отвечает за понятную задачу, и убрать всё, что дублирует, устарело или заменяется более простым способом. Уменьшить количество плагинов при этом получится почти автоматически.
Шаг 1. Составьте таблицу всех плагинов
Чистку начинают с инвентаризации, а не с кнопки «Деактивировать». Откройте список плагинов и перенесите его в таблицу. Для каждого плагина заполните несколько колонок:
- что он делает своими словами, а не по описанию из каталога;
- где на сайте это видно: конкретная страница, форма, блок, раздел админки;
- кто и когда его поставил, если это можно выяснить;
- когда плагин последний раз обновлялся автором;
- активен он или нет.
Уже на этом этапе список обычно распадается на группы. Первая: плагины, без которых сайт не работает, например конструктор страниц, SEO-плагин, формы, магазин. Вторая: дубли, когда две разные вещи делают одно и то же. Типичный пример: два плагина кэширования или SEO-плагин плюс отдельный плагин для карты сайта. Третья: плагины под разовую задачу, которые поставили для переноса сайта, импорта товаров или перегенерации миниатюр и забыли. Четвёртая: плагины, чьи функции уже есть в ядре WordPress. Пятая: мелкие плагины, которые делают одну маленькую вещь и заменяются несколькими строками кода.
Если в колонке «где это видно» вы не можете ничего написать, это кандидат на удаление. Но удалять пока рано: сначала замер и проверка.
Шаг 2. Замерьте, какие плагины реально нагружают сайт
Таблица показывает, что стоит на сайте. Какие плагины тяжёлые, она не показывает. Для этого удобен бесплатный плагин Query Monitor из каталога WordPress.org. Он показывает запросы к базе данных и умеет группировать их по компонентам: какой плагин, тема или ядро за них отвечает. Отдельно видны медленные, повторяющиеся и ошибочные запросы. Ещё он показывает HTTP-запросы к внешним сервисам с указанием компонента, кода ответа и времени, а также подключённые скрипты и стили с зависимостями.
На что смотреть в первую очередь:
- Плагины, которые подключают свои скрипты и стили на страницах, где их функция не используется. Частый случай: плагин формы, который грузится на всех страницах, хотя форма стоит только в контактах.
- Плагины, которые делают внешние HTTP-запросы при загрузке страниц. Если внешний сервис отвечает медленно, страница ждёт вместе с ним.
- Компоненты с большим числом запросов к базе или с повторяющимися запросами.
Замер лучше делать на копии сайта или хотя бы в спокойное время и под учётной записью администратора. Query Monitor это инструмент диагностики: после аудита его стоит отключить и удалить, чтобы он сам не пополнил список лишних плагинов.
Что делать с результатами. Если плагин нужен, но грузит свои файлы везде, сначала загляните в его настройки: у части плагинов есть опция подключать скрипты только на выбранных страницах. Если такой опции нет, разработчик может отключить лишние файлы на остальных страницах штатными функциями WordPress, например wp_dequeue_script и wp_dequeue_style, с условием по типу страницы. Если же плагин тяжёлый, а его задача второстепенная, это сильный аргумент искать ему замену полегче или отказаться от функции совсем.
Шаг 3. Уберите то, что уже умеет ядро WordPress
Многие сайты собирались несколько лет назад, когда для некоторых базовых вещей нужны были отдельные плагины. С тех пор ядро WordPress научилось многому само. Например, в версии 5.5 в WordPress появились:
- встроенная XML-карта сайта для поисковых систем;
- ленивая загрузка изображений, когда картинки подгружаются по мере прокрутки;
- автоматическое обновление плагинов и тем, которое включается прямо из админки;
- обновление плагина или темы загрузкой ZIP-архива;
- паттерны блоков, готовые сочетания блоков для типовых макетов.
Если плагин на сайте стоит ради одной из этих функций, его стоит проверить на замену. С картой сайта нужна аккуратность: популярные SEO-плагины часто формируют собственную карту. Главное, чтобы в итоге работала одна карта и именно её адрес был указан в Google Search Console и Яндекс Вебмастере. Две параллельные карты от разных источников индексации не помогают и только создают путаницу.
Шаг 4. Замените мелкие плагины кодом и положите код в правильное место
В каждом втором списке находятся плагины, которые делают одну крошечную вещь: добавляют код счётчика в шапку, отключают комментарии, меняют логотип на странице входа, перенаправляют одну старую страницу. Каждый такой плагин живёт своей жизнью, обновляется и может конфликтовать с остальными. Часто его функцию можно заменить несколькими строками кода.
Самая частая ошибка здесь в выборе места для этого кода. Файл functions.php основной темы перезаписывается при обновлении темы, и всё добавленное пропадает. Файл functions.php дочерней темы переживает обновления, но работает, только пока активна эта тема: при смене дизайна код придётся переносить.
Для функций, которые должны работать независимо от темы, в WordPress есть must-use плагины. Это PHP-файлы в папке wp-content/mu-plugins. По документации WordPress они загружаются автоматически, их не нужно включать в админке и нельзя отключить оттуда: только удалив файл из папки. В общем списке плагинов они не отображаются, а выводятся в отдельном разделе «Must-Use». WordPress ищет такие файлы только в корне папки mu-plugins, без подпапок, и не показывает для них уведомлений об обновлениях.
Из этих особенностей следуют правила работы. Каждый такой файл должен иметь понятное имя и комментарий в начале: что он делает и кто его написал. Ошибку в mu-плагине нельзя быстро выключить из админки, поэтому перед загрузкой нового файла нужна резервная копия и доступ к серверу. Как организовать копии, мы описывали в статье резервное копирование WordPress.
Не всё стоит переносить в код. Сложные вещи вроде безопасности, резервного копирования, интернет-магазина или мультиязычности лучше оставить хорошо поддерживаемым плагинам. Самописный код, который никто не сопровождает, обходится дороже любого популярного плагина с активным автором.
Шаг 5. Объедините функции, которые разбросаны по разным плагинам
Отдельная категория лишних плагинов появляется, когда одну задачу собирают из нескольких частей. Форма обратной связи на одном плагине, защита от спама на втором, отправка заявок в CRM на третьем. Или конструктор страниц плюс три набора дополнительных виджетов, из которых на сайте используются два виджета.
Порядок работы здесь такой. Для каждой задачи выпишите, из каких плагинов она сейчас собрана. Проверьте, умеет ли основной плагин нужное сам, в текущей версии и на вашем тарифе, если он платный. Если умеет, перенесите настройки и убедитесь, что результат на сайте не изменился. Если в наборе дополнительных виджетов используются один-два элемента, их обычно можно пересобрать стандартными средствами конструктора или заменить одним небольшим блоком.
После объединения функция становится проще в сопровождении: при сбое понятно, где искать причину, а при обновлении не нужно проверять совместимость трёх разных авторов.
Как удалять плагины и не сломать сайт
Техническая часть чистки выглядит просто, но ошибки здесь стоят дорого. Несколько правил, которые экономят часы восстановления.
Работайте на копии. Все эксперименты с отключением плагинов делаются на тестовой копии сайта. На рабочий сайт переносится уже проверенный список изменений.
Отключайте по одному. Отключили один плагин, проверили ключевые страницы, формы, корзину, личный кабинет, мобильную версию. Только после этого берите следующий. Если отключить десять плагинов сразу и что-то сломается, придётся угадывать виновника.
Ищите следы в контенте. Многие плагины выводят свои элементы через шорткоды в тексте страниц. После отключения такого плагина шорткод перестаёт обрабатываться и может показаться на странице как обычный текст в квадратных скобках. Перед удалением поищите шорткоды плагина в записях и страницах.
Помните разницу между деактивацией и удалением. В руководстве для разработчиков плагинов WordPress сказано, что при деактивации плагин должен сбрасывать временные данные вроде кэша и постоянных ссылок, а удалять свои настройки из таблицы опций и собственные таблицы в базе он должен при полном удалении. Это рекомендация авторам, а не гарантия: одни плагины убирают за собой всё, другие оставляют данные в базе навсегда. После чистки стоит проверить базу на остатки удалённых плагинов, особенно таблицы и опции, которые загружаются при каждом запросе. Про то, почему база со временем тяжелеет, есть отдельный материал: оптимизация базы данных WordPress.
Подождите перед окончательным удалением. Отключённый плагин можно оставить на несколько дней, чтобы убедиться, что ничего не всплыло: отчёты, рассылки, задания по расписанию. После этого плагин удаляйте полностью: оставлять его неактивным нет смысла.
Условный пример: корпоративный сайт с 47 плагинами
Пример собирательный, цифры условные. Сайт производственной компании пять лет развивали три разных подрядчика. К моменту аудита на нём стояло 47 плагинов, шесть из них неактивные. Каждое обновление сопровождалось поломкой какой-нибудь страницы, поэтому обновления просто перестали ставить.
После инвентаризации и замеров список разложился так:
- 6 неактивных плагинов удалили сразу, после проверки, что их данные нигде не используются;
- 4 плагина стояли под разовые задачи прошлых лет: перенос сайта, импорт каталога, перегенерация миниатюр;
- 3 плагина дублировали функции ядра и SEO-плагина: ленивая загрузка картинок и отдельная карта сайта;
- 2 из 3 наборов дополнительных виджетов конструктора использовались ради двух элементов, их пересобрали стандартными блоками;
- 5 мелких функций перенесли в один документированный mu-плагин: код счётчиков, отключение комментариев, пару перенаправлений и изменения страницы входа;
- 2 плагина форм и отдельный антиспам заменили одним решением с защитой от спама и передачей заявок в CRM, это минус 2 плагина;
- ещё 6 плагинов давно не обновлялись авторами, а их функции нашлись в уже установленных решениях.
Сама чистка заняла несколько рабочих дней, и большая часть времени ушла на проверку, а не на удаление. После каждого отключённого плагина на тестовой копии проходили один и тот же список: главная, каталог, карточка продукции, форма заявки, отправка заявки в CRM, мобильная версия. Два раза проверка поймала проблему: один из «лишних» плагинов, как выяснилось, выводил блок сертификатов на странице о компании, а другой отвечал за перенаправление со старых адресов каталога. Обе функции перенесли, прежде чем удалять плагины.
В итоге на сайте осталось 19 плагинов, и про каждый в таблице написано, зачем он нужен. Обновления снова ставятся по графику на тестовой копии, а подключаемых скриптов на типовой странице стало заметно меньше. Главная польза при этом организационная: следующий подрядчик получает не «лучше ничего не трогать», а понятный список с описанием.
Как не дать списку плагинов разрастись снова
Чистка без правил на будущее даёт эффект на год-полтора. Потом новый маркетолог ставит плагин для всплывающего окна, подрядчик добавляет ещё один для разовой задачи, и через пару лет список возвращается к прежним размерам. Чтобы этого не случилось, достаточно нескольких договорённостей.
Один владелец списка. Ставить и удалять плагины на рабочем сайте может один человек или одна команда. Остальные приходят к нему с задачей, а не с готовым плагином. Так появляется точка, где задают простой вопрос: а не умеет ли это уже что-то из установленного?
Проверка перед установкой. Перед добавлением нового плагина стоит посмотреть на его страницу в каталоге: когда он последний раз обновлялся, с какой версией WordPress проверена совместимость, сколько у него активных установок и отвечает ли автор на вопросы в разделе поддержки. Плагин без обновлений больше года на сайт компании лучше не ставить, даже если он решает задачу за пять минут.
Запись в таблицу. Каждый новый плагин сразу попадает в таблицу из первого шага: что делает, где используется, кто поставил и зачем. Плагин под разовую задачу получает пометку и дату, к которой его нужно удалить.
Плановый пересмотр. Раз в квартал пройдите по таблице: всё ли ещё нужно, не появились ли дубли, какие плагины перестали обновляться. Это полчаса работы, которые избавляют от повторной большой чистки.
Обновления через тестовую копию. Обновления плагинов сначала ставятся на копию, проверяются по короткому списку ключевых страниц и только потом переносятся на рабочий сайт. Когда плагинов немного и про каждый всё известно, такая проверка занимает минимум времени.
Когда чистку лучше доверить разработчику
Удалить пару неактивных плагинов владелец сайта может сам. Но если на сайте работают магазин, личный кабинет, интеграции с CRM или сложные формы, цена ошибки высока: сломанная корзина или пропавшие заявки за выходные обходятся дороже аудита. То же касается переноса функций в код, где нужен человек, который понимает, как устроены хуки WordPress и что будет при следующем обновлении.
Мы проводим такой аудит на тестовой копии и передаём клиенту таблицу плагинов с решением по каждому: оставить, заменить, объединить, удалить. Если сайт уже оброс плагинами настолько, что проще собрать его заново на аккуратной основе, обсуждаем и этот вариант. Подробнее о подходе на странице разработка сайтов под ключ.
Частые вопросы
Сколько плагинов нормально для сайта на WordPress?
Универсальной цифры нет. Важнее, что делает каждый плагин, насколько аккуратно он написан и поддерживается ли автором. Сайт с тридцатью качественными плагинами может работать лучше, чем сайт с десятью заброшенными.
Замедляют ли сайт неактивные плагины?
При загрузке страниц WordPress выполняет только активные плагины, поэтому на скорость неактивные не влияют. Но их файлы остаются на сервере, и инструмент «Здоровье сайта» рекомендует удалять неактивные плагины, которые вы не планируете использовать.
Удаляются ли данные плагина вместе с ним?
Зависит от автора. Руководство WordPress рекомендует удалять настройки и таблицы плагина при его полном удалении, но не все плагины это делают. После чистки стоит проверить базу данных на остатки.
Куда вставлять свой код вместо мелкого плагина?
Если код связан с оформлением конкретной темы, подойдёт functions.php дочерней темы. Если функция должна работать независимо от темы, удобнее must-use плагин в папке wp-content/mu-plugins. В functions.php основной темы код добавлять не стоит: он пропадёт при обновлении темы.
Нужен ли отдельный плагин для XML-карты сайта?
С версии 5.5 WordPress формирует XML-карту сайта сам, а многие SEO-плагины создают собственную. Отдельный плагин только ради карты обычно не нужен. Важно, чтобы на сайте работала одна карта и именно она была указана в панелях вебмастеров.