Skip to main content

Home/ Web Performance/ Group items tagged dom

Rss Feed Group items tagged

anonymous

Efficiently Rendering CSS | CSS-Tricks - 16 views

  •  
    Ne pas oublier la fin : "I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS"
  • ...10 more comments...
  •  
    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.
  •  
    "Use class selectors instead of descendant selectors." http://code.google.com/intl/fr/speed/page-speed/docs/rendering.html "It's clear that CSS selectors with a key selector that matches many elements can noticeably slow down web pages." http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
  •  
    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
  •  
    "finir de préférence sur le sélecteur #id" : si on peut faire ça, autant le mettre directement tout seul, non ?
  •  
    Non, car ton élément #id peut avoir un style différent selon le contexte
  •  
    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.
Éric D.

DOM et autres innerHTML - Performance web - 0 views

  •  
    Un petit peu de Javascript ? C'est Peter-Paul Koch aussi dit PPK qui lance la question sur Quicksmode il y a trois mois. Il tente de comparer diverses méthodes pour ajouter du contenu à une page, et plus spécifiquement innerHTML et les fonctions DOM (par DOM j'entend appendChild, createElement et associés). On créé un tableau de 50×50 avec une astérisque dans chaque cellule et on compare. Le résultat est joli, en couleurs : DOM est lent, innerHTML est rapide. On parle d'un facteur 2 à 3, sauf pour Internet Explorer (oui, toujours) où on parle d'un facteur 20 à 30. Oui, vous avez bien lu.  
Oncle Tom

leak-finder-for-javascript - Tool for finding memory leaks in JavaScript programs. - Go... - 1 views

  •  
    Outil d'analyse de fuite mémoire JavaScript dans le navigateur. C'est pas aussi aisé qu'un bookmarklet mais ça permet d'aller assez loin dans la détection de fuite.
Laurent Paoletti

A developer's guide to rendering performance - 4 views

  •  
    When we look back over the history of web performance we see a heavy focus on reducing the number of requests and getting files to the browser quickly. Our platform has changed a lot, and while optimizing for network performance remains a crucial part of our jobs, we now have to broaden our performance horizons. Our users also expect smooth scrolling, animations and interactions, even on mobile devices. In short we need to deal with not just how quickly our sites and apps load, but also how quickly they run. [video] In this session Paul takes a lightning tour of how Chrome converts the DOM into pixels, see how our code affects its workload, and arrive at a modern workflow for finding (and eliminating) rendering bottlenecks.
Oncle Tom

Script-injected "async scripts" considered harmful - 3 views

  •  
    Or why it is better to use the `script[async]` attribute to fasten page load time.
Éric D.

Don't let jQuery's $(document).ready() slow you down | Encosia - 4 views

  •  
    à voir quand même à quel point ça ne lance pas un timer qui occupe le cpu navigateur inutilement
  •  
    A noter que si les js sont insérés en bas de page, le gain sera moindre puisque le dom sera chargé. Remarque, utiliser $(document).ready() en bas de page c'est peut-être un peu enfoncer des portes ouvertes.
  •  
    Utiliser trop souvent $(document).ready sur VOTRE code c'est aussi laisser tous les autres scripts (pubilicités/widgets) s'exécuter avant vous. Ainsi ils peuvent créer autant d'éléments et occuper des requêtes navigateur pour rien. Trop souvent il est automatiquement conseillé d'utiliser $(document).ready (genre dans les guidelines pour débutant), sauf que la plupart des widgets (et surtout des publicités) se moquent de ces recommandations. Toujours maitriser l'ordre de téléchargement des éléments de votre page avant de décider d'utiliser ou non $(document).ready pour vos initialisations.
Thomas Bassetto

Why is getElementsByTagName() faster that querySelectorAll()? - 4 views

  •  
    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
Éric D.

Erreurs de syntaxe - Performance web - 0 views

  •  
    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.
Éric D.

Performance des sélecteurs CSS, encore un mot - Performance web - 0 views

  •  
    On reparle des performances CSS. Souvenez-vous, je vous avais parlé d'un document de Mozilla faisant état des sélecteurs plus ou moins performants. S'était ensuivi une discussion à propos de la pertinence de tels sujets vu la différence de performance mise en oeuvre.
Éric D.

Styles avec et sans Javascript - Performance web - 0 views

  •  
    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.
Éric D.

JSON ? - Performance web - 0 views

  •  
    JSON ! c'est le cri de tous les développeurs web à la mode dès qu'ils entendent parler d'échanges de données. Ce format est sensé être plus performant, plus simple, plus standard, plus performant, plus web 2.0 quoi. 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.
1 - 20 of 25 Next ›
Showing 20 items per page