Типичный сайт на WordPress обрастает плагинами постепенно: один для хлебных крошек, другой для похожих записей, третий для SEO-мета, и через год их набирается два-три десятка, большая часть функциональности которых используется на 10%, а грузится полностью. Часть этой функциональности пишется нативным PHP в functions.php за несколько строк — без веса чужого кода, обновлений и потенциальных уязвимостей стороннего плагина.
Простая иерархическая навигация для страниц и записей реализуется без зависимостей:
function it_gig_breadcrumbs() { if (is_front_page()) return; echo '<a href="' . home_url('/') . '">Главная</a>'; if (is_singular('post')) { $cat = get_the_category(); if ($cat) echo ' / <a href="' . get_category_link($cat[0]->term_id) . '">' . esc_html($cat[0]->name) . '</a>'; } echo ' / ' . esc_html(get_the_title()); }
Это весь объём кода, который в среднем плагине хлебных крошек обрастает десятками настроек в админке, большинство из которых на практике никогда не меняют со значений по умолчанию.
Блок «похожие материалы» — ещё одна типовая задача для отдельного плагина, которая закрывается через стандартный WP_Query с фильтром по общим тегам текущей записи, без обращения к сторонним сервисам и без дополнительных таблиц в базе данных.
Yoast SEO и Rank Math — мощные инструменты, но для сайта с устоявшейся структурой URL и понятной SEO-стратегией их функциональность в большинстве случаев сводится к паре мета-полей — title и description — и генерации sitemap.xml. Оба закрываются собственными мета-боксами через register_post_meta и выводом тегов в wp_head без необходимости тянуть весь остальной функционал плагина, который на практике не используется — именно так устроена SEO-архитектура этого сайта, через поля it_gig_seo_title/it_gig_seo_description вместо стороннего плагина.
Для нетиповых полей на страницах услуг (иконка технологии, заголовок преимущества) вместо тяжёлых конструкторов полей достаточно прямого вызова register_post_meta и ручного вывода значения через get_post_meta в шаблоне — без слоя абстракции стороннего плагина, который добавляет собственный формат хранения данных и усложняет миграцию в будущем.
Отказ от плагинов — не самоцель. Там, где функциональность сложна и критична для бизнеса — сам WooCommerce как основа интернет-магазина, платёжные шлюзы, требующие сертификации PCI DSS, — переписывать эту логику с нуля не просто дольше, но и рискованнее с точки зрения безопасности и соответствия стандартам. Граница простая: если задача — вывод небольшого куска данных или простая логика, нативный код обычно выгоднее; если задача — сложный процесс с регуляторными требованиями, проверенный плагин снимает ответственность за эти детали.
Отказ от плагинов стоит подтверждать цифрами, а не ощущением «вроде стало быстрее». Количество запросов к базе данных на одну загрузку страницы видно через Query Monitor до и после замены плагина нативным кодом, а TTFB — через curl -o /dev/null -s -w "%{time_starttransfer}n". На практике замена 3–5 лёгких плагинов на нативные функции обычно снижает число SQL-запросов на десятки штук за счёт того, что у каждого плагина свой слой инициализации и собственные обращения к опциям, которые срабатывают на каждой странице независимо от того, используется ли их функциональность на ней вообще.
Удаление плагина с одновременным переносом его функциональности в код темы без миграции уже накопленных данных — например, SEO-заголовков, которые хранились в мета-полях удаляемого плагина, а не в новых кастомных полях, — обнуляет накопленную SEO-работу, если не написать отдельный скрипт переноса значений. Вторая ошибка — перенос в код функциональности, которая должна жить независимо от темы: если сайт сменит тему, а SEO-логика была зашита только в functions.php текущей темы, при смене темы она пропадёт вместе со старой темой. Третья — экономия на тестировании: нативный код, написанный «на коленке» без обработки граничных случаев, которые готовый плагин годами дорабатывал на тысячах сайтов, может сломаться на нетипичном сценарии, который в плагине был давно закрыт. Четвёртая — полный отказ от пересмотра нативного кода наравне с тем, как обновляются плагины: код в functions.php, написанный однажды, точно так же устаревает и должен пересматриваться при обновлении PHP или WordPress, а не считаться написанным один раз и забытым навсегда.
