Développement Astro
Le JavaScript le plus rapide est celui qu’on n’envoie pas
Astro génère vos pages à l’avance et n’embarque du code que là où quelque chose doit bouger. Ce site en est fait — c’est la démonstration la plus honnête que nous puissions en donner.
- Pages générées en statique, sans calcul à la visite
- React, Svelte, Vue.js ou Alpine.js, au choix par composant
- Optimisations poussées : les meilleurs scores Lighthouse
- Surface d’attaque réduite : rien à exécuter côté serveur
Le principe
Envoyer des pages, pas une application
Ce qui rend un site lent
La plupart des sites modernes envoient au navigateur un programme complet, qui reconstruit ensuite la page que le serveur aurait pu livrer telle quelle. Sur une fibre et un ordinateur récent, cela ne se voit pas. Sur un téléphone en 4G, cela se voit beaucoup.
Astro prend le problème dans l’autre sens : chaque page peut être générée en statique, d’où une vitesse d’exécution considérable, sans consommer de processeur ni de mémoire au moment de la visite. Le visiteur reçoit une page finie, pas les instructions pour la fabriquer.
Les îlots : du code seulement où il en faut
C’est l’idée qui distingue Astro. Un site n’a presque jamais besoin d’être interactif partout : un article, une fiche produit, une page de contact sont du texte et des images. Seuls quelques endroits bougent — un menu, un filtre, un panier.
Astro n’embarque donc du JavaScript que pour ces endroits-là. Mieux : chaque morceau de page prend vie grâce au framework avec lequel son composant a été écrit — React, Svelte, Vue.js ou Alpine.js peuvent coexister dans la même page. Vous n’êtes pas enfermé dans un écosystème, et une équipe qui connaît l’un d’eux reste opérationnelle.
Ce que ça donne, mesurable
Le framework prend en charge les optimisations les plus poussées, celles qui permettent d’atteindre les meilleurs scores Lighthouse. Ce n’est pas un argument théorique : la vitesse est un critère de référencement, et une page lente perd ses visiteurs avant de s’être affichée.
Autre bénéfice, moins évoqué : cela rend l’attaque du site nettement plus difficile. Une page statique n’interroge aucune base et n’exécute aucun module à la demande — il n’y a tout simplement pas grand-chose à attaquer.
Ce n’est pas la réponse à tout
Astro convient aux sites dont le contenu peut être connu à l’avance : vitrines, catalogues, blogs, documentation, sites éditoriaux. Il s’emploie particulièrement bien sur les projets de taille modeste.
Dès qu’une application demande des écrans personnalisés par utilisateur, des données qui changent à la seconde ou une logique métier lourde côté navigateur, un autre outil est plus adapté — et nous vous le dirons. Le bon réflexe n’est pas de choisir Astro par principe, mais de vérifier si le site a réellement besoin d’être une application.
Les usages
Ce que nous construisons avec
-
Sites vitrines et éditoriaux
Le terrain naturel : des pages dont le contenu est connu à l’avance, servies instantanément. C’est exactement ce que vous lisez en ce moment.
-
Îlots interactifs
Menu, filtres, recherche, panier : du code seulement là où quelque chose bouge, dans le framework qui convient à chaque composant.
-
Branché sur un CMS
Le contenu peut venir d’un WordPress ou d’un CMS headless : vos équipes gardent l’interface qu’elles connaissent, la vitrine devient statique.
-
Pensé pour le référencement
Les pages existent avant la visite et s’indexent normalement — l’inverse d’une application front, dont le référencement est souvent impossible.
-
Peu de surface d’attaque
Ni base interrogée ni module exécuté à la demande sur la vitrine. La sécurité d’un site statique est d’abord une question de ce qu’il ne fait pas.
-
Hébergement léger
Sans processeur ni mémoire consommés à chaque visite, un site Astro tient sur une offre modeste — y compris sous un trafic qui ferait plier un site classique.
Questions fréquentes
Astro : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Astro est-il un outil sérieux ?
Son nom est moins connu que d’autres, mais Porsche, NordVPN et The Guardian l’utilisent — et ce site aussi, ce qui est la démonstration la plus vérifiable que nous puissions donner. Vous pouvez en juger sur pièces : sa vitesse d’affichage est le premier argument de la technologie.
Pourrai-je modifier mon contenu moi-même ?
Oui, à condition de le prévoir : le contenu peut venir d’un WordPress ou d’un CMS headless, dont vos équipes gardent l’interface d’administration. C’est le point à trancher au début du projet, parce qu’il détermine la chaîne de publication.
Astro ou Next.js ?
Astro quand le site est d’abord fait de pages : vitrine, catalogue, blog, documentation. Next.js quand il s’agit d’une application riche, avec des écrans personnalisés par utilisateur et une logique importante côté navigateur. La question à se poser n’est pas laquelle des deux, mais si votre projet est un site ou une application.
Faut-il un hébergement particulier ?
Non, plutôt l’inverse : un site généré en statique ne consomme ni processeur ni mémoire à la visite, donc il tient sur une offre modeste et encaisse des pics qui feraient plier un site classique. Nos offres mutualisées y suffisent largement.
Et si le projet évolue vers une application ?
Les îlots permettent d’ajouter de l’interactivité progressivement, sans tout reprendre. Mais si la part applicative devient majoritaire, mieux vaut le reconnaître et changer d’outil que de forcer Astro à faire ce pour quoi il n’est pas fait — nous vous le dirons franchement.
Votre projet est-il un site ou une application ?
C’est la question qui désigne l’outil. Décrivez-nous ce que la page doit faire, et nous vous dirons si Astro est le bon choix — ou s’il ne l’est pas.