Les applications à page unique (SPA) existent depuis des années et sont utilisées pour créer des plateformes et des sites Web tels que Facebook, Gmail et Netflix. Plus récemment, cependant, les SPA ont été utilisés pour créer des sites Web d’entreprise, comme HealthX, Ebow et Moneypenny utilisant la technologie pour produire des sites rapides et fluides qui offrent une expérience utilisateur supérieure.
Qu’est-ce qu’une application à page unique ?
Comme son nom l’indique, un SPA est une application Web complète qui fonctionne et réside sur une seule page. Vous ne naviguez pas vers des URL distinctes pour accéder aux différentes parties d’un site Web SPA, même si l’URL de l’adresse de votre navigateur change. Au lieu de cela, les sites Web SPA utilisent des « vues » plutôt que des pages.
Parce que les SPA n’utilisent qu’une seule page, l’expérience est rapide et fluide. Lorsque vous naviguez vers différentes pages ou “vues” d’un SPA, ils se chargent instantanément, agissant comme une application native que vous téléchargeriez sur votre bureau. Plutôt que de charger chaque nouvelle page d’un site Web SPA, la navigation affiche et masque différents éléments du site.
Un bon moyen de faire l’expérience de la différence de performance entre un SPA et un site Web plus traditionnel à plusieurs pages est de les utiliser l’un après l’autre. Ainsi, par exemple, la page Wikipédia d’AngularJS est un site Web de plusieurs pages. Si vous cliquez sur des liens de la barre latérale ou d’autres éléments de navigation, vous verrez qu’il faut généralement quelques secondes pour charger la nouvelle URL. En revanche, le site Web AngularJS.org est un site SPA, et si vous visitez la page d’accueil du didacticiel et cliquez sur n’importe quel lien de navigation, vous verrez à quelle vitesse il charge la nouvelle “page” ou “vue”.
Avec un SPA, tout le contenu est créé par JavaScript (JS) du côté “client”. L’application est téléchargée depuis le serveur dans un premier temps, le JS génère ensuite le contenu de la page. Toutes les interfaces sont gérées par JS et toutes les ressources – HTML, CSS et scripts sont chargées dès qu’un utilisateur visite une page du site Web et elles n’ont pas besoin d’être rechargées lors de la navigation sur le site.
Les SPA utilisent souvent un modèle de “shell d’application”, dans lequel les fonctionnalités constantes du site Web, telles que les pieds de page et les en-têtes, sont chargées et restent statiques, tandis que JS remplit le contenu unique des différentes vues lors de la navigation.
La vitesse est cruciale lorsqu’il s’agit d’avoir un site Web performant et de haut rang. Les acheteurs des magasins de commerce électronique, par exemple, s’attendent à une expérience très rapide et si une page met 5 secondes à se charger, la probabilité qu’un utilisateur quitte le site Web augmente d’environ 90%.
Dans cet esprit, vous devriez envisager d’utiliser un site Web SPA si :
- La vitesse est cruciale pour les performances de votre site
- Quand l’expérience utilisateur est primordiale
- Lorsque vous souhaitez réutiliser le code et l’API côté serveur backend pour une application mobile
Les SPA peuvent également être plus faciles à déboguer pour les développeurs et le processus de mise en cache a tendance à être beaucoup plus efficace. Avec les SPA, vous pouvez également séparer plus facilement le développement front-end et back-end, ce qui facilite la gestion de projet d’une nouvelle version.
Applications monopages et référencement
L’un des inconvénients ou des inconvénients actuels de l’utilisation d’un site Web SPA est qu’il peut rendre le référencement sur la page plus compliqué.
Un bon moyen de tester initialement un site Web SPA ou de commencer un audit SEO sur un site Web SPA consiste à l’exécuter via le test Google Mobile-Friendly. Vous pouvez ensuite voir si Google est capable de restituer correctement la page et consulter les messages de la console JS pour rechercher d’éventuelles erreurs.
Par exemple, vous pouvez constater que vous avez utilisé une fonctionnalité ou une API que Google ne prend pas en charge. Dans le cas d’une demande de géolocalisation, il est important qu’il y ait une option ou un chemin de sauvegarde dans le code afin que si la demande de localisation est refusée, par exemple par Googlebot, il y ait un contenu par défaut qui puisse être chargé. S’il n’y a pas d’option par défaut et que la demande de localisation est refusée, l’utilisateur ou le Googlebot ne verra ni n’explorera le site Web.
Pages et vues
Un problème courant avec le site Web SPA en ce qui concerne le référencement et l’expérience utilisateur est que, par défaut, l’URL affichée dans la barre d’adresse d’un navigateur restera statique, même lors de la navigation vers différentes “vues” d’un site Web SPA à l’aide de la navigation.
Si cela n’est pas rectifié, Googlebot n’indexera qu’une seule page, généralement la page d’accueil. Ceci est relativement facile à rectifier, cependant, en utilisant l’API d’historique et le balisage de lien HTML “ahref” approprié.
Les « vues » sur un site Web SPA peuvent également créer des balises méta en double telles que des méta descriptions et des titres pour chaque page indexée par Google. à chaque vue ou page.
La gestion des erreurs
La gestion des erreurs est également configurée différemment avec les SPA par rapport aux sites Web à plusieurs pages. Avec un SPA, le serveur ne gère plus les erreurs et peut renvoyer des codes d’état HTTP incorrects, ce qui peut entraîner des problèmes de référencement.
Un JS supplémentaire peut être utilisé pour lire l’URL et récupérer les données pertinentes. Si la récupération échoue, un message d’erreur s’affichera. Le serveur peut ensuite être configuré pour renvoyer un certain code d’état lorsqu’une URL spécifique est affichée. Vous pouvez donc configurer le serveur pour qu’il affiche une URL se terminant par “not-found/” si une erreur 404 se produit. Pour plus d’informations sur le code à utiliser et comment le configurer, veuillez consulter ce didacticiel vidéo YouTube de Google Search Central.
Conclusion
Les applications à page unique deviennent de plus en plus populaires, car l’expérience utilisateur devient de plus en plus importante en termes d’optimisation de la recherche et du taux de conversion. Bien qu’une expertise supplémentaire soit souvent requise afin d’optimiser un SPA pour la recherche, des URL individuelles peuvent être testées avec l’outil d’inspection d’URL dans la Search Console et le test d’optimisation mobile sans aucun niveau de compétence élevé. Toutes les meilleures pratiques de référencement techniques normales doivent être respectées avec les sites Web SPA, y compris l’utilisation d’un fichier robots.txt et d’un plan de site XML. Il est également important d’utiliser correctement les URL canoniques et le balisage des liens internes doit être correct. Enfin, le suivi des campagnes et des URL peut être plus compliqué avec les sites Web SPA. Pour plus d’informations sur la configuration du suivi sur les sites Web SPA, veuillez consulter ce didacticiel YouTube.
(Les journalistes de Devdiscourse n’ont pas été impliqués dans la production de cet article. Les faits et opinions apparaissant dans l’article ne reflètent pas les vues de Devdiscourse et Devdiscourse ne revendique aucune responsabilité à cet égard.)
— to www.devdiscourse.com