makedream
36:54Vercel
Log in to leave a comment
No posts yet
Le moteur Nitro de Nuxt semble fonctionner partout sans accroc, mais la donne change dès qu'il est déployé sur le Vercel Edge Runtime. La raison pour laquelle des bibliothèques comme sharp ou bcrypt, qui fonctionnaient parfaitement en local, renvoient immédiatement des erreurs 500 après le déploiement est que Vercel Edge bloque l'accès aux modules standard de Node.js. Personnellement, j'exécute toujours npx vercel build avant de cliquer sur le bouton de déploiement. Sans simulation préalable de l'environnement basé sur Linux, vous risquez fort de vous battre avec des erreurs d'exécution à 3 heures du matin.
Pour une exploitation stable, il est plus sûr de spécifier explicitement le preset vercel au lieu de vercel-edge dans votre fichier nuxt.config.ts. Il n'est pas nécessaire de faire tourner toutes vos API sur l'Edge. De même, ne faites pas d'appels directs à process.env pour vos variables d'environnement ; standardisez-les avec le useRuntimeConfig de Nitro. Cette simple habitude élimine 80 % des erreurs d'exécution survenant après le déploiement.
Le principal coupable des factures Vercel est le temps d'exécution et le nombre d'appels des fonctions Serverless. Les routeRules introduites dans Nitro 3 sont l'outil le plus puissant pour réduire physiquement ces coûts. En utilisant correctement la stratégie stale-while-revalidate (SWR), même si vous recevez 10 000 requêtes API, l'exécution réelle de la fonction peut n'avoir lieu qu'une seule fois. C'est une méthode astucieuse pour offrir aux utilisateurs une réponse rapide en millisecondes tout en préservant votre budget.
Voici les réglages concrets pour réduire les coûts de plus de 40 % :
routeRules de nuxt.config.ts.swr: 3600 au chemin concerné pour activer le mode de mise à jour en arrière-plan pendant une heure.maxAge et staleMaxAge dans les options cache.Ainsi, vous verrez le nombre d'appels de fonctions Serverless chuter verticalement sur votre tableau de bord Vercel.
L'erreur d'hydratation, qui survient lors de la rencontre entre le HTML généré par le serveur et le JavaScript du client, rend l'application instable. Pour résoudre ce problème, Nuxt 4 a été conçu pour utiliser deep: false par défaut lors des appels useAsyncData. En renonçant au suivi inutile des objets, on économise de la mémoire et on transfère l'état du serveur au client en toute sécurité.
Appliquez ces trois règles pour corriger les incohérences de données et réduire la taille du payload :
pick lors des appels API pour ne sélectionner que les clés nécessaires au rendu du template. Cela peut réduire la taille du payload jusqu'à 50 %.useId() là où un ID unique est requis afin de faire correspondre les identifiants entre le serveur et le client.<NuxtTime> pour un traitement basé sur la locale du navigateur.À mesure que le projet grandit, même les 8 192 Mo de mémoire fournis par le conteneur de build de Vercel peuvent s'avérer insuffisants. Plus précisément, la taille par défaut du tas (heap size) de Node.js est souvent inférieure à la mémoire disponible, ce qui provoque des collectes de déchets (garbage collection) fréquentes et finit par stopper le build.
Pour accélérer la vitesse de build et éviter les échecs de déploiement, appliquez immédiatement ces réglages :
NODE_OPTIONS="--max-old-space-size=4096" aux variables d'environnement du projet Vercel. Le simple fait de lever la limite de mémoire du tas élimine les goulots d'étranglement du build.npx nuxt analyze pour vérifier si des dépendances lourdes réservées au serveur ne sont pas mélangées dans le bundle client, et isolez-les avec l'alias #server.server/middleware/ (exécutées à chaque requête) vers des gestionnaires d'événements (event handlers) pour des routes spécifiques.Une fois cette configuration d'environnement terminée, le temps d'attente de votre pipeline CI/CD sera raccourci et le taux d'échec des déploiements diminuera considérablement.