Je me souviens d’un projet livré en urgence pour une fin de trimestre. Un site React taillé sur mesure, design impeccable, SSR activé, zéro plugin superflu. Le rapport Lighthouse affichait 98 en Performance sur la fiche produit de test. Une semaine plus tard, le client nous avertit que son taux de conversion mobile a chuté de 17 %. Le LCP mesuré par le Chrome UX Report oscillait autour de 4,8 secondes sur desktop, et dépassait 6 secondes sur mobile. Le code n’était pas sale. Il était juste aveugle aux réalités du chemin critique dans un navigateur, et Googlebot le ressentait exactement comme un visiteur avec une 4G poussive.
Quand on parle développement de site sur mesure, on vend souvent un argument massue : plus de payload inutile, pas de couche de thème qui alourdit, pas de SQL appelé vingt fois pour générer la même page. Ce contrôle technique est réel. Mais il devient un piège si on croit qu’il suffit à faire disparaître les problèmes de Core Web Vitals. Le métier de dev ne consiste pas à écrire un joli code, il consiste à décider ce qui se charge, quand et dans quel ordre. Et ces décisions, un CMS ne les prend pas à votre place, c’est vrai. Mais un framework JavaScript ne les prend pas non plus.
Le sur mesure n’achète pas la vitesse
Un site codé from scratch peut mobiliser 300 Ko de JavaScript de trop parce que le développeur a importé une librairie d’animation de 80 Ko pour un effet de hover sur trois boutons. Un thème WordPress mal optimisé vous fera un LCP à 3,5 secondes. Un site sur mesure mal architecturé vous fera un LCP à 5 secondes, sans la béquille d’un plugin de cache pour limiter la casse.
Le LCP n’est pas dans le framework, il est dans le chemin critique
Lighthouse vous dit que le plus grand élément affiché met 1,8 seconde à apparaître, score qui passe au vert, tout va bien. Sauf que l’outil utilise une simulation de réseau et un CPU bridé qui ne reflètent pas la réalité d’un mobile bas de gamme dans le métro. Sans les données de terrain de la Search Console, le score Lighthouse ne dit rien de ce que vivent vos utilisateurs.
La règle qui change tout : sur un site sur mesure, chaque fichier, chaque police, chaque appel API doit passer devant une question simple. Est-ce qu’il retarde le rendu du contenu visible à l’écran ? Les développeurs ont tendance à traiter le preload des polices, le fetch priority des images et le defer des scripts comme des optimisations de fin de chantier. Or un framework comme Next.js ou Remix ne devine pas quelle image sera votre LCP. Il applique des heuristiques, parfois bonnes, parfois à côté. Le seul moyen d’avoir un LCP sous 2 secondes de manière fiable sur un site custom, c’est d’aller placer manuellement les attributs fetchpriority="high" sur l’image qui porte le LCP, prédécouper le CSS critique dès le build, et vérifier dans les Web Vitals réelles que le changement a tenu.
J’ai déjà consacré un article complet à la mesure et au suivi de ces signaux, si vous voulez sortir du tunnel des notations synthétiques pour entrer dans le vrai pilotage par les données terrain : lire la méthode d’analyse des Core Web Vitals en continu.
Piège n°1 : le bundle JavaScript qui annule l’avantage du SSR
Le serveur envoie du HTML complet, Googlebot indexe sans problème, on pense être à l’abri. Puis le navigateur reçoit le bundle JavaScript, le parse, l’exécute, attache tous les écouteurs d’événements. Pendant ce temps, le thread principal est saturé, l’utilisateur tape sur « Ajouter au panier » et rien ne se passe. L’INP explose et personne n’avait vu venir le coup.
La sortie se prend en amont : segmenter le bundle, utiliser des Server Components pour ne pas envoyer tout le JavaScript au client, différer l’hydratation des composants non critiques.
Piège n°2 : l’INP, cet angle mort du code custom
On te dira que l’INP ne concerne que les sites interactifs. C’est faux, et voici comment on l’a mesuré : sur une fiche produit statique en apparence, j’ai vu un INP à 340 ms sur mobile parce qu’un simple champ de recherche interne déclenchait une requête autocomplete à chaque frappe sans debounce, bloquant le thread principal pendant que le navigateur peinait à maintenir le scroll fluide. Le code était « léger » selon Lighthouse, parce que Lighthouse n’interagit pas comme un utilisateur pressé.
Un site sur mesure expose souvent une logique métier complexe directement dans le front-end : validateurs de formulaire synchrones, recalculs de panier en temps réel, animations conditionnelles au scroll. Si la gestion de l’état n’est pas pensée pour minimiser les rendus inutiles, chaque saisie utilisateur provoque une cascade de re-rendus. Un choix de librairie de gestion d’état comme Zustand, beaucoup plus légère et performante que des alternative plus lourdes, peut réduire significativement ce bavardage interne. Nous avons détaillé pourquoi cette approche se distingue sur des applications React modernes dans un article dédié : comment Zustand simplifie la gestion d’état sans plomber le rendu.
La clé pour un INP acceptable (sous 200 ms dans le pire cas) sur un site sur mesure : ne jamais viser un framework « qui fait tout ». Viser plutôt une composition d’outils où chaque élément est justifié par son coût sur le thread principal. Le sur mesure devient alors un allié, parce qu’il permet de retirer ce qui ne sert pas, alors qu’un CMS vous impose parfois 45 Ko de JavaScript pour une fonctionnalité que vous n’utilisez jamais.
Reprendre le contrôle avec une approche data-driven
Le développement sur mesure donne un avantage définitif : vous possédez le pipeline. Vous pouvez brancher un outil de Real User Monitoring comme Web Vitals sur chaque page, segmenté par type de client ou par devise, et voir en temps réel si votre dernière PR a dégradé l’INP de 12 % sur les mobiles milieu de gamme. Vous pouvez corréler les déploiements avec les courbes de la Search Console, mesurer l’impact d’un diff de 27 lignes sur le taux de rebond. Ce retour d’expérience immédiat, un CMS ne vous le donne pas sans un effort d’intégration conséquent.
Cette boucle de feedback exige une discipline que peu d’équipes adoptent : traiter les métriques de performance comme des critères d’acceptation non négociables dans chaque sprint. Quand vous retirez une librairie de composants pour la recoder sur mesure, vous gagnez peut-être 20 Ko. Si vous le faites sans suivre l’INP et le LCP avant/après sur un échantillon de sessions réelles, vous travaillez à l’aveugle.
Les IDE modernes, qu’on parle de Cursor ou de Claude Code, accélèrent la rédaction de code, mais aucun ne vous dira que votre nouvelle fonction computeDiscounts se met à tourner à plus de 50 ms par rendu et fait passer l’INP de 180 à 290 ms. Pour une comparaison plus large des environnements actuels : comparer les IDE pour ne pas coder plus vite au détriment du rendu.
📌 À retenir : Un site sur mesure donne le contrôle total sur le chemin critique, mais ce contrôle ne vaut que si vous l’exercez avant la mise en ligne, pas une fois les pages indexées.
Questions fréquentes
Est-ce qu’un site en sur mesure utilisant WordPress en headless règle les problèmes de Core Web Vitals ?
Pas automatiquement. Vous retirez la couche de thème, mais vous ajoutez une dépendance à une API REST ou GraphQL. Si le back-end met 400 ms à répondre à chaque requête côté serveur pour composer une page, votre TTFB restera élevé, et le LCP s’en ressentira malgré un front-end optimisé.
À partir de combien de pages vaut-il mieux un code custom qu’un CMS ?
La question n’est pas le volume de pages mais la complexité des interactions. Un site vitrine de 5 pages avec une logique métier simple n’aura aucun gain de performance à être codé from scratch. Dès que vous devez afficher des données en temps réel, personnaliser le panier sans rafraîchissement, ou servir des contenus dynamiques avec un cache très granulaire, le sur mesure vous évite de contourner les limitations d’un CMS.
L’INP peut-il vraiment être mesuré sur un site sur mesure sans outil payant ?
Oui, l’API web-vitals de Google, intégrée dans votre bundle en moins de 2 Ko, vous remonte les valeurs brutes que vous pouvez envoyer à votre propre endpoint d’analytics. Vous évitez le coût d’une solution tierce et vous gardez la main sur les dimensions métier à corréler avec les performances.
