Skip to main content

Home/ Web Performance/ Group items tagged CleverMarks

Rss Feed Group items tagged

Boris Schapira

PerfCascade - 1 views

  •  
    A SVG-based HAR Waterfall Viewer
Boris Schapira

"Intervening against document.write()", Chrome - 0 views

  •  
    Chrome peut, dans certains cas, bloquer l'exécution de scripts qui utilisent document.write(), une très mauvaise pratique pour la performance Web.
Boris Schapira

Budget de performance : un indispensable à la rapidité des sites web - Medium - 0 views

  •  
    "... Quelle que soit l'issue, le budget de performance en tant qu'outil aura fait son office : vous vous serez interrogé sur les impacts de cette évolution, et vous en aurez maîtrisé les conséquences."
Boris Schapira

"HTTP Client-Hints", Ilya Grigorik - 0 views

  •  
    content adaption without increased client latency
anonymous

Optimizing javascript/jQuery loading time, a beginner's guide - 0 views

  •  
    "With LABjs you can load your js files completely asynchronous."
anonymous

Let's make the web faster - Google Code - 0 views

  •  
    "Here are some statistics about the size, number of resources and other such metrics of pages on the world wide web. These are collected from a sample of several billions of pages that are processed as part of Google's crawl and indexing pipeline."
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 ;-)
anonymous

Yottaa - 1 views

  •  
    Yotta fait comme beaucoup d'autres de l'analyse de performance des sites, mais permet en plus de lier cela à Google Analytics pour (tenter de) mesurer les impacts.
anonymous

How to Write Efficient CSS Selectors - O'Reilly Answers - 0 views

  •  
    "The impact of CSS selectors on performance derives from the amount of time it takes the browser to match the selectors against the elements in the document. Developers have some control over how long this matching takes by writing their selectors to be more efficient. The path to efficient selectors starts by understanding how selector matching works."
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 ...
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

Overclocking SSL - 2 views

  •  
    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
anonymous

Asynchronous and deferred JavaScript execution explained « Peter Beverloo - 6 views

  •  
    Enfin un schéma simple montrant la différence entre async, defer et rien
anonymous

jQuery LazyLoad Advertising Plugin - Web2ajaX - 6 views

  •  
    rien d'exceptionnel pour ceux qui l'ont déjà codé à la main, mais ils disent avoir une solution pour les pubs avec document.write(), à tester donc ... pour reproduire leur technique :)
  • ...2 more comments...
  •  
    jQuery LazyLoad Ad
  •  
    ça à l'air bien sympa, j'ai testé sur leur site ça fonctionne bien et avec plusieurs providers. LE truc intéressant c'est que comme c'est du "Lazy", ça peut apparaître au moment ou tu scroll la page et donc attirer l'oeil plus rapidement... ? Par contre, le nombre d'afichages de publicités avec cette technique doit baisser énormément car une pub en bas du site ne serait pas affichée si non visible. Comment justifier cette baisse auprès des commerciaux etc? Est-ce qu'un affichage en moins peut impliquer moins d'argent pour le site en question ?
  •  
    En général, je scrolle assez vite, et je ne supporte pas le lazyload des images. Donc pour les pubs, ça risque de m'énerver encore plus... ;-) Pour ce qui est du revenu à l'affichage, clair que ça le fait diminuer. Il faut privilégier le revenu au clic...
  •  
    J'aime le lazyload des images s'il est immédiat, sans fade à la noix. Je pense que les lazyload lents ne sont dû qu'à de mauvais plugins/méthodes.
Boris Schapira

"More Weight Doesn't Mean More Wait", Scott Jehl - 0 views

  •  
    Etude de cas Performance Web sur le site de  Wired
Boris Schapira

"User Timing and Custom Metrics", Steve Souders - 0 views

  •  
    "If you want to improve performance, you must start by measuring performance. But what should you measure?"
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."
Boris Schapira

Le web mobile et la performance - 24 jours de web - 0 views

  •  
    "Les 3 caches ? C'est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront."
  •  
    "Les 3 caches ? C'est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront."
1 - 20 of 23 Next ›
Showing 20 items per page