Choisir un framework JavaScript pour site vitrine : le guide malin

Un client m'appelle l'an dernier pour un site de dix pages. Présentation de sa boîte, trois services, un formulaire de contact, une page équipe. Un site vitrine, quoi. Il me demande : « On part sur React ou Vue ? » Je lui réponds : « Ni l'un ni l'autre. » Silence gêné. Il croyait que je voulais lui vendre un truc à la place. Non. C'est juste que pour ce projet, un framework JavaScript, ça allait lui coûter du temps, de l'argent et un référencement moins bon. Rien d'autre.

Cette conversation, je l'ai eue au moins une fois par mois depuis. Et à chaque fois, le même réflexe : on assimile « site web » à « application web », et donc à framework front-end. Sauf qu'un site vitrine n'a rien d'une application. Il affiche du contenu. Il n'a quasiment jamais d'état à gérer, pas de login, pas de panier. Alors pourquoi vouloir choisir un framework JavaScript pour un site vitrine quand un simple HTML bien écrit fait souvent mieux le travail ?

Pourquoi un site vitrine n'est pas une application web

Un site vitrine, ça veut dire quoi concrètement ? Quelques pages statiques : accueil, services, à propos, contact. Du texte, des images, un formulaire. Parfois un blog. C'est tout. Pas de compte utilisateur, pas de dashboard, pas de données chargées en temps réel.

Un framework JS, à l'inverse, a été conçu pour gérer de l'état. Changer un panier, rafraîchir une liste, réagir à un clic. C'est ce qu'on appelle la réactivité. Eh bien, sur un site vitrine, il n'y a rien à rendre réactif. Le contenu ne bouge pas.

Le poids inutile du JavaScript

Voilà le point que personne ne mentionne dans les comparatifs React vs Vue. Chaque framework envoie au navigateur du visiteur une bibliothèque JavaScript entière, même si votre page ne contient que trois paragraphes. React, c'est environ 45 ko compressés rien que pour le runtime. Vue, un peu moins. Svelte, beaucoup moins. Mais tout ça reste du code exécuté pour afficher du texte.

