Group items tagged

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é.

La BDD est téléchargeable à l'adresse : http://httparchive.org/downloads.php. Il est possible de faire ses propres requêtes. Les données sont stockés depuis 2010. L'échantillon regroupe 70 000 urls différentes (principalement US).

Statistiques sur les pages moyennes (nombre de requêtes, de domaines, poids, etc.)

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 ?

Nos navigateurs sont performants, ils savent gérer plusieurs téléchargements en parallèle. Ca nous permet de palier les serveurs lents, et d'optimiser le réseau. Le temps qu'on se connecte sur un serveur, qu'on fasse une requête DNS, le réseau reste occupé avec d'autres téléchargements.

Pas pris encore le temps de tester ce nouvel outil mais j'aime bien la philosophie, je suis preneur de vos retours.

y'a bien un spécialiste qui va nous pondre un comparatif un de ces quatres, ça commence à faire beaucoup mais c'est bon signe pour la performance, à adapter toujours en fonction du contexte de toute façon.

moi en tout cas ça me parle. à faire attention : comme pour d'autres loaders, il faut que le cache soit bien configuré car il fait une requête pour mettre en cache, et une 2nde requête pour exécuter, normalement depuis le cache. Si le cache n'est pas bien configuré (que veux dire "bien" : au moins 10 minutes d'expiration ?), la ressource sera téléchargée deux fois.

Sur des sites utilisant de nombreux enregistrements DNS, ça peut valoir le coup/coût de vérifier la charge/nombre de requêtes ... et désactiver le prefetching. Résultat : une baisse considérable du trafic ... à juste titre.

"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."

à 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.

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.

Je viens de croiser une liste de recommandations Microsoft pour la performance des sites web. On y retrouve plusieurs choses connues et une recommandation sur la cohérence des liens. La page MSDN donne l'exemple d'un même lien avec deux casses différentes. Certains serveurs ignoreront la casse ou corrigeront le lien mais cela restera deux ressources différentes sur le client, avec des entrées séparées sur le cache, donc au moins une requête HTTP inutile.

Tester les performances nécessite du temps, beaucoup de temps. Il y a de nombreux outils qui permettent de tracer les téléchargements, les requêtes, les temps d'attente, etc. Ce qui manque c'est la page à tester. À chaque itération il faut changer le code html, le css, le javascript, les images.

Deux règles principales pour la performance des sites web sont de réduire le nombre de requêtes HTTP et de limiter la taille des données qu'on télécharge. Malheureusement ces deux règles entre parfois en conflit. Si je fais un gros fichier unique pour toutes mes CSS, je vais inclure des règles qui seront inutiles pour la page courante, et qui augmenteront inutilement la taille totale à télécharger.

- sérieuses conséquences lorsque l'on active la capture vidéo - comparé à keynote (solution de tests payante), les pages s'affichent bcp + vite. - il y a visiblement un bug puisque certaines requêtes s'affichent en 1ms conclusion perso : - un peu jeune, mais c'est le seul qu'on ait - vu la diversité des expériences dues au réseau, il ne faut pas prendre les résultats à la lettre mais plutôt l'utiliser pour comprendre le fonctionnement des navigateurs mobiles