Optimisation performance de manda-ia.com
Audit Lighthouse, architecture Next.js et coûts cloud
Étude de cas technique de l'optimisation d'un portfolio Next.js déjà en production. L'audit relie les mesures Lighthouse, le Critical Rendering Path, le JavaScript, le CSS Tailwind, les lectures Supabase, le rendu dynamique et les fonctions Vercel aux chemins de code responsables. Les corrections ont transformé les pages publiques en contenu pré-rendu, rendu Payload optionnel, ajouté un cache partagé et conservé un tableau visiteurs actualisé sans lecture directe de la base à chaque visite. Snapshot du 26 août 2026 : 99/100 sur ordinateur, LCP 0,5 s, CLS 0 ; le profil mobile à 80/100 identifie encore le travail JavaScript à réduire.
Audit performance en production
Relier PageSpeed, architecture CSS et coûts cloud au même diagnostic
manda-ia.com fonctionnait déjà et gagnait du trafic, mais les quotas Vercel et Supabase révélaient une architecture trop coûteuse. J'ai audité le parcours complet de la requête, du navigateur jusqu'à la base, puis séparé trois problèmes souvent confondus : la vitesse visible, le travail JavaScript et CSS côté client, et les lectures serveur répétées. Le résultat est une base plus statique, un cache partagé et une preuve Lighthouse datée qui montre aussi honnêtement le prochain chantier mobile.
- Desktop Lighthouse
- 99/100, LCP 0,5 s, TBT 30 ms
- Mobile Lighthouse
- 80/100, LCP 2,4 s, TBT 680 ms
- Stabilité visuelle
- CLS 0 sur les deux profils
- Snapshot
- 26 août 2026, 58 requêtes, environ 653 KiB
Commencer par une baseline reproductible
Un score seul ne constitue pas un audit. Le snapshot Lighthouse précise l'URL, la date, le profil mobile ou desktop et les métriques qui composent le résultat. Les données de laboratoire servent à reproduire un scénario contrôlé ; elles restent distinctes des Core Web Vitals terrain collectées auprès des vrais visiteurs.
Le profil desktop atteint 99/100 avec un LCP de 0,5 seconde et un TBT de 30 millisecondes. Le profil mobile reste à 80/100 avec un TBT de 680 millisecondes. Cet écart évite une conclusion artificielle : le rendu initial est solide, mais le thread principal exécute encore trop de JavaScript dans les conditions mobiles simulées.
Auditer Tailwind par sa sortie, pas par sa réputation
L'audit CSS inspecte ce qui arrive réellement dans le navigateur : taille transférée, règles inutilisées, ordre des feuilles de style, polices, styles critiques et capacité de l'équipe à maintenir les composants. Tailwind peut produire un CSS compact lorsqu'il est correctement compilé, mais il ne dispense pas d'examiner les dépendances, les variantes et les conventions qui s'accumulent.
Le benchmark d'une autre approche CSS n'a de sens qu'avec les mêmes écrans, le même contenu et les mêmes conditions de mesure. Je compare donc le poids, le blocage du rendu, la répétition des règles et le coût de migration avant de recommander Tailwind, CSS Modules, du CSS natif moderne ou une combinaison ciblée.
Le problème serveur caché derrière une page rapide
La base Supabase contenait environ 25 Mo, mais l'organisation avait dépassé 5,5 Go d'egress. Le volume stocké n'expliquait pas ce transfert. Les pages publiques étaient rendues dynamiquement et relisaient le CMS, les fallbacks et certaines données à chaque requête, y compris lors du passage des crawlers.
Les contenus publics ont été pré-rendus, Payload rendu optionnel en production et les lectures fréquentes remplacées par un cache partagé. Le tableau visiteurs conserve une fraîcheur maximale de 30 secondes tout en renvoyant une réponse légère, sans ouvrir une lecture Supabase directe pour chaque navigateur.
Corriger sans casser le produit existant
L'ordre des changements compte autant que leur nature. Je commence par les corrections à fort impact et faible risque : rendu statique des contenus éditoriaux, cache adapté, suppression des appels dupliqués, chargement différé des scripts tiers et images dimensionnées. Les changements plus profonds arrivent seulement lorsque les mesures les justifient.
Chaque correction est vérifiée sur les parcours réels, les erreurs réseau, les pages localisées et le comportement mobile. Cette méthode permet d'améliorer un site déjà en production sans transformer l'audit en refonte imposée.
Appliquer la même discipline aux sites métier
Les sites métier utilisent cette méthode dès leur conception : rendre statique ce qui peut l'être, charger les médias selon le viewport, limiter les composants client et mesurer la version déployée. La performance devient alors une contrainte d'architecture, pas une opération cosmétique avant livraison.
Pour un hôtel, un restaurant, une agence de voyage ou un loueur, cette vitesse protège directement la conversion mobile. La page doit rester légère au moment où le visiteur compare une offre, consulte un menu, vérifie une disponibilité ou remplit une demande.
Audit performance site web
La méthode, les livrables et le périmètre d'une intervention sur un site existant.
Sites métier performants
Voir comment la performance, le SEO et la conversion sont intégrés par secteur.
Développeur React et Next.js
Rendu Next.js, composants React et architecture frontend maintenable.
Projet TeamIA
Un site métier Next.js avec fallback statique, CMS Payload et intégrations sécurisées.
Pourquoi le score mobile est-il inférieur au desktop ?
Le profil mobile Lighthouse simule un appareil et un réseau plus contraints. Le TBT de 680 ms indique surtout du travail JavaScript sur le thread principal ; il devient le prochain chantier mesurable au lieu d'être masqué derrière le score desktop.
Un score Lighthouse prouve-t-il les Core Web Vitals ?
Non. Lighthouse fournit une mesure de laboratoire reproductible. Les Core Web Vitals terrain viennent de vrais utilisateurs et doivent être suivis séparément dans CrUX, Search Console ou une solution RUM.
Faut-il abandonner Tailwind pour améliorer la performance ?
Pas automatiquement. Il faut mesurer le CSS produit, le rendu critique et la maintenabilité. Un changement de framework sans benchmark comparable peut coûter plus qu'il ne rapporte.
Peut-on auditer un site sans le reconstruire ?
Oui. Le diagnostic priorise les changements à fort impact et faible risque. Une refonte n'est recommandée que lorsque l'architecture existante empêche réellement les corrections nécessaires.