Skip to main content

Home/ Web Performance/ Group items tagged perf

Rss Feed Group items tagged

Oncle Tom

Mobile Perf bookmarklet - 4 views

  •  
    Web development on mobile devices is especially challenging. The debuggers and profilers we use on the desktop aren't available. Bookmarklets are a good alternative. They're lightweight and work on most browsers - even mobile browsers. But installing bookmarklets in mobile browsers is a pain. You could try to find all the good bookmarklets out there and install them one by one. Or... Just install the Mobile Perf bookmarklet!
  •  
    Petit favori à ajouter, sur votre ordinateur ou téléphone mobile, pour un accès rapide à des outils d'audits de performance de page Web.
Nicolas Hodin

Sélection de liens #webperf n°17 - 0 views

  •  
    Au sommaire, 23 liens sur : Arcep, Awwwards, scripts JS, DDoS et émotions, WebPageTest, FB Live, brotli et Varnish, métadonnées XML et images, 3rd party scripts, Offline First, WordPress to Hugo, Canonical AMP, démarrer en webperf, perf-tool
jpvincent

First Catchpoint Release for 2011 | Catchpoint Systems Blog - 3 views

  •  
    la nouvelle version de catchpoint permet entre autre d'analyser l'impact des DNS et des CDN sur les perfs
anonymous

11 Ways to Increase Your jQuery Performance - 7 views

  •  
    Je retiens surtout l'importance des selecteurs dans les perf jQuery : toujours utiliser un #id en premier, préfixer les classes par un balise si possible balise.maClasse ...
Samuel Martin

PythonSpeed/PerformanceTips - 4 views

  •  
    petite remarque sur le partage de liens : il y a quantités de langages server-side et quantités de ressources disponibles facilement pour chacun de ces langages je ne suis pas sur que ça vaille le coup de mettre des astuces de perfs de ces langages sur cette liste ?
  • ...2 more comments...
  •  
    Effectivement, j'ai hésité avant de publier, si tout le monde publie en fonction du language, la liste peut vite devenir imbittable. Solution 2 listes bien différenciées soit l'utilisation des tags backend / frontend
  •  
    Pour l'instant j'ai une préférence pour réserver cette liste au front, mais je donne un peu de temps pour que les gens s'expriment et on verra en fonction.
  •  
    +1 La performance front est déjà un vaste sujet, bientôt 1000 liens partagés dans ce groupe d'ailleurs :)
  •  
    Ok .. Ce qui pourrait donner : web-front-performance & web-back-performance ?
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.
jpvincent

vérifier les perfs sur la return view (avec cache) peut être trompeur - 1 views

  •  
    en gros l'idée présentée ici est que les outils montrent la return view quelques secondes après une première vue, ce qui donne généralement de bons scores. Mais en revenant 24h après sur la plupart des sites, le cache est peu utilisé
jpvincent

Outil de mesure des perfs vues par les vrais utilisateurs - 6 views

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

Performance Calendar » The State of Web Performance Optimization - 2010 - 1 views

  •  
    entre 2008 et 2010 : - un peu plus de sites appliquent les règles de perf frontend de base - les sites ont pris en poids et en complexité - du coup la performance globale est en baisse
Éric D.

Performance Calendar » Poll: Which waterfall led to greater revenues? - 6 views

  •  
    - "améliorer" les perfs a diminué le revenu - les développeurs n'ont regardé que les scores ySlow et PageSpeed + le waterfall d'une page - ils ont oublié que les utilisateurs naviguaient sur plusieurs pages - une meilleure mesure a été obtenue en posant un javascript sur les pages pour mesurer le temps de chargement effectif
jpvincent

présentation sur les perfs web - 2 views

  •  
    quelques chiffres et rappel des bases. Classique mais de bon goût
Boris Schapira

Zeroload : Mappy.com : un start render divisé par deux - 0 views

  •  
    Etude de cas Mappy pour la Web Perf.
1 - 15 of 15
Showing 20 items per page