29 juillet 2026

Temps de build Astro : ce qui compte vraiment quand un client publie

Entre le clic d'un client sur Publier et sa page en ligne, il y a surtout du temps de construction. Où il passe réellement, quelles optimisations paient, et pourquoi l'incrémental n'est pas la réponse attendue.

Sur un site statique, le délai entre le clic d’un client sur Publier et la visibilité de sa modification est presque entièrement du temps de construction. Tout le reste, la récupération du contenu, le déploiement, l’invalidation du cache, se compte en secondes. La construction se compte en minutes.

Cet écart est le plus gros coût d’usage du modèle statique, autant comprendre où le temps passe réellement plutôt que d’optimiser au jugé.

Où passe le temps sur un vrai site vitrine

Un site vitrine Astro typique, deux cents pages, trois cents images, déployé sur un exécuteur d’intégration continue hébergé :

Deux lignes dominent, et aucune n’est le rendu d’Astro.

La première : l’installation des dépendances

C’est la partie la moins intéressante et la plus régulièrement gaspillée d’une construction. Un npm install à froid sur un projet avec une bibliothèque de composants et quelques intégrations prend couramment une minute et demie. Cela arrive à chaque construction, et produit exactement le même résultat à chaque fois.

Ce qui aide, par ordre d’effet :

Un fichier de verrouillage réellement respecté. npm ci, pnpm install --frozen-lockfile. La résolution est la partie lente, et un fichier de verrouillage la supprime.

Le cache de dépendances de l’hébergeur, vérifié. Toutes les plateformes d’intégration continue mettent en cache node_modules ou le magasin du gestionnaire de paquets. La plupart des projets supposent que ça marche. Lisez un journal de construction et vérifiez : une installation avec cache chaud prend moins de quinze secondes, une installation à froid dépasse la minute. Si vous voyez la seconde à chaque fois, quelque chose ne va pas dans votre clé de cache.

Moins de dépendances. Peu spectaculaire et efficace. Un site vitrine n’a pas besoin d’une bibliothèque de composants.

La seconde : le traitement des images

C’est celle qui transforme une construction de quarante secondes en une construction de quatre minutes, et c’est là que l’intuition de la plupart des gens se trompe.

Si vos images sont traitées pendant la construction, ce travail se répète à chaque déploiement. Changez une phrase sur un site à trois cents photos, et la construction télécharge, décode, redimensionne et ré-encode trois cents images pour produire une page où une phrase a changé. Astro met agressivement en cache, ce qui aide sur un exécuteur chaud et ne sert à rien sur un conteneur neuf, c’est-à-dire exactement là où tourne la publication de votre client.

Si les images sont traitées à l’envoi, une seule fois, la construction reçoit des URL et des dimensions et ne fait aucun travail d’image. Un déploiement sur un site à deux mille photos coûte autant qu’un déploiement sur un site sans photo.

C’est le plus grand levier d’architecture sur le délai de publication, et il est décidé par votre CMS plutôt que par votre configuration Astro. C’est la raison pour laquelle notre traitement se fait à l’envoi : conversion de format, gestion de l’EXIF, redimensionnement vers un jeu fixe de largeurs, déclinaisons AVIF et WebP, le tout une fois, quand le client choisit son fichier.

Pourquoi l’incrémental n’est pas la réponse espérée

« Il suffit d’utiliser les constructions incrémentales » est la réplique standard, et elle mérite une réponse soignée.

La régénération statique incrémentale, sous les diverses formes proposées par les hébergeurs, ne reconstruit que ce qui a changé. Pour un site de cinquante mille pages, c’est une transformation. Pour un site vitrine de deux cents pages, c’est presque sans effet, parce que le rendu de deux cents pages n’a jamais été le goulot. Regardez à nouveau le tableau : le rendu des pages représente 5 à 30 secondes d’une construction qui peut durer quatre minutes.

L’incrémental s’attaque au plus petit terme. L’installation des dépendances et le traitement des images, qui dominent, ne sont pas touchés.

Il y a un second problème, plus subtil : l’incrémental suppose que le système de construction sache précisément ce qui a changé et ce qui en dépend. Sur un site piloté par le contenu, une seule modification peut affecter une page d’index, un sitemap, un flux RSS et un menu de navigation. Se tromper sur ce graphe de dépendances produit un site où certaines pages sont périmées, ce qui est pire qu’une construction plus lente mais correcte.

Le Content Layer d’Astro prend bien en charge des empreintes pour sauter les entrées inchangées, et cela aide réellement quand on a des milliers d’entrées. Ce n’est pas ce qui rend rapide une construction de deux cents pages, et cela ne sauvera pas une construction qui passe trois minutes sur des images.

À quoi ressemble un budget réaliste

Pour un site vitrine, viser une à trois minutes entre le clic et la page en ligne est honnête et atteignable. Sous la minute est possible avec un cache chaud et aucun travail d’image. Au-delà de cinq minutes, quelque chose de précis ne va pas, et c’est presque toujours les images ou l’installation.

