Plusieurs points mériteraient un billet à part entière, et je suis en désaccord sur chacun d’eux, mais je me focaliserai ici sur un seul : la performance. Les performances peuvent se voir au niveau du téléchargement et au niveau de l’interprétation par le client.

Formats d’échange

Nous avons trois formats d’échanges courants : JSON, XML, et HTML. 

JSON est apparu car il est simple à interpréter avec eval(). Maintenant dès qu’il y a un risque que quelqu’un d’autre puisse manipuler les données, il y a un problème de sécurité. On utilise donc couramment des bibliothèques Javascript externes. Ces bibliothèques analysent la chaîne json à coup d’expression rationnelles. Il existe aussi un bibliothèque d’analyse JSON native dans Firefox mais elle n’est accessible sans privilèges ni dans la version 2 ni dans la version 3. Je ferai la différence entre les trois en parlant de JSON+regexp, JSON+eval et JSON+firefox. 

XML est plus classique. A priori en Javascript vous utilisez DOM pour l’analyser. Sur les navigateurs récents ça sera peut être du E4X. Si votre but est de sortir du HTML, vous pouvez aussi utiliser le moteur XSLT des navigateurs. Là aussi, si besoin on séparera XML+dom, XML+e4x et XML+xslt.

Enfin, renvoyer une grosse chaîne HTML reste toujours faisable. S’il faut encore extraire des valeurs rien n’empêche d’avoir du XHTML. Vous bénéficier de DOM si besoin et vous pouvez envoyer ça directement dans vos pages HTML sans y toucher.

Taille à télécharger

La même données est plus petite en JSON qu’en XML. Pour chaque élément le nom de la donnée est présent une fois en JSON, et deux fois (ouverture + fermeture) en XML. Par contre la différence n’est pas aussi importante qu’on le croit. Alexis Moussine-Pouchkine trouve qu’en moyenne JSON est 40% plus petit que XML. Des test rapides de mon côté me donnent des chiffres légèrement moins optimistes, vers les 35%. Je garderai 40% par précaution.

40% c’est en même temps énorme et pas grand chose. C’est énorme en soi mais les données transférées sont généralement petites. Si on part sur une donnée de 2ko, la différence sera de 800 octets. C’est notable mais pas important non plus. C’est même probablement négligeable face au reste. 

Reste encore que XML et JSON sont tous les deux des formats qui se compressent très très bien. Si on espère un ratio de compression de 20%, nos 2ko deviennent moins de 500 octets. À ce niveau même si le ratio JSON/XML restait le même, le gain serait proche de 160 octets. Si on compte la requête et les entêtes de réponse (entre 1ko et 1.5ko), on a un gain total de 160 octets sur environ 2ko. Autant dire que ce n’est pas significatif. 

Pour que ce soit significatif (1ko de différence), il faudrait que notre XML fasse environ 12ko. Ca reste assez rare. JSON et XML à égalité ou presque sur ce point là.  

Oui mais…

Oui mais on a parlé de JSON+lib, qui est la technique sans problèmes de sécurité. Et là il faut une bibliothèque externe à télécharger. La plus courante est celle de Douglas Crockford qui fait 12ko décompressé. Celle de YUI a sensiblement la même taille. Là même zippé il restera un nombre à 4 chiffres. Ca devient vraiment gênant si vous n’arrivez pas à fusionner ce fichier avec vos autres fichiers javascript : là vous aurez une requête HTTP de plus, avec la latence et les problème de rendu bloqués que ça implique.

Finalement la différence est vraiment légère mais à l’avantage de XML. JSON vous demandera au mieux 1ko de plus une fois minifié et gzipé.

Temps à analyser

C’est là qu’on s’amuse. XML est lent à interpréter, c’est connu par tous et je ne le contesterai certainement pas. Maintenant JSON l’est aussi, et ça c’est moins accepté. L’utilisation de eval() demande à javascript lancer un nouvel interpréteur et empêche le moteur d’optimiser tout ce qu’il y a autour du eval(). C’est lent, spécialement sur Microsoft Internet Explorer. JSON+lib est malheureusement encore pire vu que l’interprétation se fait cette fois ci en pur javacript.

