SPA
Définition
Single Page Application. Application web qui charge une seule page HTML puis met à jour le contenu dynamiquement via JavaScript. Idéal pour les dashboards et apps internes, moins pour le SEO public.
Comment ça marche
Une SPA (Single Page Application) charge une seule page HTML au démarrage, puis met à jour le contenu dynamiquement en JavaScript, sans recharger le navigateur entre deux écrans. Le routage se fait côté client : quand vous cliquez sur un lien, le JS attrape l'événement, change l'URL via l'API History, et remplace le contenu visible. Les données arrivent via des appels API en arrière-plan. C'est l'architecture historique de React, Vue ou Angular sans rendu serveur, et le modèle qui a popularisé les transitions fluides à la Gmail ou à la Trello.
À quoi ça sert
La SPA brille sur les applications où l'utilisateur reste connecté longtemps et enchaîne de nombreuses actions : dashboards SaaS, back-offices métier, outils internes, éditeurs en ligne. Les transitions instantanées améliorent l'expérience perçue, l'état applicatif (filtres, sélections, modales) survit aux changements de page, et le serveur n'a plus qu'à renvoyer des données. Pour ce type d'usage, où le SEO n'a aucune importance et où l'utilisateur charge l'app une fois pour la journée, la SPA reste un choix parfaitement valable en 2026.
Quand ne pas l'utiliser
Une SPA pure ne fonctionne pas pour un site public où le SEO compte. Google crawle de mieux en mieux le JavaScript, mais voir une page vide au premier rendu reste un handicap pour l'indexation et pour le LCP. Tous les sites de contenu (blogs, e-commerce, vitrines, marketplaces, documentations) doivent rendre leur HTML côté serveur. De même, pour les apps mobiles avec connexion réseau faible, charger 500ko de JS avant de pouvoir cliquer ne tient pas. La SPA est un outil d'application, pas de site public.
Les limites à connaître
Trois limites reviennent. La performance de premier rendu : le navigateur télécharge, parse et exécute beaucoup de JavaScript avant que l'écran ne devienne utile, ce qui pèse sur les utilisateurs lents ou mobiles. L'accessibilité : sans rendu serveur, les lecteurs d'écran ont parfois du mal avec les changements de route gérés en JS, il faut soigner explicitement l'annonce des transitions. Et la mémoire : une SPA ouverte plusieurs heures peut accumuler des fuites mémoire si l'équipe n'est pas vigilante sur le nettoyage des effets et abonnements.
Les alternatives modernes
Pour un site public, on préfère le SSR ou le SSG via Next.js, Astro ou Remix. Ces frameworks rendent le HTML côté serveur puis hydratent l'interactivité côté client : on garde la fluidité d'une SPA après le premier chargement, sans pénaliser le SEO ni le LCP. Pour une app interne où le SSR n'apporte rien, on peut rester sur une SPA pure (Vite + React Router), qui démarre vite et reste simple à déployer sur un CDN. Le bon choix dépend du public et du contexte, pas d'une idéologie technique.
Les bonnes pratiques
Sur une SPA sérieuse, on découpe le bundle JavaScript par route (code splitting) pour éviter de tout charger d'un coup. On utilise React Query, SWR ou TanStack Query pour gérer le cache des appels API et l'état serveur proprement. On installe un Service Worker pour servir l'app hors-ligne quand c'est pertinent. On instrumente les métriques de performance (LCP, INP, taux d'erreur) pour détecter les régressions. Et on sépare clairement l'état serveur (données distantes), l'état URL (filtres, pagination) et l'état UI (modales, formulaires en cours).