Applications web monopages, avantages et inconvénients (2018)
Une application web monopage (AWM) interagit avec l’utilisateur en réécrivant dynamiquement la page courante plutôt que de charger de nouvelles pages entières depuis un serveur. Cette stratégie a l’avantage de pouvoir proposer une expérience utilisateur plus fluide en évitant les interruptions occasionnées par les chargements successifs des pages en provenance du serveur. Dans une AWM, tout le code nécessaire — HTML, CSS et JavaScript — est inclus dans une seule page. Si nécessaire, des ressources supplémentaires peuvent être chargées dynamiquement et injectées dans la page, généralement en réponse aux actions des utilisateurs.
Ces applications reposent essentiellement sur JavaScript qui a la possibilité d’afficher l’interface utilisateur, d’exécuter la logique applicative et de communiquer avec un serveur Web. Leur popularité récente est conjointe à celle des frameworks Javascript (AngularJS, Ember.js, Meteor.js, React, Vue.js, etc.) qui permettent de les concevoir avec une plus grande facilité que s’il fallait tout coder de A à Z. D’autres outils peuvent aussi être employés, comme Google Web Toolkit qui permet de développer l’application en Java, le compilateur croisé GWT traduisant le code en JavaScript.
Les requêtes des AWM vers le serveur sont soit des données structurées (XML/JSON) ou des portions de code HTML à injecter dans le DOM. Le serveur est déchargé de la tâche de bâtir des vues, tout est réalisé par le client.
Si le développement d’une AWM peut parfois paraître à certains la solution simple et rapide, faire une bonne application web monopage, qui soit pleinement satisfaisante pour l’utilisateur, s’avère souvent complexe et nécessite d’éviter certains écueils. En voici les principaux :
Navigation web ruinée
C’est le problème le plus fréquent, rencontré avec trop d’AWM conçues peu soigneusement. L’utilisateur a l’impression de changer de page, mais l’URL demeure fixe et l’historique du navigateur est ruiné. S’il utilise la fonction “page précédente” du navigateur, soit il ne se passe rien, soit il se retrouve à son grand étonnement sur un site précédemment consulté. Dans ce dernier cas, si cette manœuvre entraîne la perte de données déjà saisies, ou du point de parcours où il se trouvait, l’utilisateur pestera certainement et à raison après les concepteurs quand il reviendra sur l’application. Ce problème d’utilisabilité n’est pourtant pas une fatalité, car il existe plusieurs techniques fiables pour créer un pseudo-historique qui soit fonctionnel dans les navigateurs. Mais cela demande bien sûr des efforts. Et il ne faut pas oublier de gérer l’événement beforeunload en cas d’entrée de données par l’utilisateur afin de l’avertir du risque de données perdues.
SEO problématique
L’optimisation pour les moteurs de recherche est en partie le corollaire de la question précédente, les AWM ne fonctionnent pas comme un site traditionnel. Si rien n’a été spécifiquement prévu pour eux, les robots d’indexation des moteurs de recherche perdront invariablement leur latin face à une AWM. Les robots ne sont pas conçus pour exécuter du JavaScript et de tenter de comprendre ce qui se passe. Si le référencement est un enjeu capital, il est sans doute préférable de ne pas avoir recours à une AWM, ou seulement partiellement. Une solution est d’avoir, juste pour les robots, des pages HTML qui font miroir des pseudo-pages de l’application, mais ce n’est pas très élégant et cela occasionne parfois des problèmes de maintenance.
Accessibilité compromise
Force est de constater que la quasi-totalité des applications monopages que l’on croise sont médiocrement accessibles ou pas du tout accessibles. C’est dommage, mais il faut bien se rendre à l’évidence : concevoir une AWM en respectant tous les canons de l’accessibilité est tout un défi. Cela dit, il faut bien comprendre que bien des efforts portés sur l’accessibilité, même minimaux — du code HTML sémantique valide bien construit et un historique de navigation par exemple — ont des bénéfices sur le SEO.
Statistiques ardues
La plupart des outils de statistiques, comme Google Analytics, reposent sur le mécanisme du chargement d’une page complète. Ils ne peuvent pas enregistrer l’affichage d’une pseudo-page générée par une AWM. L’application refond en effet son affichage en réponse à des actions sans demander au serveur d’aller chercher un nouveau HTML. Vous ignorez donc ce que vos utilisateurs font, l’exécution étant confinée dans leur navigateur, à moins de développer vous-même des fonctions permettant de le traquer au sein de votre application, c’est à dire de faire en sorte que le serveur soit informé et enregistre l’état de l’application à des points clés. Les classiques outils de monitorage de la performance ne fonctionneront pas non plus.
Temps de chargement
La nécessité de charger des gros volumes de code JavaScript et une bonne dose de déclarations CSS au préalable, avant que l’utilisateur puisse interagir avec l’application, a forcément des impacts. Que l’utilisateur puisse penser que le serveur est simplement en panne et qu’il passe à autre chose n’étant pas le moindre (les développeurs ont généralement d’excellentes connexions à Internet, ce qui n’est pas toujours le cas pour les utilisateurs). Un travail d’optimisation du code à charger doit être fait si l’application est trop longue à charger ; différentes stratégies peuvent être mises en œuvre. Il faut aussi se poser des questions telles que “Est-ce que j’ai besoin d’inclure un framework CSS aussi lourd ? Ne pourrais-je pas en utiliser un plus léger, voire me passer de framework ?”. Etc. Dans un même registre, à l’intérieur de l’app, il peut être important de prévoir si nécessaire une indication visuelle de chargement entre les pseudo-pages pour que l’utilisateur soit incité à patienter et éviter qu’il appuie sur “Actualiser/Recharger”.
Pour conclure
Le choix de l’application web monopage relève parfois de la fausse bonne idée. Si vous avez toutefois de bonnes raisons de faire un tel choix, obtenir un résultat de qualité demandera nécessairement du temps, des compétences, de bonnes pratiques et des moyens. Si vous développez une AWM, privilégiez des frameworks vraiment conçus pour cet usage, comme Ember.js par exemple, qui facilitent le développement en offrant des moyens de contourner certains des écueils décrits ci-dessus.
S’il s’agit de concevoir juste un site web, l’idée de l’encapsuler dans une AWM n’est pas toujours très judicieuse (SEO, accessibilité, navigation, statistiques, etc.). Cette tactique n’est pas sans faire penser aux sites réalisés en Flash il y a une vingtaine d’années (avec des problèmes similaires comme le temps de chargement, le référencement, l’ergonomie, etc.). À voir certains exemples “créatifs”, on se rend compte que des designers ont réussi à recréer tous les problèmes du site Flash avec des technologies modernes — “Oui, mais c’est joli, ça bouge, c’est interactif, c’est une expérience riche.”
Les meilleurs cas d’utilisation d'une SPA sont ceux où l’application, tout en étant physiquement sur le web, n’a pas de nécessité intrinsèque à “faire partie du web”. Elles sont aussi une bonne solution si vous avez besoin d’un fonctionnement hors-ligne, ce qu’un site web ne peut offrir. Elles peuvent servir à créer des interfaces plus modernes et fonctionnelles pour un système hérité, ou des tableaux de contrôle pour des appareils. Un de leurs atouts est d’être multiplateforme par défaut (Windows, Linux, OSX, Android, iOS…).
Les AWM sont aussi bien adaptées aux applications complexes qui traitent beaucoup de données en interaction avec l’utilisateur. Pensez au client web de Gmail par exemple.
Retenons que les applications web monopages ne sont pas la solution à tout, mais sont un bon choix dans certains cas de figure. Comme pour toute technologie, elles ont des avantages, des inconvénients et des défis à relever qui leur sont propres.
Single-page application, pros and cons
Single-Page Applications (SPAs) are web apps that interact with users by dynamically updating the current page rather than loading whole new pages from a server. This strategy creates a fluid web experience by avoiding the interruptions caused by consecutive page loading from a server. With SPAs, all the necessary code — HTML, CSS and JavaScript — is included in a single page, with additional resources dynamically loaded and embedded into the page as needed, responding to the user’s actions.
These applications are essentially based on JavaScript, which can display the user interface, execute the application logic and communicate with a web server. Their recent surge in popularity is tied to Javascript frameworks (AngularJS, Ember.js, Meteor.js, React, Vue.js, etc.), which make them easier to create than if they were coded from scratch. Other tools can also be used, such as Google Web Toolkit which allows to develop the application in Java, a cross-compiler translating the code in JavaScript.
SPA requests sent to the server are either structured data (XML/JSON) or chunks of HTML code to embed into the DOM. The server is relieved of the task of building views, as everything is handled by the client.
While at first glance SPA development may seem the simplest, easiest way to go, the fact is that building a good single-page web application that provides an optimal user experience is often a complex task that poses certain challenges. The main ones are:
Interrupted Navigation
This is the most frequent problem with hastily-built SPAs. Users think they are on a new page, but the URL remains unchanged and the browsing history is interrupted. If they use the browser’s “previous page” function, either nothing happens, or to their surprise, they end up on a previously-consulted site. When returning in the application, users will curse at the programmer if this resulted in a loss of their data or of their position in the journey. Which is unfortunate, because this usability glitch is avoidable: there are several ways to create a pseudo-history that works with web browsers. Of course, this requires extra work on the developer’s part. And don’t forget to manage the beforeunload event to warn the users of the risk of data loss.
Search Engine Optimisation Problems
Search engine optimisation is partly related to the previous issue, as SPAs do not work like a traditional site. Unless developers have planned for this, search engine indexing robots don’t know what to do with an SPA. Indeed, these robots are not designed to execute JavaScript and try to understand what is going on. If referencing is crucial, then it would be best to avoid SPAs, or only partially. One solution is to develop robot-specific HTML pages that mirror the pseudo application pages, but this isn’t the most elegant solution and besides, it can lead to maintenance issues.
Compromised Accessibility
Almost all existing single-page applications are very partially or not at all accessible. The fact is that developing a decent SPA that also respects all the laws of accessibility is a major challenge. That said, all efforts to enhance accessibility, even the slightest — for example, providing a robust, valid, semantic HTML code and a browsing history — all benefit SEO.
Stuttering Statistics
Most statistical tools, such as Google Analytics, are based on the mechanism of loading complete pages. They can’t record the display of pseudo-pages generated by SPAs, since the app refreshes the display based on user actions without asking the server to get new HTML code. Since the execution is contained in the browser side, you must develop some kind of tool to track user movement within your application. In other words, you’ll need a function to keep the server in the loop and to record the state of the application at key points. It's also important to understand that if statistical services aren’t working, neither will most of the available performance-monitoring tools on the market.
Loading Time
The requirement to load large volumes of JavaScript code and copious amounts of CSS declarations takes time, delaying users’ interaction with your app. Sometimes, the delay is so long that users assume that the server is down, and they give up (developers usually have excellent Internet connections, which is not always the case for users). When applications take too long to load, the underlying code should be optimized using one or more strategies. For example, you could ask yourself whether you really need to include such a heavy CSS framework, or if you could manage with a lighter one or none at all. To continue on the topic of loading time, you could encourage users not to press “Refresh/Reload” by providing, if necessary, a visual loading indicator between pseudo-pages.
In Conclusion
Single-page applications are one of those ideas that can look good from far, but may be far from good. However, if you have good reasons to go for this solution, a quality product will require an investment in time, skills, best practices and resources. If you develop a SPA, use frameworks specifically designed for this purpose, like Ember.js, since they ease development while providing workarounds for some of the issues described above.
If you’re developing just a web site, encapsulating it in a SPA isn’t the best idea (remember: SEO, accessibility, browsing, statistics, etc.). In fact, it’s reminiscent of those sites created in Flash about twenty years ago, with similar problems, like loading times, referencing, user-friendliness, etc. In fact, if you have a look at some of the more “creative” SPA sites, you realize that some designers have recreated all of the Flash problems with modern technologies: “Look, it’s pretty, it moves, it’s interactive, it’s a rich user experience.”
The best examples of its use are those where the application, while residing on the Web, doesn’t need to “be part of the Web”. They can be a good solution if you need off-line functionality — something a Web site can’t provide. They can also be used to create more modern, functional interfaces for legacy systems, or control panels for devices. And one of their great advantages is to be multi-platform by default (Windows, Linux, OSX, Android, iOS…). SPAs are also well suited for complex applications that process a lot of data in interaction with the user. Think of the Gmail web client, for example.
To sum it up, single-page web applications are not the solution to all your problems, but they are a good choice in some circumstances. As with any technology, they have their advantages, drawbacks and challenges.