Édition Nº14 du 14 août 2012 Retour au sommaire

Performance web mobile, chargement de page 1/2

En cette période estivale, nous débutons une série sur les performances web sur mobile avec Jean-Pierre Vincent. Nous commencerons par l’analyse du chargement d’une page puis passerons plus tard à son rendu. À vos marques, prêts, chargez !

Conducteur


Jean-Pierre Vincent

Arrêts prévus :

Introduction

Vos utilisateurs viennent chez vous sur mobile : 5 % selon StatsCounter ; 10 % selon ATInternet ; 8 % d’après ce que je vois chez mes clients dont le site n’a PAS été pensé pour du mobile. Évidemment cette part est en augmentation constante, a déjà largement dépassé IE7, va dépasser IE8, et il est raisonnable de penser que, ces statistiques étant récoltées via JavaScript, certaines tentatives d’accès ne soient même pas comptabilisées ! Que vous le vouliez ou non, que votre site ait été fait ou pas pour cet usage, vos utilisateurs essaient de venir sur votre site dans des conditions de réseau qui ne vous arrangent pas forcément, mais qui vont vous poser quelques défis intéressants.

Qu’est ce qu’un mobile ?

Plus on rentre dans les détails des navigateurs, des systèmes d’exploitation et des capacités matérielles, et plus il semble illusoire de définir ce qu’est vraiment un mobile. Restons pragmatiques et, dans le cadre de cet article sur la performance, précisons ce que nous allons considérer comme notre cible :

  • capacité du navigateur à afficher des sites non spécifiquement prévus pour mobiles ;
  • navigation “tactile” ;
  • matériel sous-dimensionné par rapport à la machine de bureau moyenne ;
  • qualité de réseau fluctuante.

Ce dernier critère peut prêter à discussion, tant on observe d’utilisateurs mobiles accéder aux sites depuis le confort du WiFi de la maison : par exemple, la moitié des visiteurs dits “mobile” sont en fait sur iPad, ce qui implique (le plus souvent) le WiFi.
Mais dans le cadre de cet article nous allons surtout nous intéresser aux “problèmes supplémentaires à résoudre pour le chargement des pages” : les temps de chargement depuis une tablette / mobile sur WiFi sont largement comparables aux temps de chargement sur certains navigateurs de bureau.

Comment tester ?

Tout développement commence par la mise dans de bonnes conditions pour tester ; la mesure a lieu ensuite dans un chantier performance web. Le banc de test idéal pour le mobile est simplement impossible à monter et force est de constater que les éditeurs de sites, de l’indépendant aux sites avec des millions de pages vues, se contentent généralement de l’iPhone de l’intégrateur et éventuellement de l’Android-qui-s’appelle-revient du collègue.
Si l’on regarde les parts de marché en France, cela correspond effectivement à une réalité : nous avons Safari pour iOS partagé entre les différents iPhone et iPad, et le navigateur par défaut d’Android distribué avec les version 2.x. En queue de peloton et souvent ignorés, à tort pour les valeurs d’interopérabilité du Web, viennent les Opera (mini ou mobile) pourtant ultra-dominants dans d’autres pays, Firefox mobile, ainsi que différentes variantes de Webkit sur les OS mobiles survivants (Blackberry, SymbianOS, LG…), ainsi que IE Windows.

Ah, et ne comptez pas sur les émulateurs : ils sont déjà à peine acceptables pour tester les fonctionnalités, alors question performance ils sont tout simplement disqualifiés d’office ! Entre l’utilisation du processeur de la machine hôte, une connexion filaire sans défaut et les approximations inhérentes à tout émulateur, vous n’aurez jamais quoi que ce soit de réaliste dans votre quête de la fluidité.

