Skip to main content

Home/ Web Performance/ Group items tagged navigateurs

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.
Oncle Tom

Performance: Profiling how different web sites use browser subsystems - IEBlog - Site H... - 5 views

  •  
    détaille les différents sous systèmes du navigateur et leur répartition dans le temps total de rendu de la page
  •  
    Présentation rapide des 11 sous-systèmes utilisés par un navigateur Web pour effectuer le rendu de la page, en partant du réseau pour terminer à l'affichage. Quelques chiffres montrent qu'en tant que développeur Web, on a la main sur les temps utilisés sur chacune des couches ... pour peu qu'on l'ait en tête. C'est chose faite ;-)
Oncle Tom

Replacing the -9999px hack (new image replacement) - 5 views

  •  
    Une nouvelle technique pour masquer du contenu sans utiliser le fameux `left: -9999px`. Principal avantage : le navigateur n'a pas besoin de dessiner une boîte énorme pour y placer ce contenu.
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.
É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.
Oncle Tom

Performance Impact of CSS Selectors - 1 views

  • The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.
  •  
    Comment une mauvaise utilisation des sélecteurs CSS, en complément d'une page chargée en nombre de balises HTML, peut drainer la vitesse du navigateur. Comme d'habitude : KISS. Et tout ira bien.
Éric D.

Expires et Cache-Control, une date limite de consommation pour vos contenus - Performan... - 0 views

  •  
    Je parle de détails et de ce que je rencontre dans mes lectures, et j'en oublie le principal. alors voilà, si vous ne devez retenir qu'une chose c'est d'utiliser des dates d'expiration explicites sur vos contenus. Il s'agit d'informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n'a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d'autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément.
Éric D.

Pipelining : enchaîner les requêtes HTTP - Performance web - 0 views

  •  
    Le pipelining HTTP c'est faire gérer au serveur une file de requêtes. Le navigateur envoie plusieurs requêtes à la suite les unes des autres sans attendre la réponse du serveur. Le serveur renvoie alors les réponses dès qu'il les a, potentiellement en parallèle aux requêtes du navigateur. Non seulement on utilise le principe de la connexion persistante, mais on évite d'attendre la réponse précédente avant d'envoyer la suite. Pour chaque ressource à télécharger après la première, c'est un aller-retour réseau à rien faire qui est évité.
Oncle Tom

HTML5 Rocks - Improving the Performance of your HTML5 App - 6 views

  • It is not commonly known that JavaScript supports naming function expressions.
  •  
    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 ? ;-)
  • ...2 more comments...
  •  
    tu t'es trompé dans l'url ou alors elle a été supprimée ? Sinon les fonctions anonymes posent pas mal de problème avec IE il me semble.
  •  
    J'ai l'impression que Diigo supprime systématiquement le dernier slash dans l'URL ;-(
  •  
    ok, j'aurais pu le trouver tout seul. Excellente URL, elle parle de sujets qu'on trouve pas vraiment ailleurs.
Oncle Tom

Fastersite: How a web page loads - 5 views

  •  
    Comment le code source d'une page web est parsé et interprété pour comprendre l'effet sur le chargement et la performance.
  •  
    Bon pour comprendre comme une page HTML est effectivement parsée, décodée puis interprétée par un navigateur Web.
Nicolas Hodin

spin.js - Un indicateur de chargement en js - 4 views

  •  
    Facilement configurable, supporte la majorité des navigateurs dont IE6 et plus léger qu'une image gif (1,7ko en gzip).
Samuel Martin

Adaptive Images in HTML - 3 views

  •  
    Petite résolution d'écran = Chargement de petites images
  •  
    Je bookmarke, mais impossible de tester avec l'iphone, le site délivré est différent. J'ai tenté de charger le site de démo dans un navigateur avec une faible dimension, c'est toujours l'image la plus grande qui est chargée. Cela se base donc sur la résolution écran et non la résolution navigateur. A confirmer.
Boris Schapira

"Content Performance Policy : une étape supplémentaire pour un web plus rapid... - 0 views

  •  
    "Tim Kaldec et Yoav Weiss se sont donc inspirés de ce mécanisme [Content Security Policy], pour le transposer au sujet de la performance web, en proposant un nouvel en-tête HTTP (Content Performance Policy) permettant de déclarer précisément le degré de compatibilité d'une page avec certaines bonnes pratiques de performance web. À la charge ensuite du navigateur web, de forcer l'application des bonnes pratiques annoncées qui ne seraient pas respectées par l'éditeur."
1 - 20 of 48 Next › Last »
Showing 20 items per page