Performances Web - Vers 1000ms et au-delà

Transcript

1. © Pixar Disney / Pixar

2. Quelques chiffres Evolution du poids des pages ! 56% plus

   lourd qu’en 2011 ! Les images prennent une proportion importante ! Taille moyenne d’une page : 1093 kB (Top 1000 sites) webperformancetoday.com, dareboost.com

3. Quelques chiffres Evolution du nombre de scripts loadés ! En

   moyenne 96 KB en 2011, 175KB en 2014 ! En moyenne 24% du poids de la page ! 56% des pages comptent +de 20 tags <script> (juillet 2014) (Top 1000 sites) webperformancetoday.com, dareboost.com

4. Quelques chiffres Evolution du nombre de custom fonts ! En

   hausse de 625% ! Utilisées dans 4% des sites en 2011, 29% en 2014 Top 1000 sites, webperformancetoday.com

5. Quelques chiffres Source kissmetrics.com Chaque seconde compte ! Les 1ers

   abandons de page ont lieu dès la 1re seconde d’attente

6. Quelques chiffres Les utilisateurs veulent toujours plus de vitesse !

   Temps tolérable passé de ~10 sec en 1997 à ~1sec en 2014 ! ! Secondes 0 3 5 8 10 1997 1999 2004 2014 Tolerable Waiting Time Source http:/ /cba.unl.edu

7. Impact de la performance 365 days of clone | David

   Eger Impacts de la performance

8. Impacts économiques • 1 seconde de délai supplémentaire de réponse

   peut engendrer une baisse des conversions de 7% ! • Amazon : réponse en +100ms = CA -1% (2011) ! • Bing : réponse en +1sec = CA - 2.8% (2011) ! • Google : délai suppl. de 0.5sec = traffic -20 % (2006) ! • Shopzilla : réponse 6sec -> 1.2 sec = CA + 5-12% (2009) ! ! ! Source kissmetrics.com, mcrinc.com, glinden.blogspot.fr

9. Impacts économiques Source kissmetrics.com

10. flickr.com/photos/st3f4n Mesurer

11. http:/ /www.webpagetest.org • ~40 serveurs de test répartis dans le

    monde • Nombreux browsers, dont mobiles • Capture vidéo • Désactivation Javascript • Comparaison avec les principaux sites • Recommandations PageSpeed

12. http:/ /www.gtmetrix.com • 7 serveurs de tests • Firefox /

    Chrome / Chrome android • Capture vidéo • Option Adblock • Monitoring de sites • Recommandations PageSpeed et YSlow

13. http:/ /www.dareboost.com • Options limitées en compte gratuit • Firefox

    / Chrome / Chrome android • Validation W3C • Recommandations accessibilité et SEO • Dispose d’un blog dédié à la performance web

14. Speed Index WTF ??

15. Speed Index https:/ /sites.google.com/a/webpagetest.org/docs/ using-webpagetest/metrics/speed-index • Temps moyen au bout

    duquel les parties visibles de la page sont affichées • Indicateur UX • Compris entre ~500 et ~10000 • Doit être combiné avec d’autres indicateurs

16. Speed Index Source httparchive.org

17. Time To First Byte • Souvent appelé "back-end time" •

    Temps au bout duquel l’utilisateur récupère le 1er byte de data • Un TTFB important peut indiquer des problèmes backend : • Serveur • Base de données • Content delivery • … • TTFB important = Bad UX

18. Time To First Byte BLOCAGE

19. flickr.com/photos/kalexanderson Diagnostiquer

20. Waterfall patterns Lenteurs Back-End

21. Waterfall patterns Poids important des ressources à télécharger Source Pat

    Meenan

22. Waterfall patterns Ressource lente, bloquante Source Pat Meenan

