Un client m'a appelé un lundi matin l'année dernière. Pas un message. Un appel téléphonique. Ce n'est jamais bon signe. Il avait déployé un site marketing Next.js sur le plan Pro de Vercel le jeudi précédent, avait lancé un produit le week-end, et s'était réveillé avec une facture de 340 $ dans sa boîte de réception. Le site avait très bien fonctionné. Le trafic avait explosé. Et Vercel avait discrètement mesuré chaque gigaoctet de données quittant leur réseau. Il n'avait pas défini de limite de dépenses. Aucune alerte configurée. Rien.
Cet appel est la raison pour laquelle je consacre maintenant vingt minutes à l'hygiène de facturation Vercel avec chaque client avant de déployer quoi que ce soit en production.
Voici ce que vous devez comprendre sur la façon dont Vercel facture la bande passante, pourquoi cela prend les gens au dépourvu, et ce qu'il faut vraiment faire à ce sujet.
---
Ce que « Sortie » signifie réellement sur Vercel
L'egress est la data transférée hors du réseau de Vercel vers l'utilisateur final. Chaque image, chaque bundle JavaScript, chaque réponse API, chaque fichier de police. Si ça quitte leur edge et arrive dans un navigateur, ça compte.out of Vercel's network to the end user. Every image, every JavaScript bundle, every API response, every font file. If it leaves their edge and hits a browser, it counts.
Sur le plan Hobby vous avez 100GB de bande passante par mois, inclus. Sur Pro c'est 1TB. Ça semble beaucoup. Mais voilà le truc : si vous servez de grandes images, si vous faites du rendu côté serveur sur des pages avec des payloads JSON lourds, ou si votre app connaît un pic de trafic soudain, vous pouvez dépasser 1TB plus vite que vous ne le penseriez. Vercel facture $0,15 par GB de dépassement sur Pro au moment où j'écris (vérifiez toujours leur page de tarification actuelle parce que ça bouge).their current pricing page because this moves).
Donc 500GB au-delà de votre limite c'est $75. Pas catastrophique. Mais un moment viral, une configuration d'optimisation d'image ratée, ou un scraper qui martèle vos API routes ? Ça peut être des milliers.
Pourquoi Ça Prend Les Gens Par Surprise
Le truc c'est que le développement local ne vous donne aucune indication. Vous buildez vite, vous déployez vite, tout semble aller bien. Le dashboard de Vercel montre l'utilisation de la bande passante mais il ne vous crie pas après. Si vous n'avez pas proactivement configuré une alerte de facturation, vous l'apprenez quand la facture arrive.
---
Les Configs Les Plus Susceptibles de Wrecker Votre Facture
J'ai audité beaucoup de déploiements chez Seahawk. Il y a quatre coupables que je vois encore et encore.
1. Images Non Optimisées Contournant next/image
next/image est vraiment bon dans ce qu'il fait. Il redimensionne, convertit en WebP, et cache. Mais j'ai vu des projets où les développeurs tiraient les images directement d'une balise <img> pointant vers des fichiers en pleine résolution dans un bucket S3, proxifiés via une API route Vercel. Chaque requête tirait un JPEG de 4MB à travers le réseau de Vercel au lieu d'un WebP de 200KB depuis un edge CDN. Multipliez ça par 50 000 vues de page et faites le calcul. is genuinely good at what it does. It resizes, converts to WebP, and caches. But I've seen projects where developers were pulling images straight from an <img> tag pointing at full-resolution files in an S3 bucket, proxied through a Vercel API route. Every request was pulling a 4MB JPEG through Vercel's network instead of a 200KB WebP from a CDN edge. Multiply that by 50,000 page views and do the maths.
Utilisez toujours next/image avec une configuration remotePatterns appropriée. Si la source de l'image est externe, assurez-vous qu'elle passe par le cache du CDN et ne fait pas d'aller-retour à travers vos fonctions serverless.next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.
2. Routes API qui retournent des payloads volumineux
En 2021, j'ai construit un catalogue de produits e-commerce pour un détaillant britannique. Leur route API récupérait une liste de produits depuis leur base de données et retournait l'objet produit entier, y compris les champs que le front-end n'utilisait jamais. Description, notes SKU internes, métadonnées de variantes, tout. Chaque réponse faisait environ 80 KB au lieu des 12 KB dont elle avait besoin.entire product object, including fields the front end never used. Description, internal SKU notes, variant metadata, the lot. Each response was around 80KB instead of the 12KB it needed to be.
Affinez vos réponses API. Retournez uniquement les champs que le client consomme réellement. Si vous utilisez quelque chose comme Prisma, utilisez select pour limiter ce que vous récupérez. Si vous utilisez une API tierce, transformez et réduisez le payload avant de l'envoyer en aval.select to limit what you pull. If you're using a third-party API, transform and slim the payload before sending it downstream.
3. ISR avec des fenêtres de revalidation courtes sur les routes à fort trafic
L'Incremental Static Regeneration est brillant en théorie. En pratique, si vous définissez revalidate: 30 sur une page qui reçoit 10 000 hits par minute, vous mettez toujours en cache correctement. Mais si vous la définissez à revalidate: 1 parce que vous vouliez des mises à jour quasi en temps réel et avez oublié de la changer... vous faites essentiellement du SSR avec des étapes supplémentaires et payez l'egress sur chaque réponse de cache presque manquée.revalidate: 30 on a page that gets 10,000 hits per minute, you're still caching correctly. But if you set it to revalidate: 1 because you wanted near-real-time updates and forgot to change it... you're basically doing SSR with extra steps and paying for the egress on every near-miss cache response.
Soyez délibéré sur vos fenêtres de revalidation. La plupart du contenu n'a pas besoin de se revalider chaque seconde.
4. Fonctions serverless sans en-têtes de cache
Celui-ci est subtil. Si votre réponse de fonction serverless n'inclut pas un en-tête Cache-Control (ou la combinaison s-maxage / stale-while-revalidate de Vercel), la réponse n'est pas mise en cache à la périphérie. Chaque requête accède à la fonction et fait l'aller-retour complet. Vous perdez complètement l'avantage du CDN et payez l'egress sur chaque réponse.Cache-Control header (or Vercel's s-maxage / stale-while-revalidate combo), the response is not cached at the edge. Every request hits the function and travels the full round trip. You lose the CDN benefit entirely and pay egress on every single response.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 `` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
Cet en-tête seul a fait économiser de l'argent réel à mes clients. Sérieusement. La documentation de caching de Vercel explique le comportement de l'en-tête en détail. Lisez-la une fois correctement.Vercel's own caching docs explain the header behaviour in detail. Read them once properly.
---
Comment configurer les alertes de facturation (avant d'en avoir besoin)
Cela devrait être l'étape une avant tout déploiement en production. Pas l'étape sept.
- Allez dans les paramètres de votre équipe Vercel.
- Sous Billing, trouvez Spend Management.Billing , find Spend Management.
- Définissez une limite de dépense (plafond strict, où Vercel cesse de servir les requêtes après la limite) ou un seuil de notification (alerte douce, vous envoie un email quand vous atteignez un montant).spend limit (hard cap, where Vercel stops serving requests after the limit) or a notification threshold (soft alert, emails you when you hit a number).
- Je recommande de définir une notification à 50% de ce que vous considéreriez comme douloureux, et une limite stricte à environ 120% de votre facture mensuelle prévue.
Le plafond strict est une arme à double tranchant. Si vous l'atteignez, votre site s'arrête. Réfléchissez donc bien. Pour un site marketing? D'accord, imposez un plafond strict. Pour un SaaS avec des utilisateurs payants? Définissez des notifications généreuses et surveillez le tableau de bord à la place.
---
Déléguer les tâches lourdes ailleurs
Vercel n'est pas un CDN pour les assets statiques. Je veux dire, il a un CDN, mais vous payez par gigaoctet qui en sort. Pour les assets statiques en gros volume, mettez-les quelque part de moins cher.
Je route les gros fichiers média via Cloudflare R2 depuis environ dix-huit mois. R2 n'a aucun frais de sortie. Vous payez le stockage et les opérations, pas les données qui sortent. Pour les sites lourds en images, c'est une vraie économie. Un de mes clients gère une plateforme de portfolio photographique et payait environ 180 $/mois en frais de sortie Vercel. On a déplacé toutes les images en haute résolution et les assets de galerie vers R2, on a gardé les miniatures via next/image, et la facture Vercel est tombée à moins de 40 $.Cloudflare R2 for about eighteen months now. R2 has zero egress fees. You pay for storage and operations, not for the data going out. For image-heavy sites this is a serious saving. A client of mine runs a photography portfolio platform and was paying around $180/month in Vercel egress. We moved all the full-res images and gallery assets to R2, kept the thumbnails going through next/image, and the Vercel bill dropped to under $40.
Les alternatives qui méritent d'être connues :
- Cloudflare Pages pour les déploiements statiques où vous n'avez pas besoin des fonctionnalités edge de Vercel. Tier gratuit généreux, aucun frais de sortie. for static deployments where you don't need Vercel's edge features. Generous free tier, no egress fees.
- AWS CloudFront devant S3 si vous êtes déjà dans l'écosystème AWS. Les coûts de transfert sont plus bas que les tarifs de dépassement de Vercel à grande échelle. in front of S3 if you're already in the AWS ecosystem. Transfer costs are lower than Vercel's overage rates at scale.
- BunnyCDN est bon marché et rapide pour la pure livraison d'assets. Je l'ai utilisé sur quelques migrations WordPress-vers-Next.js à fort trafic où le volume d'assets était important. is cheap and fast for pure asset delivery. I've used it on a few high-traffic WordPress-to-Next.js migrations where the asset volume was large.
Le point, c'est : Vercel est le bon endroit pour exécuter votre logique d'application Next.js. Ce n'est pas toujours le bon endroit pour servir vos gigaoctets de média.
---
Surveillance de l'utilisation en temps réel
Ne vérifiez pas votre tableau de bord uniquement à la fin du mois. C'est comme ça que mon client s'est retrouvé à m'appeler un lundi.
Quelques outils que j'utilise vraiment :
- Vercel Analytics vous donne les données au niveau de chaque page et c'est utile pour identifier quelles routes génèrent le plus de trafic (et donc le plus de bande passante sortante). gives you page-level data and is useful for spotting which routes are generating the most traffic (and therefore the most egress).
- Axiom s'intègre parfaitement aux drains de journaux de Vercel et vous permet de requêter la taille des requêtes au fil du temps. J'ai commencé à l'utiliser fin 2022 et ça a été utile sur les gros projets pour corréler les pics de trafic aux augmentations de bande passante sortante. integrates cleanly with Vercel's log drains and lets you query request size over time. I started using it in late 2022 and it's been useful on bigger projects for correlating traffic spikes with egress jumps.
- Configurez un simple cron (Vercel supporte nativement les crons maintenant) qui appelle leur API et envoie un message à un canal Slack quand la bande passante dépasse un seuil. J'ai construit une version légère de ça pour l'infrastructure propre de Seahawk. Ça prend deux heures, ça épargne pas mal d'anxiété.
L'API REST de Vercel expose les données de déploiement et d'utilisation. Ce n'est pas l'API la plus élégante du monde mais elle fait ce qu'il faut pour des alertes basiques.Vercel REST API exposes deployment and usage data. It's not the most elegant API in the world but it does what you need for basic alerting.
---
La Décision Architecturale Dont Personne Ne Parle
Voici quelque chose que je ne vois pas assez discuté : parfois Vercel n'est pas le bon choix par défaut.
Si votre projet est un site marketing statique sans vraie fonctionnalité dynamique, vous n'avez pas besoin de Vercel. Cloudflare Pages ou le tier gratuit de Netlify feront le travail sans aucune préoccupation de bande passante sortante. Vous ne « gaspillez » pas Vercel, vous utilisez juste pas le bon outil pour la charge de travail.
À l'inverse, si tu construis une véritable app Next.js avec du edge middleware, des server components, et des API routes qui font du vrai travail, Vercel vaut le coup de payer. Le DX est genuinely excellent et le réseau edge est rapide. Fais juste en sorte que l'architecture soit correcte dès le départ.
L'erreur que j'ai faite tôt dans ma carrière (vers 2016, avant même que Vercel existe, à l'époque où je figais le déploiement sur Heroku et Netlify) était de traiter la plateforme de déploiement comme une afterthought gratuite. Le choix de la plateforme façonne ton profil de coûts autant que le choix de ta base de données. Prends-le au sérieux.
---
FAQ
Le plan Hobby est-il soumis à des frais d'egress si je dépasse 100GB ?
Non. Sur le plan Hobby, Vercel ne facture pas de dépassement ; il ralentit ou suspend le déploiement une fois que tu atteins la limite. Ce n'est pas top de toute façon, mais tu ne recevras pas de facture surprise. Les factures surprises arrivent sur Pro et Enterprise où l'usage est mesuré au-delà du montant inclus.
L'optimisation d'images de Vercel compte-t-elle dans l'egress ?
Oui. Les images optimisées servies via next/image comptent toujours dans l'egress. Les économies se font sur la taille du fichier : tu sers un WebP de 180KB au lieu d'un JPEG de 3MB, donc l'egress par image est beaucoup plus bas. C'est l'optimisation elle-même qui réduit le coût, pas une exemption spéciale.next/image still count as egress. The saving is in file size: you're serving a 180KB WebP instead of a 3MB JPEG, so the egress per image is much lower. The optimisation itself is what reduces the cost, not some special exemption.
Puis-je utiliser un CDN custom devant Vercel pour réduire l'egress ?
Tu peux mettre le proxy de Cloudflare devant ton déploiement Vercel. Cloudflare met en cache les réponses à son edge, ce qui signifie que les requêtes qui touchent le cache de Cloudflare ne atteignent jamais Vercel du tout. Cela peut réduire significativement à la fois l'egress et les invocations de fonction. Il y a quelques restrictions avec les preview deployments et la gestion des headers, mais pour la production, c'est une approche courante et légitime. La documentation de Cloudflare sur le proxying couvre la configuration.Cloudflare's documentation on proxying covers the setup.
Quelle est la cause unique la plus importante des factures Vercel inattendues ?
D'après mon expérience : la gestion des images. Soit des images en pleine résolution servies sans optimisation, soit des routes d'optimisation d'images appelées à chaque requête sans mise en cache appropriée. Réglez d'abord votre pipeline d'images, tout le reste ensuite.
Vercel vous notifie-t-il automatiquement si l'utilisation augmente soudainement ?
Non par défaut. Vous devez le configurer. Il n'y a pas d'alerte prête à l'emploi qui dit « vous avez utilisé 80 % de votre bande passante ». C'est là le problème. Définissez vos seuils de gestion des dépenses le même jour où vous configurez votre déploiement en production. Pas plus tard.
---
Vercel est une excellente plateforme. Je l'utilise, Seahawk l'utilise, et je continuerai à la recommander pour les bons projets. Mais c'est un service mesuré qui fonctionne sur une infrastructure réelle, et la tarification le reflète. Les développeurs qui souffrent des factures surprises sont presque toujours ceux qui l'ont traité comme un CDN gratuit et n'ont jamais regardé les paramètres de facturation. Cinq minutes de configuration au moment du déploiement vous épargneront un appel téléphonique très désagréable le lundi matin.