Vercel Functions : les fichiers statiques FastAPI passent au CDN

Depuis le 10 septembre 2026, Vercel a modifié un poste de coûts pour les applications FastAPI. Les requêtes éligibles du frontend et des fichiers statiques vont désormais du CDN de Vercel jusqu’au visiteur, sans déclencher d’invocations de Vercel Functions ni consommer de calcul. Les requêtes CDN et le transfert restent comptabilisés : la nouveauté réduit donc l’usage des Functions, mais ne rend pas la diffusion statique gratuite.

La requête contourne désormais les Vercel Functions

Un fichier statique peut être envoyé tel quel par le serveur : fichier HTML, feuille de style, bundle JavaScript, police ou image. Une Vercel Function correspond ici au processus FastAPI en cours d’exécution qui traite les requêtes dynamiques. Le CDN est la couche de diffusion située au plus près du visiteur.

Avant ce changement, un fichier monté via FastAPI pouvait encore emprunter le chemin de la Function. La requête arrivait sur le réseau de Vercel, invoquait la Function FastAPI, puis Python renvoyait le fichier.

Désormais, Vercel repère pendant le build les fichiers éligibles placés derrière app.frontend() et StaticFiles de FastAPI. Il les publie sur le CDN, et les requêtes correspondantes sont servies sans invoquer la Function.

Le trajet passe donc de :

visitor → CDN → FastAPI Function → file → visitor

à :

visitor → CDN file → visitor

L’API dynamique ne devient pas statique pour autant. Seuls les fichiers correspondants sont déplacés. Les fichiers du répertoire public/ à la racine du projet étaient déjà servis par le CDN : une application qui y stockait tous ses assets publics ne bénéficie donc d’aucune nouvelle économie avec cette mise à jour.

Par défaut, les répertoires promus restent également inclus dans le bundle de la Function. Le réglage tool.vercel.fastapi.static.exclude = true supprime cette copie en double, mais il s’agit d’un choix distinct concernant le bundle. Il n’est pas nécessaire pour que les requêtes passent par le CDN.

La facture perd le calcul, pas la diffusion

Vercel mesure une requête sur plusieurs couches. Le compteur Function Invocations recense les requêtes qui atteignent votre code. Active CPU et Provisioned Memory mesurent le travail et les ressources d’exécution mobilisés par ces invocations. Fast Origin Transfer mesure le trafic entre le CDN et la Function.

Les compteurs de diffusion externes sont distincts. Le compteur CDN Requests, affiché sous le nom Edge Requests dans le tableau de bord, s’applique aux assets statiques comme au trafic des Functions. Fast Data Transfer mesure les octets envoyés entre le CDN et le visiteur.

Voici le relevé exact pour un million de requêtes d’assets par ailleurs identiques, qui atteignaient la Function avant le déploiement et deviennent éligibles à la promotion après celui-ci :

Le tarif Pro publié est de $0.60 par million de Function invocations. Un million de requêtes de fichiers qui atteignaient auparavant la Function retire donc $0.60 de consommation brute liée aux invocations avant le crédit mensuel, plus l’Active CPU, la Provisioned Memory et le Fast Origin Transfer réellement consommés par ces requêtes.

Cette dernière part doit être établie à partir de vos données Usage. Une réponse de fichier qui sollicitait à peine Python laisse peu de CPU à économiser. Une réponse volumineuse peut en revanche laisser davantage de transfert depuis l’origine à économiser. Cette mise à jour ouvre un nouveau chemin ; elle ne garantit aucun pourcentage d’économie universel.

La consommation CDN reste de l’autre côté du relevé. La page tarifaire actuelle du CDN de Vercel indique que l’offre Pro inclut jusqu’à 10 millions d’Edge Requests et 1 TB de Fast Data Transfer avec la facturation à l’usage, avant l’application de tarifs régionaux. Les équipes qui utilisent Flat Rate CDN consomment à la place la capacité de requêtes et de transfert prévue par cette offre. Le décryptage de Flat Rate CDN traite séparément cette décision budgétaire.

