Web mobile : quelles solutions pour les ressources lourdes ?

Dans le monde merveilleux du Web mobile, ce qu’il y a de moins merveilleux c’est qu’on est parfois en situation de mobilité. Comprenez : tributaire de connexions internet pour le moins sporadiques voire inexistantes.

Lorsque l’on sait qu’un « mobinaute » quitte généralement la page au bout de 4 à 5 secondes de chargement, on comprend mieux que chaque ressource chargée, chaque octet et chaque fonctionnalité compte bien plus que sur environnement de bureau.

Quelle stratégie globale ?

Pour être sûr de charger le moins de ressources chronophages sur terminal mobile, il ne suffit pas de les masquer, il… ne faut pas les charger. Cette lapalissade demeure la véritable clé de voûte d’un site web optimisé pour toutes les plate-formes.

Dans l’idéal, le bon sens nous indique qu’il suffirait de scinder deux types de terminaux connectés : ceux qui ont une bonne bande passante ; et les autres.

Et ça tombe bien ! Une API ayant pour but de détecter l’état de la connexion vient d’être proposée au W3C, et elle est à l’état de brouillon.
Elle s’appelle « HTML5 Network Information API » (23 novembre 2012) et semble vouée à un bel avenir.

Mais en attendant… Eh ben en attendant, on se débrouille avec le moyens du bord, et tout n’est pas encore glorieux !

Quelles solutions concrètes ?

En attendant que les spécifications idéales soient implémentées par les navigateurs, nous allons devoir nous contenter de l’équation « grand écran = meilleure connexion ».

Pas le choix, c’est la vie. Cela signifie — vous l’admettrez avec moi — que toute démarche actuelle visant à charger conditionnellement des ressources lourdes sur mobiles est à classer au rang des « bidouilles ».

Partant de ce principe, toute ressource gourmande ne sera chargée que sur grands écrans (mettons supérieurs à 800 pixels par exemple) : images lourdes, audio, vidéo, styles, polices de caractères exotiques, scripts et widgets « bonus », etc.

Concrètement, chaque type de ressource nécessitera potentiellement une détection et un traitement différents.

Parcourons chacune de ces ressources une par une…

Les images de contenu (HTML)

Les images de contenu (éléments <img>) ont parfois beau être compressées pour économiser chaque octet, il faut bien se rendre à l’évidence : charger une image de 1024 px de large sur un terminal qui n’en fait que 320 relève de l’aberration… Et les masquer n’est jamais la bonne solution.

• Solution « standard » prévue : Le groupe de travail « Responsive Images » du W3C planche sur un couple <picture> et/ou attribut srcset. Ce duo offre (entre autres) la possibilité de charger différentes sources d’images selon la résolution de l’écran. Le premier brouillon de spécifications est tout frais et risque de beaucoup changer dans les prochains temps… Mais aucun navigateur ne supporte encore ce standard.
• Solution alternative : En attendant la démocratisation du standard adéquat, l’alternative consiste à prévoir un chargement conditionnel via JavaScript selon la taille de l’écran, ou de la position du curseur dans la page (« Lazy Loading »)
• Exemple : http://www.thinkmobilefirst.net/media/4.html
• En savoir plus : http://blog.cloudfour.com/responsive-imgs-part‑2/, http://css-tricks.com/snippets/javascript/lazy-loading-images/

Les images de décoration (CSS)

Les images décoratives doivent être gérées en CSS via background-image, c’est un fait. Et cela nous arrange puisque CSS nous offre une technologie magique : les CSS3 Media Queries.

• Solution « standard » prévue : Le W3C ne prévoit malheureusement pas encore de détecter la connectivité (bandwidth) via Media Queries.
• Solution alternative : Il va donc falloir prévoir des Media Queries pour petits écrans (max-width : 640px par exemple), pour grands écrans (min-width : 641px par ex) et charger la bonne image d’arrière-plan pour chaque cas de figure.
• Exemple : http://www.goetter.fr/ (image de fond)
• En savoir plus : http://www.alsacreations.com/article/lire/930-css3-media-queries.html

Les médias

Audio et vidéos sont de magnifiques cobayes pour tester la lenteur de votre connexion ! Mais tout n’est pas encore perdu, les solutions arrivent…

• Solution « standard » prévue : Le W3C autorise l’emploi des Media Queries au sein des éléments <source> des balises audio et vidéo.
  Il est donc possible de charger conditionnellement une version légère ou lourde selon la taille du périphérique, comme le montre l’exemple suivant : <video><source src=« une_video_mini.mp4 » type=« video/mp4 » media= »(max-device-width:640px) »></video>
