Skip to main content

Home/ Web Performance/ Group items tagged render

Rss Feed Group items tagged

anonymous

Rendering on the Server and Client in Node.js - 1 views

  •  
    "At Artsy we've been building Node.js applications that share code and rendering between the server and browser. We've seen many benefits from this - pages load faster, we can optimize SEO, developers are more productive, and JavaScript coding is just an overall better experience."
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.
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.
Frank Taillandier

Performance Calendar » Deciphering the Critical Rendering Path - 0 views

  •  
    Pour les sites complexes avec beaucoup de JS, surveiller DOMContentLoaded (fin du parsing) plutôt que juste Load (fin du chargement) pour améliorer le ressenti utilisateur
anonymous

Scour is an open-source Python script that aggressively cleans SVG files - 1 views

  •  
    "Scour is an open-source Python script that aggressively cleans SVG files, removing a lot of 'cruft' that certain tools or authors embed into their documents. The goal of scour is to provide an identically rendered image"
Frank Taillandier

High Performance Web Sites :: Render first. JS second. - 0 views

  •  
    gros parti pris de Souders sur l'exécution de javascript : il ne devrait même pas être asynchrone, mais différé jusqu'à ce que la page soit rendue
  •  
    Il n'a pas tout à fait tort, mais il oublie quand même pas mal de choses sur les interfaces modernes. Beaucoup n'ont pas de fallback, ou un fallback très mauvais. Genre un bouton commander qui ouvre une popin. Il est impossible d'envisager ne pas accrocher immédiatement le gestionnaire javascript
Boris Schapira

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

  •  
    Etude de cas Mappy pour la Web Perf.
Boris Schapira

"The Website Obesity Crisis", Maciej Cegłowski - 0 views

  •  
    "I want to share with you my simple two-step secret to improving the performance of any website. 1. Make sure that the most important elements of the page download and render first. 2. Stop there."
Éric D.

Faster Websites: Crash Course on Web Performance - igvita.com - 4 views

  •  
    3 hour workshop on web performance from the ground up: what is fast, impact of latency and bandwidth, TCP performance, SPDY protocol, browser parsing and execution, rendering optimizations, critical path, and more.
Laurent Paoletti

Blocking JavaScript with Web Page Test - simulate eliminating JavaScript on web page lo... - 1 views

  •  
    Summary: Learn how to simulate the elimination of JavaScript with Web Page Test. By eliminating, deferring or converting your JavaScript behavior into CSS you can speed up your page rendering and load times.
Boris Schapira

Akamai Acquires Website Performance Company Blaze Software - 1 views

  •  
    "Blaze's cloud-based service automatically optimizes the code on a web page during the delivery process to ensure faster transmission of content and a faster rendering of the page, whether served to a PC, tablet or smartphone."
Laurent Paoletti

Optimizing the critical rendering path - 0 views

Vincent Voyer

Retour d'expérience sur l'optimisation de la homepage de mappy.com - 0 views

  •  
    Un gros travail sur la priorisation des téléchargements a été effectué. Rassurez-vous je ne vais pas poster tous les blog posts de mon blog :) Simplement celui-ci est le plus intéressant pour le moment.
Éric D.

Performance Calendar » Mobile performance analysis using pcapperf - 3 views

  •  
    - ne marche que sur le wifi - testé seulement sur mac - pas de start render ou de onload, juste l'observation du trafic réseau
1 - 20 of 21 Next ›
Showing 20 items per page