Group items tagged

Un petit peu de Javascript ? C'est Peter-Paul Koch aussi dit PPK qui lance la question sur Quicksmode il y a trois mois. Il tente de comparer diverses méthodes pour ajouter du contenu à une page, et plus spécifiquement innerHTML et les fonctions DOM (par DOM j'entend appendChild, createElement et associés). On créé un tableau de 50×50 avec une astérisque dans chaque cellule et on compare. Le résultat est joli, en couleurs : DOM est lent, innerHTML est rapide. On parle d'un facteur 2 à 3, sauf pour Internet Explorer (oui, toujours) où on parle d'un facteur 20 à 30. Oui, vous avez bien lu.  

Et si on parlait un peu des images ? du point de vue des performances web, toujours.    Sur un site classique comme TF1, Amazon, LeMonde, on dépasse les 100 images sur la page d'accueil, pour un total de près de 300ko. Les sites plus au fait des problèmes de performance ont entre 30 et 50 images mais le poids total est encore souvent supérieur à 100ko.

J'abuse, il parait. Je parle de demi seconde ou même de centaines de milli-secondes. Je parle de quelques dizaines de kilo-octets là où la plupart ont des pages qui en font cinq ou dix fois plus. Alors voilà, j'assume. Mais peut être que ça vaut le coup de rappeler trois chiffres qui permettront à chacun d'avoir des arguments quand on ne les prend pas au sérieux :

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.

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.

Nous avons peu d'informations officielles de la part des navigateurs sur les performances de leurs moteurs. Le Mozilla Developer Center nous propose tout de même une courte page sur comment écrire des feuilles de style efficaces.

Après un test de votre site sur Yslow vous retrouvez une recommandation qui vous propose de désactiver les ETags. Une recherche rapide vous mène sur les pages de l'équipe performance de Yahoo! qui vous disent la même chose.

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.

Trois ans plus tard, ça ne me semble pas corrigé dans Safari 5.0.5 sous Windows. Quelques soit les headers de caching utilisés, Safari fetch à nouveau la source à chaque fois, même plusieurs fois sur la même page. Ca me semble étrange qu'un si gros bug ne soit pas corrigé après tout ce temps, donc peut-être une mauvaise config de ma part.

- bien sur utiliser la version asynchrone - déplacer l'appel en bas de page (attention aux pertes de données pour les visiteurs qui cliquent vite) - mettre ga.js sur un serveur local

- 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