Когда клиент пришёл с просьбой ускорить сайт на WordPress, мы сначала предложили оптимизацию плагинов и кэширование. После двух недель работы Lighthouse поднялся с 38 до 56. Этого было мало.
Тогда мы предложили переписать фронт на Next.js, оставив WordPress как headless CMS. В этой статье — что получилось, что пошло не так и как мы это починили.
Почему WordPress перестал тянуть
На сайте было 12 активных плагинов, каждый подгружал свои стили и скрипты. Совокупный вес главной страницы — 4.7 МБ, время до первого контента — 5.2 секунды на 4G.
Простая оптимизация (минификация, кэш, отложенная загрузка) дала +18 пунктов в Lighthouse. Но фундаментальная проблема — рендеринг на PHP с десятками запросов в БД — оставалась.
Что мы посчитали перед миграцией
- Стоимость поддержки WP с регулярными обновлениями плагинов
- Риски ломки сайта при апдейтах ядра WordPress
- Время разработчика на каждую новую фичу — в 2–3 раза больше, чем на Next.js
- Стоимость хостинга PHP-стэка vs Node.js
«Решение мигрировать стало очевидным, когда мы прикинули: за два года старый стэк обойдётся дороже, чем переписать всё с нуля».
Как переносили данные
WordPress оставили под капотом как headless CMS. Контент-менеджеры продолжили работать в привычной админке, а Next.js при сборке тянет посты через REST API.
// app/[slug]/page.tsx
export async function generateStaticParams() {
const posts = await fetch(`${API}/posts?per_page=100`)
.then(r => r.json());
return posts.map((p) => ({ slug: p.slug }));
}
export const revalidate = 3600; // ISR раз в часИспользуем ISR с ревалидацией раз в час — этого хватает для контентного сайта. Если редактор хочет ускорить публикацию, есть webhook на ручную ревалидацию страницы.
Что в итоге получили
Lighthouse Performance — 96 на десктопе, 89 на мобильном. LCP — 1.2 секунды. Время сборки сайта — 4 минуты на 800 страницах. Стоимость хостинга упала с 9 800 ₽ до 2 200 ₽ в месяц.
Самое неожиданное — контент-команда не заметила миграцию. Они продолжили работать в WP-админке, как и раньше, просто теперь сайт стал быстрым.