Group items tagged

C'est fou quand même : en pratique, les temps de chargement via CDN sont plus importants que sans CDN.

en même temps les "fortune 1000" ne sont surement pas tout purement Web, et pour les sites corporates, je ne pense pas que le manque de performance soit très grave

on aurait aimé qu'il teste autre chose que le temps de chargement, mais c'est la métrique la plus facile à tester sur beaucoup d'urls. Et ça démontre que consciemment ou pas, les sites plus performants que la moyenne obtiennent de l'argent

Clicky rajoute 500ms au temps d'ouverture d'un lien externe. NetRatings ajoute 500ms à l'ouverture de tout les liens !

petite remarque sur le partage de liens : il y a quantités de langages server-side et quantités de ressources disponibles facilement pour chacun de ces langages je ne suis pas sur que ça vaille le coup de mettre des astuces de perfs de ces langages sur cette liste ?

+1 La performance front est déjà un vaste sujet, bientôt 1000 liens partagés dans ce groupe d'ailleurs :)

Ok .. Ce qui pourrait donner : web-front-performance & web-back-performance ?

l'auteur suggère de gérer son cache en javascript pour la partie intelligente = ne recharger la page que lorsque quelque chose a changé. Ca fait un bout de temps que j'y pense, mais j'hésite à mettre ce genre de chose en prod

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.

La taille des pages a plus que triplé en 5 ans, passant de 90Ko à 310Ko. Dans le même temps on a aussi doublé le nombre de composants externes par page (de 25 à 50). Cette progression ne faiblit pas, bien au contraire. Attention, je bourre le reste de l'article de chiffres, et certains font peur.

Je vous l'avais dit, une balise

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 ?

Aujourd'hui je fais réviser les bases avec Yslow. Il s'agit d'un outil développé par Yahoo! pour vérifier de façon automatisée l'application des règles de performances web internes. Il offre une vue rapide du poids et du temps de rendu de la page, une notation après vérification une à une de 13 des règles de performance web Yahoo!, des graphiques statistiques sur la gestion du cache, et des informations détaillées sur tous les composants de la page

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.