Функцональность: плагин против темы

Существует множество факторов, которые влияют на производительность сайта под управлением WordPress. Одним из моментов, которые всегда упоминаются "экспертами", является рекомендация избегать плагинов. Они утверждают, что лучше размещать функционал внутри темы вместо активации плагина. Верно ли данное утверждение?

Введение

Когда встает вопрос о производительности сайта под управлением WordPress, на конечный результат оказывают воздействие множество факторов. Данные факторы включают вопросы о том, насколько хорошо написана тема вашего ресурса, какое количество изображений и других ресурсов должно быть загружено, как кешируется ваш сайт, какое качество активированных плагинов, и многое другое. Однако, два фактора имеют нулевое влияние на уровень производительность вашего сайта - это количество плагинов (да, утверждение на 100% серьёзно) и куда включен функционал (как плагин или как часть темы).

В Интернет можно найти множество уроков, в которых имеются строки "... без плагина".  Данная тенденция поддерживает идею о том, что использование плагинов - плохая практика, и она наносит урон производительности. И множество людей полагают, что лучше включать функционал в код темы (вне зависимости от того, написана она собственноручно или куплена), чем полагаться на плагин.

Однако, есть несколько аспектов полагать, что данное утверждение ошибочно. Мы разберем их один за другим. Также рассмотрим утверждение, что лучше использовать лишь несколько плагинов. Оно имеет серьезные контр-аргументы.

Общие заблуждения

1. Функционал лучше размещать в коде темы, чем использовать плагин

Идея, которая стоит за данным утверждением, заключается в предположении, что плагин часто является источником проблем на вашем сайте либо по причине плохого кода, либо из-за конфликтов с другими частями темы. Если плагины часто оказываются плохими, то имеет смысл размещать код (например, контактную форму) в теме, не так ли?

Согласны? А зря! И вот почему:

Во-первых, единственная разница между кодом, который содержится в плагине, и кодом, помещенным в тему, является время выполнения. Активированный плагин загружается и выполняется перед текущей активной темой. То есть нет разницы, где содержится выполняемый код. Как нет влияния на эффективность его выполнения в зависимости от точки его заргузки. Есть отличная диаграмма процесса загрузки ядра WordPress.

Во-вторых, у нас появляется вопрос “Насколько тема хороша для размещения функционала?“ как только мы выяснили , что код плагина и код темы выполняются одинаково. Ответ прост. Так как тема имеет нулевое преимущество пред плагином с точки зрения места размещения функционала, плагин приобретает пару существенных преимуществ. Мы рассмотрим их чуть позже.

2. Код темы выполняется лучше, чем код плагина

Не понятно, откуда появилось данное утверждение. Хотя, можно предположить, что оно родилось под воздействием страха людей перед плагинами и слухами о нарушении плагинами производительности сайтов. Данное утверждение смешно по своей сути. Как уже говорилось выше,  нет разницы (кроме времени выполнения), где располагается код при сравнении плагина и темы.

Если вы поместите функцию в плагин, выполните его и засечете время выполнения, а затем проделаете такие же операции с размещением функции в теме, то обнаружите нулевую разницу. Они будут выполняться с одинаковой скоростью без каких-либо преимуществ в плане производительности.

Таким образом, появляется четкий ответ на вопрос, есть ли несомненное преимущество темы над плагином с точки зрения функционала? Ответ - нет.

Несколько доводов, почему плагин лучше

Теперь следует дать ответ на вопрос, является ли плагин лучшим местом для размещения функционала, чем тема? Отвечая коротко - да, в большинстве случаев - несомненно. Почему? Вот несколько доводов:

1. Разделение кода на блоки является очень хорошей практикой для больших проектов. Так как проект становится легко поддерживать и отлаживать при выявлении проблем. Размещая части функционала в собственных плагинах, вы эффективно создаете блоки. Каждый плагин поддерживается раздельно, что существенно облегчает процесс обнаружения проблем.
2. Если что-то ломается, вы просто деактивируете плагин. Допустим, контактная форма интегрирована в код темы и ломается, подвешивая весь сайт. Что делать? Если у вас недостаточно опыта для замены контактной формы с функционалом, то проблема становится большой. А елси функционал размещается в плагине, вы просто отключаете плагин, а потом включаете его снова, когда проблема решена, или находите новый.
3. Если у вас когда-нибудь возникнет идея поменять тему ( у большинства владельцев сайтов такое происходит рано или поздно), весь пользовательский функционал будет утерян (включая короткие коды),  потому что новая тема не имеет таких функций или выполняет их по-другому. Но если ваши короткие коды или контактные формы находятся в плагинах, то вам нужно будет лишь загрузить их в новую тему и активировать. И все будет работать как и раньше. Разве это не существенный довод в пользу плагинов?
4. Плагины могут обновляться и улучшаться отдельно. Если вы добавляете изменения к теме, то вся тема будет обновляться. Как часто вы встречали добавления пользователей в файлы style.css или functions.php? Если они делают так, то становится невозможно обновление и улучшение темы без ручного перемещения всех изменений. Данное утверждение основано на предположении, что пользователь не создавал дочернюю тему, что большинство владельцев сайтов не делают. Когда улучшения размещаются в плагинах, пользователю остается только обновить их через панель администратора.

Можно продолжать данный список, но и без того понятно, что плагины имеют множество преимуществ в качестве места размещения функционала.

Теперь возникает вопрос, плохо ли использовать большое количество плагинов. Вы наверняка представляете себе, как растет число плагинов, когда каждая важная часть функционала помещается в отдельный блок. Приведет ли такое увеличение к проблемам? Что если плагинов станет 10? Не много? А как насчет 20 или 30? Не экстремально ли?

Нет.

Профессиональные разработчики WordPress делали сайты с дюжинами небольших плагинов, каждый из которых выполнял специальную функцию, без каких либо проблем. В качестве примера можно посмотреть сайт Pippin’s Plugins? на котором активировано около 50 плагинов.

Дело в том, что плагины не вызывают проблем просто потому, что она плагины. Даже когда их активировано 100 или 200 одновременно. Проблемы производительности  возникают с плагинами, которые плохо написаны, а не от их числа. Один плохой плагин может вызвать больше неприятностей, чем 300 простых и хорошо разработанных.

Производительность обычно страдает при загрузке ресурсов или выполнении запросов к базе данных. Поэтому плагины, выполняющие большое количество таких задач влияют на производительность. А плагины, которые не загружают ресурсов и не выполняют запросов к базе данных имеют, практически, нулевое влияние на производительность. Поэтому вы можете использовать 300 плагинов без ущерба для сайта.

Например, WP Candy имеет от 80 до 90 активных плагинов.

Ключевой момент, который надо помнить, что не количество плагинов влияет на производительность, а качество их реализации и тип функционала.

Второй ключевой момент - код плагина выполняется также, как и код темы, поэтому стоит выкинуть идею о том, что лучше размещать функции в теме, чем в плагине. Тема предназначена для управления визуальным представлением сайта, а не для реализации функционала.

И последнее, плагин становится воплощением зла, когда плохо сделан. Только плохой код делает плагин плохим.

• Комментарии