La performance sur mobile

Post on 21-Jun-2015

774 views 0 download

Tags:

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 of La performance sur mobile

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