Pour l’offre Hobby, le gain peut prendre la forme d’une marge de manœuvre supplémentaire plutôt que d’une facture moins élevée. Hobby inclut un million de Function invocations, quatre heures d’Active CPU et 360 GB-hours de Provisioned Memory. Le trafic des fichiers publics qui n’atteint plus la Function cesse d’entamer ces quotas, tandis que sa diffusion par CDN reste comptabilisée là où elle s’applique.

L’éligibilité dépend des routes et des règles de sécurité

Pour StaticFiles, Vercel respecte l’ordre de déclaration de FastAPI. Une route déclarée avant un montage statique l’emporte au même chemin et atteint la Function. Déclarée après le montage, elle cède la priorité au fichier du CDN.

app.frontend() fonctionne un peu différemment. Les routes d’API restent toujours prioritaires sur les fichiers du frontend, quel que soit l’ordre de déclaration. Un frontend monté sur / ne peut donc pas absorber un véritable endpoint d’API.

La sécurité modifie elle aussi le comportement par défaut. Un fichier CDN n’entre jamais dans Python : les middlewares FastAPI et les contrôles Depends() ne peuvent donc pas s’exécuter. Par défaut, Vercel conserve alors les chemins suivants sur la Function :

• Tous les montages statiques et tous les frontends lorsque l’application possède un middleware de premier niveau.
• Les montages statiques d’une sous-application lorsque celle-ci possède un middleware.
• Un frontend protégé par des dépendances FastAPI.

Le réglage cdn = false fait le compromis inverse. Il désactive la promotion et maintient chaque requête correspondante sur la Function. C’est un choix valable lorsque le code de l’application doit examiner toutes les requêtes.

Il subsiste un cas limite plus discret : le chemin racine d’un montage StaticFiles, sans barre oblique finale, atteint toujours la Function afin que FastAPI puisse rediriger vers la forme qui en comporte une. Ne vous attendez pas à voir un zéro absolu dans la consommation des Functions si des clients continuent à demander ce chemin sans la barre oblique.

Ce que cette évolution change concrètement

Pour un fondateur SaaS seul avec un dépôt FastAPI

Un fondateur qui sert une application web bundlée via app.frontend() peut conserver une API dynamique tout en sortant du chemin de la Function le trafic public HTML, CSS et JavaScript. Le bénéfice : une base de référence plus lisible pour le calcul. Le trafic lié au produit peut progresser sans que chaque chargement d’asset par le navigateur ressemble à du travail backend.

Pour un ingénieur d’agence entre fichiers publics et privés

Un ingénieur d’agence peut placer l’interface publique sur le CDN tout en déclarant une route sensible avant le montage statique. Le gain ne se limite pas à une moindre utilisation des Functions. La carte des routes indique clairement quels fichiers clients nécessitent une décision d’accès dans Python et lesquels peuvent s’en passer.

Pour un responsable backend qui travaille avec la finance

Un responsable backend peut remettre à la finance deux prévisions distinctes : le trafic FastAPI dynamique pour le poste Function, puis l’ensemble du trafic visiteur pour le poste CDN. Une baisse de Function Invocations ne sera ainsi plus confondue avec une baisse équivalente d’Edge Requests ou de transfert.

Pour une équipe dotée d’un middleware global

Une équipe qui utilise au niveau supérieur un middleware de journalisation, de résolution du tenant ou d’authentification doit s’attendre à ce que les montages statiques restent par défaut sur la Function. La bonne question consiste à déterminer si une zone d’assets clairement publique peut contourner ce middleware. Si la réponse est non, ce changement ne permet de budgéter aucune économie sans risque.

Auditer un déploiement

Partez d’un véritable inventaire des routes, pas de l’hypothèse selon laquelle tout fichier doté d’une extension serait public.

