С чего всё началось
До того как я плотно сел на Next.js, я работал с двумя платформами, которые занимают огромную долю рынка в СНГ — 1С-Битрикс и WordPress. Оба инструмента решают задачи бизнеса. Но как только я попробовал современный стек на React + Next.js, обратного пути не было.
Расскажу конкретно, почему.
Проблема №1: спагетти-код
Если вы когда-нибудь открывали шаблон WordPress-темы или компонент Битрикса, вы знаете это ощущение — когда HTML, PHP, SQL-запросы, бизнес-логика и стили перемешаны в одном файле. Это и есть спагетти-код.
Пример типичного WordPress-шаблона:
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<div style="color: red; font-size: 14px;">
<h2><?php the_title(); ?></h2>
<?php $result = $wpdb->get_results("SELECT * FROM wp_posts WHERE..."); ?>
<?php foreach($result as $row): ?>
<p><?php echo $row->content; ?></p>
<?php endforeach; ?>
</div>
<?php endwhile; endif; ?>
Здесь в одном файле — разметка, стили, запрос к базе данных и вывод данных. Через полгода поддержки такого кода вы уже не помните, что делает тот или иной кусок. А если проект передаётся другому разработчику — это отдельная боль.
В Next.js каждый слой отделён: компоненты отвечают за отображение, API-роуты — за логику, а данные приходят через явные функции. Код читается как книга, а не как ребус.
Проблема №2: WordPress везёт с собой «движок»
Когда пользователь открывает страницу на WordPress, происходит следующее:
- Сервер запускает PHP
- PHP поднимает весь WordPress-движок (тысячи строк кода, десятки подключаемых файлов)
- Подключаются активные плагины — каждый со своей логикой
- Выполняются запросы к базе данных
- Собирается HTML
- HTML + CSS + JS отправляются браузеру
Даже если на странице просто три абзаца текста — сервер всё равно поднимает весь этот монолит. Каждый раз. На каждый запрос.
С Next.js статические страницы генерируются один раз при сборке и отдаются мгновенно как готовый HTML. Никакого PHP, никакой базы данных в момент запроса — CDN просто отдаёт файл.
Проблема №3: скорость и Google PageSpeed
Это не просто ощущения — это цифры.
Типичный сайт на WordPress без серьёзной оптимизации получает в Google PageSpeed Insights оценку 40–60 из 100 на мобильных устройствах. Причины:
- тяжёлые плагины добавляют десятки JavaScript-файлов
- стили подключаются глобально, даже если не нужны на конкретной странице
- изображения без оптимизации
- медленный Time to First Byte из-за серверного рендеринга «на лету»
На Битриксе ситуация часто ещё хуже — платформа исторически не оптимизирована под Core Web Vitals.
Сайты на Next.js, которые я делаю, стабильно получают 90–100 баллов на мобильных. Это результат:
- автоматической оптимизации изображений через
next/image - разделения кода на чанки — браузер загружает только то, что нужно для текущей страницы
- статической генерации и кеширования на уровне CDN
- минимального JavaScript на начальной загрузке
Google учитывает Core Web Vitals при ранжировании. Высокий PageSpeed — это не только UX, это прямо влияет на позиции в поиске.
Поддержка кода: год спустя
Ещё один момент, который понимаешь только на практике — поддержка проекта через год.
На WordPress и Битриксе обновление плагина или ядра платформы регулярно ломает что-то на сайте. Конфликты плагинов, устаревшие API, хуки, которые перестали работать — это реальность любого долгосрочного проекта на этих платформах.
В Next.js зависимости явные и управляемые. Компоненты изолированы. TypeScript ловит ошибки ещё до деплоя. Если через год нужно добавить новый раздел или изменить логику — понятно, куда идти и что менять.
Когда WordPress или Bitrix всё же оправданы
Буду честен: есть сценарии, где CMS-платформы имеют смысл.
- Клиент сам хочет редактировать контент через визуальный редактор без разработчика
- Нужен быстрый старт с большим количеством готовых плагинов
- Команда уже знает платформу и нет ресурсов на переобучение
Но для проектов, где важны скорость загрузки, SEO, масштабируемость и качество кода — Next.js выигрывает. Именно поэтому все свои проекты я делаю на нём.
