La performance sur mobile

1 419 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
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 419
Sur SlideShare
0
Issues des intégrations
0
Intégrations
173
Actions
Partages
0
Téléchargements
14
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • L’angoisse de la page blanche
  • 50% des sites oublie, 30% mettent des temps très courts
    Les devs n’aiment pas ça
  • Penser à vérifier sur les vrais navigateurs / OS
  • Fait par google et les autres. Ne pas abuser (pas de cache, coût de décodage et mise en mémoire)
  • PNG 8 Alpha
    PNG : aplats de couleur. JPG : presque tout sauf aplats et texte
  • « problème retina »
  • SVG : gziper
    Généralement plus petits et de meilleure qualité
  • Android 2.3 : impossible, il faut deviner
  • Ex Youtube : passer de 3Mo à moins de 100Ko pour le premier rendu => ouverture aux pays émergents
  • 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

    ×