la performance sur mobile
DESCRIPTION
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.TRANSCRIPT
Web mobile et Performances
Jean-Pierre Vincent – BrainCracking @theystolemynick
Jean-pierre VINCENT - BrainCracking
• Expertise technique – Applications Web (HTML5 / JS) – Performances !
• Formation – JavaScript – Performances
• Veille : – @theystolemynick – braincracking.org
À 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)
À une demie seconde près !
Site témoin
• Facile à utiliser • Simple • Lent • Chargé • Mobile friendly • Rapide
Latence de 500 ms
• Lent • Basique • Navigation difficile • Ennuyant • Compliqué • frustrant
Tests utilisateurs : perception de la marque tesco.com
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
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)
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
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
Forcément …
LE CHEMIN CRITIQUE
Le chemin critique
Les grands classiques
• Grouper CSS / JS
• Minifier
• Compresser (lvl 9)
Les polices
• Non critiques (icônes, variantes) : – Inclusion standard
• Critiques (titres, corps) – Police de fallback, inclusion asynchrone – Négocier la suppression …
L’enfer c’est les autres
• Boutons sociaux
• Scripts (jQuery, bootstrap, boilerplate …)
• Polices
• Solutions : – Options asynchrones
– Rapatriement – Pubs en iframe
LES 3 CACHES
« Il n’y a pas plus rapide qu’une requête qu’on ne fait pas »
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
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
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 !
LES IMAGES
« ça va plus vite sans images »
Remplacer les images
• CSS3 : – Dégradés – Arrondis – rotations, – Opacités
• Caractères unicodes : – ►★✓⇢ – ✎♥☎ – ♻⚠ – ☻☺⇨
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
Images embarquées
• Technique de data:uri + encodage base 64 • Images critiques encodées dans le HTML
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)
IMAGES ADAPTATIVES
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 ?
Une réponse compliquée à un problème compliqué
• Format officiel final : <picture> • Librairie d’émulation officielle : picturefill 2.0
La technique improbable
« grand JPG qualité nulle » http://bit.ly/jpg-0 (sur un écran à haute densité)
Les formats vectoriels
• Polices icôniques • SVG
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
LES TECHNIQUES DISCUTABLES
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
Domain sharding
Il faut arrêter maintenant hein • Résolution DNS couteuses • Saturation immédiate de la bande passante
JavaScript en bas de page
• Ça ne sert à rien pour le site lambda – Ralentit l’affichage sur Safari iOS – Ralentit l’exécution partout
INTERFACES FLUIDES
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 )
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
MÉTHODOLOGIE
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
Mesurer, avant action
• La base : WebPageTest • Mesures utilisateurs – Google, de base – À enrichir avec des mesures liées au métier
Surveiller dans le temps
• Compléments payants ou gratuits à WPT • Analytics – Google, de base – À enrichir avec des mesures liées au métier
CONCLUSION Parce qu’il en faut une
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
Questions ?
Jean-pierre Vincent – BrainCracking @theystolemynick
Slides : http://bit.ly/perf-mobile