Group items tagged

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.

Je vous l'avais dit, une balise

La latence réseau a un impact très important sur les performances. Si les ressources sont zippées, que vos images sont correctement compressées, et que les fichiers textes sont minimisés, la latence peut devenir presque plus pénalisante que les téléchargements eux même.

Media Query & Asset Downloading Results A little while back, I mentioned I was doing some research for the book about how images are downloaded when media queries are involved. via Pocket

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.

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

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

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.

En avril je vous parlais du packer de Dean Edwards qui permet de miniser le code javascript avant envoi. J'émettais un doute sur l'option base62. Avec cette option le code javascript est codé avant envoi. Une fois ce javascript reçu, le navigateur va le décoder, puis utiliser eval() pour l'exécuter. C'est tout sauf transparent pour le client, surtout que pendant ce temps de traitement supplémentaire, c'est tout le rendu et les téléchargements de la page qui sont bloqués.

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.

Il y a peu on a vu fleurir des liens vers des propositions au groupe de travail CSS. Et en particulier une proposition de variables CSS. Ces variables peuvent être changées dynamiquement en javascript. Le rendu est alors refait avec la nouvelle valeur, partout où la variable était utilisée.

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

Hier j'ai tenté de convaincre de mettre les codes javascript à la fin du document. Et là, d'ordinaire, chacun trouve une raison pour ne pas suivre le conseil. Des fois de très bonnes raison, souvent des contestables.

Chaque fois que je parle de reléguer les codes javascript en fin de page, je vois une moue sur le visage de mon interlocuteur. Mettre le javascript dans le du document, et encore plus à la fin de celui-ci, et souvent préjugé comme une pratique "sale". Laissez moi vous convaincre du contraire.

Pour diminuer la taille des téléchargements on utilise la compression et la minimisation. La minimisation c'est l'art d'enlever tout ce qui est inutile dans un fichier : espaces blancs, commentaires, et éventuellement noms de variables longs.

JSON ! c'est le cri de tous les développeurs web à la mode dès qu'ils entendent parler d'échanges de données. Ce format est sensé être plus performant, plus simple, plus standard, plus performant, plus web 2.0 quoi. Plusieurs points mériteraient un billet à part entière, et je suis en désaccord sur chacun d'eux, mais je me focaliserai ici sur un seul : la performance. Les performances peuvent se voir au niveau du téléchargement et au niveau de l'interprétation par le client.