Le chiffre compte parce qu’il détermine l’interface. À une à trois minutes, montrer la progression et finir par « en ligne à 14 h 32 » est une bonne expérience : l’éditeur voit qu’il se passe quelque chose et obtient une réponse définitive. À dix minutes, ça ne l’est pas, et aucun travail d’interface ne rattrape ça.

Comment mesurer la vôtre plutôt que deviner

La plupart des optimisations de construction se font au folklore. Dix minutes de mesure valent mieux qu’un après-midi de suppositions.

Tous les hébergeurs affichent des journaux horodatés. Ouvrez le plus récent et notez quatre nombres : quand l’installation a commencé et fini, quand la récupération du contenu a eu lieu, quand le traitement des images a commencé et fini, et quand l’envoi a démarré. Vous obtenez la forme de votre construction, et elle est presque toujours surprenante.

La comparaison qui compte le plus est une construction à froid contre une à chaud. Déclenchez une construction avec le cache vidé, puis relancez immédiatement. Si l’écart dépasse une minute, votre cache de dépendances fait un travail lourd qui ne sera pas là le jour où ça compte, parce que les clés de cache changent dès que votre fichier de verrouillage change.

En local, la même forme apparaît avec :

# Où passe réellement le temps, par phase
time npx astro build

# Les images sont-elles le problème : construire deux fois, la seconde est chaude
rm -rf node_modules/.astro && time npx astro build
time npx astro build

Si la seconde exécution est nettement plus rapide, vous payez le traitement des images à chaque construction froide d’intégration continue, et le correctif est architectural plutôt qu’un drapeau de configuration.

Ce qui n’est pas du temps de construction

Deux choses se situent hors de la construction et méritent d’être écartées avant de l’optimiser.

Le temps d’attente en file. Sur une intégration continue partagée, une construction peut attendre avant de démarrer. Cela apparaît dans le tableau de bord comme une durée qui ne correspond pas aux horodatages du journal. Si vos constructions sont rapides mais que publier paraît lent, regardez là d’abord.

La propagation du CDN. Une fois le déploiement promu, les caches de bordure doivent le récupérer. Sur les hébergeurs modernes, c’est quasi instantané pour le HTML, mais une ressource mise en cache agressivement avec une longue durée et sans empreinte dans son nom peut rester périmée longtemps. Les noms de fichiers avec empreinte règlent la question, et Astro en produit par défaut pour les ressources empaquetées. Là où ça mord, c’est sur les fichiers gérés à la main dans public/.

Le regroupement, et pourquoi publier n’est pas toujours immédiat

Il y a un délai que nous ajoutons volontairement, et il mérite une explication parce qu’il ressemble à de la lenteur.

Un éditeur publie rarement une seule fois. Il corrige un titre, puis un tarif, puis repère une faute. Trois publications en quatre-vingt-dix secondes. Déclencher trois constructions signifie que deux sont gaspillées, qu’elles s’attendent, et que sur certains hébergeurs elles entrent en course d’une façon où la plus ancienne peut gagner et défaire discrètement la plus récente.

Les publications rapprochées sont donc fondues en une seule construction. Le coût est que le tout premier clic n’est pas toujours instantané. Le bénéfice est que les trois corrections de l’éditeur arrivent ensemble, une fois, dans le bon ordre.

Ce que vous pouvez réellement faire

Par ordre de rendement :

1. Sortir le traitement des images de la construction. Le plus gros gain, et c’est un choix de CMS.
2. Vérifier que votre cache de dépendances est chaud. Lisez un journal. Beaucoup découvrent qu’il n’a jamais fonctionné.
3. Utiliser un fichier de verrouillage figé. Une ligne dans votre configuration.
4. Récupérer le contenu depuis quelque chose de rapide et immuable. Un instantané sur CDN plutôt qu’une API vivante : la récupération se compte en millisecondes et ne peut pas être lente parce qu’un tiers a un mauvais après-midi.
5. Retirer les dépendances inutilisées.
6. Seulement ensuite, envisager l’incrémental, et seulement si votre nombre de pages est réellement élevé.

La limite honnête

Rien de tout cela ne rend un site statique instantané. Si votre client a besoin qu’une modification soit visible en dix secondes, le modèle statique est mauvais pour lui et le rendu serveur est bon, et aucune optimisation ne comble cet écart.

Ce que le modèle statique achète en échange, c’est un site qui ne coûte presque rien à héberger, absorbe les pics de trafic sans intervention, et n’a aucune dépendance à l’exécution vers le CMS : si nous sommes à terre, les sites publiés restent en ligne et les constructions aboutissent, parce que l’instantané est sur un CDN et non dans notre API.

Cet échange est bon pour un site vitrine et mauvais pour une rédaction. Savoir lequel des deux vous construisez est la vraie décision, et les quatre familles de CMS montre comment elle se décline.