Aller au contenu
Logo MandaMANDA.

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.

Diagnostic

Patch isoléUn score ou un symptôme visible
Audit + optimisationLogs, réseau, fonctions, SQL et egress reliés au code

Performance

Patch isoléCompression ou suppression ponctuelle
Audit + optimisationRendu, cache et données optimisés ensemble

Coûts cloud

Patch isoléRéduction difficile à expliquer
Audit + optimisationMoins d'appels, de calcul et de transfert mesurés

Données fraîches

Patch isoléCache désactivé par prudence
Audit + optimisationDurée de cache choisie selon le besoin métier

Risque de régression

Patch isoléVérification manuelle limitée
Audit + optimisationTests fonctionnels et mesures avant/après

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
Audit performance site web & coûts cloud | Manda