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.
7 commentaires sur cet article
Xavier, le 14 décembre 2012 à 9:20
Merci pour cet article bien complet. Beaucoup de ressources intéressantes que j'irai consulter.
Johan, le 14 décembre 2012 à 9:26
Article intéressant auquel j'adhère complètement.
Néanmoins petite remarque : Vous parlez des écrans "Haute-Définition" pour les écrans dit "Rétina" mais cela n'a rien à voir (c'est un abus de langage de vouloir placer de "Haute Définition" partout). La résolution d'un iPhone 5 n'a rien de "Haute-Définition" par exemple puisqu'elle est de 640 × 1136 or c'est un écran Rétina.
Vous auriez pu parler des écrans HiDPI (qui est un autre abus de langage, mais c'est une autre histoire) pour les écrans dits Rétina...
Pascal, le 14 décembre 2012 à 10:23
De bonnes ressources, merci Raphaël ; )
Pour une approche mobilefirst quelques ressources supplémentaires ici :
https://github.com/filamentgroup (certaines ressources sont basées sur jquery )
Quelques exemples qui recoupent les solutions citées par Raphaël :
eCSSential (chargement de css en fonction de mediaqueries par exemple)
responsive-carousel (dont un exemple chargé avec ajax à voir parmi toutes les démos http://filamentgroup.github.com/responsive-carousel/test/functional/ )
Picturefill pour le chargement des images en fonction de la taille d'écran (et hd) https://github.com/scottjehl/picturefill
L'article de CloudFour évoque le solution noscript il y a aussi la solution avec contenu commenté ( https://github.com/dmolsen/lazyBlock ) qui permet de charger conditionnellement du contenu sans ajax (attention à noscript le contenu n'est pas accessible via js pour android < 3 (4?) ) je l'ai testé rapidement ici : http://soqr.fr/rwd-slider/
Dans l'attente d'avancées concernant la qualité de la connexion, nous devrions peut-être laisser le choix à l'utilisateur final (" veux-tu charger ce joli slideshow ? avec des images hd ? ") Dans certains cas la solution RESS est aussi à envisager... avec précautions évidemment.
mlb, le 14 décembre 2012 à 13:30
S'agissant du Retina : http://blog.netvlies.nl/design-interactie/retina-revolution/
noclat, le 17 décembre 2012 à 8:26
Super article qui regroupe beaucoup de ressources importantes. Je suis on ne peut plus d'accord sur le "mobile first" en intégration mais "desktop first" en design.
Voici un bon moyen d'offrir un rendu décent des images sur Retina sans gratter sur les perfs : http://filamentgroup.com/lab/rwd_img_compression/
emporeso, le 24 décembre 2012 à 11:56
@Raphaël Goetter : 100% ok avec ton aprroche « Mobile First » non dogmatique.
@noclat : pour le "mobile first" en intégration j'qi bien aimé cette artcile : http://www.html5rocks.com/en/mobile/responsivedesign/
lunettes de soleil, le 10 janvier 2013 à 9:10
Salut, j
ai beaucoup aimé votre blog. Je ne suis pas spécialiste dans la matière, avez-vous d
autres billets sur le même sujet ? Continuez comme ça, c`est toujours agréable de lire votre blog !Céline.
Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :