Si vous prenez en compte le trafic total d’un site, genre 1 millions de visite par jour, même 1%, même 3 octets peuvent au final économiser quelques téraoctet par jour.

Il n’y a pas de « plus ou mieux que ». C’est surtout une question de meilleurs choix en fonction de l’ensemble des contraintes techniques/financières/humaine.

Une des lacunes de json par rapport au XML, c’est l’absence de « schéma ». Mais est-ce qu’un schéma est bien nécessaire pour l’usage qui en est fait ?

Bref, le temps passe et SOAP disparaîtra 🙂

Par contre pour la taille tu ne peux pas faire attention à quelques octets qui sont finalement très léger en valeur absolue, et en même temps considérer comme négligeable l’import de la bibliothèque.

Même avec le cache, c’est dans les 40% des utilisateurs qui téléchargeront la lib une fois au cours de leur visite. Il va falloir faire beaucoup de json pour compenser.

Mais même si ça compense, entre télécharger un gros morceau, une fois, de manière bloquante, et télécharger plein de petites fois quelques octets de plus, au fil de l’eau, je te garantis que tu verras passer le premier cas mais que le second ne se verra pas du tout.

Pour qualifier de petit :
– Moins de 1.4Ko ça passe dans un seul segment TCP, c’est virtuellement identique que tu transfères 300 octets ou 1Ko. Pour voir une différence il faudrait que ces messages de 300 octets arrivent à saturer la bande passante disponible. Sur une connexion TCP saturer la bande passante avec des messages d’un seul segment est quasiment impossible, il faudrait que tu en envoies des milliers en simultané et en continu sur ton navigateur. Si ton navigateur envoit 5 requêtes ajax en simultané il y a déjà probablement un problème de conception ou d’agrégation donc on a de la marge.

– En dessous de 4Ko ça passe dans moins de trois segments TCP, donc ça passe en un seul round trip, sans attendre les ACK TCP. Là aussi, même chose, pour saturer il en faudrait quelques milliers à la fois.

Donc voilà, si ton message ne dépasse pas les 5 Ko (et je doute qu’il le fasse) tu ne verras pas la différence. Tant qu’il ne dépasse pas les 20 Ko et que tu as une faible latence, la différence sera négligeable vu qu’on parle de requêtes en fond, non bloquantes.

Et non, si tu considères que 40% c’est énorme sans regarder la valeur absolue c’est toi qui a un problème de raisonnement.

Je provoque, il reste intéressant, mais les grands navigateurs intègrent maintenant un objet JSON nativement. Alors justement, il serait très intéressant d’étayer ce texte avec de nouveaux petits tests je trouve.

Par ailleurs, bien que globalement d’accord avec les conclusions de l’article, je trouve la démonstration incroyablement orientée, et très peu objective. Elle minimise puis occulte ouvertement chaque éléments contraires à la conclusion recherchée, les uns après les autres, pour finalement aboutir, par la force des choses, à la conclusion qu’aucun n’est viable.

Je noterai quand même, dans le désordre,
qu’une librairie externe JS est rarement re-téléchargée à chaque page ;
que 40% en taille, quoi qu’on en dise sur la valeur absolue, c’est énorme (pourquoi supposer qu’on ne transmet que de toutes petites données, et qu’est-ce qu’on appelle petites données ? Pour moi, 800 octets c’est gros quand c’est une différence que l’on trouve dans chaque objet passé !) ;
etc.

Dans « Ridicule », un professeur démontre au roi l’existence de Dieu. Il termine sa démonstration sous les applaudissement du roi par cette phrase, qui lui vaudra la mort : « j’aurais pu tout aussi bien démontrer le contraire si son Altesse me l’avait demandé »…

Enfin, bon travail de documentation cependant, merci 😉

Wait and see…

Je pars sur une donnée de 2ko qui me parait représentative, mais on peut refaire le calcul avec d’autres chiffres la conclusion restera assez similaire. Sur un XML de 2ko, une fois passé par gzip, l’équivalent json+gzip la différence en valeur absolue est d’environ 160 octets. La différence de poids entre XML et JSON pour le type de données qu’on transfère habituellement est franchement négligeable devant le poids de la requête HTTP elle-même.

Bref, on gagne d’un côté 160 octets négligeables face à ce qui est transmis par ailleurs, mais on perd bien plus en devant ajouter une bibliothèque javascript de décodage ou simplement en utilisant eval().

Replacé dans son contexte, la différence de poids est peu significative.

Etonnant 🙂

Mais super article tout de même

Il toujours bon dans le cadre de scripts web de prévoir des sas de sécurité afin de limiter la casse en cas de coups durs.

Je ne suis pas formel mais il est fort possible qu’attacher dynamiquement un élément soit plus performant qu’un eval() sous IE.

Pour information, cette technique a été popularisée par Yahoo 😉

http://joseph.randomnetworks.com/archives/2007/01/08/json-does-not-require-eval/
http://developer.yahoo.com/common/json.html

http://www.wait-till-i.com/2008/04/11/example-of-an-unobtrusive-lazy-loading-badge-using-the-twitter-api/

Je trouve son exemple plutôt intéressant, non ?

Mais pour Firefox il faut encore les privilèges chrome, ce qui empêche toute utilisation sur un site web classique. Ca ne changera pas pour Firefox 3. D’ici à Firefox 4, d’ici à ce que les autres navigateurs et particulièrement MSIE proposent quelque chose d’équivalent … il y aura de l’eau sous les ponts.

Entre temps E4X arrive, et XML pourrait regagner le coeur des développeurs.

J’aurai plutôt dit « grâce à sa gestion native » 😛

Et justement, ça doit être pour ça que JSON est moins performant que XML, puisqu’il reste artisanal (un gros eval c’est un peu crados), peut-être que si les navigateurs proposaient des méthodes pour exploiter du JSON les résultats seraient différents.

(mais je doute que les développeurs de navigateurs veuillent se pencher là dessus…)

Merci pour cet article, je bois tes conseils 😉 !