23. Comprendre les indicateurs • Time : temps nécessaire pour complèter

    l’opération (rappel : TWT moyen 1 sec (2014) • Requests : nombre de requêtes HTTP effectuées • Bytes in : poids des ressources nécessaire au load de la page (rappel : poids moyen 1093 KB)

24. Comprendre les indicateurs • Load Time : temps passé entre

    le lancement de la page et le « Document Complete » • Start render : moment auquel quelque chose apparait à l’écran

25. Analyser les assets

26. S’aider des outils d’analyse PageSpeed Insights

27. Agir TCP : au coeur du Web callprosupport.com

28. New-York <-> Londres High Performance Browser Networking, O’Reilly « Three-way

    handshake »

29. Gestion de la congestion : TCP slow start High Performance

    Browser Networking, O’Reilly New-York <-> Londres Roundtrip Time : 56ms

30. Bande passante vs. Temps de latence High Performance Browser Networking,

    O’Reilly

31. Agir

32. Objectif : 1000 ms High Performance Browser Networking, O’Reilly «

    Pour qu’une réponse paraisse instantanée, elle doit intervenir dans un délai de quelques centièmes de secondes. Au-delà d’une seconde, l’engagement de l’utilisateur pour la tâche initiale diminue. »

33. Agir sur le temps de latence Réduire le nombre de

    requêtes Piste 1 : Mise en cache avec .htaccess Utilisation de mod_expires Durée conseillée : 1 mois > x < 1 an • Moins de requêtes HTTP • Contenu total à télécharger diminué • Cache mobile limité (Android 2.x < 6Mo; iOS ~50Mo)

34. Agir sur le temps de latence Réduire le nombre de

    requêtes Piste 2 : Mise en cache avec localStorage ! • Cache conservé à la fermeture du browser • Facile à mettre en place en Javascript • Compatibilité anciens navigateurs • « String » uniquement (images => base64)

35. Agir sur le temps de latence Réduire le nombre de

    requêtes Piste 3 : Concaténer ses sources ! • Moins de requêtes, donc moins de RTT • Difficile à automatiser sans task runner

36. Agir sur le temps de latence Réduire le nombre de

    requêtes Piste 3 : utiliser des sprites ! • Permet de récupérer les images en 1 seul fichier. Moins de requêtes, donc moins de RTT • Gestion via les classes CSS • Regrouper les images utilisant la même palette de couleur. Dans le cas contraire, taille ++ • Peut être combiné à de l’encodage base64

37. Agir sur le temps de latence Localisation des données High

    Performance Browser Networking, O’Reilly Servir les données situées + près de l’utilisateur peut réduire considérablement le temps de latence. Les techniques de routing par CDN peuvent améliorer la performance

38. Agir sur le temps de latence La Toolbox • https:/

    /github.com/h5bp/html5-boilerplate/blob/ master/.htaccess • http:/ /caniuse.com/#feat=namevalue-storage • http:/ /blog.carbonfive.com/2014/05/05/roll-your-own-asset- pipeline-with-gulp/ • https:/ /github.com/addyosmani/basket.js • spriteme.org / wearekiss.com/spritepad • http:/ /www.base64-image.de/

39. Agir sur le poids des pages Compression GZIP • Permet

    d’économiser jusqu’à 70% du poids de la ressource • Mise en place avec mod_deflate (.htaccess) • Ne fonctionne que sur des ressources de type texte (HTML, JS, CSS) http:/ /www.whatsmyip.org/http-compression-test/

40. Agir sur le poids des pages Minifier ses sources «

    Le code source est écrit pour les humains, pas pour les machines » @drublic • Les espaces, indentations, sauts de ligne, commentaires, ne sont pas utiles à la machine. • Facilement automatisable (Gulp, Grunt, etc.)

41. Agir sur le poids des pages Optimiser les images Piste

    1 : Choisir le bon format ! Fichiers photos : jpg. Format destructeur. L’image compressée est modifiée. Aplats de couleurs : png. Format non destructeur. Plusieurs formats d’encodage existant ! Piste 2 : Rapport qualité / poids ! Il n’est jamais nécessaire d’enregistrer à 100% de qualité.

42. Agir sur le poids des pages Optimiser les images Photo,

    411x533 px Qualité 100, 77,52K JPG Qualité 60, 33,16K JPG Qualité 0, 6,8K JPG 4 couleurs 7,95K PNG 8bits Poids en PNG 24 bits : 210,8K

43. Agir sur le poids des pages Optimiser les images Aplat,

    216x188 px Qualité 100, 19,42K JPG Qualité 0, 2,5K JPG 32 couleurs, 7,5K PNG 8bits 24-bits, 31,17K PNG 24bits Le format PNG supporte mal les dégradés de couleurs !

44. Agir sur le poids des pages Optimiser les images Malgré

    la compression, certaines informations restent stockées dans le fichier image (méta- données, copyright, informations de calques…) ! Ces informations peuvent être supprimées sans risque (cf Toolbox) pour réduire encore le poids.

45. La Toolbox • http:/ /www.smashingmagazine.com/2009/07/01/ clever-jpeg-optimization-techniques/ • http:/ /www.smashingmagazine.com/2009/07/15/ clever-png-optimization-techniques/

    • smallerapp.com (Mac OS) • imageoptim.com (Mac OS) / pnggauntlet.com (Windows) • smushit.com/ysmush.it / kraken.io • https:/ /github.com/sylzys/my-gulp-starter Agir sur le poids des pages

46. Agir sur le contenu Sources bloquantes Sauf exception, les fichiers

    Javascript doivent être appelés en bas de <body> 1 <head>! 2 ! <script type="text/javascript" src="js/blocking.js"></script>! 3 ! <link rel="stylesheet" href="dist/css/final.css">! 4 </head>!

47. Agir sur le contenu Chargement des sources Ici, on agit

    sur le sentiment de vitesse ressenti par l’utilisateur. ! Les attributs HTML5 « async » et « defer » permettent de retarder le chargement d’un fichier Javascript Objectif : charger et interpréter le JS sans bloquer le rendu HTML/CSS ! https:/ /developer.mozilla.org/fr/docs/Web/HTML/Element/script http:/ /caniuse.com/#search=defer http:/ /caniuse.com/#search=async

48. Agir sur le contenu Chargement des sources defer ! Indique

    au navigateur de télécharger les scripts en parallèle, après l’analyse du document, en RESPECTANT l’ordre d’appel ! N’est pas effectif sur les <script> sans attribut ‘src’

49. Agir sur le contenu Chargement des sources async ! Indique

    au navigateur de télécharger les scripts en parallèle, après l’analyse du document, SANS NECESSAIREMENT RESPECTER l’ordre d’appel ! N’est pas effectif sur les <script> sans attribut ‘src’

50. Domain sharding ! Objectif : répartir les fichiers statiques (images,

    CSS, JS) sur plusieurs sous-domaines. • Nombre de requêtes simultanées multiplié • Résolution DNS à chaque sous-domaine (~200ms) • Peu efficace sur mobile • Obsolète avec HTTP2 / SPDY ? Agir sur le contenu Chargement des sources

51. Agir sur le contenu Lazy Loading et Cie • Agit

    à la fois sur les performances et la perception de vitesse. • Ne charger en priorité que ce qui est « above the fold » • Etudier le CSS Critical Path https:/ /speakerdeck.com/patrickhamann/css-and-the- critical-path http:/ /googlecode.blogspot.de/2009/09/gmail-for- mobile-html5-series-reducing.html

52. Agir sur le contenu Limiter les repaints / reflows •

    Repaint : intervient en cas de changement de l’apparence d’un élément, sans changer son layout. • Ex: background-color, color, box-shadow, outline… • Reflow : intervient en cas de changement de le layout d’un élément, et donc de la page. + coûteux que le repaint. • Ex: width, margin, border, positioning…

53. Agir sur le contenu Limiter les repaints / reflows Mozilla

    / Paul Rouget

54. Agir sur le contenu Limiter les repaints / reflows •

    Limiter la taille du DOM et le nombre de sélecteurs CSS le plus possible • Ne pas utiliser Javascript pour gérer le style 1 var el = document.getElementById('caenjs');! 2 el.style.color = "#eee";! 3 el.style.backgroundColor = "#000";! 4 el.style.borderColor = "red";! 1 var el = document.getElementById('caenjs');! 2 el.className = "caenjs";! 3 reflows 1 reflow

55. Agir sur le contenu Limiter les repaints / reflows Mozilla

    / Paul Rouget

56. Agir sur le contenu Limiter les repaints / reflows •

    Opérations rapides, gérées par le GPU ! • scale -> transform: scale(x) • move -> transform: translateX(y px) • rotate -> transform: rotate(z deg) • fade -> opacity (0…1) ! Les autres opérations nécessitent de recalculer le layout, et souvent du repaint => plus lent

57. Agir sur le contenu Limiter les repaints / reflows •

    Chrome Canary : « Show paint rectangles », « show layer borders », Continuous Painting Mode, about:tracing, etc. • https:/ /github.com/janjongboom/css-reflow- tracer ! ! https:/ /www.youtube.com/watch?v=enKJMUArlV4

58. Agir sur le back-end • Les « bouchons » liés

    aux dysfonctionnement en back-end entraînent une augmentation exponentielle du temps de réponse

59. Agir sur le back-end • RAM / Swap insuffisante •

    Débit insuffisant • Configuration du nombre max de connections BDD insuffisant • BDD mal configurée (indexes…) • Configuration du nombre max de connections au serveur Web insuffisant • Process MySQL gourmand / en boucle • File-locking mal configuré • …

60. Agir Bonus

61. Limiter les frameworks Bonus jquery-1.11.1.min.js => 96Ko ! jQuery est

    inutile s’il ne sert qu’à la selection DOM ! github.com/ded/qwery => 1.281Ko minifié github.com/chjj/zest => 11Ko minifié ! ! Privilégier Vanilla JS autant que possible ! PS : http:/ /microjs.com/

62. Touch vs. Clic Bonus Malgré les annonces des dernières implémentations,

    il existe toujours un délai de 300ms au clic sur la plupart des navigateurs mobiles. ! • github.com/ftlabs/fastclick • github.com/EightMedia/hammer.js • github.com/filamentgroup/tappy • developers.google.com/mobile/articles/ fast_buttons

63. <link> vs. @import Bonus Utilisé sur une ressource externe, @import

    ne permet pas le téléchargement en parallèle de l’asset. Cela peut donc bloquer d’autres ressources ! • https:/ /developers.google.com/speed/docs/ best-practices/rtt#AvoidCssImport • http:/ /www.stevesouders.com/blog/ 2009/04/09/dont-use-import/

64. Réseaux sociaux Bonus « Charger les boutons sociaux Google+, Twitter

    et Facebook totalise 19 requêtes serveur, et prend 246,7ko en bande passante » Zurb ! • http:/ /zurb.com/article/883/small-painful-buttons-why- social-media-bu • http:/ /www.heise.de/extras/socialshareprivacy/ (DE) • http:/ /www.webperformancetoday.com/2014/06/09/can- third-party-scripts-take-entire-site-slides/

65. Javascript / jQuery Bonus document.write(), arrays, selectors, for/each… ! Plus

    d’infos lors de CaenJS V2, le 13/09/2014 !

66. SPDY Bonus SPDY (« SpedDY ») : ! • Développé

    depuis 2009, par Google. Vise une réduction de 50% du temps de load • Met en place le multiplexing • Sécurisé par défaut • Devrait servir de base pour HTTP2 ! Google a testé 25 des « top 100 » sites => Amélioration 39%-55% http:/ /chimera.labs.oreilly.com/books/ 1230000000545/ch12.html

67. La Toolbox • http:/ /updates.html5rocks.com/2014/06/Automating- Web-Performance-Measurement • http:/ /httparchive.org/trends.php •

    http:/ /chimera.labs.oreilly.com/books/1230000000545 • http:/ /24ways.org/2010/speed-up-your-site-with- delayed-content/ • http:/ /www.webperformancetoday.com/ • http:/ /www.upgradetheweb.com Bonus

68. Merci ! Des questions ? sylzys