Audit performance site web & optimisation des coûts cloud
Votre site fonctionne déjà, mais il devient lent, consomme trop de ressources ou approche les quotas Vercel et Supabase ? J'audite le parcours complet de la requête, du navigateur à la base de données, puis je corrige les causes structurelles : rendu, cache, CMS, API, images et polling. L'objectif n'est pas seulement un meilleur score, mais un site plus rapide, plus fiable et moins coûteux à exploiter.
Mis à jour le
Audit mesuré
Logs, métriques, réseau et requêtes réelles.
Performance web
Rendu, cache, images et Core Web Vitals.
Coûts maîtrisés
Egress, fonctions, API et base de données.
Requêtes optimisées
Moins de lectures inutiles et de doublons.
Architecture fiable
ISR, CDN et invalidation ciblée.
Résultats vérifiés
Tests avant/après et garde-fous.
Cas reel audite et mesure
Une base de 25 Mo pouvait produire 5,5 Go d'egress
Le volume de donnees n'etait pas le probleme. L'architecture relisait les memes contenus a chaque page et a chaque passage de crawler.
Alerte initiale
5,5 Go
Quota d'egress atteint alors que la base ne pesait qu'environ 25 Mo.
12,206
lectures du contenu global
18,261
requetes projet par slug
23,658
lectures du tableau visiteurs
Avant : cout invisible
Rendu dynamique sur toutes les routes
CMS et fallbacks relus pour chaque visite
Polling navigateur directement jusqu'a la base
Apres : architecture maitrisee
Pages prerendues avec revalidation ciblee
Contenu CMS distant active uniquement si necessaire
Cache CDN partage et chargement GA a la demande
696 B
par reponse visiteurs
10 -> 1
appels HTTP vers requete SQL
30 s
fraicheur maximale du tableau
Mesures issues de l'audit de manda-ia.com. Les gains exacts dependent du trafic, de l'hebergement et de l'architecture du site audite.
Comment appelle-t-on cette intervention ?
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.
Ce que j'audite réellement
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.
Le cas manda-ia.com : le volume n'était pas le problème
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.
Ma méthode en quatre étapes
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.
Livrables, délai et tarif
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.
Patch rapide ou optimisation structurelle ?
Les deux peuvent améliorer un score à court terme, mais seule l'analyse de bout en bout réduit durablement la consommation et les risques.
| Critère | Patch isolé | Audit + optimisation |
|---|---|---|
| Diagnostic | Un score ou un symptôme visible | Logs, réseau, fonctions, SQL et egress reliés au code |
| Performance | Compression ou suppression ponctuelle | Rendu, cache et données optimisés ensemble |
| Coûts cloud | Réduction difficile à expliquer | Moins d'appels, de calcul et de transfert mesurés |
| Données fraîches | Cache désactivé par prudence | Durée de cache choisie selon le besoin métier |
| Risque de régression | Vérification manuelle limitée | Tests fonctionnels et mesures avant/après |
Diagnostic
Performance
Coûts cloud
Données fraîches
Risque de régression
Le bon objectif n'est pas de tout mettre en cache. Il consiste à ne recalculer que ce qui doit réellement changer, au moment où cela apporte de la valeur à l'utilisateur.
Questions fréquentes
Quelle différence entre un audit PageSpeed et cet audit de performance ?
PageSpeed observe surtout l'expérience de chargement dans le navigateur. Mon audit relie aussi cette expérience aux coûts serveur : rendu Next.js, appels API, fonctions Vercel, egress Supabase, requêtes SQL, CMS et stratégie de cache.
Pouvez-vous optimiser un site déjà en production sans le reconstruire ?
Oui. Je commence par les changements à fort impact et faible risque, puis j'élargis seulement si l'architecture l'exige. Le but est d'améliorer le produit existant, pas d'imposer une refonte inutile.
Travaillez-vous uniquement avec Vercel et Supabase ?
Non. Ce cas utilise Vercel, Supabase, Next.js et Payload, mais la méthode s'applique aussi à d'autres hébergeurs, bases, CMS et API. Les outils changent, les principes de mesure, cache et réduction des requêtes restent les mêmes.
Le cache ne risque-t-il pas d'afficher des données périmées ?
Un cache bien conçu possède une durée adaptée et une stratégie d'invalidation. Une page éditoriale peut être revalidée après publication ; un tableau presque temps réel peut utiliser un cache partagé de 30 secondes. La fraîcheur est décidée selon le besoin métier.
Quels résultats peut-on attendre ?
Cela dépend du trafic et de l'architecture. L'objectif est mesurable : moins de requêtes et de transfert, des réponses plus légères, de meilleurs temps de chargement et davantage de marge avant les quotas. Je fournis les valeurs avant/après plutôt qu'une promesse générique.
Prêt à démarrer votre projet ?
Discutons de vos besoins lors d'un appel découverte gratuit de 30 minutes.
Démarrer un projet