Skip to main content

Home/ Web Performance/ Group items tagged http

Rss Feed Group items tagged

Laurent Paoletti

Lazy loading below the fold - 6 views

  •  
    I've started experimenting with my home page to make it load even faster. Amazon famously does this too which you can read more about in this Steve Souders post. They make sure everything that needs to be visible above the fold is loaded first, then, it starts loading all the other "stuff" below the fold.
  •  
    Assez d'accord avec les commentaires , il faut éviter que le crawler passe sur la ressource dédiée au chargement des huits autres articles, sinon il y a un risque de duplicate content. Pour éviter cela il faut gérer des règles pour robots.txt, est-ce suffisant ? Le découpage je le fais plutôt au niveau du styling CSS et JS. J'inclue le style css indispensable à l'affichage et charge le reste . Bref il y aussi le risque de reflow dans ce cas.
  •  
    Indian Cheap Escort In Dubai Model Cheap Escort In Dubai Massage Cheap Escort In Dubai Call Girls Cheap Escort In Dubai Vip Cheap Escort In Dubai Desi Indian Escort In Dubai Desi Pakistani Escort In Dubai Desi Call Girls Escort In Dubai Desi Punjabi Escort In Dubai
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.

HTTPS Performance Tuning - HttpWatch Blog - 3 views

  •  
    Quelques conseils pratiques pour optimiser ses sites en HTTPS. La clé : HTTP 1.1 + Cache-Control à Public afin que les navigateurs regardent dans leur cache.
Laurent Paoletti

Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster - I... - 0 views

  •  
    This week begins face to face meetings at the IETF on how to approach HTTP 2.0 and improve the Internet. How the industry moves forward together on the next version of HTTP - how every application and service on the web communicates today - can positively impact user experience, operational and environmental costs, and even the battery life of the devices you carry around.
Oncle Tom

Chrome Speeding up SSL with SSL FalseStart - 2 views

  •  
    Technique déployée dans Chrome pour accélérer les négociations de contenus en HTTPS.
É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é.
Éric D.

Impact du cache HTTP - Performance web - 0 views

  •  
    Le cache HTTP permet aux visiteurs de ne pas re-télécharger les pages ou les éléments de pages qui l'ont déjà été. C'est un des meilleurs mécanismes pour accélérer l'accès du navigateur au contenu mais il est mis en échec par de nombreux cas.
Éric D.

jQuery Event Delegation Improves Performance - 7 views

  •  
    Je suis sceptique quant à ce qui est exposé là : la doc jQuery (http://api.jquery.com/delegate/) indique que delegate est équivalent à faire un "live" sur chaque élément. Le code de jQuery va également dans ce sens : https://github.com/jquery/jquery/blob/master/src/event.js J'aimerais bien avoir des résultats de test du coup.
  • ...1 more comment...
  •  
    Je n'ai pas vérifié comment traire ça jQuery spécifiquement, mais le procédé est habituel. Au lieu d'enregistrer un événement pour 10 éléments dans zone géographique réduite un à un, on l'enregistrer sur le parent et c'est le javascript qui fait l'éventuelle répartition ensuite. Ça peut effectivement avoir un impact sur les performances. Après si jQuery fait effectivement une simple boucle en interne pour enregistrer 10 fois l'évenement, ça n'amène à rien. Ce serait étrange tout de même
  •  
    Au temps pour moi, en allant plus loin dans l'analyse, il semble que jQuery ne place qu'un listener sur l'élément parent, ce qui parait logique ! J'étais d'accord avec le principe, mais c'est la doc de jQuery qui m'a mis le doute. En tout cas ça n'empêche pas que j'aimerais avoir le résultat d'un benchmark :).
Laurent Paoletti

SPDY performance on mobile networks - Google Developers Blog - 1 views

  •  
    SPDY is a replacement for HTTP, designed to speed up transfers of web pages by eliminating much of the overhead associated with HTTP. SPDY supports several optimizations that give it an edge over HTTP when it comes to speed.
Oncle Tom

Pushing Beyond Gzipping - 7 views

  •  
    Une bonne solution pour s'occuper du cas des 15% de personnes ne recevant pas de contenu compressé, pour cause de proxy ou d'entête mal formée.
  •  
    Attention qu'on risque de casser le rendu pour certains quand même. Je préfère l'optique de http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/ et http://velocityconf.com/velocity2010/public/schedule/detail/14334 Il s'agit de faire passer un petit js gzipé. S'il s'exécute correctement c'est que le navigateur sait lire gzip. On met alors un cookie et c'est la présence de ce cookie qui permet de forcer gzip côté serveur. La conséquence c'est que ces 15% n'auront pas gzip lors de leur premier accès, mais en retour on sait qu'on n'activera pas gzip s'ils ne le supportent vraiment pas
Éric D.

Analyse d'une requête HTTP - serveur et réseau - Performance web - 0 views

  •  
    On parle de temps, de performance, mais finalement que mesure t-on ? La question n'est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?
1 - 20 of 1850 Next › Last »
Showing 20 items per page