• Solution alternative : Comme à l’accoutumée, la solution de repli réside dans un test de largeur d’écran via JavaScript (voir la partie « images de contenu »).
• En savoir plus : http://www.iandevlin.com/blog/2012/08/html5/responsive-html5-video

Polices superflues

CSS3 permet de s’offrir des petites folies typographiques en chargeant n’importe quelle police de caractères. Mais cela a un coût en termes de poids et de performances, d’autant plus si vous avez opté pour les versions grasses et italiques de votre fonte. Avez-vous vraiment besoin de charger votre police exotique sur un smartphone ?

• Solution « standard » prévue : Il est possible d’indiquer un chemin « local » dans le cache, pour éviter ainsi le chargement de la police, mais cette solution n’apparaît plus dans la syntaxe « bulletproof » de la règle @font-face, car elle pose des problèmes de compatibilité, notamment avec Mac OSX et Android.
• Solution alternative :
  Pour ne pas changer nos habitudes, il nous faudra prévoir un chargement conditionnel de la feuille de style — contenant l’appel vers le fichier de fonte —  via JavaScript (en détectant la taille de l’écran).
• Exemple : http://www.thinkmobilefirst.net/content/4.html
• En savoir plus : http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax

Les scripts de « confort »

En parlant de JavaScript, j’ai lu récemment que les temps de traitements JavaScript sur mobile sont dix fois plus longs que sur navigateurs de bureau ? (Je cherche encore la source de cette information.)
Je vous invite vivement à y réfléchir à deux fois avant de charger n’importe quel script superflu, voire votre bibliothèque préférée jQuery, Mootools et compagnie si vous n’en éprouvez pas le besoin sur mobile.

• Solution « standard » prévue : Malheureusement, le W3C n’a encore aucun brouillon à l’étude sur ce domaine, c’est à nous de prendre nos dispositions.
• Solution alternative : Une fois de plus, la solution réside dans des chargements conditionnels (selon la taille de l’écran), bref : utiliser JavaScript pour charger ou non un script JavaScript !
  Une autre idée pertinente est de remplacer la grosse bibliothèque  jQuery par des alternatives plus légères (jQuip – jQuery in parts – ou Zepto.js), encore peu connues mais très efficaces. Par exemple, jQuip se vante de couvrir 90 % des fonctionnalités de jQuery pour un poids divisé par 6.
• Exemple : http://www.thinkmobilefirst.net/content/5.html
• En savoir plus : https://github.com/mythz/jquip

Et le retina alors ?!

Vaste question que posent les écrans Haute-Définition (ou « Retina » par abus de langage) !

Le manque de support des tests de connectivité (Wi-fi, 3G, egde) des terminaux mobiles nous force à détecter la résolution ou la densité de pixels.
Or, la vraie question à se poser est : « suis-je obligé de subir une image rétina (donc plus lourde) si je navigue sur un terminal HD en situation de faible bande passante ? ». La réponse devrait être « non ».

Pour l’instant, les seules pistes — standards ou alternatives — se préoccupent de la taille du terminal ou de sa résolution : le W3C propose image-set pour les images d’arrière-plan, et picture + srcset pour les images de contenu.

L’alternative réside toutefois encore dans l’emploi des Media Queries et une détection de la résolution.

En savoir plus : http://www.creativejuiz.fr/blog/veille-technologique/css-retina-hd-webkit-image-set-picture-srcset

Mais finalement, c’est ça le « mobile first » !?

Mouais, plus ou moins.

J’ai toujours été assez réticent face aux contraintes que je considère comme « extrêmes » de la philosophie « Mobile First ». Pour au moins une raison simple : je n’ai toujours pas trouvé de client — ni de webdesigner — qui raisonne dans le sens « mobile » en premier. Il nous semble « naturel » de concevoir ses fonctionnalités, son ergonomie et son design en partant de son outil de travail principal, à savoir : un ordinateur de bureau et un logiciel graphique de bureau.

Toujours est-il que je suis convaincu que faire du  « mobile-first pour les ressources » est une absolue nécessité : même si votre design est pensé pour le bureau, rien ne vous empêche de l’intégrer en incluant par défaut le moins possible d’éléments gourmands en ressources.

Bref, faites du « Mobile First » non dogmatique.