Pourquoi ne pas AJAX'ify des sites Web entiers?
Existe-t-il un raisonnement solide sur la raison pour laquelle les sites ne devraient pas être développés avec une fonctionnalité ajax qui charge les principales parties de chaque partie (en supposant que des éléments tels que l'en-tête, la navigation, etc. restent les mêmes)?
Cela nécessiterait sûrement moins de ressources, car le serveur n'aurait pas à servir le contenu qui apparaît sur chaque page, ce qui profiterait à l'hôte et à l'utilisateur final.
Répondez à la question en prenant en considération:
Le comportement javascript des sites se dégrade gracieusement dans tous les cas.
En ce qui concerne ma question, je parle de nouveaux sites où ce comportement pourrait être mis en œuvre dès le départ, de sorte qu'il ne coûte techniquement rien, nous ne retournons pas à un produit fini pour le mettre en œuvre.
Si le contenu peut être atteint sans l'activation de JavaScript, votre question n'a aucun sens. Ce n'est pas "entièrement Ajaxifié" si vous pouvez accéder au contenu par d'autres moyens. Vraiment, vous demandez: "est-il possible d'améliorer l'expérience de mon utilisateur avec Ajax?". La réponse est évidemment "oui".
modifier
À l'époque où Google présentait sa proposition Ajax, il était considéré comme un très mauvaise idée . Fait pour une lecture intéressante.
Premières choses d'abord
Les pros
- AJAX peut vous permettre d'utiliser une page "de base" commune et de simplement charger les zones de contenu, ce qui peut réduire le temps de chargement des utilisateurs, car une grande partie de la page est déjà chargée.
- Peut permettre des friandises pour les yeux telles que la décoloration de la zone de contenu.
Les inconvénients
- Ne joue pas Nice si la page est téléchargée.
- Peut déconner avec les dispositifs d'invalidité.
- Les spectateurs dont le javascript est désactivé ne pourront utiliser le contenu que si une version non javascript est également utilisée.
- Beaucoup plus de travail (faut-il vraiment le dire?).
Maintenant pour votre question
En supposant que votre site se dégrade gracieusement pour ceux qui ne disposent pas de Javascript, la qualité du résultat dépend de la manière dont cela se fait. Par exemple, si vous affichez simplement un lien vers une version non-javascript, c'est un inconvénient pour les utilisateurs de cliquer sur un autre lien. Par contre, s’il existe une "page principale" noscript qui utilise des liens traditionnels, cela fonctionne mieux pour la plupart des utilisateurs, mais ne prend toujours pas en charge ceux qui utilisent des dispositifs pour handicapés, cas où l’utilisateur vient pour une "page" spécifique à partir d’une page. lien, etc.
Dans l’univers de la connexion Internet de plus en plus rapide, cela ne justifie pas vraiment de couper une petite quantité de la taille du fichier (nous présumerons que tout le Javascript, le CSS, et les images peuvent et seront mises en cache, laissant juste la page "base" elle-même sur laquelle vous pouvez économiser des octets) présente les inconvénients qu’elle peut générer, à savoir la difficulté supplémentaire (bien que ce ne soit pas toujours un défi est bon) et le manque de support que cela peut donner à certains utilisateurs.
Dans l’ensemble, je dirais que c’est à vous de décider, que cela fonctionnerait probablement très bien et que, pour la grande majorité des utilisateurs, ils verront probablement le site comme prévu, mais personnellement, je dirais que non. dérange, car cela ne vaut pas la peine pour une amélioration aussi marginale de la taille du fichier.
Départ http://gawker.com/ - Ce site se charge presque complètement après coup. Ils utilisent "hashbangs" (http://mydomain.com/#!some_section) pour déterminer quelle page de contenu doit être chargée, la navigation principale reste statique.
Consultez http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ pour un bref tutoriel sur le concept utilisé par Gawker .
Il y a des avantages et des inconvénients, vous devez tenir compte des moteurs de recherche (voir http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), des personnes avec JavaScript désactivé, et faire beaucoup d'essais.
Cela dit, l'argument le plus important à leur encontre est probablement que lorsqu'un utilisateur attend le chargement d'une page, il doit attendre un chargement plus long, il peut être impatient. À mon avis, la meilleure pratique consiste à charger le site principal, la navigation et le contenu principal en un seul passage (sur demande), puis à enregistrer le AJAX pour les incidents non essentiels. Cela fonctionne avec l'idée de amélioration progressive , et mélange le meilleur des deux approches.
Parce que ce n'est probablement pas nécessaire.
Le chargement de documents HTML de base est simple et fonctionne. Introduire Ajax ajoute une autre couche de processus pour les navigateurs, le code et la maintenance pour le Javascript, les applications dorsales, les URL de hashbang étranges, etc. Parfois, cela peut être justifié, parfois non. Cela pourrait vous faire économiser des ressources du serveur (peut-être), mais cela suffira-t-il à compenser l’entretien? Vous devez évaluer cela par projet.
Par exemple, lors de la dernière refonte de Twitter, Twitter a décidé qu’il ne s’agissait pas simplement d’un site Web (de pages), mais également d’une application, et que le tout repose largement sur Ajax, même si la plupart de ses fonctionnalités être traité avec les demandes de page régulières. L'un des plus gros problèmes, qui se produit encore aujourd'hui, mais beaucoup moins, est d'arriver là-bas et d'être accueilli avec une page blanche parce qu'un élément d'Ajax a échoué.
En pratique, produire un site Web "entièrement AJAX" est une tâche ardue, en particulier pour les grands sites Web très complexes. Certains sites Web qui tentent cela sont Google et Facebook, mais même ils ne le font pas parfaitement.
Les problèmes courants sont la navigation (c'est-à-dire, en avant et en arrière) et la mise en favori, mais il existe de nombreux autres problèmes que beaucoup de développeurs préfèrent ne pas avoir à traiter. Et cela signifie essentiellement la création de deux versions du site Web compatibles avec les utilisateurs de Javascript et les utilisateurs non-javascript (et des correctifs pour tous les navigateurs avec un support AJAX incorrect).
Oui, cela devrait être, mais ce devrait être l'inverse.
Les parties communes de la page doivent être envoyées via HTTP. Ensuite, un petit contrôle ajax (ou même de meilleurs websockets) charge le contenu dynamique de manière asynchrone.
Bien sûr, vous devez d’abord déterminer si le javascript est activé (par cookie) et n’utiliser cette méthode que s’il est activé.
Vous avez donc besoin de l'itinéraire HTTP normal complet, puis d'un itinéraire Websockets. Cela nécessite une duplication de code, sauf si vous utilisez un outil tel que node.js
La plupart des gens "pensent" que cela ne vaut tout simplement pas l'effort supplémentaire. Et parfois ce n'est pas.
En plus, beaucoup de gens ajaxifient les pages de manière fausse. Ils décident en fait que vous n'avez pas besoin d'une version non-javascript et de toutes ces étranges URLs de hachage et de boutons cassés avant/arrière. Faire ajax correctement nécessite l’historique HTML5 (IE9 ne l’a pas). Il faut également que le développeur complète les versions de votre site Web.
Avoir des éléments ajax sur une page est bien quand vous avez une petite base d'utilisateurs, mais quand vous avez plus de trafic; vous souhaitez utiliser une approche plus statique pour réduire l’utilisation abusive des ressources.
Par exemple, supposons que 200 personnes essaient d'accéder à une page à la seconde. Vous avez environ 7 requêtes de base de données pour vos appels ajax; soit 1400 appels de base de données par seconde, ce qui peut écraser un site Web.
Un site Web qui doit être conçu pour un trafic plus important doit avoir des pages statiques orientées vers l'extérieur, pour du contenu pouvant être affiché de manière statique. Pour ce faire, utilisez un script côté serveur qui s'exécute toutes les secondes pour reconstruire la page statique, extraite pour l'utilisateur final. Vous avez ainsi réduit votre charge de 1400 appels de base de données par seconde à 7.
C'est une approche SOA à la construction de sites Web.
Puisque vous avez dit que cela se dégraderait gracieusement pour les visiteurs dont le Javascript est désactivé, je ne vois que deux problèmes réels (et un possible) qui pourraient survenir.
Mauvais pour l'accessibilité
Les lecteurs d'écran et autres technologies d'assistance sont souvent perturbés par les modifications dynamiques du DOM. Ils traitent et lisent la page de manière linéaire, et il est possible que le contenu de la page une fois chargée ne soit pas correctement géré.
Il y a peut-être des techniques pour contourner cela, mais je n'ai pas trop étudié la question.
Complexité accrue
Maintenir ce type de site pourrait être délicat. Par exemple, si vous avez créé une nouvelle mise en page et modifié l'ID de la zone de contenu que vous remplaciez par vos liens AJAX, cela pourrait casser votre schéma de navigation de manière assez déconcertante.
Ce type de comportement AJAX compliquerait également toute analyse de trafic que vous pourriez effectuer; Google Analytics n’enregistrerait pas correctement ces charges AJAX sans appel manuel à pageTracker._trackPageview('this_page');.
Ajouter plus de complexité au fonctionnement de votre page soulève également la barre pour les nouveaux développeurs; quiconque travaillant sur le site devra probablement être informé de l'impact de ce comportement sur le chargement de pages.
Possible: chargement de page plus lent lors de la première visite
Selon la manière dont vous structurez les choses, cette page permettant d'extraire le code AJAX ne pourra être utilisée qu'une fois le document entièrement chargé. Ainsi, ce n'est qu'après que votre visiteur a téléchargé la page entière, puis le Javascript (s'il s'agissait d'un fichier externe), et son navigateur l'a rendu et a récupéré le contenu via AJAX, ils ont pu voir le contenu de la page.
Chaque lien cliqué par la suite serait plus rapide, mais la première page consultée par un utilisateur prendrait plus de temps qu'une version statique.
La raison pour laquelle j'ai qualifié cela de problème possible est que vous pouvez toujours envoyer la première page de manière statique (puisque vous aurez déjà la version statique comme solution de secours), puis utiliser AJAX pour les liens suivants.
Pour ce que cela vaut, cela ne me semble pas une très mauvaise idée - en particulier pour les utilisations sensibles à la bande passante telles que les pages mobiles. Vous devrez toutefois peser soigneusement les inconvénients pour vous assurer que cela en valait la peine dans votre cas, cependant.