Sur ma propre plaquette en ligne (que j'ai refaite en HTML statique il y a deux ans), j'ai mesuré la différence : un score Lighthouse de 68 en version React contre 98 en version HTML pur. Même contenu. Même design. Le JS en trop plombait le rendu.

Ce que ça change pour le SEO

Google mesure la vitesse de chargement. Un site qui met trois secondes à afficher son contenu parce que le navigateur doit d'abord télécharger et exécuter un bundle JS, c'est un site pénalisé. Pas dramatiquement. Mais suffisamment pour perdre quelques places sur une requête concurrentielle.

Le SSG (génération statique) règle ce problème : on pré-génère le HTML au moment du build. Sauf que si vous pré-générez tout en HTML, pourquoi utiliser React pour le faire ? C'est la question qu'on ne se pose pas assez.

Quand un framework JavaScript se justifie vraiment

Je ne suis pas un ayatollah du HTML. Il y a des cas où un framework est la bonne réponse. Encore faut-il identifier lesquels.

Les signaux qui doivent vous alerter

• Vous prévoyez d'ajouter un espace client dans les six mois
• Le site doit afficher des données dynamiques issues d'une API (tableau de bord, prix en temps réel)
• Plusieurs personnes non techniques vont éditer le contenu régulièrement et vous voulez un vrai CMS headless
• Vous avez déjà une équipe React en interne et le coût d'apprentissage d'un autre outil dépasse le gain

Vous voyez le point commun ? Aucun de ces cas ne décrit un site vitrine classique. Ce sont des projets qui vont grandir vers une application. Dans ce cas-là, oui, choisissez votre framework maintenant. Sinon, non.

Le cas du blog avec des milliers d'articles

Là, nuance. Un site vitrine avec un blog très lourd (plusieurs milliers d'articles, recherche interne, filtres par catégorie) peut justifier Next.js ou Nuxt. Pas pour le rendu des pages, mais pour la gestion de la recherche et du routage. Encore une fois : le contenu n'est pas le problème, c'est l'outillage autour.

Sur un projet client l'an dernier, 1 800 articles, on est parti sur Nuxt. Pas par mode. Parce qu'on avait besoin d'un rendu hybride (SSR pour les pages dynamiques, SSG pour les articles figés) et d'une couche API unifiée. Sur les dix autres sites vitrines que j'ai livrés cette année-là, zéro framework JS. Aucun client ne s'en est plaint.

Les bonnes options en 2026

Si vous abandonnez l'idée du framework JS classique, par quoi remplacer ?

Astro

C'est mon outil par défaut pour un vitrine aujourd'hui. Astro génère du HTML statique et n'envoie quasiment aucun JavaScript au navigateur par défaut. Il permet d'utiliser des composants React, Vue ou Svelte si vous en avez besoin quelque part, mais uniquement là où c'est nécessaire. Le reste reste du HTML.

Franchement, pour 90 % des sites vitrines que je vois passer, Astro fait tout ce dont on a besoin. Le build est rapide, le SEO excellent, et les clients peuvent brancher un CMS headless dessus sans douleur.

Eleventy (11ty)

Plus minimaliste encore. Pas de JS par défaut, pas de composant, juste des templates et du contenu. On écrit en Markdown, on génère en HTML. C'est brutalement efficace. Je l'utilise pour les projets où le client veut vraiment zéro dépendance et une maintenance à long terme sans surprise.

Le revers : la courbe d'apprentissage est faible, mais l'écosystème est petit. Vous êtes un peu seul si vous cherchez un plugin spécifique.

HTML/CSS pur

Avouons-le : pour cinq pages sans blog, on peut très bien écrire du HTML à la main. Deux heures de travail. Aucune dépendance. Le site tiendra dix ans sans qu'une mise à jour de framework ne casse quoi que ce soit. Je l'ai fait pour mon propre site perso. Il n'a pas bougé depuis trois ans.

WordPress

Si le client veut gérer son contenu sans vous appeler tous les mardis, WordPress reste la réponse la plus pragmatique. Ce n'est pas un framework JavaScript, et c'est justement l'idée. Le code servi au visiteur est du HTML, généré côté serveur. Le back-office, lui, propose une interface familière.

Pour un site vitrine d'une PME, c'est souvent le vrai choix rationnel. On l'oublie parce que ce n'est pas « moderne ». Mais un site WordPress bien configuré (cache, thème léger, hébergement correct) charge en moins d'une seconde chez la plupart des visiteurs.

Tableau comparatif : quel outil pour quel site vitrine

Outil	Type de site idéal	JS envoyé au visiteur	Effort d'apprentissage
HTML/CSS pur	1 à 5 pages, pas de blog	Aucun	Faible
Astro	Vitrine + blog, besoin ponctuel de composants	Minimal, à la carte	Modéré
Eleventy	Contenu en Markdown, zéro dépendance	Aucun, sauf ajout manuel	Faible à modéré
WordPress	Client qui édite lui-même	Aucun (rendu serveur)	Faible côté client, géré par vous
Next.js / Nuxt	Vitrine qui deviendra une application	Variable, souvent lourd	Élevé
React / Vue / Svelte seuls	Application web, pas site vitrine	Toujours lourd	Modéré à élevé

Vous remarquerez que les frameworks JS classiques apparaissent en bas du tableau. Ce n'est pas un hasard. Ce ne sont pas de mauvais outils. Ce sont juste des outils qui ne sont pas conçus pour ce cas d'usage.

Les critères qui comptent vraiment pour un vitrine

Si vous devez évaluer une option, voici les questions à poser dans cet ordre précis.

1. Est-ce que le contenu change sans intervention humaine technique ? Si non, un générateur statique suffit.
2. Combien de JavaScript part au navigateur ? Testez, ne croyez pas les docs. Un outil qui promet « léger » peut quand même envoyer 80 ko si vous ne faites pas attention.
3. Qui va maintenir ça dans trois ans ? Si ce n'est pas vous, choisissez l'outil le plus répandu et le mieux documenté, même s'il est ennuyeux.
4. Quel est le coût d'hébergement ? Un site statique se déploie gratuitement chez Netlify, Vercel ou Cloudflare Pages. Un site Nuxt/Next avec SSR nécessite un serveur Node qui tourne en permanence. La différence se chiffre à quelques euros par mois, mais ça s'accumule sur dix ans.
5. À quoi ressemblera la migration si vous changez d'avis ? Du HTML, c'est du HTML. On peut le déplacer partout. Du Next.js, c'est un écosystème. On ne migre pas sans casse.

La popularité sur GitHub, le nombre d'étoiles, les classements annuels : tout ça n'a aucune importance pour un site vitrine de dix pages. Ce sont des signaux utiles pour un développeur qui construit une application. Pas pour un client qui veut une plaquette.

Et si le client insiste pour du React ?

Ça arrive. Souvent parce qu'il a lu un article, ou parce qu'il veut réutiliser son équipe front. Dans ce cas, ne vous braquez pas. Proposez Next.js en mode statique (export statique), qui génère du HTML à la compilation. Vous obtiendrez la plupart des bénéfices d'un site statique tout en gardant React côté développement. C'est un compromis raisonnable.

Mais dites-lui clairement le coût. Le build sera plus long, le site un peu plus lourd, et le jour où il voudra changer de framework, il faudra tout réécrire. Un bon client préfère entendre ça maintenant.

Mon avis sans détour

Pour choisir un framework javascript pour site vitrine, la bonne réponse en 2026 est presque toujours « n'en choisissez pas ». Astro si vous voulez un outil moderne. Eleventy si vous aimez le minimalisme. HTML pur si vous êtes sûr de ne rien vouloir ajouter. WordPress si le client gère son contenu.

React, Vue, Svelte et Angular sont d'excellents outils. Ils sont faits pour construire des applications où l'utilisateur interagit, où les données bougent, où l'état change. Sur un site vitrine, vous allez payer leur complexité sans jamais toucher à leur vraie valeur.

La prochaine fois qu'un client vous demande quel framework choisir pour son site vitrine, posez-lui une seule question avant de répondre : « Est-ce que vous prévoyez d'ajouter un espace client ou une fonctionnalité qui nécessite une connexion ? »

S'il dit non, vous avez votre réponse. S'il dit oui, vous avez déjà commencé à construire une application, et le site vitrine n'est plus le vrai sujet.