• Home
  • Nous contacter

Le blog d'Adfab

Le blog d'Adfab

Le blog d'Adfab

Le blog d'Adfab
Outils

Compte rendu du Velocity Europe 2013 – Jour 1

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.

StatsD

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.

SuperGrep 

C’est un applicatif web qui permet de voir des logs très simplement.

Skyline & Oculus

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 :

  • WebPagetest

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

  • PhantomJS

Cette stack web est un webkit scriptable via une API javascript. Il permet ainsi de reproduire un navigateur avec du javascript.

  • Phantomas

Cet outil est basé sur PhantomJS et permet d’avoir de collecter et d’avoir un suivi sur les perfomances web

  • SiteSpeed.io

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.

  • HttpArchive

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.

StatsD

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.

SuperGrep 

C’est un applicatif web qui permet de voir des logs très simplement.

Skyline & Oculus

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 :

  • WebPagetest

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

  • PhantomJS

Cette stack web est un webkit scriptable via une API javascript. Il permet ainsi de reproduire un navigateur avec du javascript.

  • Phantomas

Cet outil est basé sur PhantomJS et permet d’avoir de collecter et d’avoir un suivi sur les perfomances web

  • SiteSpeed.io

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.

  • HttpArchive

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.

21/03/2014 96 MIN READ BY: Thomas ROGER 0 COMMENT
SHARE
LIRE LA SUITE

Thomas ROGER

Introduction a nodeJS – part 2

Les erreurs de débutant en programmation

VOUS POURRIEZ AIMER

Outils Compte rendu du Velocity Europe 2013 – Jour 3

Outils GitKraken – libérez vous du terminal

Backend Développement Outils Strapi v3, une mise à jour majeure

Outils 5 trucs GIT que j’utilise tous les jours

Outils Créer un package pour Composer avec Github et Packagist – Partie 1

e-Commerce Outils Magento plugin for NetBeans IDE (part. 1)

A propos d’Adfab

Nous sommes un studio de production digitales et d’innovation digitales au service des agences et des annonceurs
Nous recherchons le scintillement dans les regards et le plaisir de réalisations sur-performantes
Nous sommes techno-agnostiques
Nous sommes Adfab

Le blog d'Adfab
Copyright © 2018 Adfab Connect