Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web UX - Performance Web

Web UX - Performance Web

https://talks.nicolas-hoizey.com/ett39R/web-ux-performance-web

L'utilisateur n'aime pas attendre. Sa perception de la vitesse d'un site Web a donc une influence sur son comportement. Cette perception peut être orientée positivement en travaillant intelligemment l'optimisation des performances côté client du site Web.

Le premier réflexe quand on parle de performances Web est de se tourner vers des tests de montée en charge et des optimisations côté serveur, alors que l'optimisation des performances côté client peut être plus simple, plus efficace, et plus rentable.

Nous aborderons dans cette conférence les différents aspects de l'optimisation côté client des performances Web, en attirant l'attention sur – par exemple – les téléchargements bloquants, les manières optimales d'inclure le code JavaScript et CSS, et leur impact sur les performances perçues par les internautes.

9aa2aa68144b2781ac025a29c83bbdd4?s=128

Nicolas Hoizey

September 30, 2011
Tweet

Transcript

  1. Performance  Web   Nicolas  Hoizey   Co-­‐fondateur  &  directeur  technique

     Clever  Age   @nhoizey  
  2. Le  visage  du  Web  change  

  3. Les  débits  augmentent*…   Fibre  opDque   100  Mbps  

    *  Pour  certains  privilégiés  
  4. …les  pages  grossissent  

  5. Mais  les  apparences   sont  trompeuses  

  6. Le  Web  ne  Dre  pas  profit  du  débit  

  7. La  mobilité  prend  de  l`ampleur   •  Bande  passante  faible,

     variable  et  instable   •  Faiblesses  intrinsèques  des  navigateurs   mobiles   – Faible  puissance  de  calcul  pour  le  rendu   – Faible  puissance  de  calcul  pour  le  JavaScript   – Taille  réduite  du  cache  
  8. L`u;lisateur  n`aime  pas   a<endre  

  9. Etude  Akamai  en  2009   47%  des  clients  e-­‐commerce  

    veulent  la  page  en  2s   4s  en  2006   8s  en  1999  
  10. Expérience  pour  CA  au   Glasgow  Caledonian  University   Site

     peu  performant     ConcentraDon  +50%   AgitaDon,  stress  
  11. Amazon.com   Page  +100  ms   CA  -­‐1%   En

     2006  
  12. Microso_  Bing   Page  +1s      CA  -­‐2,8%  

  13. Google  Search   Page  +0,4  s   Recherches  par  uDlisateur

     -­‐0,76%     Après  arrêt  de  l`expérience   Toujours  -­‐0,21%   Pas  de  retour  à  la  «  normale  »  !  
  14. None
  15. None
  16. Plus  que  la  performance  réelle,   c’est  sa  percep;on  qui

     compte  !  
  17. La  percepDon  de  la  vitesse   réelle   espérée  

    perçue   mémorisée   @stoyanstefanov   +15%   +35%  
  18. Avec  un  site  plus  rapide   •  Les  visiteurs  reviennent

      •  Ils  regardent  plus  de  pages  à  chaque  visite   •  AmélioraDon  de  la  sa;sfac;on  uDlisateur   •  Meilleur  taux  de  conversion   •  Plus  de  chiffre  d`affaires   •  Economies  d`infrastructure  (hardware  et  BP)   •  Meilleur  posi;onnement  chez  Google  
  19. La  cascade,  base  de  travail  

  20. FNAC.fr  

  21. FNAC.fr   Serveur  5%   Client  95%  

  22. FNAC.fr   hnp://cas.im/wpt-­‐fnac-­‐110202    

  23. DécomposiDon  d`une  requête   DNS   Connexion   TCP  

    Anente  de   la  réponse   Chargement   de  la  réponse  
  24. DécomposiDon  d`une  requête   •  Requête  DNS   •  Etablissement

     de  la  connexion   •  Envoi  de  la  requête  du  client  vers  le  serveur   •  Calcul  de  la  page  côté  serveur   –  Pour  ce  qui  est  dynamique   •  Envoi  de  la  réponse  du  serveur  vers  le  client   •  Calcul  du  rendu   –  HTML  +  CSS   •  Traitements  dynamiques   –  JavaScript,  expressions  CSS  
  25. FNAC.fr   Start   Render   ~  1,8s   Document

      Complete   ~  7,7s  
  26. hnp://cas.im/wpt-­‐amazon-­‐110202     Amazon.fr   Start   Render   ~

     1,75s   Document   Complete   ~  4,3s  
  27. FNAC.fr  vs  Amazon.fr  

  28. Le  «  Start  render  »  n`est  pas   un  indicateur

     suffisant  
  29. FNAC.fr  vs  Amazon.fr  

  30. FNAC.fr  vs  Amazon.fr  

  31. FNAC.fr  vs  Amazon.fr  

  32. FNAC.fr  vs  Amazon.fr  

  33. Above  the  Fold  Time   •  The  fold   – 

    Linéralement,  «  le  pli  »   –  La  «  ligne  de  flonaison  »  du  site   •  AFT   –  (tentaDve  de  déterminer)  quand   toute  la  parDe  visible  du  site  est   affichée   –  Un  délai  clé  foncDon  du  débit   –  Une  classificaDon  pixels   dynamiques  /  staDques   •  A  uDliser  avec  précauDon  
  34. W3C  :  Resource  Timing   •  InstrumentaDon  intégrée  aux  navigateurs

      –  Travaux  de  Microso_  et  Google   •  Working  Dra_  depuis  le  24  mai  2011  !   –  hnp://www.w3.org/TR/2011/WD-­‐resource-­‐Dming-­‐20110524/  
  35. Que  mesurer  ?   •  Chargement  sans  cache,  première  visite

      –  Important  pour  capter  de  nouveaux  visiteurs   •  Chargement  avec  cache  opDmal,  nouvelle  visite  sur  une   même  page   –  L’uDlisateur  s’anend  à  récupérer  la  page  instantanément   •  Chargement  avec  cache  parDel,  en  cours  de  navigaDon   –  96%  des  pages  vues  
  36. Quelques  ou;ls  

  37. Quelques  ouDls   •  Différents  types  d`ouDls   – VérificaDon  de

     la  cascade   – Audit  de  suivi  de  bonnes  praDques  et   recommandaDons   – OpDmisaDon   •  AnenDon,  ce  ne  sont  que  des  ouDls   – La  percep;on  humaine  et  le  bon  sens  doivent   rester  de  rigueur  
  38. webpagetest.org  

  39. webpagetest.org   •  La  référence   – WebPagetest  :  Projet  AOL

     mis  en  open  source   – De  IE6  à  IE9,  Chrome  en  cours   – Des  serveurs  partout  dans  le  monde     – Différentes  bandes  passantes   – Largement  paramétrable   – Résultats  détaillés  et  expliqués   – Enregistrement  vidéo   – ExpérimentaDon  AFT  
  40. Firefox  +  Firebug   Webkit  Developer  Tools   Chrome  +

     Speed  Tracer   IE9  Developer  Tools   Les  navigateurs  
  41. Yahoo!  YSlow   •  Extension  de  Firebug  développée   par

     Yahoo!   – hnp://developer.yahoo.com/yslow/   •  Analyse  la  page  et  détermine   l`usage  des  bonnes  praDques   – 23  critères   – Donne  un  «  grade  »  de  A  à  F   – Donne  des  recommandaDons   Voyages-­‐sncf.com  
  42. Google  Pagespeed   •  Différents  ouDls  développés  par  Google  

    – hnp://code.google.com/intl/fr/speed/page-­‐ speed/   •  Une  extension  pour  Firebug,  similaire  à  Yslow   – Analyse  la  page  et   donne  une  note   – Donne  des   recommandaDons  
  43. Google  Pagespeed  Online  

  44. Google  Webmaster  Tools  

  45. Et  les  autres…  

  46. OuDls  d’opDmisaDon   •  Les  architectes  et  développeurs  !  

    •  Beaucoup  d`arDsanat   – IdenDfier  les  faiblesses   – Prioriser  les  acDons   – Trouver  les  ouDls   – Industrialiser  
  47. Google  mod_pagespeed   •  Un  module  pour  Apache,  automaDsant  

    l`applicaDon  de  certaines  bonnes  praDques   – hnp://code.google.com/intl/fr/speed/page-­‐ speed/docs/module.html   – 15  filtres   – Seulement  9  acDfs  par  défaut   – Les  6  autres  à  uDliser  avec  prudence  
  48. Microso_  Doloto   •  Download  time  opDmizer   –  hnp://research.microso_.com/en-­‐us/projects/doloto/

      •  OuDl  dédié  aux  applicaDons  uDlisant  beaucoup   de  code  JavaScript  /  Ajax   •  Processus  opéraDonnel   –  Analyse  des  uDlisaDons  du  code   –  Découpage  des  foncDons  entre  code  nécessaire  au   lancement  et  code  uDlisé  ultérieurement   –  Chargement  dynamique  selon  les  besoins  
  49. Au  travail  !  

  50. Eviter  les  requêtes  inuDles   •  Eviter  les  redirecDons  

    •  Pas  d’erreur  404  dans  les  ressources  liées   •  Pas  de  ressources  liées  non  uDlisées  
  51. Réduire  la  latence   •  Réduire  la  latence  réseau  

      – Rapprocher  le  client  du  serveur   – CDN   •  Content  Delivery  Network   – PerDnent  en  cas  de  public  internaDonal  
  52. Réduire  le  nombre  de  requêtes  DNS   •  Limiter  le

     nombre  de  domaines  uDlisés   – Chaque  domaine  implique  une  requête  DNS  
  53. Réduire  le  nombre  de  requêtes   •  Exploiter  le  cache

     du  navigateur   – Configurer  le  serveur  pour  indiquer  la  date  de   pérempDon  des  ressources   – Le  navigateur  ne  demandera  la  ressource  que  si   elle  a  expiré  
  54. Réduire  le  nombre  de  requêtes   •  Concaténer  les  codes

     JavaScript  et  CSS   6  JS  -­‐>  1  JS  
  55. Réduire  le  nombre  de  requêtes   •  Combiner  les  images

     sous  forme  de  sprites     •  AnenDon  à  l’accessibilité  
  56. Réduire  le  nombre  de  requêtes   •  Passez  tout  de

     suite  au  slide  suivant…   •  Intégrer  du  JS  ou  CSS  au  HTML   – Uniquement  si  gain  de  performance  conséquent   •  A  réserver  aux  «  landing  pages  »   – Fait  perdre  la  mise  en  cache  des  JS  ou  CSS   externes   •  Intégrer  des  images  au  CSS,  JS  ou  HTML   – UDlisaDon  des  data:uri   – Encodage  en  base64  
  57. Réduire  le  poids  des  requêtes   •  Compresser  tout  

    – Gzip   – Gain  de  50  à  80%  !   •  Minifier  les  sources  HTML,  JavaScript  et  CSS   – Suppression  des  caractères  inuDles,  blancs,   commentaires,  opDmisaDon  de  la  syntaxe  
  58. Réduire  le  poids  des  requêtes   •  Réduire  le  poids

     des  images   – Suppression  des  métadonnées  inuDles  (EXIF,  IPTC)   – Choix  des  bons  formats   •  GIF   •  JPEG  :  quelle  compression  ?   •  PNG  :  quel  format  ?  8,  24,  32   – Jusqu`à  90%  de  gain  !  
  59. Réduire  le  poids  des  requêtes   •  Eviter  les  cookies

     inuDles   – Les  cookies  alourdissent  les  requêtes  vers  le   serveur   •  Si  possible,  servir  les  ressources  staDques   depuis  un  domaine  sans  aucun  cookie  
  60. RéparDr  sur  plusieurs  domaines   •  Les  navigateurs  ont  une

     limite  de   téléchargements  simultanés  PAR  DOMAINE   – 2  requêtes  selon  HTTP/1.1   – 6  à  8  en  praDque  dans  tous  les  navigateurs  en   dernières  versions   – AnenDon,  2  dans  IE6  &  IE7   •  Mise  en  place  de  plusieurs  domaines   – «  Domain  sharding  »  
  61. RéparDr  sur  plusieurs  domaines   •  Téléchargements  en  parallèle  

    •  Si  trop  de  domaines   – Trop  de  requêtes  DNS   •  Consensus  pour  2  à  4  domaines  selon  usages  
  62. OpDmiser  le  rendu  du  navigateur   •  Ordonnancer  le  chargement

     des  ressources   – HTML  et  CSS  au  plus  vite   •  OpDmisaDon  du  «  start  render  »   •  Eviter  le  «  reflow  »  avec  des  CSS  tardives   •  Flush  de  HTML  parDel   – JavaScript  le  plus  tard  possible   •  Le  JS  bloque  le  chargement  pendant  son  exécuDon   – Différer  le  chargement  des  ressources  qui  ne  sont   pas  uDles  au  départ   •  «  lazy  loading  »  
  63. OpDmiser  le  rendu  du  navigateur   •  Nenoyer  les  CSS

     et  JS  du  code  inuDle   •  Tenir  compte  des  performances   – des  CSS   – de  JavaScript   – des  frameworks  JavaScript  
  64. AnenDon  aux  ressources  externes   •  Ressources  provenant  de  Ders

      – OuDls  de  staDsDques   – Régies  publicitaires   – Widgets  de  partenaires   •  hnp://stevesouders.com/p3pc/  
  65. Il  faut  pra;quer  pour   progresser  !  

  66. Profiter  du  webperf  contest   •  WebPerf  Contest  2010  

    – Concours  internaDonal   •  hnp://webperf-­‐contest.com/   •  Novembre  2010   – ObjecDf   •  OpDmisaDon  d`une  page  Web   •  Fournie  par  la  FNAC   •  hnp://entries.webperf-­‐contest.com/   base-­‐fnac-­‐_w/index.html  
  67. Profiter  du  webperf  contest   •  Bilans  très  instrucDfs  

    – hnp://braincracking.org/2011/01/10/concours-­‐ webperf-­‐2010-­‐les-­‐bases/   – hnp://www.yterium.net/Ma-­‐parDcipaDon-­‐au-­‐ Webperf  
  68. Avant   Start  Render        :  2.441  s

      Document  Complete    :  11.028  s   Fully  Loaded        :  17.261  s   Après   Start  Render        :  1.639  s   Document  Complete    :  1.214  s   Fully  Loaded        :  6.083  s    
  69. Une  veille  permanente   •  Dans  la  vraie  vie  

    – Evénements  du  Web  Perf  User  Group   hnp://cas.im/webperf-­‐user-­‐group   •  Sur  Diigo   – Groupe  Web  Performance   hnp://groups.diigo.com/group/web-­‐performance   •  Sur  Twiner   – Suivre  le  compte  @webperf_fr  
  70. A  vous  de  jouer  !   Illustrations : hnp://iwdrm.tumblr.com/  &

     hnp://fromme-­‐toyou.tumblr.com/  
  71. Clever Age! c Fondée en 2001 par des managers expérimentés,

    Clever Age est aujourd'hui un acteur incontournable dans le domaine du conseil et de la réalisation de projets. L'idée directrice qui a conduit à cette création et qui prévaut aujourd'hui encore est l'indépendance, aussi bien vis-à-vis des éditeurs que des investisseurs.
  72. Chiffres clefs G3+! Banque de France 90 collaborateurs! sur 4

    agences Croissance régulière! et rentable
  73. Rezulteo http://www.rezulteo-pneu.fr/ ! MACSF http://www.macsf.fr LVMH – DIOR PCD http://beauty.dior.com/

    M6 Groupe http://www.groupem6.fr/! http://www.m6mobile.fr/ Fnac Market Place! http://goo.gl/vzZA Nouvelles Frontières http://www.nouvelles-frontieres.fr/ Références internet et e-Commerce
  74. Vet Affaires http://www.vetaffaires.fr/ ! Aéroport de Bordeaux http://www.bordeaux.aeroport.fr/ Atelier BNP

    Paribas http://www.atelier.net/ Saint Gobain! http://www.saint-gobain.com/ Mondial Assistance US! http://www.mondial-assistance.us Siplec – Groupe E. Leclerc http://www.siplec.com/ Références internet et e-Commerce
  75. Applications mobiles

  76. Choix d'une solution Portail / CMS pour l'ensemble des projets

    internet / extranet / intranet du groupe Conseil fonctionnel et technique pour la réalisation! d'une application de gestion des sinistres (assurances) puis réalisation de l'application (JEE / EJB / Symfony) Mission Accompagnement POC et Processus e-Commerce dans le cadre du chantier de refonte du site internet APEC Accompagnement dans la définition et la mise en oeuvre d'une architecture SOA dans le cadre de la refonte globale (Back- office et end-user) Choix d'une architecture Portail / CMS / eCommerce pour le groupe et ses filiales Conseil en architecture technique