Ускорение сайта на Next.js и Payload: как мы сократили время загрузки в 2 раза

Недавно к нам пришел проект с очень понятной формулировкой:

"Очень часто падает сайт."

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

Проект - Berhasm.com, e-commerce сайт на Next.js и Payload CMS.

На первый взгляд можно было пойти стандартным путем: посмотреть картинки, Lighthouse, кеширование, CDN, бандлы, шрифты и lazy loading. Это нормальные шаги. Но здесь было важно сначала не полировать верхний слой, а понять, почему система вообще ведет себя нестабильно.

И причина оказалась глубже.

Внутри одного проекта одновременно использовались Payload CMS v1, v2 и v3.

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

Что было не так

Сам стек был нормальный.

Next.js подходит для e-commerce, SEO-страниц и быстрых интерфейсов. Payload CMS тоже хороший инструмент, особенно когда нужна кастомная структура данных, админка и API под проект.

Проблема была не в технологиях, а в конкретной сборке проекта.

Мы нашли несколько основных причин:

• в проекте одновременно оставались следы Payload CMS v1, v2 и v3;
• зависимости конфликтовали между собой;
• поведение CMS и API было нестабильным;
• инфраструктура была перегружена Docker, Traefik, Cloudflare и лишними промежуточными слоями;
• часть слоев добавляла задержки, но не давала реальной пользы;
• команде было сложно понять, где именно ломается система.

Для пользователя все это выглядит очень просто: он открывает каталог, страница долго думает, иногда открывается, иногда нет.

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

Поэтому задача была не просто "ускорить сайт".

Задача была вернуть проекту предсказуемость.

Почему нельзя было чинить только frontend

Когда сайт тормозит, часто хочется сразу идти в очевидные оптимизации:

• сжать изображения;
• включить кеширование;
• убрать лишний JavaScript;
• оптимизировать шрифты;
• переписать тяжелые компоненты;
• подкрутить CDN.

Но если внутри конфликтуют версии CMS, а запрос проходит через лишние инфраструктурные слои, такие правки дают ограниченный эффект.

В проектах на Next.js + Payload скорость складывается из всей цепочки:

Если один слой настроен плохо, страдает вся цепочка.

Если плохо настроены несколько слоев сразу, сайт начинает вести себя странно: сегодня открывается за 2 секунды, завтра тот же раздел может отвечать 8-12 секунд или вообще упасть.

Вот почему мы начали не с косметики, а с архитектуры.

Что мы сделали

Сначала мы привели CMS-слой к одному нормальному состоянию.

Убрали конфликтующие зависимости, вычистили устаревшие части, проверили совместимость пакетов и зафиксировали рабочую версию Payload. Это скучная, но очень важная работа. Когда CMS отвечает за товары, категории, медиа, локализации и API, она не может жить в состоянии "частично v1, частично v2, частично v3".

Потом упростили инфраструктуру.

Docker, Traefik и Cloudflare сами по себе не плохие. Наоборот, это нормальные инструменты. Но в этом проекте часть слоев добавляла сложность и задержки, не решая реальную задачу. Мы убрали лишнее, сократили путь запроса и сделали поведение системы понятнее.

После этого отдельно посмотрели на метрики:

• ответ сервера;
• время до отрисовки;
• самые тяжелые URL;
• скачки по дням;
• разницу между главной, каталогом и карточкой товара.

Это важно, потому что "сайт медленный" - слишком общее описание. Нужно понимать, где именно медленно: сервер, CMS, API, frontend, изображения или инфраструктура.

Что получилось по цифрам

После работ средняя картина стала заметно спокойнее.

По мониторингу на выбранных страницах:

• средний ответ сервера: 1 724 мс;
• среднее время до отрисовки: 2 074 мс;
• главная /ru: 1 776 мс по ответу сервера;
• главная /en: 1 618 мс по ответу сервера;
• страница товара: около 2 006 мс по ответу сервера;
• тяжелые страницы каталога пока оставались отдельной зоной для следующего этапа.

На графике видно главное: до исправлений были скачки до 12-14 секунд, а после наведения порядка средняя линия стала значительно ниже и спокойнее.

По времени до отрисовки картина похожая:

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

