This extension measures page load time and displays it in the toolbar.
Web Timing API is used for precise measurement (Google Chrome version 6+ required).
Une excellente synthèse des APIs disponibles en HTML5 et CSS3 pour tirer partie des optimisations des navigateurs, et des choses à éviter dans le code.
Qui eut cru que les fonctions anonymes pouvaient être nommées ? ;-)
jQuery is served by Google AJAX Libraries API.Other Javascript and CSS resources are minimized by YUI Compressor.HTTP caching and other server-side options are optimized based on advice from YSlow.The text uses Unicode characters in place of graphics wherever possible.The entire book was lovingly hand-authored in HTML 5 to avoid markup cruft.
Retrouvez une sélection de liens sur le thème des performances Web de la semaine passée. Au sommaire, 12 liens sur : un nouvel outil pour analyser les performances par Microsoft, le TTFB, API PerformanceObserver chez Canary, perception de la vitesse, CSS right to left, HTTP/2, optimisation des JPG, …
je suis pas d'accord avec tout.
par exemple : "Don't [tag qualify] with class names either" => j'avais justement lu le contraire. Qu'un "a.toto" était plus efficace qu'un ".toto". Mais ça dépend aussi peut-être des moteurs...
D'ailleurs, je ne comprends pas pourquoi les moteurs ne cherchent pas d'abord le bout le plus discriminant dans le sélecteur. Ça arrive souvent de commencer un sélecteur par un sélecteur d'ID, et il me semble que ce serait plus rapide que de commencer par lui, plutôt que par le tag qui se trouve à la fin (ex: #menu a { }).
Oui si .toto est présent sur le même type de tag à savoir "ul" ..inutile d'écrire ul.toto. " .toto" suffit et est apparement plus rapide à interpréter. C'est le cas pour les nouveau parseurs DOM il me semble (firefox). Après savoir si tous la navigateurs se comportent de la même façon sur ce point, je l'ignore.
mais par exemple, dans un jQuery, c'est le contraire, semble-t-il.
Si la perf de querySelectorAll est la même que celle utilisée pour appliquer les CSS, on doit pouvoir tester avec jsperf.com.
Oui, c'est l'opposé sur jquery, parce que jquery ne peut pas utiliser les index du navigateur efficacement. Ceci dit ça peut changer à l'avenir pour jquery au fur et à mesure qu'ils pourront utiliser les API querySelector et ce genre de choses.
Deux règles :
- finir de préférence sur le sélecteur #id, ou .classe, éventuellement un nom de balise (mais si possible pas un trop fréquent), pas de sélecteurs plus complexes (attribut seul, pseudo sélecteur, *)
- éviter de surspécifier le sélecteur à gauche
Sachant que la plupart (tous) des navigateurs lisent les règles CSS de droite à gauche, il vaut mieux éviter de spécifier le tagName.
Dans des librairies comme jQuery le problème est un peu différent même si jQuery (sizzle) lit aussi de la droite vers la gauche.
Sur les navigateurs qui n'implémentent pas certaines fonctionnalités comme getElementsByClassName (IE6-8), sélectionner $('.maclasse') sera plus long que $('a.maclasse'). Le mieux étant de faire $('.maclasse', noeudDomDeDepart) si on sait a peu près où sont les classes pour éviter de traverser tout le DOM.
Autre différence $('#mydiv span');sera plus rapide que $('span'); Alors qu'on pourrait croire que jQuery lit toujours de la droite vers la gauche, il effectuera une exception ici et sélectionnera d'abord $('#mydiv') puis regardera les "span". (http://forum.jquery.com/topic/about-selectors-right-to-left#14737000000472293)
Enfin si on travaille sur des noeuds qui ne sont pas encore dans le DOM (pas de append()) , les méthodes employées pour parcourir le noeud seront de simples boucles qui regardent tous les noeuds, pas d'accès à getElementsByClasseName ni getElementbyId. Là dans ce cas il vaut mieux spécifier carrément le tagName + la classe (voire l'ID) ça évite de faire des tours de boucle pour rien.
ça reste des cas franchement spécifiques qui ne devraient pas exister, on ne parcourt pas des noeuds html qui ne sont pas dans le DOM dans une application classique et on évite de faire des sélections brutes de $('.classe') si on connait a peu près la structure DOM.
Edit:
jquery (sizzle) utilise querySelectorAll quand disponible, sinon des méthodes perso combinées avec getElementbyId, className, tagname.
http://www.neeraj.name/2010/02/15/how-jquery-selects-elements-using-sizzle.html
Comme j'aime bien embêter : Jquery et le natif utilisent les algos aux propriétés presque opposées dans certains cas. Comme le jquery peut renvoyer vers le natif, si vous cherchez trop la bête, vous irez forcément dans le mur sur certains navigateurs.
Bref, faites simple. Un "#xxx .yyy" sera à peu près acceptable sur jquery comme sur le natif pour peu qu'on n'utilise pas trop souvent la classe en dehors de l'arbre #xxx. C'est peut être le compromis qui passera le mieux partout (simple pour le navigateur parce qu'il utilise son index pour trouver le .yyy, que remonter au #xxx sera rapide, et qu'il ne remontera pas trop souvent inutilement ; et simple pour jquery parce que grâce à #xxx il peut isoler un arbre DOM restreint sur lequel lancer sa recherche)
Comme cette discussion est oriente vers le js:
Des selecteurs optimisés c'est bien, un bon design d'application c'est mieux.
selection d'une collection - binding d'une fonction sur ces éléments ---> anti-pattern.
Event Delegation ----> pattern
(lors de l initialisation)
selection d'une collection - modification de propriétés css ----> anti-pattern
insertion d'html préstylé (classes) ---> Pattern
@Vincent
Juste pour pinailler :
> Le mieux étant de faire $('.maclasse', noeudDomDeDepart)
Je dirais le mieux serait même $('noeudDomDeDepart').find('.maclass')
Source : http://jsperf.com/jquery-selectors-context/2
sans les tirets alors :-)
À la base, je trouve ça assez fou que $(XXX).find(YYY) soit tellement plus rapide que $(YYY, XXX).
Mais quand on regarde le code on voit qu'il y a beaucoup de "if" dans l'init de jQuery et que les cas les plus courants sont placés en premier. Le cas du contexte est traité à la toute fin, ça explique la différence.
Je n'ai pas vérifié comment traire ça jQuery spécifiquement, mais le procédé est habituel. Au lieu d'enregistrer un événement pour 10 éléments dans zone géographique réduite un à un, on l'enregistrer sur le parent et c'est le javascript qui fait l'éventuelle répartition ensuite. Ça peut effectivement avoir un impact sur les performances.
Après si jQuery fait effectivement une simple boucle en interne pour enregistrer 10 fois l'évenement, ça n'amène à rien. Ce serait étrange tout de même
Au temps pour moi, en allant plus loin dans l'analyse, il semble que jQuery ne place qu'un listener sur l'élément parent, ce qui parait logique !
J'étais d'accord avec le principe, mais c'est la doc de jQuery qui m'a mis le doute.
En tout cas ça n'empêche pas que j'aimerais avoir le résultat d'un benchmark :).
Petite appli en ligne pour générer son propre framework Javascript, basé sur votre propre sélection de librairie, de JSON2 à Spine en passant par Ender.
Les tailles sont indiquées et les librairies choisies le sont en particulier pour leur robustesse et faible empreinte mémoire.
J'ai assisté à la présentation de Zepto à la JSConf
Ce micro framework permet d'avoir une API compatible avec jQuery, mais utilisant directement les implémentations native de webkit. Il est destiné à fonctionner sur les plateformes iOS et Android avec un poids de 4 Kb contre 31 Kb pour jQuery
Excellent, merci Alexandre pour cette précision. Comptent-ils pousser la compatibilité vers d'autres navigateurs ?
En tous cas, combiné avec yepnope (pour le polyfill), ça peut être super pour construire ses dépendances à poids mini.