Utilisation de l’AJAX dans un site Internet
Wa l’autre, il démarre direct avec un disclaimer. C’est que ça va être velu comme sujet.
Même pas.
La majorité de cet article a pour objectif de faire comprendre le fonctionnement de l’AJAX sur un site Internet, pour en saisir les enjeux, bonnes pratiques et la complexité.
Certes, il y aura quelques enclaves purement techniques où seuls les initiés paneront quelque chose mais c’est pour la bonne cause.
Bonne lecture :D
PS : On ne parlera ni de détergent, ni de héros grec, ni de football dans cet article. Si vous êtes arrivés ici pour ces raisons, vous avez été victime d’homonymie. Désolé.
Qu’est ce que c’est que l’AJAX ?
En premier lieu, il convient de définir l’AJAX et de faire un poco d’histoire.
Tout d’abord, AJAX veut dire Asynchronous JavaScript and XML. Ce titre est un peu trompeur car aujourd’hui, l’AJAX n’est pas limité à ses deux langages. Si le principe de l’AJAX existe de 1998, le terme lui, a été officialisé en 2005.
L’AJAX n’est pas une technologie à proprement parler, mais un principe. Quand vous demandez une page web, vous émettez une requête à un serveur web, qui vous renvoie un résultat, sous forme d’HTML (ensuite formaté par du CSS et du JavaScript).
Et bien l’AJAX, c’est pareil, mais sans que votre page web soit rechargé. Il s’agit d’une requête à un serveur web (souvent le même), mais programmée en JavaScript suite à une action (clic sur un bouton, scroll…).
Cas d’utilisation
Bien souvent, les requêtes AJAX sont utilisés en toute transparence. Éventuellement, un petit loader vous signale que quelque chose est en cours mais cela va suffisamment vite pour être oublié dès qu’il disparaît.
Voici quelques cas d’utilisations où l’AJAX est utilisé :
Infinite Scroll
Terme très explicite, il s’agit de blogs ou de réseaux sociaux, où vous pouvez scroller indéfiniment car le système aura toujours quelque chose à afficher. Bien entendu, le système n’a pas tout chargé d’un coup, car cela ferait beaucoup trop d’informations pour rien.
L’objectif de l’AJAX ici est de ne charger que les contenus quand on sait que l’utilisateur les veut.
Le site internet détecte votre position et quand il arrive en bas de page, il va charger les contenus suivants, puisque votre utilisation ne semble pas terminée. Il est aussi possible d’avoir un bouton “Charger plus de contenus” pour s’assurer que vous souhaitez effectivement voir plus de contenus. Il n’est pas rare d’avoir les deux systèmes car la détection n’est pas infaillible, alors qu’un clic sur un bouton fonctionne à tous les coups.
Sur un bouton “Ajouter au panier”
Un autre classique car lorsque vous ajoutez un produit dans le panier de votre site e-commerce préféré, on vous affiche une petite fenêtre vous indiquant que le produit a bien été ajouté, et on vous propose de continuer vos achats, ou bien d’aller à la page de commande.
Peu importe votre décision, le produit a bien été ajouté, car le système a besoin de vous le réserver (gestion des stocks etc…).
Et bien cet ajout au panier et cette réponse sont générés par une requête AJAX.
Dans une section commentaires
Sur Facebook, Youtube, Linkedin, Twitter etc, vous avez la possibilité d’écrire des réponses aux contenus des plateformes. Et lorsque vous publiez une réponse ou likez le contenu, votre action est instantanément publiée, sans temps de chargement., c’est magique !
Et bien non, désolé.
Ce qui est intéressant ici, c’est que le système simule le futur résultat retourné par les prochains chargements de la page, en même temps qu’il sauvegarde votre action, pour vous donner l’illusion de réactivité.
De temps à autres, une notification apparaît pour vous signaler du bon déroulement de votre action (souvent sur les partages de contenus).
Bonnes pratiques
Tous ces systèmes sont aujourd’hui rodés et appréciés, sans qu’il existe forcément une bonne compréhension de leur fonctionnement. L’AJAX a permis d’améliorer drastiquement les performances et l’ergonomie des applications.
Toutefois, comme toute notion d’ergonomie, il convient de savoir quand l’utiliser.
Les exemples d’utilisation ci-dessus mettent en évidence une logique : l’AJAX est parfait pour des petites actions. Son objectif doit toujours être d’effectuer un traitement léger et contrôlé, que ce soit pour sauvegarder une action ou pour charger un contenu.
Pensez à ajouter un loader ou tout élément indiquant à l’utilisateur que quelque chose se passe et que son action à bien été prise en compte.
Pour éviter les problèmes liés aux impatients qui martèlent leur souris, ou encore aux double-clics malencontreux, pensez également à désactiver l’événement déclencheur en attendant la réponse du serveur :)
De même, notifiez toujours l’utilisateur de la réponse du serveur, qu’elle soit bonne ou mauvaise. Ne vous contentez jamais de faire disparaître le loader, il doit se passer quelque chose à l’écran et l’utilisateur doit comprendre si son action s’est conclue par un succès ou un échec.
De plus, l’AJAX utilisant la technologie JavaScript, et même si nous sommes en 2018, il conviendrait de doubler chaque utilisation de cette technologie par des méthodes traditionnelles.
En effet, si le support ne supporte pas la technologie et que votre fonctionnalité n’est basé que sur un traitement AJAX, l’utilisateur ne pourra pas en disposer du tout.
C’est au conditionnel car il existe une centaine de support, plus ou moins obsolètes, et il est difficile de tous les prendre en compte.
C’est la raison pour laquelle nous appliquons des scripts détectant les versions dépréciées de ces supports, pour inviter l’utilisateur à le mettre à jour et ainsi assurer la bonne compatibilité avec nos développements.
Enfin, gardez un œil sur les temps de traitement de vos requêtes et si elles sont appelées dans le bon contexte. En effet, une requête AJAX ne se différencie pas d’une requête normale, et il est tout à fait possible d’outrepasser l’utilisation normale de ce bouton en envoyant une “fausse” requête via la console de développeurs.
Voilà pour ces quelques bonnes pratiques générales. Il en existe bien d’autres, mais elles sont beaucoup plus techniques et seront traitées dans un article spécifique :)
Mise en place technique & Librairies
Il faut d’abord savoir que mettre en place de l’AJAX sur une application ne requiert rien de particulier, si ce n’est une bonne organisation. Vous devez savoir quelle requête va renvoyer quel contenu.
Côté client
La meilleure façon de gérer vos requêtes AJAX est d’utiliser une librairie comme jQuery ou Mootools. Elles disposent d’un ensemble de fonctions et de raccourcis qui vous feront gagner énormément de temps.
Par curiosité, vous pouvez jeter un œil à la - vieille - façon de faire de l’AJAX avant ces librairies (XmlHttpRequest) : https://developer.mozilla.org/fr/docs/Web/API/XMLHttpRequest
Avec jQuery par exemple, la fonction Ajax vous permet de configurer la totalité des données envoyées et dispose de tous les callbacks nécessaires pour traiter les retours, bons ou non.
// http://api.jquery.com/jquery.ajax/
$.ajax({
type: 'POST',
async: false,
url: window.location.pathname,
data: {
"TL_AJAX": 1
,"REQUEST_TOKEN": wemForm.el.find('input[name="REQUEST_TOKEN"]').first().attr('value')
,"module": "wem-contao-form-submissions"
,"action": "abortSubmission"
,"form": wemForm.formID
,"fields":wemForm.fields
,"logs":wemForm.logs
}
}).done(function(data){
// Faire quelque chose en cas de succès précisément
}).fail(function(jqXHR, textStatus){
// Faire quelque chose en cas d'échec précisément
}).always(function(data, textStatus, jqXHR){
// Faire quelque chose dans tous les cas
});Pour gérer les notifications, nous utilisons la librairie Toastr, qui est à la fois légère, performante et simple d’utilisation. Accessible via un CDN, customisable et disposant de 4 statuts pré-définis (success, info, warning, danger), c’est amplement suffisant pour de simples retours !
Côté serveur
Le souci avec le côté serveur, c’est qu’il dépend du système utilisé. Si vous utilisez un framework comme Symfony ou Laravel, vous pouvez configurer des routes (qui correspondent à des schémas URLs) et ensuite, la fonction correspondante s’exécute.
Pour les CMS, c’est un peu la même chose, mais il est généralement moins évident de configurer les URLs pour tomber au bon endroit.
Tout ce qui compte, c’est que le traitement renvoie un résultat que le JavaScript saura interpréter correctement.
On a le choix entre 3 langages pour le retour : le JSON, le XML ou l’HTML. Les deux premiers servent principalement à retourner un simple statut avec un message tandis que le dernier sera plus utilisé dans le cas de chargements de contenus.
Un retour AJAX côté serveur consiste à simplement afficher le retour comme vous le feriez sur une page normale. Avec un “echo” donc.
Vous pouvez ajouter un “die” après votre retour. Ainsi, vous vous assurez que rien ne sera ajouté ensuite.
// Construction d'un tableau
$arrResponse = ["status"=>"success", "msg"=>"Le contenu a été mis à jour !"];
// Formatage d'un tableau au format JSON
$strResponse = json_encode($arrResponse);
// Affichage de la chaîne de cartactère
echo $strResponse;
// Et on stoppe tout
die;Même si les exemples ci-dessus suffisent, il est plus correct d’utiliser des librairies dont l’objectif est de créer des retours “propres”, comme Guzzle, Unirest ou Httpful.
Si vous utilisez un framework ou un CMS, il est possible que celui-ci intègre déjà nativement une librairie.
Chez Contao, on utilise le package “Haste”, qui fournit quelques classes utilitaires pour envoyer ce genre de réponse.
AJAX & SEO
Si vous utilisez l’AJAX pour charger des contenus ou changer de page, vous devez faire très attention à votre référencement.
En effet, Google et les autres moteurs de recherche n’exécutent pas encore officiellement le code JavaScript des sites Internet analysés, donc ils n’ont aucun moyen de savoir que d’autres pages existent.
Exemples : Infinite scroll, paginations et menus de navigation en Ajax.
Pour contrer cela, il faut vous assurer que toutes les URLs soient accessibles via une méthode classique, pour les robots.
Vous devez également mettre à jour l’URL de l’utilisateur, pour éviter une incohérence dû à un rafraichissement de la page.
Assurez-vous d’avoir une page répertoriant toute l’arborescence accessible de votre site.
Enfin, générez un sitemap.xml répertoriant lui aussi toutes les URLs de votre site, et envoyez-le sur Google Webmaster Tools pour éviter toute erreur d’indexation.
En soit, ce sont des bonnes pratiques SEO à respecter, même si vous n’utilisez pas d’AJAX dans vos navigations, mais c’est toujours bon de les rappeler.
Conclusion
Utiliser l’AJAX semble être indispensable aujourd’hui, tant ce principe colle avec les bonnes pratiques et l’idée que l’on se fait d’une bonne ergonomie. Tant indispensable qu’on le retrouve dans plein de thèmes et landing pages à télécharger.
Mais on peut aussi s’en passer. S’il est possible de l’utiliser partout, pour tout et n’importe quoi, cela ne veut pas pour autant dire que c’est une bonne idée.
L’AJAX, c’est avant tout un concept pensé pour améliorer l’interaction utilisateur en se basant sur des scénarios utilisateurs - use cases - pensés à l’avance. En ne chargeant que le strict minimum, au moment où cela est nécessaire, on s’assure de suivre le scénario tout en conservant de bonnes performances d’utilisation.
De plus, il ne faut pas oublier que c’est une technologie basée du côté client de votre application / site internet, ce qui veut dire qu’elle est par essence beaucoup plus difficile à maintenir.
Avant d’opter pour cette technologie, demandez vous toujours s’il n’y a pas d’autres solutions, s’il existe des exemples de sites connus et approuvés ou encore des discussions autour de ce que vous souhaitez faire avec.
C’est toujours un très bon indicateur pour distinguer les bonnes idées, si personne n’en parle, c’est que vous avez peut-être eu l’idée du siècle, mais il est bien plus probable que vous faites fausse route :)
Dans la même catégorie
