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

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.

𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀

Comment nous avons réduit les réponses lentes de 80 % en migrant vers le Next.js App Router

Les temps de réponse lents sont un tueur silencieux pour l'engagement des utilisateurs et les taux de conversion. Chez Subito, nous avons été confrontés à ce défi : notre application devenait de plus en plus lourde, entraînant des temps de chargement de plus en plus longs qui affectaient l'expérience de nos utilisateurs.

Après une analyse approfondie, nous avons identifié que le principal coupable était notre architecture basée sur le Pages Router de Next.js, qui nous obligeait à envoyer une quantité massive de JavaScript au client pour l'hydratation.

La solution ? Une migration complète vers le Next.js App Router. Voici comment cette transition a transformé nos performances, réduisant nos réponses lentes de 80 %.

Le problème : Le goulot d'étranglement du Pages Router

Avec le Pages Router, la plupart de nos composants étaient des composants client. Cela signifie que pour chaque page, le navigateur devait :

  1. Télécharger un gros bundle JavaScript.
  2. Exécuter ce JavaScript pour construire l'interface utilisateur (UI).
  3. Effectuer l'hydratation pour rendre la page interactive.

Ce processus créait un "waterfall" (effet cascade) de requêtes de données et une charge CPU importante sur le client, ce qui ralentissait considérablement le Time to Interactive (TTI).

La solution : L'App Router et les React Server Components

Le passage à l'App Router nous a permis d'adopter les React Server Components (RSC). Contrairement aux composants client, les RSC sont exécutés exclusivement sur le serveur.

1. Réduction drastique de la taille du bundle

En utilisant les Server Components, nous avons pu déplacer la logique de récupération de données et le rendu de l'UI lourde directement sur le serveur. Le résultat est immédiat : le navigateur ne reçoit que le HTML nécessaire et un fragment de JavaScript minimal.

Nous avons constaté une réduction massive de la quantité de JavaScript envoyée au client, ce qui a accéléré le temps de chargement initial.

2. Streaming et Suspense : Une meilleure perception de la vitesse

L'une des fonctionnalités les plus puissantes de l'App Router est le Streaming. Grâce à l'intégration de React Suspense, nous ne sommes plus obligés d'attendre que l'intégralité des données d'une page soit récupérée avant d'envoyer quoi que ce soit au client.

Nous pouvons désormais "streamer" les parties critiques de la page (comme la navigation et le contenu principal) immédiatement, tout en affichant des états de chargement (loading.js) pour les composants plus lents (comme les tableaux de bord ou les listes complexes). Cela améliore considérablement le First Contentful Paint (FCP) et la perception de vitesse par l'utilisateur.

3. Récupération de données optimisée (Fin du Waterfall)

Avec le Pages Router, nous devions souvent récupérer les données dans getServerSideProps, ce qui créait un goulot d'étranglement : si une page avait besoin de plusieurs sources de données, elles étaient souvent récupérées de manière séquentielle.

Avec l'App Router, nous pouvons effectuer des appels de données en parallèle directement dans nos composants serveurs en utilisant des async/await. Cela élimine les cascades de requêtes et réduit le temps total de génération de la page.

Les résultats

Les résultats de notre migration ont dépassé nos attentes :

Conclusion

La migration vers le Next.js App Router n'a pas été qu'une simple mise à jour technique ; c'était un changement de paradigme dans notre manière de construire des interfaces. En exploitant la puissance des Server Components et du Streaming, nous avons pu offrir une expérience fluide, rapide et hautement réactive à nos utilisateurs.

Si votre application Next.js commence à montrer des signes de ralentissement, il est peut-être temps d'envisager le passage à l'App Router.