La solution minimale du pauvre, c’est de conserver ses mobiles et d’attendre qu’ils vieillissent ou d’acheter des occasions datant d’un an ou deux, sans mettre à jour le système d’exploitation. Pour simuler un réseau 3G, on pourra utiliser des proxys via WiFi qui dégradent volontairement la connexion. Il y a une grosse dizaine de solutions, généralement limitées à un seul OS (souvent Mac). La plus compatible et reconnue est le proxy payant Charles mais la gratuité de Trickle (Linux), Network Link Conditioner (OSX 10.6) ou Slowy App (OSX 10.5) peut vous séduire.
Le principe est simple : ces logiciels contiennent de quoi dégrader artificiellement une connexion (débit, perte de paquets, latence). Vous configurez votre téléphone pour utiliser votre machine comme proxy via WiFi, et voilà ! En prime, vous pouvez analyser les trames réseau qui passent. C’est moins cher que de vraies cartes SIM et la constance de la dégradation permet de faire des tests répétés, là où la qualité d’un vrai réseau data peut varier d’une minute à l’autre.
Pour être honnête, les techniques décrites dans cet article ont surtout été testées sur le navigateur Android 2.3 et Safari iOS (à jour), avec des vérifications fonctionnelles sur Firefox et Opera mobile sur Android, les deux absents notoires étant le Safari de Blackberry et Internet Explorer.

Qu’est ce que la performance ?

Comme sur ordinateur de bureau, on peut distinguer :

  • le chargement de la page,
  • la fluidité du rendu.

Ce premier article va parler du chargement des pages, que votre site soit classique ou fasse office d’application Web.

Chargez !

L’importance du réseau