D’autres que moi ont fait des tests. Un premier test trouve XML+dom deux fois plus rapide que JSON+eval. Dave Johnson des graphiques intéressants en fonction du nombre d’éléments dans le jeu de données. Du plus rapide au plus lent sous Microsoft Internet Explorer 6 il trouve XML+xslt, XML+dom et enfin JSON+eval. Sous Firefox 1.5 c’est JSON+eval qui est plus rapide mais la différence est moitié moins importante. En considérant un marché français de 25% de Firefox, JSON+eval est en moyenne nettement plus lent.

J’aimerais trouver des comparatifs de performance avec XML+e4x. La différence risque de s’agrandir d’autant plus. Il faut aussi ajouter qu’un appel à XMLHttpRequest.responseText serait environ deux fois plus lent qu’un appel à XMLHttpRequest.responseXML. Je ne comprend pas pourquoi et je n’ai pas vérifié la validité de l’affirmation mais cela se rajouterait encore à la différence, en faveur de XML.

Reste à vérifier si cette différence de performance est significative. Le premier test est fait sur 10000 entrées pour un gain de 15ms (sur le second test on ne connait pas le temps pris par chaque itération). Peut être qu’un support natif dans dans les navigateurs fera la différence dans quelques années. Pour l’instant, même si JSON est plus lent, les différences ne sont pas significatives.  

Oui mais…

Oui mais là aussi je n’ai pas pris en compte JSON+lib. Il faut non seulement interpréter les 12ko de javascript au départ mais ensuite faire tourner le moteur basé sur des expressions rationnelles. Il y a mieux. C’est toujours Dave Johnson qui nous propose un comparatif entre JSON+lib, JSON+eval et XML+xslt. Il y a un monde entre JSON+lib et JSON+eval, quel que soit le navigateur. Même avec peu d’itérations, on voit les temps monter significativement dans le test JSON+lib.

Pire, sous Microsoft Internet Explorer et avec JSON, le temps nécessaire pour l’analyse évolue en factorielle avec le nombre d’éléments dans les données. Ca c’est disqualifiant. Plus la données est grosse, plus la différence de performance entre JSON et XML augmente. Une augmentation non linéaire est rarement négligeable.

Plus haut je disais que sur plus de 10ko la différence de téléchargement devenait significative en faveur de JSON. Mais avec ces résultats on voit aussi que la différence de temps de traitement le devient aussi, dans le sens opposé. La différence de taille évoluant linéairement et la différence de temps de traitement évoluant de manière factorielle, JSON ne sera jamais plus performant. N’oublions pas que pendant que Javascript est exécuté, c’est toute l’interface qui ne répond plus.

Alors ?

Alors quoi ? Alors déjà il faudrait un peu plus de test. J’en ferai peut être si je ne trouve rien de suffisamment complet. Il faudrait par exemple vérifier si le mauvais à priori du à évolution en factorielle et mauvaise performance des bibliothèques javascript pour JSON se traduit par des valeurs significatives ou pas. Si ça se joue au final à quelques dizaines de millisecondes par exécution c’est négligeable, si ça dépasse la demi-seconde ça ne l’est peut être pas.

Ceci dit, en attendant, je peux affirmer une chose claire : JSON n’a aucun avantage côté performance. XML se payerait même le luxe d’être au moins légèrement plus performant, à cause de sa gestion native dans les navigateurs.

Cette petite étude ne me permet pas de refuser JSON, par contre elle me permet de commencer à douter de ses soit-disant avantages. XML est présent partout, dans tous les langages, dans la plupart des applications. Il gagnera toujours les points compatibilité, extensibilité et pérennité. Est-ce que ça vaut vraiment la peine de s’embêter avec JSON sur le web tant qu’il n’y a pas d’avantages de performance ?