On a reconstruit notre site agence en Next.js 16 : INP/LCP avant et apres

TL;DR. On a reconstruit notre site agence sur Next.js 16 App Router (avec le nouveau mode webpack), ajoute les reveals stagger GSAP et le smooth scroll Lenis, et regarde le LCP passer de 2,8s a 1,4s et l'INP de 280ms a 145ms. Le takeaway n'est pas "utilisez le nouveau truc" — c'est qu'App Router permet de streamer le contenu de facon predictible et de garder l'INP sous le seuil de 200ms meme avec des animations lourdes.

Pourquoi reconstruire

L'ancien site etait un build Next.js 14 Pages Router. Assez rapide sur Lighthouse, lent sur la 4G marocaine reelle. L'INP etait la douleur — chaque interaction de navigation avait un delai de ~280ms parce que le bundle faisait tourner un seul gros client component.

La nouvelle realite Core Web Vitals compte : INP a remplace FID en mars 2024 et la mise a jour Google de mars 2026 a augmente le poids des CWV. On avait besoin d'etre dans la bande verte — LCP sous 2,5s, INP sous 200ms, CLS sous 0,1 — sans sacrifier le type d'animation editoriale qu'on vend aux clients.

Ce qui a change (les chiffres)

Metrique	Avant (Pages, v14)	Apres (App Router, v16)
LCP (75e percentile, vrais users)	2,8s	1,4s
INP	280ms	145ms
CLS	0,06	0,02
JS total (gzip, page initiale)	187 ko	114 ko
Temps d'hydratation sur Android a 200 EUR	~1,4s	~620ms

Chiffres du dashboard Vercel Analytics 75e percentile, mai 2026 vs fevrier 2026. Mobile uniquement.

Ce qui a vraiment bouge

Server Components par defaut. Les pages marketing (home, services, blog, about) sont toutes RSC. Seuls le widget concierge, la dropdown header, et le formulaire brief sont client. Le JS client a chute de 39%.
Mode webpack (flag --webpack). Le webpack de Next.js 16 est plus agressif sur le tree-shaking + code-splitting que le mode dev turbopack par defaut. On echange un peu de vitesse de dev-server contre des bundles de prod plus petits.
GSAP charge seulement la ou il est utilise. Les reveals stagger sont cables via un fin client component (GsapStagger) qui enregistre ScrollTrigger en lazy. Pas de GSAP sur les routes qui n'en ont pas besoin.
Lenis smooth scroll, scope. Un SmoothScrollProvider a la racine, mais c'est un client component de la taille d'un timbre — Lenis est lazy-importe. Ne bloque pas le LCP.
Strategie images. Les images du hero et des cartes tier sont en CSS background-image (decoratives). Pour les heros case study et les couvertures blog on utilise next/image avec priority sur celle au-dessus du fold.

Ce qui a casse

Deux choses nous ont mordu :

1. Mismatches d'hydratation avec la persistance theme. next-themes plus le smooth-scroll provider double-renderaient au premier paint. Resolu en montant le theme provider dans une Suspense boundary et en gatant le cablage smooth-scroll sur un useEffect.

2. Timing Lenis + GSAP. Si les deux s'initialisent sur la meme frame, GSAP peut installer les handlers ScrollTrigger avant que Lenis ne reroute les events scroll. Solution : enregistrer Lenis d'abord, puis GSAP au prochain animation frame.

Ce qu'on ferait differemment

On a sur-investi dans le polish d'animation avant de mesurer l'INP. Le plus gros gain est venu de la restructure RSC, pas d'un tweak d'animation. Si on refaisait : livrer la migration App Router ennuyeuse d'abord, mesurer, puis ajouter l'animation.

Aussi : se mettre sur Vercel Analytics ou PageSpeed Insights des le jour 1. L'INP est dur a fixer retroactivement parce que le pire offender est generalement un seul composant que personne n'a flagge.

Si vous voulez ca pour votre site

C'est exactement ce que livre notre ligne Web. Spark et Signal viennent App Router-par-defaut avec la meme discipline CWV. Pour du travail de performance plus agressif — un SaaS lourd ou une migration e-commerce — c'est un engagement Studio.