Croyez-le ou non, les débits théoriques en 3G et technologies au-delà peuvent être plus rapides que les débits constatés des ADSL. Mais comme finalement assez peu de gens font du Web depuis les laboratoires de tests des constructeurs, il va falloir composer avec la réalité physique : une couverture nuageuse un peu forte, un déplacement un peu rapide, un doigt mal placé, un mur un peu épais, ou des gens autour de vous également équipés de mobiles (incroyable en 2012), et vous vous retrouvez rapidement avec des débits ridicules, des pertes de paquets énormes et le sentiment global qu’on vous a un peu survendu la “meilleure couverture réseau de France”.
Lorsque le réseau marche, l’utilisateur français moyen a en moyenne 350 Ko/s avec des pointes à 1 Mo/s (source : Akamaï, ce qui vaut certaines connexions ADSL (600 Ko/s en moyenne toujours selon Akamaï). Par contre, la latence ou ping est entre 100 et 300 ms, alors qu’elle est 10 fois inférieure sur ADSL.
Depuis toujours, la latence est l’ennemi numéro 1 de nos pages Web. Ceci est du à la nature même de HTTP et signifie que pour un débit moyen deux fois inférieur, le temps de chargement sera en fait 3 à 6 fois plus long sur mobile ! Pire, la perte de paquets est assez conséquente et inhérente à la technologie radio utilisée pour communiquer entre le mobile et l’antenne de l’opérateur, et plus fréquemment pour les petites requêtes…
Exactement celles qui composent la majorité de nos pages Web actuelles !

Ajoutez à cela qu’accrocher et maintenir le réseau data est une des opérations les plus coûteuses en terme de batterie : passez en mode avion sur votre smartphone, utilisez-le presque comme d’habitude (lectures, jeux…) et vous verrez qu’il peut tenir une seconde journée sans recharge. Et souvenez-vous des anciens portables sans data qui tenaient une semaine…
Bref, c’en est au point que les constructeurs optimisent comme ils peuvent le matériel, par exemple en mettant en veille la radio après un certain temps d’inutilisation. On se retrouve donc dans des situations où, le temps de lire cet article, l’antenne s’est déconnectée et il vous faudra plusieurs secondes pour que la requête suivante aboutisse !
Malgré cela, les utilisateurs ne sont pas beaucoup plus patients que sur un ordinateur de bureau : après 5 à 10 secondes de page blanche, une majorité d’utilisateurs a déjà rebroussé chemin, et autant vous dire qu’ils n’apparaissent même pas sur les statistiques collectées en JavaScript. Comment faire pour vaincre l’hémorragie de visiteurs et proposer des services de meilleure qualité perçue ?
Eh bien il va nous falloir revisiter tout l’arsenal des classiques de la Performance Web.

Remettre en cause les classiques

Lorsque le pape de la performance, Steve Souders, a émis chez Yahoo! les premières recommandations de performance Web, c’était en faisant du reverse-engineering sur les moteurs IE6-IE7 et Firefox 2. C’était en 2005 et, avec l’abandon progressif du support de ces navigateurs antédiluviens (à l’échelle du Web) d’un côté et la banalisation de l’ADSL de l’autre, certaines règles ou astuces sont devenues moins importantes.
L’apparition de la navigation sur mobile en a même rendu certaines dangereuses !

Le domain-sharding

Citons par exemple le domain-sharding, qui consiste à répartir ses fichiers statiques sur plusieurs sous-domaines différents. Étonnamment populaire, à l’origine cette technique permettait de passer outre la limitation à 2 files de téléchargement par domaine et de bénéficier de toute la largeur des bandes passantes modernes. Mais à partir de IE8, sorti en 2009, cette technique devient inutile car le nombre de téléchargements simultanés passe de 2 à généralement 6 : les navigateurs se sont adaptés à la banalisation des gros débits et tentent d’en tirer parti.

Utilisons le service Cuzillon qui va nous permettre de simuler une page avec 24 images réparties sur 4 domaines et une autre page avec 24 images sans domain-sharding. Le service WebPageTest nous permet de voir qu’il y avait effectivement une amélioration sur le temps de chargement sur IE7 :

WebPagetest - Test de chargement d’une page sous IE7 avec et sans sharding
WebPagetest – Test de chargement d’une page sous IE7 avec (en bas) et sans sharding (en haut) (Voir la source)

Le test sur les mêmes URLs sur IE8 nous montre que l’on ne gagne plus grand chose en premier rendu (les petites images chargées) :

WebPagetest - Test de chargement d’une page sous IE8 avec et sans sharding
WebPagetest – Test de chargement d’une page sous IE8 avec (en bas) et sans sharding (en haut) (Voir la source)

On ne gagne plus rien car la parallélisation des téléchargements est assurée de base par le navigateur. On a en fait rajouté deux mini-problèmes en rajoutant un temps de résolution DNS supplémentaire par domaine, et en faisant concourir plusieurs images pour la même bande passante. Je dis “mini-problème” en supposant qu’on ne ciblait que les navigateurs de bureau (c’est mal) où ces problèmes sur des vrais sites (75-150 requêtes, 10-15 domaines) passent finalement inaperçus, mais vous ciblez les mobiles, pas vrai ?
Sur mobile, les navigateurs ouvrent également plusieurs connexions par domaine et font même du multiplexing HTTP (plusieurs requêtes HTTP dans le même tuyau TCP) pour minimiser les problèmes liés à la latence. Vous prenez alors le risque de couper court à ces optimisations. Résultat ?

WebPagetest - Test de chargement d’une page sous iOS avec et sans sharding
WebPagetest – Test de chargement d’une page sous iOS avec (en bas) et sans sharding (en haut) (Voir la source)

L’affichage a été ralenti ! En forçant encore plus de domaines, vous demandez à plus d’objets de se partager la même bande passante, que vous devez considérer a priori comme rare sur mobile. Donc vous ralentissez l’affichage des premières images alors même que les suivantes ne sont pas immédiatement utiles. Ici, le temps de chargement total est en plus augmenté car le multiplexing n’a pas pu être utilisé, ce qui peut être le cas sur des sites avec un ratio ressources / domaine faible.

Les scripts en bas de page

Le temps avant le premier rendu (l’affichage des premiers pixels du site) est un peu le but ultime de la performance Web, car il y a une très forte corrélation entre ce temps et une augmentation des taux de transformation ( + rapide = + d’argent ).
Dans ce cadre, une autre technique populaire consiste à déplacer toutes les balises script en bas de page. Cette technique marche effectivement bien sur les anciens navigateurs et continue à faire ses preuves dans une moindre mesure sur les nouveaux malgré leurs progrès dans la prioritisation des téléchargements.
Regardons l’effet attendu avec IE8 sur une page simple où le téléchargement du JavaScript est retardé côté serveur.

Bureau : tests de comparaison de chargement d’une page avec les scripts en bas et en haut de page
Bureau : tests de comparaison de chargement d’une page avec les scripts en bas et en haut de page (Voir la source)

En haut, la page améliorée par déplacement des balises script ; on voit que le contenu (une simple phrase) s’affiche rapidement, alors qu’en bas la page blanche de la mort est de rigueur.

Passons sur mobile, si vous le voulez bien, et testons Safari iOS et Android Browser 2.3.

Mobiles Android et iOS : tests de comparaison de chargement d’une page avec les scripts en bas de page
Mobiles Android et iOS : tests de comparaison de chargement d’une page avec les scripts en bas de page (Voir la source)

Android se comporte comme nos navigateurs de bureau et affiche le contenu dès qu’il l’a. Safari iOS préfère attendre le script avant d’afficher quoi que ce soit, sans doute par peur du FOUC (Flash Of Unscripted Content).
On peut débattre sur le fait qu’ergonomiquement il vaut mieux attendre une page bien faite (complètement scriptée) plutôt que d’afficher rapidement du contenu pas finalisé, mais les taux de transformation montrent que l’affichage rapide rapporte plus.
Et de toute façon, en tant qu’auteur de la page, c’est à vous de juger si elle peut être vue momentanément sans scripting ou pas : si vous utilisez des méthodes de développement par couche (HTML, puis CSS, puis JS), ça devrait être bon. Si vous voulez de la performance, il va donc falloir faire évoluer votre technique d’inclusion de script pour passer à une version asynchrone.

Le chargement asynchrone à la base est bête comme chou :

1
2
3
4
var oNode = document.createElement('script’);
oNode.type = 'text/javascript’;
oNode.src = 'http://domaine/monscript.js’;
document.getElementsByTagName('head’)[0].appendChild(oNode);

Vous utilisez le DOM pour créer dynamiquement de nouveaux noeuds script qui vont charger des fichiers JS. Cette technique est notamment utilisée par les Google Analytics, boutons G+ et autres Like Facebook pour s’insérer dans vos sites sans introduire de dépendance forte vis-à-vis de leurs serveurs.
Autrement dit, lorsque leurs serveurs sont en rade ou bloqués par un proxy, le navigateur va tout de même afficher votre page (trop aimable). Utiliser cela avec ses propres scripts est globalement une bonne idée, et devient vital sur mobile. Vous aurez probablement besoin d’aller plus loin avec le chargement dynamique de scripts (exécuter du code lorsque le fichier est arrivé, gestion des dépendances et de l’ordre de chargement, concaténation de fichiers à la volée…), aussi pensez à utiliser des frameworks solides comme requireJS, YepNope.js (inclus avec Modernizr), HeadJS, LabJS… Chacun a sa philosophie.
Et puisque je vous tiens, voici le mien : LazyLoadLight, qui se veut léger et facile :)

Suite de cet article la semaine prochaine !

Performance web mobile, chargement de page 1/2

Note de cet article : 3 / 5

Pour pouvoir noter les articles, vous devez voyager avec un billet (c'est gratuit !).
Toutes les infos sur la page d'abonnement !
Déjà inscrit ? Connectez-vous.

12 ans à coder pour le Web, ça marque un homme. Depuis 2011 Jean-pierre VINCENT est expert technique indépendant sur les performances Web et HTML5, mais également auteur du livre "HTML5" chez Dunod, conférencier multi-récidiviste et formateur. Avant ça ? du PHP depuis 2000, puis de l'intégration et du gros JavaScript en 2005-2008 chez Yahoo!, avant de tenter l'expérience startup en tant que lead technique.

Découvrir les autres articles de cet auteur

3 réactions à cet article (RSS)

Frédéric Kayser

#1

Une petite remarque concernant le « traffic shapping » l’offre est particulièrement riche pour Mac OS X car sa pile TCP/IP est d’origine BSD. C’est en fait dummynet qui est solicité pour simuler différents types de liaisons, on le retrouve naturellement dans FreeBSD qui est libre et facilement virtualisable, dummynet est également disponible pour Windows et Linux.
Pour plus d’informations concernant dummynet : http://info.iet.unipi.it/~luigi/dummynet/

Trop tard pour réagir... ;)

Cet article a plus de 30 jours, il n'est donc plus possible d'y réagir.