## Quand un site statique suffit (et quand Astro l'accélère) Les sites statiques reviennent au centre des projets web orientés contenu : pages pré-générées, peu de JavaScript côté client, déploiement simple sur CDN. Selon la documentation officielle d'Astro, le framework vise précisément ce profil en ne chargeant que l'interactivité nécessaire sur chaque page. ## Concept central HTML pré-rendu, JavaScript minimal par défaut : des Core Web Vitals plus stables qu'avec une SPA complète. Build statique servi par Netlify, Vercel ou Cloudflare Pages, sans serveur Node permanent. Composants React, Vue ou Svelte intégrables à la demande, sans imposer un runtime lourd partout. Avant de migrer, listez les pages réellement dynamiques (compte utilisateur, panier, dashboard temps réel) : si la liste est courte, Astro reste souvent le meilleur compromis. ## Cas d'usage où Astro brille Astro convient particulièrement aux sites marketing, blogs, documentation produit et vitrines d'agence. Le projet démarre avec l'assistant officiel : ```bash npm create astro@latest ``` Les fichiers `.astro` mélangent markup, styles et logique serveur au build. Un composant minimal : ```astro --- // src/components/Header.astro ---

Bienvenue sur mon site Astro

``` Import dans une page : ```astro --- ---

``` Cette séparation garde le HTML lisible tout en permettant des îlots interactifs là où ils apportent de la valeur. ## Comparaison rapide avec d'autres approches - **Next.js** : pertinent si l'application est surtout dynamique (auth, API routes, rendu hybride intensif). - **Hugo ou Eleventy** : excellents pour du contenu pur Markdown, avec moins de composants UI multi-frameworks. - **WordPress ou CMS headless** : utiles quand l'équipe éditoriale non technique pilote le contenu au quotidien. Astro se situe entre générateur statique classique et framework UI moderne : plus flexible qu'un SSG minimaliste, plus léger qu'une application React full client. ## Limites à anticiper Un site Astro n'est pas la bonne base pour une marketplace temps réel ou un back-office collaboratif complexe. Les formulaires, recherches instantanées et personnalisations utilisateur demandent souvent des fonctions serverless ou un backend dédié en complément. La sécurité reste bonne grâce à la surface d'attaque réduite, mais les dépendances npm et les intégrations tierces restent à maintenir comme sur tout projet JavaScript. ## Checklist avant mise en production 1. **Valider le périmètre statique** : quelles routes restent en SSG, lesquelles passent en SSR ou en API ? 2. **Brancher le dépôt Git** sur la plateforme d'hébergement choisie (preview à chaque PR). 3. **Mesurer avec Lighthouse** : LCP, CLS et poids JavaScript par template de page. 4. **Prévoir l'évolution** : CMS headless, i18n ou blog si le volume de contenu augmente. ## Pour aller plus loin sur le blog Pour approfondir côté pratique, consultez Astro : guide d'installation rapide pour un site web performant et Astro 5 : repenser l'efficacité du web avec la génération statique. ## Sources - Astro : Why Astro? (documentation) - Astro, site officiel - Jamstack.org, architecture web moderne Choisir Astro, c'est accepter un modèle statique-first : moins de magie runtime, plus de pages rapides livrées dès le build.

#jamstack

Astro et sites statiques : quand choisir cette voie