Audit performance site web & optimisation des coûts cloud

C'est une optimisation technique d'un site web existant, aussi appelée audit de performance web ou optimisation d'architecture cloud. Elle va plus loin qu'un simple audit PageSpeed : j'analyse pourquoi le site consomme du CPU, de l'egress, des fonctions serverless ou des lectures de base de données, puis je corrige le système qui produit ces coûts.

Cette intervention est utile quand le produit fonctionne déjà mais que les pages ralentissent, que les quotas gratuits disparaissent trop vite, que les crawlers déclenchent des traitements coûteux ou que chaque visite relit les mêmes données.

Je pars des symptômes vérifiables : temps de réponse, waterfall réseau, Core Web Vitals, logs Vercel, métriques Supabase, volume d'egress, fréquence des fonctions, poids des réponses et requêtes SQL. Je relie ensuite chaque coût au code qui le déclenche.

L'analyse couvre le rendu Next.js (statique, dynamique, ISR), les stratégies de cache navigateur et CDN, les appels vers Payload ou un autre CMS, les fallbacks de données, le polling, les images, les bibliothèques chargées côté serveur et les invalidations après publication.

La base occupait environ 25 Mo, mais l'organisation avait dépassé 5,5 Go d'egress. L'audit a montré que les pages publiques étaient rendues dynamiquement et relisaient plusieurs sources distantes à chaque requête. Les crawlers, visiteurs et rafraîchissements répétaient donc le même travail.

J'ai remplacé ces lectures par des pages pré-rendues avec revalidation, rendu le CMS distant optionnel en production, ajouté des caches partagés, limité le rafraîchissement du tableau visiteurs aux onglets visibles et déplacé le cache à l'edge Vercel. Le tableau reste actualisé à moins de 30 secondes sans interroger Supabase à chaque visite. Cette intervention est documentée dans l'étude de cas complète.

L'audit ne s'arrête pas au backend. Je mesure le CSS réellement transféré, les styles inutilisés, les dépendances entre composants, les polices, l'image LCP et les feuilles de style qui bloquent le rendu. Avec Tailwind, la question n'est pas de défendre le framework : il faut vérifier ce que la compilation produit, si les classes restent maîtrisables et si une autre stratégie CSS apporterait un gain mesurable.

Je relie ensuite le Critical Rendering Path au JavaScript exécuté avant l'interaction : composants client, hydratation, scripts tiers, écouteurs globaux et bibliothèques chargées trop tôt. Sur le snapshot Lighthouse du 26 août 2026, manda-ia.com atteint 99/100 sur ordinateur avec un LCP de 0,5 s et un CLS nul. Le score mobile de 80/100 et un TBT de 680 ms indiquent clairement le prochain chantier : réduire le travail JavaScript du thread principal.

1. Mesurer : établir une baseline avant toute modification. 2. Localiser : relier les consommations aux routes, requêtes et composants responsables. 3. Corriger : choisir le bon rendu, supprimer les lectures redondantes, alléger les réponses et placer le cache au bon niveau. 4. Vérifier : comparer les métriques, tester le rafraîchissement des données et contrôler qu'aucune fonctionnalité n'a régressé.

Je documente les changements et les compromis. Vous savez ce qui a été corrigé, pourquoi, et quelles métriques surveiller ensuite.

Vous recevez un diagnostic priorisé, la cartographie des coûts techniques, les corrections convenues dans le code, les mesures avant/après et une liste de garde-fous pour éviter le retour du problème. Un audit ciblé peut être réalisé en quelques jours ; une optimisation complète dépend du nombre de routes, de fournisseurs et de flux de données.

Je travaille au TJM de 350 €, avec un périmètre et un devis établis avant de commencer. L'intervention peut être autonome ou intégrée à une mission d'amélioration continue.