1. 1

   Distinguer les chemins publics et protégés

   Recensez chaque répertoire app.frontend() et chaque montage StaticFiles. Marquez les fichiers qui peuvent être renvoyés à n’importe quel visiteur. Isolez ensuite tout chemin dont la réponse dépend d’un utilisateur, d’un tenant, d’un rôle, d’un cookie ou du résultat d’un middleware au moment de la requête.

2. 2

   Vérifier l’ordre de déclaration

   Placez une route de Function avant un montage StaticFiles lorsqu’elle doit rester prioritaire. Voici le modèle documenté par Vercel :

   from fastapi import FastAPI
   from fastapi.staticfiles import StaticFiles
   
   app = FastAPI()
   
   # Declared before the mount, so this route wins over any CDN file at this path.
   @app.get("/static/protected.json")
   def protected():
       return {"access": "denied"}
   
   app.mount("/static", StaticFiles(directory="static"))

3. 3

   Maintenir les chemins protégés sur la Function

   Contrôlez le middleware de premier niveau, celui des sous-applications et les dépendances du frontend avant de modifier la configuration. Ne définissez pas cdn = true dans le seul but de faire baisser un graphique, sauf si tous les fichiers concernés sont réellement publics. Utilisez cdn = false lorsque tout le trafic correspondant doit passer par FastAPI.

4. 4

   Décider s’il faut alléger le bundle

   Si l’application en cours d’exécution ne lit jamais les fichiers promus, vous pouvez exclure leurs répertoires sources du bundle de la Function avec le réglage documenté :

   [tool.vercel.fastapi.static]
   exclude = true

   Conservez le réglage par défaut si le code exécuté a encore besoin de ces fichiers.

5. 5

   Déployer et contrôler la séparation

   Exécutez vc deploy. Testez un fichier public, un fichier protégé et une route d’API. Vérifiez que la réponse protégée se comporte toujours correctement, puis comparez dans Usage les valeurs Function Invocations, Active CPU, Provisioned Memory, Fast Origin Transfer, Edge Requests et Fast Data Transfer du projet. L’échantillon public doit quitter le chemin de la Function sans disparaître des totaux du CDN.

La limite réelle des économies

Le tarif direct des invocations n’est que de $0.60 par million sur Pro. Pour une petite application, l’économie peut se compter en centimes ou être absorbée par le crédit mensuel d’utilisation. Le principal bénéfice peut plutôt être de retirer le bruit des assets dans l’usage des Functions et de préserver la capacité de calcul pour le véritable travail de l’API.

L’économie augmente lorsque le trafic des assets publics est important, lorsque l’ancien chemin par la Function mobilisait la mémoire assez longtemps pour avoir un effet, ou lorsque les réponses généraient un Fast Origin Transfer significatif. Elle reste faible si les fichiers se trouvaient déjà dans public/, si le trafic est réduit ou si les règles de sécurité maintiennent à juste titre les chemins sur la Function.

Cette évolution ne remplace pas non plus l’optimisation des assets. Le même bundle JavaScript, la même image ou la même police volumineuse doit toujours traverser le CDN jusqu’au visiteur. Réduire la taille de ces fichiers reste le moyen de diminuer le Fast Data Transfer.

À faire dès lundi

Agissez cette semaine si app.frontend() ou StaticFiles sert des fichiers publics et que ces requêtes apparaissent dans l’usage des Functions. Attendez si les fichiers sont protégés et que leurs règles d’accès n’ont pas encore été séparées. Vous n’êtes pas concerné si les fichiers en question proviennent déjà de public/ ou d’un autre chemin desservi par un CDN.

Lundi, inventoriez les chemins d’assets publics et protégés, préservez chaque route et chaque contrôle qui doit s’exécuter, puis validez un déploiement avec une requête de chaque catégorie. Budgétez la baisse mesurée de l’usage des Functions. Conservez les requêtes CDN et le transfert dans le tableau.

Pour recevoir d’autres décryptages en langage clair sur les évolutions de plateformes qui modifient les coûts d’exploitation, abonnez-vous à la newsletter.