Group items matching

in title, tags, annotations or url

getElementsByTagName("a") is faster than querySelectorAll("a") in nearly all browsers. There's one very important difference between these two methods, and it's not that one accepts only a tag name and the other accepts a full CSS selector. The big difference is in the return value: the getElementsByTagName() method returns a live NodeList while querySelectorAll() returns a static NodeList. This is extremely important to understand.

en fait, la création de la liste d'éléments est 90% plus rapide avec getElementsByTagName par contre ça peut être compensé par les accès aux propriétés, plus rapides avec la liste statique retournée par querySelectorAll : http://jsperf.com/access-to-nodes-via-queryselectorall-vs-getelementsbyta/2 donc rien d'absolu, ça dépend de chaque code

mod_pagespeed is an open-source Apache module that automatically optimizes web pages and resources on them. It does this by rewriting the resources using filters that implement web performance best practices. Webmasters and web developers can use mod_pagespeed to improve the performance of their web pages when serving content with the Apache HTTP Server.

- JSONP au lieu de XHR pour plus de parallélisme - data uris pour les images

Vraiment très bon. Je note le coup du setTimeout pour l'insertion du script.

il modifie à la volée le HTML pour gérer le cache des statiques, compresser HTML, concaténer JS/CSS, mettre CSS/JS inline ou le contraire,

- fait par Steve Souders - le but avoué est d'en faire un standard - calculs basés sur l'API WebTiming, la google toolbar, un plugin firefox, ou simplement JS + un cookie

On rentre un peu dans le fonctionnement des JIT (notamment Javascript) et c'est diablement intéressant. Attention ça fait peur : on y explique des histoires de codes qui s'auto-modifient (ça me rappelle les émulateurs SNES ça).

J'ai beaucoup parlé de CSS, de réseau, de javascript, et j'entend parfois dire que le HTML lui n'a aucune importance. Ce n'est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM. Je vous détaille le premier ici, les deux autres bénéficieront d'un billet dédié afin de mieux organiser les commentaires.

Je vous en parlais il y a presque deux mois, JSON c'est lent à interpréter si on le fait bien. C'est même globalement plus lent que XML parce que le code est en javascript, côté utilisateur, alors que XML est géré nativement par les navigateurs.

Tester les performances nécessite du temps, beaucoup de temps. Il y a de nombreux outils qui permettent de tracer les téléchargements, les requêtes, les temps d'attente, etc. Ce qui manque c'est la page à tester. À chaque itération il faut changer le code html, le css, le javascript, les images.

Hier j'ai tenté de convaincre de mettre les codes javascript à la fin du document. Et là, d'ordinaire, chacun trouve une raison pour ne pas suivre le conseil. Des fois de très bonnes raison, souvent des contestables.

Chaque fois que je parle de reléguer les codes javascript en fin de page, je vois une moue sur le visage de mon interlocuteur. Mettre le javascript dans le du document, et encore plus à la fin de celui-ci, et souvent préjugé comme une pratique "sale". Laissez moi vous convaincre du contraire.