La performance sur mobile

1 607 vues

Publié le

Les utilisateurs sont encore moins patients sur mobile que sur navigateur de bureau, malgré leur débit à priori faible et la faible puissance de leur machine. Quelles techniques et quelles méthodologies pour limiter la casse ? Le RWD est il un fléau ou une opportunité ? La 4G sauvera-t-elle le monde ?

Dans ce talk mêlant business, ergonomie de base, méthodologie et techniques, nous répondrons au moins partiellement à ces questions.

Publié dans : Technologie
  • Soyez le premier à commenter

La performance sur mobile

  1. 1. Web mobile et Performances Jean-Pierre Vincent – BrainCracking @theystolemynick
  2. 2. Jean-pierre VINCENT - BrainCracking • Expertise technique – Applications Web (HTML5 / JS) – Performances ! • Formation – JavaScript – Performances • Veille : – @theystolemynick – braincracking.org
  3. 3. À une seconde près ? Temps de réaction Perception 0 – 100 ms Instantané (wow) 100 – 300 ms Ça rame 300 – 1000 ms La machine travaille 1 s+ Changement de contexte mental 10 s+ Je reviendrais (ou pas)
  4. 4. À une demie seconde près ! Tests utilisateurs : perception de la marque tesco.com Site témoin • Facile à utiliser • Simple • Lent • Chargé • Mobile friendly • Rapide Latence de 500 ms • Lent • Basique • Navigation difficile • Ennuyant • Compliqué • frustrant
  5. 5. Combien coûte le temps ? • Etsy : – 1 image de 160K = + 12% de taux de rebond • DoubleClick – 1 redirection en moins = +12% de taux de clic • RadWare – 60% d’abandon après 4 secondes de chargement • Wallmart – -50% de conversion par seconde • Akamai – -6% de vidéo vue par seconde • Google – Critère de Référencement
  6. 6. Où est le problème ? • Réseau mobile français (Akamai) : – 6 Mb/s en moyenne – 34 Mb/s en pointe • La 4G française (degrouptest) : – 21-32 Mb/s • 75% d’utilisation via le wifi (Étude Google)
  7. 7. Les contraintes externes • Latence 4G : 50-100 ms • Vraies situations de mobilité : need for speed • Utilisateur : un site avec moins de contenu doit se charger plus vite non ? • Saturation et variabilité des réseaux
  8. 8. Les contraintes des sites mobiles • Le poids des sites – +56% sur les dédiés mobile ! – 750 Ko en moyenne • Les fonctionnalités – Fonts, grosses images – Trackers, AB testing, pub • Le mauvais RWD – Retina© + IE6 + 5 breakpoints – Mettez tout sur la HP
  9. 9. Forcément …
  10. 10. LE CHEMIN CRITIQUE
  11. 11. Le chemin critique
  12. 12. Les grands classiques • Grouper CSS / JS • Minifier • Compresser (lvl 9)
  13. 13. Les polices • Non critiques (icônes, variantes) : – Inclusion standard • Critiques (titres, corps) – Police de fallback, inclusion asynchrone – Négocier la suppression …
  14. 14. L’enfer c’est les autres • Boutons sociaux • Scripts (jQuery, bootstrap, boilerplate …) • Polices • Solutions : – Options asynchrones – Rapatriement – Pubs en iframe
  15. 15. LES 3 CACHES
  16. 16. « Il n’y a pas plus rapide qu’une requête qu’on ne fait pas »
  17. 17. Manage cache (or die trying) La seule bonne méthode : • Définir des temps de cache longs (1 mois - 1 an) • Invalidation par changement de l’URL d’appel
  18. 18. Cache manuel Les caches sur mobile ne sont pas fiables • Utiliser localStorage (voir google HP) – Stockage de plusieurs Mo – HTML, CSS, JS, images, données JSON
  19. 19. Le cache ultime http://bit.ly/demo-offline • HTML5 Application Cache • Apparition instantanée de l’interface • Équivalent de l’installation d’une d’application native • Gère la déconnexion !
  20. 20. LES IMAGES
  21. 21. « ça va plus vite sans images »
  22. 22. Remplacer les images • CSS3 : – Dégradés – Arrondis – rotations, – Opacités • Caractères unicodes : – ►★✓⇢ – ✎♥☎ – ♻⚠ – ☻☺⇨
  23. 23. Chargement juste à temps • Ne charge que les images visibles • Libére la connexion pour les ressources critiques • Ex: lequipe.fr – 30 images et 300Ko économisés • Librairie bullet-proof
  24. 24. Images embarquées • Technique de data:uri + encodage base 64 • Images critiques encodées dans le HTML
  25. 25. Les formats d’image Optimiser les formats actuels • Gif < PNG < JPG • Des dizaines d’outils de compression auto • Nettoyage des EXIF • JPG progressif : NON Distribuer les remplaçants de JPG • WebP (Android Chrome) • JPG XR (Windows phone) • JPG 2000 (iOS Safari)
  26. 26. IMAGES ADAPTATIVES
  27. 27. Définir le problème • Taille d’images adaptée à la taille de viewport ? • Support des écrans haute résolution ? • Variation des formats d’image ? • Art direction ?
  28. 28. Une réponse compliquée à un problème compliqué • Format officiel final : <picture> • Librairie d’émulation officielle : picturefill 2.0
  29. 29. La technique improbable « grand JPG qualité nulle » http://bit.ly/jpg-0 (sur un écran à haute densité)
  30. 30. Les formats vectoriels • Polices icôniques • SVG
  31. 31. Technique « fait main » • Images d’interface critiques encodées en base64 • Images de contenu critiques visibles en basse définition (<img src>) • Images de contenu critiques en haute définition (JS) • Images contenu secondaire en lazy-loading • Image d’interface secondaires en font / SVG / sprites
  32. 32. LES TECHNIQUES DISCUTABLES
  33. 33. SPDY / HTTP 2 Réduit les dégâts d’un grand nombre de requêtes Support • Chrome (forcément), Firefox, iOS 8 Limites • HTTPS only • Laisse ramer IE 8, iOS < 7, navigateur Android
  34. 34. Domain sharding Il faut arrêter maintenant hein • Résolution DNS couteuses • Saturation immédiate de la bande passante
  35. 35. JavaScript en bas de page • Ça ne sert à rien pour le site lambda – Ralentit l’affichage sur Safari iOS – Ralentit l’exécution partout
  36. 36. INTERFACES FLUIDES
  37. 37. Grandeur et décadence • Animations – Directement en CSS3 (généré si besoin) – Utiliser translate – Tenter requestAnimationFrame • Scroll de longues pages – Technique du recyclage d’objets • Décoration – Éviter CSS3 … (ombrages) • Calcul – Web Workers – L’increvable setTimeout( 0 )
  38. 38. Fluidité • Une seule règle : tester et profiler • Avoir de vrais téléphones • Utiliser les déboguages via USB : – Chrome Android – Safari iOS – Windows – Firefox OS
  39. 39. MÉTHODOLOGIE
  40. 40. Impliquer • Le mythe du développeur héro solitaire • La vitesse doit être prévue dans les specs – Google : « Speed is the #1 feature » • Exemple : – Pour 80% des utilisateurs – Premier rendu en moins de 2 secondes – Fonctionnalité principale en moins de 5 secondes – Navigations internes en moins de 2 secondes
  41. 41. Mesurer, avant action • La base : WebPageTest • Mesures utilisateurs – Google, de base – À enrichir avec des mesures liées au métier
  42. 42. Surveiller dans le temps • Compléments payants ou gratuits à WPT • Analytics – Google, de base – À enrichir avec des mesures liées au métier
  43. 43. Parce qu’il en faut une CONCLUSION
  44. 44. RWD ? Non : mobile first • Suivre les utilisateurs : – Déjà en multi-écrans – Commencent souvent par une navigation mobile – Parfois moyen unique d’accès au net • Bonus : accélération pour tout le monde – IE 8 – marchés lointains – smartphones bas de gamme
  45. 45. Questions ? Jean-pierre Vincent – BrainCracking @theystolemynick Slides : http://bit.ly/perf-mobile

×