Application d’une seule page
parce que le SPA est une évolution loin du modèle de page-redessiner sans état pour lequel les navigateurs ont été conçus à l’origine, de nouveaux défis ont émergé. Les solutions possibles (de complexité variable, d’exhaustivité et de contrôle de l’auteur) incluent:
- bibliothèques JavaScript côté Client.
- frameworks web Côté Serveur spécialisés dans le modèle SPA.
- l’évolution des navigateurs et la spécification HTML5, conçue pour le modèle SPA.,
search-engine optimizationEdit
En raison du manque d’exécution de JavaScript sur les crawlers de certains moteurs de recherche Web populaires, Le SEO (Search engine optimization) a historiquement présenté un problème pour les sites Web publics souhaitant adopter le modèle SPA.
entre 2009 et 2015, Google Webmaster Central a proposé puis recommandé un « schéma D’exploration AJAX » utilisant un point d’exclamation initial dans les identifiants de fragment pour les pages AJAX avec État (#!)., Un comportement particulier doit être mis en œuvre par le site SPA pour permettre l’extraction des métadonnées pertinentes par le robot du moteur de recherche. Pour les moteurs de recherche qui ne prennent pas en charge ce schéma de hachage D’URL, les URL hachées du SPA restent invisibles. Ces URI « hash-bang » ont été considérés comme problématiques par un certain nombre d’auteurs, y compris Jeni Tennison au W3C, car ils rendent les pages inaccessibles à ceux qui n’ont pas JavaScript activé dans leur navigateur. Ils cassent également les en-têtes HTTP referer car les navigateurs ne sont pas autorisés à envoyer l’identifiant de fragment dans l’en-tête Referer., En 2015, Google a déprécié leur proposition D’exploration Ajax hash-bang.
alternativement, les applications peuvent afficher le chargement de la première page sur le serveur et les mises à jour de page suivantes sur le client. Ceci est traditionnellement difficile, car le code de rendu peut avoir besoin d’être écrit dans un langage ou un framework différent sur le serveur et dans le client. L’utilisation de modèles sans logique, la compilation croisée d’une langue à une autre ou l’utilisation de la même langue sur le serveur et le client peuvent aider à augmenter la quantité de code pouvant être partagée.,
en 2018, Google a introduit le rendu dynamique comme une autre option pour les sites souhaitant offrir aux robots d’indexation une version lourde non JavaScript d’une page à des fins d’indexation. Le rendu dynamique bascule entre une version d’une page rendue côté client et une version pré-rendue pour des agents utilisateurs spécifiques. Cette approche implique que votre serveur web détecte les robots d’exploration (via l’agent utilisateur) et les achemine vers un moteur de rendu, à partir duquel ils reçoivent ensuite une version plus simple du contenu HTML.,
parce que la compatibilité SEO n’est pas triviale dans les SPAs, il convient de noter que les SPAs ne sont généralement pas utilisés dans un contexte où l’indexation des moteurs de recherche est soit une exigence, soit souhaitable. Les cas d’utilisation incluent les applications qui font apparaître des données privées cachées derrière un système d’authentification. Dans les cas où ces applications sont des produits de consommation, un modèle classique de « redessinage de page » est souvent utilisé pour la page de destination des applications et le site de marketing, qui fournit suffisamment de métadonnées pour que l’application apparaisse comme un hit dans une requête de moteur de recherche., Les Blogs, les forums de support et autres artefacts de redessinage de page traditionnels se trouvent souvent autour du SPA qui peut ensemencer les moteurs de recherche avec des termes pertinents.
Une autre approche utilisée par les frameworks web centrés sur le serveur comme ItsNat basé sur Java consiste à rendre tout hypertexte sur le serveur en utilisant le même langage et la même technologie de modèle. Dans cette approche, le serveur connaît avec précision L’état DOM sur le client, toute mise à jour de page grande ou petite requise est générée dans le serveur, et transportée par Ajax, le code JavaScript exact pour amener la page client au nouvel état exécutant les méthodes DOM., Les développeurs peuvent décider quels états de page doivent être explorables par les araignées web pour le référencement et être en mesure de générer l’État requis au moment du chargement en générant du HTML simple au lieu de JavaScript. Dans le cas du framework ItsNat, cela est automatique car ItsNat conserve L’arborescence DOM client dans le serveur en tant qu’arborescence DOM Java W3C; le rendu de cette arborescence DOM dans le serveur génère du HTML brut au moment du chargement et des actions DOM JavaScript pour les requêtes Ajax., Cette dualité est très importante pour le référencement car les développeurs peuvent construire avec le même code Java et le même modèle basé sur HTML pur l’état Dom souhaité dans le serveur; au moment du chargement de la page, le HTML conventionnel est généré par ItsNat rendant cet état DOM SEO compatible.
à partir de la version 1.,3, ItsNat fournit un nouveau mode sans état, et le DOM client n’est pas conservé sur le serveur car, avec le client en mode sans état, L’état DOM est partiellement ou entièrement reconstruit sur le serveur lors du traitement de toute requête Ajax basée sur les données requises envoyées par le client informant le serveur de l’état DOM actuel; le mode sans état peut également être compatible SEO car la compatibilité SEO se produit au moment du chargement de la page initiale non affectée par les modes avec État ou sans état., Un autre choix possible est des frameworks comme PreRender, Puppeteer, Rendertron qui peuvent être facilement intégrés dans n’importe quel site Web en tant que middleware avec une configuration de serveur web permettant aux requêtes bot (Google bot et autres) d’être servies par le middleware tandis que les requêtes non-bot sont servies comme d’habitude. Ces frameworks mettent en cache périodiquement les pages web pertinentes pour permettre aux dernières versions d’être disponibles pour les moteurs de recherche. Ces cadres ont été officiellement approuvés par google.
Il existe quelques solutions de contournement pour donner l’impression que le site web est rampable., Les deux impliquent la création de pages HTML distinctes qui reflètent le contenu du SPA. Le serveur pourrait créer une version HTML du site et le livrer aux robots d »exploration, ou il est possible d » utiliser un navigateur sans tête tel que PhantomJS pour exécuter l » application JavaScript et sortir le HTML résultant.
ces deux éléments nécessitent un peu d’effort et peuvent finir par donner un casse-tête de maintenance pour les grands sites complexes. Il existe également des pièges potentiels pour le référencement. Si le HTML généré par le serveur est jugé trop différent du contenu SPA, le site sera pénalisé., Exécuter PhantomJS pour sortir le HTML peut ralentir la vitesse de réponse des pages, ce qui est quelque chose pour lequel les moteurs de recherche – Google en particulier – rétrogradent les classements.
Client/server code partitioningEdit
Une façon d’augmenter la quantité de code qui peut être partagée entre les serveurs et les clients est d’utiliser un langage de modèle sans logique comme moustache ou Handlebars. Ces modèles peuvent être rendus à partir de différents langages hôtes, tels que Ruby sur le serveur et JavaScript dans le client., Cependant, le simple partage de modèles nécessite généralement une duplication de la logique métier utilisée pour choisir les modèles corrects et les remplir de données. Le rendu à partir de modèles peut avoir des effets négatifs sur les performances lorsqu’il ne met à jour qu’une petite partie de la page, par exemple la valeur d’une entrée de texte dans un grand modèle. Le remplacement d »un modèle entier peut également perturber la sélection ou la position du curseur d » un utilisateur, où la mise à jour uniquement de la valeur modifiée peut ne pas., Pour éviter ces problèmes, les applications peuvent utiliser des liaisons de données D’interface utilisateur ou une manipulation DOM granulaire pour mettre à jour uniquement les parties appropriées de la page au lieu de restituer des modèles entiers.
browser historyEdit
avec un SPA étant, par définition, « une seule page », le modèle casse la conception du navigateur pour la navigation de l’historique des pages à l’aide des boutons »forward « ou » back »., Ceci présente un empêchement d’utilisabilité quand un utilisateur appuie sur le bouton de retour, attendant l’état précédent d’écran dans la station thermale, mais au lieu de cela, la page simple de l’application se décharge et la page précédente dans l’historique du navigateur est présentée.
la solution traditionnelle pour les SPAs a été de changer l’identifiant de fragment de hachage de l’URL du navigateur en accord avec l’état actuel de l’écran. Cela peut être réalisé avec JavaScript, et provoque des événements D’historique D’URL à construire dans le navigateur., Tant que le SPA est capable de ressusciter le même état d’écran à partir des informations contenues dans le hachage D’URL, le comportement attendu du bouton de retour est conservé.
Pour résoudre ce problème, la spécification HTML5 a introduit pushState et replaceState fournissant un accès programmatique à l’URL réelle et à l’historique du navigateur.
AnalyticsEdit
Les outils D’analyse tels que Google Analytics dépendent fortement du chargement de nouvelles pages entières dans le navigateur, initié par un nouveau chargement de page. Les SPAs ne fonctionnent pas de cette façon.,
Après le chargement de la première page, toutes les modifications de page et de contenu suivantes sont gérées en interne par l’application, qui doit simplement appeler une fonction pour mettre à jour le package analytics. À défaut d’appeler cette fonction, le navigateur ne déclenche jamais un nouveau chargement de page, rien n’est ajouté à l’historique du navigateur et le package analytics n’a aucune idée de qui fait quoi sur le site.
ajout de charges de page à un SPAEdit
Il est possible d’ajouter des événements de chargement de page à un SPA à l’aide de L’API D’historique HTML5; cela aidera à intégrer les analyses., La difficulté vient de gérer cela et de s’assurer que tout est suivi avec précision – cela implique de vérifier les rapports manquants et les doubles entrées.Certains frameworks fournissent des intégrations d’analyse open source s’adressant à la plupart des principaux fournisseurs d’analyse. Les développeurs peuvent intégrer dans l’application et s’assurer que tout fonctionne correctement, mais il n’est pas nécessaire de tout faire à partir de zéro.
vitesse de chargement initialedit
Les Applications mono-Page ont un chargement de première page plus lent que les applications serveur., En effet, la première charge doit faire tomber le framework et le code de l’application avant de rendre la vue requise en HTML dans le navigateur. Une application basée sur un serveur doit simplement envoyer le code HTML requis au navigateur, ce qui réduit la latence et le temps de téléchargement.
accélérer le chargement de la page
Il existe certaines façons d’accélérer la charge initiale d’un SPA, telles qu’une approche lourde de la mise en cache et des modules de chargement paresseux en cas de besoin., Mais il est impossible de sortir du fait qu’il a besoin de télécharger le cadre, au moins une partie du code de l’application, et sera très probablement frapper une API pour les données avant d’afficher quelque chose dans le navigateur. Il s’agit d’un scénario de compromis « payez-moi maintenant ou payez-moi plus tard ». La question des performances et des temps d’attente reste une décision que le développeur doit prendre.