Single-page application (SPA) : expliqué simplement.

Une single-page application (SPA) est une application web qui charge une seule page HTML puis met à jour son contenu dynamiquement avec du JavaScript au fil de la navigation, au lieu de demander une nouvelle page complète au serveur à chaque clic. Gmail, Trello et la plupart des applications construites avec React, Vue ou Angular fonctionnent ainsi : le navigateur récupère la coquille de la page et un bundle JavaScript au départ, puis remplace les vues dans le DOM sans rechargement complet. La navigation paraît instantanée, plus proche d'une application native que d'un site web classique.

La contrepartie, c'est que le navigateur fait plus de travail au démarrage, et que l'application a besoin de sa propre logique de routage pour que l'URL, l'historique du navigateur et le bouton retour se comportent correctement, puisqu'un seul document est techniquement servi.

Lors de la première requête, le serveur envoie une coquille HTML quasi vide accompagnée d'un bundle JavaScript. Une fois chargé, un routeur côté client intercepte les clics sur les liens et met à jour l'URL et le contenu visible sans demander de nouveau document au serveur. Une route minimale côté client peut ressembler à ceci :

const routes = {
'/': HomePage,
'/tarifs': PricingPage,
'/contact': ContactPage,
};

window.addEventListener('popstate', () => {
render(routes[location.pathname] || NotFoundPage);
});

Les données qui arrivaient auparavant intégrées dans une page rendue côté serveur passent désormais par des appels API depuis le navigateur, en général des endpoints REST ou GraphQL, et l'interface se met à jour dès que la réponse arrive, sans transition de page visible.

• Rendu côté client (CSR) : le navigateur construit toute la page à partir du JavaScript ; navigation rapide, mais premier affichage plus lent et SEO natif plus faible.
• Rendu côté serveur (SSR) : le serveur affiche la première vue en HTML, puis la SPA prend le relais ; premier affichage plus rapide, meilleure indexation.
• Génération de site statique (SSG) avec hydratation côté client : les pages sont pré-construites au déploiement, puis deviennent interactives une fois le JavaScript chargé.
• Progressive web app (PWA) : une SPA qui fonctionne aussi hors ligne et peut s'installer comme une application native, via un service worker et un manifeste web.

React, Vue et Angular restent les frameworks les plus utilisés pour construire des SPA, souvent associés à un méta-framework comme Next.js, Nuxt ou Angular Universal pour ajouter du rendu côté serveur quand le SEO ou la vitesse de premier chargement comptent.

• Rendre le contenu critique côté serveur (SSR ou SSG) dès qu'une page doit se positionner dans les résultats de recherche, car une page purement rendue côté client peut retarder l'indexation.
• Garder le bundle JavaScript initial léger et le découper par route, pour ne pas forcer l'utilisateur à télécharger toute l'application avant de voir le premier écran.
• Mettre à jour le titre de la page et les balises meta à chaque changement de route ; sans cela, toutes les vues de la SPA peuvent partager la même balise title.
• Préserver le comportement normal du navigateur (bouton retour, liens directs, actualisation de page) grâce à un routage côté client bien conçu, sinon un lien profond peut atterrir sur une page blanche.

Une SPA qui rend tout côté navigateur peut pénaliser le Largest Contentful Paint (LCP) et le Time to Interactive, car la page reste visuellement vide tant que le bundle JavaScript n'a pas été téléchargé, analysé et exécuté. Les moteurs de recherche savent indexer du contenu rendu en JavaScript, mais le budget de crawl et les délais de rendu rendent le rendu côté serveur ou la génération statique plus sûrs pour les pages qui dépendent du trafic organique. Un tableau de bord ou un outil interne derrière une connexion a beaucoup plus de liberté pour rester purement rendu côté client, puisqu'il n'est jamais destiné à se positionner.

Nous développons des SPA pour nos clients quand le produit a besoin d'une expérience proche d'une application (tableaux de bord, configurateurs, espaces membres), et nous les associons à du rendu côté serveur ou à de la génération statique dès qu'une page publique doit aussi se positionner dans les résultats de recherche. Le produit reste ainsi rapide et interactif sans sacrifier l'indexabilité des pages qui génèrent du trafic. Voir notre service web apps pour savoir comment nous concevons ces interfaces.