{product.description}
``` Ce code est volontairement simplifié : il suppose que le contenu de l’API peut être chargé en bloc et qu’une fiche statique n’exige pas un rafraîchissement immédiat. Sur une vraie plateforme, on choisira une couche de données commune, un cache maîtrisé et, si nécessaire, une pagination ou des appels groupés. **Le stock ou les prix très variables ne doivent pas être figés sans stratégie d’actualisation** : ils peuvent nécessiter du rendu à la demande. Les autres pistes suivent la même logique : éliminer les traitements Markdown redondants, examiner les plugins Vite, éviter les calculs répétés dans un layout et repérer les conversions d’images anormalement nombreuses. Chaque changement doit correspondre à une hypothèse vérifiable dans ` --timings `. ## 4. Avant/après : établir une comparaison fiable Il est tentant de comparer une exécution locale avec un build effectué sur un autre ordinateur ou dans une CI. Pourtant, CPU, mémoire, état du cache, débit de l’API, versions de Node.js et contenu exact peuvent modifier les temps mesurés. La comparaison n’a de valeur qu’à **périmètre constant**. ## Notre protocole reproductible en six étapes 1. **Figer les données :** mêmes 600 produits, mêmes images et dépendances verrouillées. 2. **Noter le contexte :** CPU, RAM, Node.js, version Astro, CI, état du cache. 3. **Exécuter le build de référence :** conserver le rapport ` --timings ` de plusieurs essais. 4. **Modifier une seule cause :** par exemple des requêtes indépendantes ou un traitement d’image. 5. **Mesurer de nouveau :** utiliser le même environnement et comparer les médianes. 6. **Vérifier la qualité :** contrôler les 600 pages, les données, les liens et les erreurs. Un protocole pratique consiste à effectuer **cinq exécutions par variante**, en distinguant bien builds à cache froid et builds à cache chaud. C’est une méthode proposée pour l’article, pas une valeur de référence officielle d’Astro. | Tableau de relevé du catalogue | Avant | Après | | --- | --- | --- | | Temps total médian | À mesurer | À mesurer | | Phase « generate pages » | À mesurer | À mesurer | | Transformations d’images | À mesurer | À mesurer | | Mémoire maximale en CI | À mesurer | À mesurer | | Nombre de pages produites | 600 attendues | 600 attendues | **Pourquoi ces cellules ne contiennent-elles aucun chiffre ?** Parce qu’aucune compilation de ce catalogue fictif n’a été effectuée. Un article technique fiable doit distinguer le protocole proposé des résultats réellement obtenus. ## 5. Faut-il activer le prérendu parallèle expérimental ? Astro 7.4 introduit ` experimental.parallelPrerender `, qui répartit le prérendu statique sur plusieurs **worker threads Node.js**. Ce mécanisme peut être pertinent sur des projets riches en calcul, avec plusieurs cœurs disponibles. Il s’active par exemple ainsi : ``` // astro.config.mjs — test uniquement import { defineConfig } from "astro/config"; export default defineConfig({ experimental: { parallelPrerender: { workers: 4 }, }, }); ``` Par défaut, Astro utilise tous les cœurs disponibles sauf un lorsque l’option est activée sans nombre de workers explicite. Chaque worker peut générer plusieurs pages selon ` build.concurrency `, mais il **augmente aussi la consommation mémoire**. Une machine disposant de peu de mémoire ou un build limité par des services réseau n’en tirera pas forcément avantage. **Attention : expérimental** ## Cloudflare et mémoire : deux limites importantes L’option est ignorée lorsque l’adaptateur possède son propre système de prérendu. Parmi les adaptateurs officiels, c’est notamment le cas de ` @astrojs/cloudflare `, pour lequel Astro affiche un avertissement. Mesurez les temps, le nombre de cœurs réellement exploités et le pic mémoire avant de conserver le réglage. Le bon ordre est donc : supprimer d’abord les appels API inutiles, vérifier les postes coûteux avec ` --timings `, puis comparer les configurations de workers seulement lorsque le rendu CPU constitue un goulot d’étranglement démontré. ## 6. Images, compatibilité Node.js et autres nouveautés ### Deux services d’images pour deux environnements Astro 7.4 autorise un service pour les **pages prérendues au build** et un autre pour les **pages rendues à la demande**. On peut, par exemple, utiliser Sharp pendant la construction et un service CDN adapté au runtime de production : ``` // astro.config.mjs import { defineConfig } from "astro/config"; export default defineConfig({ image: { service: { build: { entrypoint: "astro/assets/services/sharp" }, runtime: { entrypoint: "my-image-cdn-service" }, }, }, }); ``` Le nom ` my-image-cdn-service ` est un **placeholder**, et non un module prêt à l’emploi : il doit être remplacé par un service d’images compatible installé et configuré. Le service de build sert aussi pendant le développement ; le service runtime est destiné aux pages à la demande et à l’endpoint d’images en production. Le service unique traditionnel reste pris en charge. ### Node.js 22.22.0 devient le minimum supporté Astro 7.4 et ses intégrations officielles exigent au minimum **Node.js 22.22.0**. Il faut donc vérifier à la fois les postes de développement, les images Docker, la CI et l’hébergement, puis tester les dépendances lors de la mise à jour. La commande de migration recommandée est : ``` npx @astrojs/upgrade ``` Les intégrations ` @astrojs/cloudflare ` et ` @astrojs/markdoc ` doivent également être actualisées vers leurs versions compatibles avec ` astro@^7.4.0 `. Pensez à sauvegarder le projet et à valider le résultat du build avant déploiement. Parmi les changements annexes figurent le nouveau gestionnaire ` notFound() ` pour les points d’entrée construits avec ` astro/fetch ` ou ` astro/hono `, une meilleure détection des paramètres de polices non pris en charge par leur fournisseur et une **page de redirection statique personnalisée, expérimentale**. ## 7. Génération, chargement et SEO : ne pas mélanger les indicateurs **La performance de génération** mesure la rapidité du travail effectué avant la mise en ligne : compilation, récupération des données, traitements et production des fichiers. Elle affecte surtout les équipes, l’intégration continue et les délais de déploiement. **La performance de chargement** concerne l’expérience des visiteurs : temps réseau, JavaScript, polices, images, cache et réactivité. Les **Core Web Vitals** évaluent notamment le LCP (chargement), l’INP (interactions) et le CLS (stabilité visuelle). ` --timings ` ne mesure aucun de ces indicateurs. **Le SEO technique** dépend aussi de l’indexabilité, des balises, de la structure HTML, des URL canoniques, du maillage et du sitemap. Un build plus rapide ne corrige pas automatiquement ces problèmes. Il faut mesurer les Core Web Vitals et contrôler séparément le contenu rendu et son accessibilité aux moteurs de recherche. Si l’enjeu concerne surtout la taille des images livrées au navigateur, notre article sur [JPEG XL, WebP et AVIF](https://sdx-development.com/actualites/developpement-web/chrome-155-jpeg-xl-optimisation-images-web) couvre un chantier complémentaire : le poids transféré aux utilisateurs n’est pas la même chose que le temps de traitement des images durant la génération. ## FAQ : les questions courantes sur Astro 7.4 ### Est-ce que ` --timings ` accélère le site ? Non. Le rapport identifie des lenteurs du build ; il faut encore corriger leur cause et mesurer l’effet réel des changements. Il n’agit pas directement sur l’expérience des visiteurs. ### Comment repérer un composant Astro coûteux ? Observez les pages les plus lentes et la section de rendu des composants, puis inspectez les layouts communs, les requêtes, les boucles coûteuses et les traitements externes. Le rapport oriente l’enquête, sans indiquer à lui seul une ligne de code précise. ### Le prérendu parallèle fonctionne-t-il sur Cloudflare ? La fonctionnalité expérimentale est ignorée par ` @astrojs/cloudflare `, dont le système gère déjà son propre prérendu. Il ne faut donc pas lui attribuer des gains inexistants. ### Faut-il migrer immédiatement vers Astro 7.4 ? L’outil de diagnostic vaut le test sur un build lent. Avant une migration durable, vérifiez la version minimale de Node.js, les intégrations et l’environnement de déploiement. L’option de timings peut être utilisée sans activer le prérendu parallèle. ## Conclusion : des optimisations guidées par les mesures La nouveauté la plus utile d’Astro 7.4 est la **visibilité sur la chaîne de génération**. Avec ` astro build --timings `, on peut identifier un appel externe répétitif, un composant lent ou une transformation coûteuse, traiter cette cause et comparer le résultat. Le prérendu parallèle et les services d’images séparés répondent à d’autres besoins, mais ne remplacent pas cette démarche. Chez **SDX Development**, cette logique s’applique à la conception, à la refonte et à l’optimisation des sites professionnels : livrer plus efficacement, conserver un socle maintenable et vérifier indépendamment la performance ressentie par les visiteurs. Sources et méthodologie 4 références - [Astro — Astro 7.4](https://astro.build/blog/astro-740/), annonce officielle du 15 octobre 2026 et exemple 2,10 → 1,13 seconde. - [Astro — Documentation de la CLI](https://docs.astro.build/en/reference/cli-reference/), description de ` --timings `. - [Astro — Prérendu parallèle expérimental](https://docs.astro.build/en/reference/experimental-flags/parallel-prerender/), configuration et limites. - [web.dev — Web Vitals](https://web.dev/articles/vitals?hl=fr), définition des métriques d’expérience utilisateur. Le tableau de mesures officielles concerne le projet de démonstration Astro, et non un catalogue réel. Le cas de 600 fiches constitue une méthode reproductible dont les résultats restent à mesurer. DÉVELOPPEMENT WEB ## Préparez les évolutions de votre application web. Migration PHP, mise à jour de CMS ou évolution de framework : identifiez les points de compatibilité et validez les parcours essentiels avant la mise en ligne. - Compatibilité des dépendances vérifiée - Parcours essentiels testés en préproduction - Mise en ligne avec possibilité de retour arrière [Préparer votre évolution](https://sdx-development.com/contact)[Voir les expertises](https://sdx-development.com/expertises) --- [Consulter la page HTML](https://sdx-development.com/actualites/developpement-web/astro-7-4-build-timings-optimiser-generation-site)