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.

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.
  • Exemplehttp://www.goetter.fr/ (image de fond)
  • En savoir plushttp://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 plushttp://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 ?

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.
  • Exemplehttp://www.thinkmobilefirst.net/content/5.html
  • En savoir plushttps://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.

Raphaël Goetter

À propos de Raphaël Goetter

Appartient à la grande famille des Intégrateurs du Dimanche. Créateur et administrateur du site Alsacreations.com, communauté libre d'apprentissage web spécialisée dans les standards. Co-fondateur et co-gérant de l'agence web Alsacreations.fr. Expert et Formateur en langages HTML et CSS. Auteur de divers livres techniques chez Eyrolles: "CSS avancées, vers HTML5 et CSS3", "CSS2, Pratique du design web", et des Mementos XHTML, CSS2 et CSS3.

Vous pouvez partager cet article sur Facebook, Twitter ou Google+.

Faites un don pour soutenir l'association Handiparentalité !

L'association Handiparentalité a pour objet d'aider les parents ou futur-parents en situation de handicap, et de faire reconnaître le statut de parent handicapé au niveau des institutions.

Les fonds récoltés vont directement sur le compte PayPal de l'association. En cliquant sur le bouton "Faire un don" ci-dessus, vous allez être redirigé vers PayPal. Vous n'êtes pas obligés de créer un compte PayPal pour faire un don.

7 commentaires sur “Web mobile : quelles solutions pour les ressources lourdes ?

  1. Xavier, le Vendredi 14 décembre 2012 à 09:20

    Merci pour cet article bien complet. Beaucoup de ressources intéressantes que j'irai consulter.

  2. Johan, le Vendredi 14 décembre 2012 à 09: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...

  3. Pascal, le Vendredi 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.

  4. mlb, le Vendredi 14 décembre 2012 à 13:30

    S'agissant du Retina : http://blog.netvlies.nl/design-interactie/retina-revolution/

  5. noclat, le Lundi 17 décembre 2012 à 08: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/

  6. emporeso, le Lundi 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/

  7. lunettes de soleil, le Jeudi 10 janvier 2013 à 09: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.

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.