La conférence « Velocity Europe 2013 » a eu lieu en Novembre 2013. Il est grand temps de faire un petit retour de cette première journée de conférence. Le thème de cette conférence est la performance web (back, front, système).
La conférence « Velocity Europe 2013 » a eu lieu en Novembre 2013. Il est grand temps de faire un petit retour de cette première journée de conférence. Le thème de cette conférence est la performance web (back, front, système).
Gone in 60 frames per second par Addy Osmani (Google Chrome)
https://speakerdeck.com/addyosmani/velocityconf-rendering-performance-case-studies
Cette présentation s’est focalisée sur les bonnes pratiques pour obtenir le meilleur framerate possible et donc une meilleur fluidité lors de la navigation sur une page web. En effet, après la génération du code html par le serveur et la transmission du code via le réseau, le navigateur rend la page.
il faut toujours avoir en tête que les performances sur desktop ne sont pas les mêmes que sur mobile. Un framerate de 60 fps est le mieux, car c’est le taux de rafraîchissement en moyenne de tous les devices. Pour optimiser le rendu d’une zone, il faut qu’elle s’affiche en 16.7 ms.
Voici quelques bonnes pratiques :
- disposer des images à la bonne taille
- limiter les handlers sur l’évènement onScroll()
- limiter tous les éléments ‘fixed’ ou utiliser translateZ(0)
- les ombres CSS
- les flous CSS
- les dégradés CSS
Il existe des outils pour améliorer le framerate. En effet, dans chrome dans le developper tools, il existe dans « Timeline » un onglet « Frames » qui permet de voir en détails le différentes étapes de rendu de la page. Grâce à cet outil, on peut alors voir les éléments qui mettent beaucoup (trop ?) de temps à s’afficher.
Pour finir, il faut pas deviner si ça être optimisé ou pas, il faut juste le tester et le mesurer.
Bring the noise : Making effective use of a quarter million metrics par Jon Cowie (Etsy)
http://fr.slideshare.net/jonlives/bring-the-noise
Cette présentation va se focaliser sur la stack « monitoring » des applicatifs de Etsy.
Voici le contexte d’Etsy :
- 1.5 millards de pages vues
- 950 000 utilisateurs
- déploiement continu
- 250 contributeurs
- Plus de 30 déploiements par jour
Ils utilisent beaucoup d’outils pour le monitoring : Graphite, Ganglia, Nagios et des outils qu’ils ont modifiés ou créés : StatD, Supergrep,Skyline et Oculus.
C’est un daemon qui permet de faire des statisiques sur des compteurs ou des timers et permet de les envoyer vers différents agrégateurs de données pour avoir un dashboard plus friendly.
C’est un applicatif web qui permet de voir des logs très simplement.
Cette suite applicatives permet de détecter les comportements anormaux (pic de charges, etc) en temps réel ou presque. Grace à de beaux graphiques, on peut voir des anomalies assez facilement (représenté par des pics dans les graphs). On peut aussi mettre en place des scénarios comme le nombre de requêtes HTTP par secondes, le top 10 des pages, le temps de générations d’affichage, ou le temps d’exécution de requête sql.
Le mot de la fin de Jon :
If it moves, graph it ! If it doesn’t move, graph it anyway
Responsive images Technique and Beyond par Yoav Weiss (WL Square)
http://yoavweiss.github.io/velocity-eu-13-presentation/
Cette présentation se focalise sur les images responsives. Le principal enjeu est de charger l’image qui devra être correctement dimensionnée par rapport à la page.
72 % des sites en responsive design servent les mêmes ressources pour toutes les résolutions d’écrans et les images représentent 61% en moyenne dans le poids d’une page.
La plupart du temps, on peut optimiser 72% du poids des images en les compressant correctement. Un outils utilisant PhantomJS de Yoav permet de mesurer l’optimisation d’une image : Sizer Soze.
Il faut faire attention à servir une dimension différente de l’image en fonction des différents supports( une attention supplémentaire est requis pour les images rétina qui doivent être servis uniquement pour les devices rétina), parce que la bande passante est importante aussi bien pour le mobile que pour le desktop.
Ensuite, Yoav nous parle du « Art Direction » qui permet d’avoir une image pour le layout (assez utilisé pour les publicités), cela alourdit généralement assez rapidement un site.
Quelques solutions sont abordés :
- Le pré loader qui permet d’améliorer la performance de navigation (en moyenne 20%). Pour avoir plus d’informations sur ce sujet c’est ici.
- Se baser sur un cookie pour charger des images (Pas de double chargement d’image, les images s’affichent si le js plante, mais ça marche pas lors de la 1ère connexion, problème de cache, restriction sur le nom de domaine)
- LQIP pour Low Quality Image Placeholder (Chargement rapide des images, affichage des images si le JS plante, mais deux chargements d’image, beaucoup de ressources dans le markup et l’image final est affiché après)
Question à se poser avant de choisir un des solutions :
- Est ce que je peux modifer toute ma page ?
- Est ce que je peux modifier le markup ?
- ESt ce que je peux control le serveur qui permet de rendre les images ?
Il existe des solutions standardisées :
- l’attributs srcSet qui est proposé par Apple qui permet d’étendre la balise
pour de multiples ressources. Il est implémenté dans Webkit et Blink. Voici un exemple.
- l’élément est proposé par Bruce Lawson qui permet d’avoir des sources par élement picture. Voici un exemple.
- Src-N qui est proposé par Tab Atkins et John Mellor. Il se base sur la syntax DRP. Voici un exemple et un autre exemple.
- Response Image Container qui se base sur le fait d’avoir une image par résolution.
Be Mean to your code with Gauntlt and the Rugged Way par James Wickett (Mentor Graphics)
http://www.slideshare.net/wickett/gauntlt-velocity-eu2013
Cette présentation se focalise sur le framework Gauntlt qui est spécialisé dans la sécurité des applicatifs web. Ce framework permet de lancer des attaques sur l’applicatifs (XSS, Non sécurisation des pages utilisateurs, Injections SQL) et faire de la supervision (notamment sur les API Rest)
Il peut aussi s’intégrer à l’intégration continu.
Pour savoir comment on peut l’intégrer, c’est par ici.
Hands-on Web Performance Optimization Workshop par Andy Davies (Asteno) et Toias Baldauf (Freelance)
https://speakerdeck.com/tbaldauf/velocity-2013-hands-on-web-performance-workshop
Cette session est focalisé sur la perfomance Web et présente divers outils :
Ce site permet de tester la perfomance d’un site en fonction de différents critères comme la localisation, le navigateur, la connexion, etc
Cette stack web est un webkit scriptable via une API javascript. Il permet ainsi de reproduire un navigateur avec du javascript.
Cet outil est basé sur PhantomJS et permet d’avoir de collecter et d’avoir un suivi sur les perfomances web
C’est un outil openSource qui permet d’analyser la vitesse d’un site internet et la perfomance web et affiche les résultats pour analyse.
Ce site permet d’avoir des informations diverses sur l’ensemble du web.
Conclusion
Cette première journée s’est essentiellement focalisée sur les problèmatiques de déploiement avec la nécessité de mettre en place des tests et de les analyser avec des outils. La notion de monitoring est importante et permet d’anticiper ou de voir plus rapidement les problèmes. Enfin, le responsive design apporte de nouvelles problèmatiques notamment au niveau de la lourdeur des pages.
Gone in 60 frames per second par Addy Osmani (Google Chrome)
https://speakerdeck.com/addyosmani/velocityconf-rendering-performance-case-studies
Cette présentation s’est focalisée sur les bonnes pratiques pour obtenir le meilleur framerate possible et donc une meilleur fluidité lors de la navigation sur une page web. En effet, après la génération du code html par le serveur et la transmission du code via le réseau, le navigateur rend la page.
il faut toujours avoir en tête que les performances sur desktop ne sont pas les mêmes que sur mobile. Un framerate de 60 fps est le mieux, car c’est le taux de rafraîchissement en moyenne de tous les devices. Pour optimiser le rendu d’une zone, il faut qu’elle s’affiche en 16.7 ms.
Voici quelques bonnes pratiques :
- disposer des images à la bonne taille
- limiter les handlers sur l’évènement onScroll()
- limiter tous les éléments ‘fixed’ ou utiliser translateZ(0)
- les ombres CSS
- les flous CSS
- les dégradés CSS
Il existe des outils pour améliorer le framerate. En effet, dans chrome dans le developper tools, il existe dans « Timeline » un onglet « Frames » qui permet de voir en détails le différentes étapes de rendu de la page. Grâce à cet outil, on peut alors voir les éléments qui mettent beaucoup (trop ?) de temps à s’afficher.
Pour finir, il faut pas deviner si ça être optimisé ou pas, il faut juste le tester et le mesurer.
Bring the noise : Making effective use of a quarter million metrics par Jon Cowie (Etsy)
http://fr.slideshare.net/jonlives/bring-the-noise
Cette présentation va se focaliser sur la stack « monitoring » des applicatifs de Etsy.
Voici le contexte d’Etsy :
- 1.5 millards de pages vues
- 950 000 utilisateurs
- déploiement continu
- 250 contributeurs
- Plus de 30 déploiements par jour
Ils utilisent beaucoup d’outils pour le monitoring : Graphite, Ganglia, Nagios et des outils qu’ils ont modifiés ou créés : StatD, Supergrep,Skyline et Oculus.
C’est un daemon qui permet de faire des statisiques sur des compteurs ou des timers et permet de les envoyer vers différents agrégateurs de données pour avoir un dashboard plus friendly.
C’est un applicatif web qui permet de voir des logs très simplement.
Cette suite applicatives permet de détecter les comportements anormaux (pic de charges, etc) en temps réel ou presque. Grace à de beaux graphiques, on peut voir des anomalies assez facilement (représenté par des pics dans les graphs). On peut aussi mettre en place des scénarios comme le nombre de requêtes HTTP par secondes, le top 10 des pages, le temps de générations d’affichage, ou le temps d’exécution de requête sql.
Le mot de la fin de Jon :
If it moves, graph it ! If it doesn’t move, graph it anyway
Responsive images Technique and Beyond par Yoav Weiss (WL Square)
http://yoavweiss.github.io/velocity-eu-13-presentation/
Cette présentation se focalise sur les images responsives. Le principal enjeu est de charger l’image qui devra être correctement dimensionnée par rapport à la page.
72 % des sites en responsive design servent les mêmes ressources pour toutes les résolutions d’écrans et les images représentent 61% en moyenne dans le poids d’une page.
La plupart du temps, on peut optimiser 72% du poids des images en les compressant correctement. Un outils utilisant PhantomJS de Yoav permet de mesurer l’optimisation d’une image : Sizer Soze.
Il faut faire attention à servir une dimension différente de l’image en fonction des différents supports( une attention supplémentaire est requis pour les images rétina qui doivent être servis uniquement pour les devices rétina), parce que la bande passante est importante aussi bien pour le mobile que pour le desktop.
Ensuite, Yoav nous parle du « Art Direction » qui permet d’avoir une image pour le layout (assez utilisé pour les publicités), cela alourdit généralement assez rapidement un site.
Quelques solutions sont abordés :
- Le pré loader qui permet d’améliorer la performance de navigation (en moyenne 20%). Pour avoir plus d’informations sur ce sujet c’est ici.
- Se baser sur un cookie pour charger des images (Pas de double chargement d’image, les images s’affichent si le js plante, mais ça marche pas lors de la 1ère connexion, problème de cache, restriction sur le nom de domaine)
- LQIP pour Low Quality Image Placeholder (Chargement rapide des images, affichage des images si le JS plante, mais deux chargements d’image, beaucoup de ressources dans le markup et l’image final est affiché après)
Question à se poser avant de choisir un des solutions :
- Est ce que je peux modifer toute ma page ?
- Est ce que je peux modifier le markup ?
- ESt ce que je peux control le serveur qui permet de rendre les images ?
Il existe des solutions standardisées :
- l’attributs srcSet qui est proposé par Apple qui permet d’étendre la balise
pour de multiples ressources. Il est implémenté dans Webkit et Blink. Voici un exemple.
- l’élément est proposé par Bruce Lawson qui permet d’avoir des sources par élement picture. Voici un exemple.
- Src-N qui est proposé par Tab Atkins et John Mellor. Il se base sur la syntax DRP. Voici un exemple et un autre exemple.
- Response Image Container qui se base sur le fait d’avoir une image par résolution.
Be Mean to your code with Gauntlt and the Rugged Way par James Wickett (Mentor Graphics)
http://www.slideshare.net/wickett/gauntlt-velocity-eu2013
Cette présentation se focalise sur le framework Gauntlt qui est spécialisé dans la sécurité des applicatifs web. Ce framework permet de lancer des attaques sur l’applicatifs (XSS, Non sécurisation des pages utilisateurs, Injections SQL) et faire de la supervision (notamment sur les API Rest)
Il peut aussi s’intégrer à l’intégration continu.
Pour savoir comment on peut l’intégrer, c’est par ici.
Hands-on Web Performance Optimization Workshop par Andy Davies (Asteno) et Toias Baldauf (Freelance)
https://speakerdeck.com/tbaldauf/velocity-2013-hands-on-web-performance-workshop
Cette session est focalisé sur la perfomance Web et présente divers outils :
Ce site permet de tester la perfomance d’un site en fonction de différents critères comme la localisation, le navigateur, la connexion, etc
Cette stack web est un webkit scriptable via une API javascript. Il permet ainsi de reproduire un navigateur avec du javascript.
Cet outil est basé sur PhantomJS et permet d’avoir de collecter et d’avoir un suivi sur les perfomances web
C’est un outil openSource qui permet d’analyser la vitesse d’un site internet et la perfomance web et affiche les résultats pour analyse.
Ce site permet d’avoir des informations diverses sur l’ensemble du web.
Conclusion
Cette première journée s’est essentiellement focalisée sur les problèmatiques de déploiement avec la nécessité de mettre en place des tests et de les analyser avec des outils. La notion de monitoring est importante et permet d’anticiper ou de voir plus rapidement les problèmes. Enfin, le responsive design apporte de nouvelles problèmatiques notamment au niveau de la lourdeur des pages.
