Les pixels, voilà l’ennemi !
Par Dave Rupert
Les résolutions d’écran des appareils mobiles ne cessent d’augmenter, et on voit la même tendance pour les ordinateurs de bureau et les portables. On ne pourra pas y couper : l’affichage à haute densité de pixels (alias « Retina ») devient maintenant la norme ; et on voit bien que nos sites web conçus pour du LCD traditionnel commencent à faire grise mine. Mais plutôt que nous jeter à corps perdu dans le développement de sites de plus en plus gros, nous ferions mieux d’identifier les problèmes qui se présentent à nous et de trouver les solutions d’avenir les plus raisonnables, tout en gardant prioritairement à l’esprit nos utilisateurs.
Le problème majeur : des images énormes
Comme la plupart d’entre nous voulons toujours avoir une longueur d’avance, nous avons commencé à faire des sites web « @2× » [en proposant au départ des images deux fois plus grandes, pour ensuite les réduire de 50%, NdT] mais en espérant quand même que l’@3× ne serait pas pour demain. Bien qu’on puisse croire qu’une image @2× pèse deux fois plus de kilobytes, en réalité on arrive à environ trois ou quatre fois plus. Comme vous le verrez dans ma démonstration sur @1× contre @2×, pour des photos ou des compositions très détaillées on se retrouve rapidement avec non plus des kilobytes mais des mégabytes.
Je vous entends déjà répliquer : « Et alors ? Le web, ça doit être beau, non ? » Et je suis bien d’accord. C’est même souvent pour ça qu’on a choisi ce métier, pour faire du beau web. Mais là où le bât blesse, c’est dans l’idée qu’on se fait de la bande passante disponible.
Dans les pays riches, on a tendance à considérer que l’accès à une bande passante à haut débit est un droit, alors que pour beaucoup de gens dans le monde la bande passante est limitée, ou bien payante selon le débit téléchargé. Même si vous vous dites que « c’est pour faire plus beau », ce n’est pas une raison suffisante pour envoyer une image de 1 MegaBit à travers un réseau 3G ou, Dieu nous préserve, quelque chose comme un réseau Edge.
Et même dans nos petits paradis du haut débit, on n’a pas à chercher loin pour trouver des exemples de bande passante limitée. Un visiteur peut accéder à votre site avec une tablette ou un téléphone à haute définition qu’il soit confortablement installé sur son canapé, ou au milieu du désert de l’Arizona. De même, leurs Macbook Pro Retina flambant neufs peuvent très bien être connectés à Internet via un réseau Google Fiber, ou accrocher péniblement le signal d’un hotspot d’aéroport. Il est dangereux de croire qu’un écran à haute densité implique une bande passante illimitée.
La mauvaise solution : le JavaScript
« Eh bien moi, je vais mettre un petit JavaScript. »
— Signé : la terre entière
JavaScript nous a tellement souvent sauvé la mise par le passé qu’on est tenté d’implorer son secours une fois de plus. Néanmoins, la plupart des solutions ne donnent pas satisfaction, et finissent par imposer aux utilisateurs le fameux « double téléchargement ».
Mat Marquis a déjà expliqué tout ça, mais ça vaut la peine de le répéter : obsédés par une recherche incessante de vitesse sur le web, les navigateurs ont entrepris de pré-charger toutes les images d’un document avant même que le JavaScript puisse entrer en jeu et effectuer le moindre changement.
Du coup, dans le cas de solutions qui peuvent admettre de hautes résolutions et pour lesquelles une deuxième source d’images est injectée, les navigateurs vont chercher non plus une mais deux images, obligeant ainsi les utilisateurs équipés en haute résolution à attendre que les deux jeux d’images soient téléchargés. Ce double téléchargement n’est pas vraiment pénalisant quand il ne s’agit que d’une seule image, mais imaginez ce que ça peut donner à l’échelle d’une galerie photo contenant 100 images par page. Ça fait mal.
Il existe d’autres pistes, comme la détection de bande passante, le réglage des cookies, la détection côté serveur, ou bien un mélange des trois. C’est bien beau de laisser des machines s’occuper de régler tous nos problèmes, mais en réalité, pour le développeur web lambda, ces différentes solutions vont poser plus de problèmes qu’en résoudre. Leur plus gros défaut commun réside dans l’interdépendance serveur/cookie, dont on sait bien que c’est source d’ennuis.
Ce qu’il nous faudrait plutôt, c’est une solution à 100% côté client pour les images à haute résolution.
Et ça vous rappelle quelque chose, ça ? Si oui, c’est parce que les images à haute résolution et les images réactives renvoient à la même question de base : comment fournir différentes images à différents appareils et dans différents contextes, tout en employant la même et unique balise HTML.
La bonne vieille solution des familles : l’enrichissement progressif
Ceux qui parmi nous travaillent sur la question des CSS et des normes du web connaissent depuis longtemps le concept d’enrichissement progressif. Dans ce domaine, il faut vraiment que nous visions tous le même objectif. Peu importe le type de terminal qui les reçoit, peu importe la capacité de leur écran : quand on parle de pixels, on parle d’un élément d’enrichissement qui sera affiché par certains navigateurs, et pas par d’autres. Il faut mettre en place une base commune solide, puis procéder à des améliorations selon les besoins rencontrés. En fait, c’est en apprenant à construire correctement un site à enrichissement progressif que vous (et vos clients) pourrez en fin de compte gagner beaucoup de temps.
Voici les règles que nous suivons avec mes collègues de Paravel, et qui nous guident dans la jungle des images à haute résolution sur le web :
- utiliser CSS et des polices web en priorité
- employer le format SVG et les polices d’icônes quand c’est utile
- pour les images non vectorielles, passer par Picturefill en JavaScript.
Examinons chaque règle en détail.
Les CSS et les polices web
Grâce à CSS3, nous pouvons reproduire assez facilement dans les navigateurs des effets visuels plus riches, et l’explosion des polices de caractère adaptées au web nous permet de construire des sites en nous appuyant sur une typographie riche, et non plus sur des collages d’images. Avec ce que nous offrent aujourd’hui les CSS, nous avons de moins en moins de raisons de nous baser sur des images géantes pour obtenir l’impact visuel recherché.
On en revient donc à la bonne vieille règle : s’il est possible de réaliser le design de votre site avec HTML et CSS, faites-le. Et si cela ne semble pas possible, commencez par vous poser la bonne question : pourquoi donc ? Après tout, si nous nous considérons comme des professionnels du design pour le web, alors il est impératif que nos designs fonctionnent avant tout pour le web — et de la façon la plus efficace possible.
Prenez du recul et appréciez de travailler avec ce qui fait la chair et le sang du Web : HTML et CSS.
Le format SVG et les polices d’icônes
Les images SVG sont des chemins vectoriels définis dans un document en XML ; elles ont été conçues comme une alternative au format Flash. Elles fonctionnent comme des fichiers Illustrator dans un navigateur. Non seulement elles ne dépendent pas du tout de la résolution des écrans, mais en plus elles produisent généralement des fichiers extrêmement légers (en fonction du nombre de points dans le vecteur).
Les polices d’icônes (comme Pictos ou SymbolSet) consistent pour l’essentiel en des collections de graphiques vectoriels, rassemblés dans des polices de casseaux (dingbats) sur mesure qui sont intégrées aux pages à travers des caractères unicodes, dans des fontes embarquées via @font-face. Une remarque en passant : à Paravel, nous avons remarqué que les petites images vectorielles comme les boutons et les icônes offrent un moins bon rendu sur les écrans à haute résolution. Les polices d’icône offrent une bonne alternative aux Sprites CSS, et nous avons d’ailleurs commencé à les utiliser en substitution dès que possible.
La déclaration @font-face est très bien interprétée, et on peut dire que la possibilité d’intégrer du SVG est devenue quasi-universelle — sauf bien sûr pour les suspects habituels, c’est-à-dire les versions anciennes d’IE et d’Android. Reste qu’aujourd’hui nous pouvons sans risque commencer à employer du SVG, quitte à faire quelques concessions aux navigateurs plus anciens si nécessaire, en les détectant puis en leur fournissant un script d’émulation de la fonction manquante (polyfill) ou bien un affichage alternatif (fallback), voire en utilisant un de ces nouveaux projets qui automatisent les Sprites SVG/PNG.
Mais il existe des cas où ces formats ne font pas l’affaire. Par exemple, les polices d’icônes ne fonctionnent qu’en une seule couleur. D’autre part, même si les SVG sont agrandissables à l’infini, qui dit agrandissement ne dit pas plus haute fidélité ni plus haut niveau de détail. C’est là que nous devons sortir l’artillerie lourde.
Images bitmap et Picturefill
L’élément <picture>, mis en avant par le Groupe Images Réactives du W3C et qui n’est pas inconnu des familiers de ce site (le site A List Apart, Ndt), constitue une solution élégante au chargement de grandes images bitmap. Avec <picture>, nous pouvons indiquer progressivement quelle est la source d’images à choisir par le navigateur, en fonction du nombre de pixels disponible.
L’élément <picture> n’est pas exempt de critiques, d’autant qu’il a un concurrent de poids. L’attribut d’image @srcset, qui est notamment poussé par Apple, se base sur la propriété CSS image-set() et vise à fournir des éléments haute-résolution en tant qu’images de fond. Voici un exemple de la syntaxe proposée (avec mes commentaires personnels) :
<img alt="Un chat qui danse" src="small-1.jpg"
srcset="small-2.jpg 2x, // ça c’est plutôt bien
large-2.jpg 100w, // bof...
large-2.jpg 100w 2x // bof bof...
">L’attribut @srcset se présente comme une solution complète pour les images réactives, mais sa microsyntaxe est pénible, et il n’est pas suffisamment universel : par exemple il emploie les mystérieuses unités h et w qui lui sont propres, basées sur le pixel ; en revanche il n’accepte pas l’unité em. Mais certaines qualités le sauvent : en théorie, l’attribut @srcset pourrait permettre au navigateur de choisir en fonction de la bande passante. Celui-ci pourrait alors prendre la décision la plus appropriée quant à la résolution qui convient le mieux, selon les réglages choisis par l’utilisateur et/ou en fonction des données collectées sur la vitesse de l’ensemble des requêtes.
Néanmoins, vue la façon dont sa spécification est rédigée, @srcset n’est rien de plus qu’un ensemble de suggestions que le navigateur peut choisir de suivre ou d’ignorer. L’auteur de ces lignes grince un peu des dents à l’idée de laisser un contrôle total au navigateur sur cette question, et j’imagine ne pas être le seul.
Est-ce qu’on ne pourrait pas trouver un juste milieu ?
Voyant les avantages de l’attribut @srcset, le Groupe Images Réactives a publié une proposition qu’il appelle « le Compromis de Florian », et qui associerait les atouts d’@srcset et de l’élément <picture>.
<picture alt="Un chat qui danse">
<source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
<source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
<source srcset="small-1.jpg 1x, small-2.jpg 2x">
<img src="small-1.jpg">
</picture>Certes, la syntaxe de <picture> est plus verbeuse, mais elle reste très lisible et nous évite l’étrange raccourci syntaxique « 100w ». On peut imaginer que certaines choses évoluent à l’avenir, mais en attendant, de notre côté nous utilisons la solution Picturefill de Filament Group, qui est basée sur les div, que nous trouvons facile à utiliser et qui ne requiert pas d’architecture serveur ni de fichiers .htaccess. Elle se contente d’émuler l’élément <picture> comme s’il existait déjà.
Histoire d’aller fouiner sous le capot, notre démonstration précédente utilisait deux exemples originellement tirés de Picturefill pour modifier les sources selon la taille adoptée par le navigateur. J’ai effectué de petites modifications à notre démo, en combinant les deux sources @1× et @2× en une seule démo Picturefill écrite avec sa nouvelle syntaxe.
Technique expérimentale : le hack du 1.5×
Nous avons tenté une autre approche à Paravel : jouer sur les moyennes. Quelle que soit votre expérience, vous avez dû remarquer que les écrans à haute résolution se débrouillent fort bien quand il s’agit d’exploiter au mieux les pixels disponibles ; vous pouvez vous en rendre compte avec cette version expérimentale en @1.5× de notre démo :
| Taille | Petit | Moyen | Grand |
|---|---|---|---|
| @1× | 37kb | 120kb | 406kb |
| @1.5× | 73kb | 248kb | 835kb |
| @2× | 120kb | 406kb | 1057kb |
Si vous n’avez pas d’écran haute résolution, vous pouvez monter le zoom de votre navigateur à 200% pour simuler son rendu des différents niveaux de compression. L’image @1× offre de façon évidente la moins bonne fidélité sur les écrans haute résolution, tandis que l’image @2× a sans nul doute la meilleure. On voit néanmoins que la version @1.5× est presque aussi bonne que la @2×, tout en étant presque 20% plus légère. Que croyez-vous que vos visiteurs remarqueront en priorité, la différence de fidélité de l’image ou la vitesse de chargement de la page ?
Au bout du compte, la pertinence de la technique @1.5× dépend de la situation. Il est certain qu’elle pénalise l’utilisateur doté d’une configuration en @1×, mais vous trouverez peut-être qu’un @1.2× ou @1.3× constitue pour vous un meilleur compromis. Aujourd’hui, on peut considérer cette méthode du « prévoyez un poil plus grand » comme une solution viable pour gagner un peu de qualité sur des images d’importance moyenne, sans pour autant ajouter encore un niveau de complexité à nos clients. Dans les cas où vous ne pouvez pas faire de changements de fond, ce peut être une bonne façon d’améliorer le rendu sans (trop) alourdir la page.
Et surtout : utilisez votre cerveau
Récemment, alors que nous travaillions sur un nouveau design pour notre propre site à Paravel, nous avons appris à remettre en question nos propres règles. Comme nous comptons dans l’équipe l’illustrateur de talent qu’est Reagan Ray, notre site utilise beaucoup de SVG. Mais lorsque nous avons exporté notre image adorée des « Trois Amigos », nous avons réalisé un petit audit et nous nous sommes aperçus que la version SVG faisait 410kb. Comme nous trouvions ça lourd, nous avons exporté une version PNG plutôt grande en 2000x691, mais qui ne pesait plus que 84kb. Pas besoin d’être des Einstein de l’expérience utilisateur pour juger que nos visiteurs vont préférer des images qui se chargent cinq fois plus vite, par conséquent cette image sera en PNG.
Donc, utilisez votre cerveau. J’ai la légère impression que dans nos métiers, on ne le dit pas assez. Mais enfin, vous n’êtes pas idiots, c’est vous qui faites d’Internet ce qu’il est, et vous êtes bien capables de prendre de bonnes décisions. Regardez bien ce que vous faites, pesez le pour et le contre, et vérifiez tout le temps si vos idées préconçues s’avèrent pertinentes.
Et puis soyez souples. Dans ce métier, il n’y a pas de baguette magique pour tout résoudre : les positionnements en absolute, les méthodes, les processus de travail, tout cela peut se démoder d’une semaine à l’autre. Nous l’avons bien vu avec notre propre site : si on s’oblige à toujours appliquer des règles qu’on s’est imposé à nous-mêmes, ce ne sera pas forcément au bénéfice de nos utilisateurs.
Or, l’attention portée à l’utilisateur devrait rester primordiale pour le développement côté client — tout comme pour tout le reste de l’industrie du web, d’ailleurs. Certes, la densité des pixels peut évoluer dans tel ou tel sens, mais gardez en tête ce proverbe : ce qui est bon pour l’utilisateur est toujours bon pour les affaires.
http://alistapart.com/article/mo-pixels-mo-problems