Важно: "ускорили в 2 раза" здесь не значит, что каждая страница стала идеальной.

Это значит, что мы убрали корневую нестабильность и получили нормальную базу. После этого уже можно спокойно заниматься категориями, кешированием, изображениями, Core Web Vitals и SEO-структурой.

Почему это важно для клиента

Для e-commerce скорость - это не абстрактная техническая метрика.

Она влияет на деньги.

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

Для SEO это тоже база.

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

Поэтому этот кейс на самом деле не только про скорость.

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

Что еще осталось на следующий этап

После стабилизации проекта появляются уже более точные задачи.

Для Next.js + Payload мы бы дальше смотрели на:

• кеширование данных для страниц, которые не меняются каждую минуту;
• оптимизацию запросов к Payload;
• уменьшение лишних связанных данных в ответах API;
• отдельную работу с категориями /catalog/women и /catalog/men;
• изображения товаров и адаптивные размеры;
• Core Web Vitals;
• мониторинг ошибок и времени ответа после каждого деплоя.

Например, для каталога важно не тянуть "все данные на всякий случай". Страница категории должна получать ровно те поля, которые нужны для текущего интерфейса: название, slug, цену, превью, доступность, SEO-данные и нужные связи. Все остальное лучше запрашивать отдельно или не запрашивать вообще.

Это уже не аварийная работа, а нормальная плановая оптимизация.

Как понять, что сайту нужен такой аудит

Я бы смотрел на несколько признаков:

• сайт иногда работает нормально, а иногда резко тормозит;
• страницы периодически падают;
• после обновлений появляются случайные баги;
• сборка проходит нестабильно;
• в проекте давно не обновлялись зависимости;
• CMS ведет себя непредсказуемо;
• каталог заметно медленнее главной;
• SEO-страницы плохо индексируются;
• инфраструктура стала сложной, но никто не может объяснить зачем;
• команда боится вносить изменения.

Последний пункт особенно важный.

Если команду пугает любое изменение в проекте, значит проблема уже не только в скорости. Значит системе не хватает предсказуемости.

Что можно заказать в PXSTUDIO

Если сайт на Next.js, Payload или другой headless CMS начал тормозить и падать, лучше начинать с технического аудита.

В PXSTUDIO мы можем:

• найти узкие места во frontend, backend, CMS и инфраструктуре;
• проверить Next.js, Payload, API-запросы, кеширование и сборку;
• убрать конфликтующие зависимости;
• упростить архитектуру;
• настроить мониторинг;
• подготовить сайт к SEO-продвижению;
• отдельно оптимизировать категории, карточки товаров и контентные страницы.

Мы не обещаем волшебную кнопку "ускорить все за один вечер".

Зато можно спокойно разобрать систему, убрать корневые причины и сделать сайт снова рабочим инструментом для бизнеса.

Если хотите посмотреть другие направления, с которыми мы работаем, можно перейти в раздел услуг PXSTUDIO. Часто оптимизация сайта идет рядом с backend-разработкой, SEO-структурой, интеграциями и нормальной поддержкой проекта после запуска.

Источники и полезные ссылки

• Next.js Documentation - официальная документация Next.js по рендерингу, кешированию, маршрутам и оптимизации.
• Next.js Image Optimization - как Next.js работает с изображениями и responsive media.
• Payload Documentation - официальная документация Payload CMS.
• Payload REST API - как Payload отдает данные через REST API.
• Payload Local API - работа с данными Payload внутри server-side кода без лишнего HTTP-слоя.
• Google Core Web Vitals - базовые метрики пользовательского опыта и производительности страниц.
• Google Search Central: Page Experience - как Google описывает page experience и качество страницы.

Вывод

В этом кейсе сайт ускорился почти в 2 раза не из-за одного хитрого параметра.

Мы убрали конфликтующие зависимости, привели Payload к единому состоянию, упростили инфраструктуру и разделили проблемы frontend, backend и CMS.

После этого сайт перестал вести себя непредсказуемо, а у клиента появилась нормальная база для SEO, рекламы и дальнейшего развития e-commerce проекта.

Так что если сайт на Next.js и Payload тормозит, проблема часто не в самом стеке.

Чаще проблема в том, как он собран.