Group items tagged

en même temps les "fortune 1000" ne sont surement pas tout purement Web, et pour les sites corporates, je ne pense pas que le manque de performance soit très grave

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

Proposition pour embarquer l'alpha dans un fichier JPEG

j'espère que ça restera vraiment une "expérience", utiliser canvas, javascript, css pour afficher une image transparente, avec ces inconvénients : # By default, the images load without their alpha, then get alpha'd causing a flash. This can be worked around by making them invisible until correctly loaded. # The image must reside on the same server as the web page or the cross site scripting prohibitions in AJAX will come into play. # My examples are double loading the image, for some reason the AJAX fetch is not using the cache. I don't know why, but it is probably just me. ça reste un affreux bricolage qui pourrait donner des envies à des gens qui n'y connaissent rien et pourrir des sites avec ça. Mais l'expérience est "amusante" de là à en faire une "proposition", j'ai des doutes

C'est clair qu'afficher l'alpha avec canvas+js reste du bricolage. En revanche, si les implémenteurs arrivent à se mettre d'accord pour le faire directement dans le navigateur, ça pourrait être intéressant.

Excellente technique complémentaire au Data URI, pour Internet Explorer 7 et moins.

Comment réduire la charge CPU et le temps d'affichage des pages en SSL, avec un patch et pas mal de bonnes idées.

côté serveur, ça a l'air par mal, surtout qu'ils l'ont testé sur Gmail. Par contre côté client, il me semble que tous les objets (images, css, js) ont aussi besoin d'être décodés, ce qui prend du temps CPU au client. Pour Gmail qui a très peu d'images, ça n'est pas un problème, mais pour un site lambda, ça peut commencer à compter

- use #id, .class or tagname at right of CSS selectors (in this order)\n- be precise when you use :hover (even if not at the right of the selector)\n- in javascript, a loop for read then a loop for write may be quicker than a loop with read/write because we can avoid the engine to rebuild the layout for each iteration

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.

Charger le javascript le plus tard possible, ou au moins de manière asynchrone, implique que le visiteur risque de voir la page avant l'exécution du dit javascript. Si le javascript enrichit ou modifie la page, le visiteur aura la désagréable surprise de voir la page se modifier sous ses yeux.

Je fais suite au précédent billet sur la présentation de Steve Souders aux conférences Velocity 2008. Tout à la fin il nous donne une seconde information sur le javascript inline, et ceci est une nouveauté pour moi.

Utiliser les filtres CSS d'Internet Explorer n'est pas une bonne idée. Déjà ils sont inutiles la plupart du temps, quand vous pouvez vous contenter d'un PNG8 avec une transparence binaire (c'est à dire la plupart du temps si vous avez suivi le début de la phrase), mais en plus ils sont lents.

Ceux qui ont utilisé les jeux vidéo il y a 10 ou 15 ans connaissent forcément les sprites. Pour économiser les ressources on regroupe toutes les icônes et les images dans un ou plusieurs fichiers. Le résultat c'est une sorte de tableau d'images, le jeu utilise alors simplement une partie de cette image à chaque fois qu'il a besoin d'une icône.  Tout est une question de ressources disponibles, à l'époque on parlait de mémoire occupée et d'accès disque. Plusieurs années après, le Web a les mêmes problématiques : la poids et le nombre d'éléments à charger impactent directement et fortement les performances des pages. Il est donc logique qu'on utilise les mêmes solutions.