Application monopage (SPA) : définition et compromis

Qu'est-ce qu'une application monopage (SPA) ?

Une application monopage (SPA, pour single page application) charge un seul document web, puis met à jour son contenu en JavaScript, généralement en récupérant des données auprès d'une API, au lieu de demander au serveur une nouvelle page HTML à chaque clic. La barre d'adresse change tout de même et le bouton retour fonctionne, car l'application gère elle-même l'URL. MDN la définit de la même façon et en note le coût : le SEO, l'état, la navigation et la surveillance des performances demandent plus d'efforts que sur un site classique à plusieurs pages.

Comment fonctionne une SPA

1. Le navigateur demande la page et le serveur renvoie une petite coquille HTML avec des références à des bundles JavaScript.
2. Le navigateur télécharge et exécute les bundles, et le framework affiche la première vue dans le navigateur. C'est le rendu côté client.
3. Le clic sur un lien est intercepté par un routeur côté client, qui met à jour l'URL via la History API et affiche la vue suivante sans demander de nouveau document.
4. Chaque vue récupère les données dont elle a besoin auprès de votre backend, en général du JSON via HTTP.

Le premier chargement paie donc le téléchargement et l'exécution de l'application, et chaque navigation suivante se résume à un appel d'API et un rendu.

SPA et application multipage (MPA)

La frontière est aujourd'hui floue. Des frameworks comme Next.js rendent d'abord côté serveur, puis s'hydratent en SPA dans le navigateur : un même site peut donc avoir les deux.

SPA et SEO

Google exécute le JavaScript avec un Chromium sans interface, mais dans une étape distincte après l'exploration, et il ne suit que les liens qui sont de vrais éléments <a href>. Les bases du SEO JavaScript de Google indiquent que le rendu côté serveur ou le prérendu restent une bonne idée, car c'est plus rapide pour les utilisateurs et tous les robots n'exécutent pas le JavaScript. Trois points pratiques tirés de ce guide :

• Utilisez de vrais chemins avec la History API, pas des routes en #/fragment.
• Une application routée côté client ne peut pas envoyer seule un vrai statut 404 pour une page inexistante. Redirigez vers une URL qui renvoie 404, ou ajoutez une balise robots noindex, pour que les pages inexistantes ne soient pas indexées comme des soft 404.
• Ne bloquez pas vos fichiers JavaScript dans le robots.txt.

Exemple

Un outil de gestion de projet est une SPA typique. Après connexion, l'utilisateur ouvre un tableau, déplace une carte et modifie un commentaire, et chaque action appelle une API sans recharger la page. Le site marketing du même produit est un mauvais candidat pour une SPA : il a besoin d'un premier affichage rapide et d'un texte explorable, et se sert mieux en HTML statique ou rendu côté serveur.

Erreurs fréquentes

• Un seul bundle énorme. Livrer toutes les routes d'emblée retarde la première vue. Découpez le code par route et chargez les composants lourds en chargement différé.
• Construire les pages marketing en SPA pure. Les robots et les appareils lents reçoivent d'abord une coquille vide.
• Historique cassé. Des vues sans URL propre font échouer le bouton retour, les favoris et le partage.
• Pas d'états de chargement ni d'erreur. Un écran blanc pendant le chargement des données paraît en panne. Utilisez des squelettes et des limites d'erreur pour qu'un composant défaillant ne fasse pas tomber toute l'application.
• Ne mesurer que le premier chargement. Dans une SPA, l'essentiel de l'expérience a lieu après la navigation, ce qu'un test de page ponctuel ne montre pas.

Tester et surveiller une SPA

Une SPA déplace du travail vers le navigateur et fait de votre backend une API : testez donc les deux moitiés.

• Vitesse de rendu : suivez le Largest Contentful Paint et les autres Core Web Vitals. La surveillance de la vitesse des pages de LoadFocus exécute Lighthouse depuis des emplacements cloud à intervalles réguliers, et la surveillance des utilisateurs réels montre ce que vivent vraiment les visiteurs lors des navigations côté client.
• Capacité de l'API : chaque vue est un appel d'API, donc un pic de trafic frappe votre backend. Les tests de charge de LoadFocus exécutent des scripts JMeter et k6 depuis plus de 25 régions cloud. Ces outils travaillent au niveau du protocole et n'exécutent pas le JavaScript de votre frontend : ils mesurent les API appelées par la SPA, pas le rendu dans le navigateur.

Pour une démarche pas à pas, lisez comment optimiser les tests de charge des applications monopage (en anglais).

Questions fréquentes : application monopage

Les SPA sont-elles mauvaises pour le SEO ?

Pas par nature, mais une SPA rendue uniquement côté client donne aux robots une coquille vide tant que le JavaScript ne s'exécute pas. Le rendu côté serveur ou le prérendu, de vraies URL et des codes de statut corrects suppriment l'essentiel du risque.

Google indexe-t-il les SPA ?

Oui. Google exécute le JavaScript avec un Chromium sans interface avant d'indexer. Le rendu est une étape distincte : un contenu qui doit être indexé rapidement est plus sûr dans le HTML initial.

Quelle différence entre une SPA et le rendu côté client ?

Le rendu côté client décrit la manière dont le contenu est affiché : dans le navigateur, en JavaScript. Une SPA est un style d'application avec un seul document et une navigation côté client. La plupart des SPA utilisent le rendu côté client, mais une application rendue d'abord côté serveur, qui reprend ensuite la navigation dans le navigateur, reste une SPA.

Quelle différence entre une SPA et une PWA ?

Une application web progressive ajoute à une application web l'installation, le mode hors ligne et les service workers. Beaucoup de PWA sont des SPA, mais une SPA n'est pas automatiquement une PWA.

Quand éviter de construire une SPA ?

Pour les sites éditoriaux comme les blogs, la documentation et les pages marketing, où comptent surtout un premier affichage rapide et la visibilité dans les moteurs de recherche. Des pages statiques ou rendues côté serveur y conviennent mieux.