𝗛𝗼𝘄 𝗪𝗲 𝗖𝘂𝘁 𝗦𝗹𝗼𝘄 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲𝘀 𝗯𝘆 𝟴𝟬%

Subito is a top marketplace in Italy. We handle thousands of requests every minute. Our ad detail page is vital for SEO and revenue.

We moved this page from Next.js Pages Router to App Router. We did not stop product work to do this. We moved in small steps.

Here is how we did it.

𝗧𝗵𝗲 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵

We used an incremental strategy. We added the App Router tree alongside the old Pages Router. This let us ship new features while we migrated.

We used Server Components to own data fetching. This removed the need to pass data through many layers. We also created a Data Access Layer. This made sure we only fetch data once per request.

We used Suspense and the use() hook to enable HTML streaming. This shows a skeleton screen while data loads. The user sees the page faster.

𝗧𝗵𝗲 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀

Problem 1: HTTP 410 Gone Search engines need a 410 status when a page is permanently removed. The App Router does not have a built-in way to send this. We solved this using our Express server. The server intercepts the response and changes the status code.

Problem 2: HTML Streaming We found that our loading skeletons did not appear. The page stayed blank for seconds.

We discovered that Nginx and Akamai were buffering our responses. If the CDN buffers the HTML, streaming fails. We had to turn off buffering in Nginx and apply custom settings in Akamai. Once we fixed this, content streamed to the user perfectly.

𝗧𝗵𝗲 𝗥𝗼𝗹𝗹𝗼𝘂𝘁

We rolled out in two phases to protect our SEO.

Phase 1: We moved traffic to the App Router but kept streaming off. We did this one category at a time.

Phase 2: We enabled HTML streaming. We tested this on small categories first. Our SEO team monitored rankings for two weeks before we moved to the next category.

𝗧𝗵𝗲 𝗥𝗲𝘀𝘂𝗹𝘁𝘀

The results were huge. Before the migration, up to 40% of our responses were slow. After the migration, slow responses dropped by 80%.

Most pages now load in under 500ms.

𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀

• Use parallel routing to migrate without stopping feature work.
• A custom server layer helps you control traffic and fix framework gaps.
• Streaming requires configuration at every layer. Check Nginx and your CDN.
• Test your SEO metrics during the rollout.

Как мы сократили количество медленных ответов на 80%, перейдя на Next.js App Router

В нашем приложении мы столкнулись с серьезной проблемой: пользователи жаловались на медленную работу. Анализ метрик показал, что значительная часть ответов была «медленной», что негативно сказывалось на пользовательском опыте.

В этой статье мы расскажем, как миграция на Next.js App Router помогла нам сократить количество медленных ответов на 80%.

Проблема: Клиентский фетчинг и «водопады» (waterfalls)

До перехода на App Router мы использовали Pages Router и полагались на клиентский фетчинг данных. Это приводило к нескольким критическим проблемам:

1. Waterfall-эффект: Сначала браузер должен был загрузить JavaScript-бандл, затем выполнить код, который инициировал запросы к API. Только после получения данных начинался рендеринг контента. Это создавало цепочку последовательных задержек, где каждый следующий запрос ждал завершения предыдущего.
2. Огромные JS-бандлы: Большинство библиотек для получения данных и управления состоянием отправлялось клиенту, что увеличивало время загрузки страницы и нагрузку на устройство пользователя.
3. Задержка гидратации: Пользователи видели пустую страницу или индикаторы загрузки (spinners) слишком долго, пока React не «оживлял» (hydrated) страницу.

Решение: Next.js App Router и Server Components

Переход на App Router позволил нам кардинально изменить подход к получению данных и рендерингу.

1. React Server Components (RSC)

С использованием Server Components мы перенесли логику получения данных с клиента на сервер. Теперь запросы к базе данных или API происходят непосредственно на сервере, в той же среде, где формируется HTML.

Преимущества:

• Нулевой JS на клиенте: Код, используемый для получения данных, больше не отправляется в браузер. Это значительно уменьшает размер бандла.
• Устранение waterfall-эффектов: Мы можем выполнять запросы параллельно или на сервере, минимизируя количество сетевых прыжков (round-trips) между клиентом и сервером.

2. Streaming и Suspense

Вместо того чтобы ждать загрузки всех данных перед отправкой страницы, мы начали использовать потоковую передачу (streaming) с помощью компонента Suspense.

Это позволило нам:

• Сразу отправлять пользователю основную структуру страницы (shell).
• Постепенно подгружать тяжелые компоненты по мере готовности данных.
• Улучшить показатель Time to First Byte (TTFB) и визуальное восприятие скорости.

3. Улучшенное кэширование

App Router предоставляет мощные механизмы кэширования на уровне запросов и сегментов маршрутов. Это позволило нам избежать повторных запросов к одним и тем же данным, значительно снижая нагрузку на наши API и сокращая время ответа.

Результаты

После завершения миграции мы зафиксировали впечатляющие результаты:

• Медленные ответы: Количество сократилось на 80%.
• Производительность: Пользователи стали ощущать приложение как гораздо более быстрое и отзывчивое.
• Нагрузка на клиент: Размер передаваемого JavaScript значительно уменьшился.

Заключение

Миграция на Next.js App Router не была простой задачей, так как потребовала переосмысления архитектуры нашего приложения. Однако результат того стоил: мы получили гораздо более производительную систему, что напрямую отразилось на удовлетворенности наших пользователей.