Introduction aux images responsives 9 : image breakpoints

C'est l'avant-dernière partie de notre série au long cours sur les images responsives, et c'est la plus redoutable. Mais comme toujours avec l'excellent Jason Grigsby, très complète et très claire.

Par

Cette partie de notre série sur les images responsives est la plus redoutable. Nous devrons tous nous attaquer à la sélection des points de rupture images et, honnêtement, je n’ai pas de bonnes réponses à vous donner.

Mais tôt ou tard nous serons confrontés au koan des points de rupture images. Alors, autant commencer à les examiner dès maintenant.

koan

Qu’est-ce que les points de rupture images ?

Dans notre mise en page responsive, les points de rupture (breakpoints) correspondent aux dimensions du viewport à partir desquelles nous devons modifier notre mise en page ou réexaminer les fonctionnalités d’une page. Ils sont gérés par nos media queries.

Les points de rupture images sont similaires mais légèrement différents. Lorsque je pense aux points de rupture images, j’essaie toujours de répondre à deux questions :

  • Combien de sources images dois-je fournir pour couvrir le continuum de dimensions pour lesquelles l’image sera utilisée ?
  • Où et quand ces sources doivent-elles être utilisées ?

Les réponses à ces questions conduisent à des points de rupture différents de ceux que nous utilisons pour nos mises en pages. Pour ces dernières, nous suivons l’excellente méthodologie de Stephan Hay : nous redimensionnons la fenêtre du navigateur jusqu’à ce que notre layout devienne moche, et boum ! nous avons notre point de rupture.

À l’exception de la direction artistique, la principale raison pour laquelle nous avons besoin de sources images multiples n’a rien à voir avec le fait qu’elles deviendraient moches. Si nous voulons fournir plusieurs sources images, c’est à cause de préoccupations liées à la performance ou aux densités d’écrans.

Bref, pour les images nous ne pouvons pas nous contenter de réutiliser nos points de rupture de mise en page. Ou, pour le dire autrement, nous pourrions nous en contenter mais nous ne répondrions pas au besoin
les raisons fondamentales pour lesquelles nous voulions des images responsives.

Les points de rupture images pour la direction artistique

Dans le cas d’usage direction artistique, celle-ci nous indiquera le plus souvent le nombre de sources images dont nous avons besoin et quand elles doivent être utilisées.

Si nous revenons à notre exemple du navigateur Nokia, nous pouvons facilement dire à quel moment l’image passe du mode paysage au mode portrait. Quand ce changement se produit, nous savons que nous avons besoin d’une source image différente.

Cependant, cela peut n’être qu’une partie du problème. Que se passe-t-il si une des images couvre un large spectre de dimensions ? Nous pourrions avoir besoin de sources multiples qui ne correspondent pas aux modifications de la direction artistique.

Voyez cet exemple de la page d’accueil de Shopify que nous avons vu dans la 6e partie.

lorsqu’on redimensionne la fenêtre, l’image est recadrée

Ici, l’image ne comporte qu’une seule modification importante — passant d’une image entière à une image recadrée — et pourtant Shopify fournit six sources d’images pour répondre aux questions de taille du fichier et de densité d’affichage.

<picture>  
  <source srcset="[email protected], [email protected] 2x"       
          media="(min-width: 990px)">
  <source srcset="[email protected], [email protected] 2x" 
          media="(min-width: 750px)">
  <img srcset="[email protected], [email protected] 2x" 
       alt="Shopify Merchant, Corrine Anestopoulos">
</picture>  

Bref, le fait de savoir que nous sommes dans le cas d’usage direction artistique nous donne quelques pistes mais ne répond pas à toutes les questions relatives aux points de rupture images.

Les points de rupture de changement de résolution

C’est ici que ça devient compliqué. Au moins, la direction artistique nous donne quelques clés concernant le nombre de points de rupture requis.

Tant que nous redimensionnons les images flexibles, elles auront toujours un bel aspect. Nous ne pouvons pas compter sur elles pour devenir moches et nous dire que nous devions changer de source.

Voyons un exemple de changement de résolution :

différentes tailles d’image de Michelle Obama

Dans cet exemple, nous avons une photo de Michelle Obama dans laquelle l’image affichée dans la page fait 400 × 602px pour la taille de viewport en cours. La plus grande taille d’affichage est 2000 × 3010px. Ce dernier fichier pèse 250K.

Nous pourrions n’avoir qu’une seule image de 2000px et simplement la réduire pour les écrans de petite taille. Le résultat serait esthétiquement satisfaisant, mais cette image serait inutilement lourde et il serait préférable de fournir une version plus petite comme celle de 800 × 1204px qui ne pèse que 73K.

Nous serons tous d’accord pour dire que pour une image affichée à 400 × 602px il est préférable de fournir une image de 800 × 1204px plutôt que la plus grande version.

Mais pourquoi s’arrêter à 800 × 1204px ?

encore plus de tailles d’images de Michelle Obama

Si nous fournissions une autre source d’image qui ferait 600 × 903px, elle ne pèserait que 42K, ce qui nous économiserait 31K (soit 42%) par rapport à l’image de 800 × 1204px.

Très bien. Une économie de 42% est une bonne affaire. Et nous pourrions peut-être continuer ? 500 pixels de large ? 450 ?

plus de tailles d’images de Michelle Obama

Chaque source d’image plus petite nous permet de réduire le poids de l’image. Si nous continuons ainsi, nous arriverons à la taille exacte de l’image affichée dans la page.

Mais voici maintenant la question épineuse relative aux points de rupture images : comment savoir si une source d’image est trop grande pour la taille à laquelle elle est censée être affichée dans la page ?

La réponse est qu’à moins de correspondre exactement à la taille d’affichage, une image sera toujours trop grande. Il sera toujours possible d’optimiser plus encore l’image en en fournissant une plus petite.

Pourquoi ne pas fournir la taille exacte ?

Ici, vous vous demandez peut-être pourquoi nous ne donnons pas tout simplement la taille exacte de l’image telle qu’elle est censée être utilisée dans la page.

Tout d’abord, l’idée des images flexibles dans le design responsif est justement de fournir des images qui se redimensionnent en fonction de la taille du viewport. Si nous fournissions des images à la taille exacte utilisée dans la page, nous devrions sans doute télécharger une image différente à chaque fois que nous changerions la taille ou l’orientation de notre viewport.

Ensuite, il n’est pas réaliste de fournir des images à toutes les tailles imaginables. Oui, nous pouvons redimensionner les images de façon dynamique, mais quand nous le faisons le serveur travaille et cela ralentit le chargement des images vers le navigateur.

C’est pourquoi la plupart des sites mettent en cache les images sur des CDN (content delivery network). Mettre en cache toutes les dimensions d’images possibles seraient extrêmement coûteux.

Enfin, le navigateur ne connaît pas la taille exacte de l’image dans la page au moment où il commence le téléchargement. C’est ce qui nous a amené au nouveau standard des images responsives, rappelons-le !

Quelques façons de choisir les points de rupture images

Comme je l’ai mentionné en commençant, je n’ai pas de solution à 100% pour choisir le nombre de sources d’images nécessaire. Je décrirai à la place les différentes façons d’aborder le problème et d’orienter nos décisions.

À l’impro (a.k.a. avec les points de rupture)

Quelqu’un dans votre équipe dit “hé les gars, de combien de sources images vous pensez qu’on a besoin pour ces photos de produits ?”

Vous réfléchissez un moment et vous répondez “humm… qu’est-ce que vous diriez de 3 ? Petite, moyenne et grande.”

Pas de honte à avoir si vous avez déjà procédé ainsi. Je suis à peu près sûr que tous ceux qui travaillent sur les images responsives ont déjà fait de même.

Peut-être que votre société pense encore que les smartphones, les tablettes et les ordis donnent encore un sens à petit, moyen et grand.

Ou peut-être que vous analysez la taille à laquelle les images seront affichées et vous faites simplement une supposition. Peut-être regardez-vous simplement les principaux points de rupture et vous décidez de faire la même chose pour les images.

Je comprends parfaitement. Et il vaut mieux cela que de fournir une image géante pour tous les viewports.

Mais il serait certainement mieux d’avoir plus de logique derrière nos décisions.

Tester les images représentatives

Si le petit bonheur la chance n’est pas une bonne stratégie, alors intégrons un peu de science dans l’art de choisir les points de rupture images. Nous pouvons regarder quelques images représentatives et nous faire une idée du nombre de points de ruptures nécessaire.

Le plus difficile ici est de choisir les images représentatives, et même de déterminer s’il y en a.

Pour certains sites, les photos ont peut-être toutes un style dicté par la marque. Dans ce cas, il est facile de trouver des images représentatives. Prenez-en quelques-unes, redimensionnez-les et sauvegardez-les à des tailles allant de la plus grande à la plus petite jusqu’à ce que vous pensiez que vous avez une couverture décente.

Bien sûr, si votre site comporte une grande diversité de styles d’images, trouver des images représentatives s’avère quasiment impossible.

Utilisation de la mémoire

Cet été, Tim Kadlec a fait une présentation sur le traitement de l’image dans les smartphones. Dans cette présentation, il s’est intéressé à l’utilisation de la mémoire par les images flexibles dans les designs responsifs.

Ce que Tim a montré c’est que plus une image est grande, plus l’impact de son redimensionnement s’accroît.

redimension de deux carrés

Dans l’exemple ci-dessus, on voit que le fait de réduire de 50 pixels (en hauteur et en largeur) une image de 600 × 600px correspond à une perte de 230.000 bytes alors que la même réduction sur une image de 200 × 200px correspond à une perte de 70.000 bytes.

Ceci nous en dit un peu sur la manière dont nous devrions choisir nos points de rupture. Plutôt que d’espacer régulièrement nos points de rupture, nous devrions avoir plus de points de rupture à mesure que les images s’agrandissent.

image

Malheureusement, cela ne nous dit pas où ils devraient se trouver.

Se baser sur les budgets de performance

Pourquoi ne pas appliquer l’idée de budget de performance (performance budget) aux images responsives ? Qu’est-ce que ça donnerait ?

Pour commencer, nous pourrions définir un budget des bytes superflus que le navigateur serait autorisé à charger au-dessus du strict nécessaire pour correspondre à la taille de l’image dans la page.

Par exemple, admettons que nous ayons décidé un budget de 20K pour chaque image responsive. Cela signifie que nous devrions nous assurer que les diverses sources définies pour notre image ne soient jamais à plus de 20K d’écart.

Ce faisant, nous allons nous rendre compte que le nombre de points de rupture images change radicalement en fonction de la diversité visuelle des images et de la compression utilisée.

Time Square, 8 points de rupture images

Time Square

Cette image contient une grande diversité visuelle. Les variations de couleurs et de textures ont pour conséquence que la compression jpeg lossy ne peut pas être appliquée sauvagement sans endommager la qualité de l’image.

C’est pourquoi nous avons huit points de rupture images — séparés par intervalles de 20K — entre la plus petite taille (320×213) et la plus grande (990×660).

Breakpoint #LargeurHauteurPoids Fichier
1320213 25K
2453302 44K
3579386 65K
4687458 85K
5786524104K
6885590124K
7975650142K
8990660151K

Lever du jour à Kettering

le matin à Kettering

Contrairement à l’image de Time Square, cette image contient beaucoup de couleurs similaires et n’est pas très variée. La compression jpeg peut être beaucoup plus efficace.

Sur une image mieux compressée, notre budget de 20K nous permet de faire beaucoup mieux. Pour cette image, nous n’avons besoin que de trois points de rupture images pour couvrir toute l’étendue des tailles auxquelles l’image sera utilisée.

Breakpoint #LargeurHauteurPoids Fichier
13202139.0K
2731487 29K
3990660 40K

Logo Microsoft — 1 point de rupture

logo Microsoft en noir et blanc

C’est un simple fichier PNG8. À sa taille maximale (990×660), il ne pèse que 13K. Il entre donc dans notre budget 20K sans aucune modification.

Breakpoint #LargeurHauteurPoids Fichier
199066013K

Jetez un coup d’oeil à cette page pour voir quelques autres cas de figure et voyez comme le nombre de points de rupture varie.

Maintenant, je ne suis pas en train de suggérer qu’on devrait déterminer les points de rupture image par image. Mais je pense qu’à l’avenir on pourra indiquer à notre serveur un budget de performance de 20K pour nos images responsives et laisser le serveur calculer le nombre d’images sources, pour chaque image.

J’ai écrit plus en détail sur le sujet des budgets de performance pour les images responsives, si vous mettez en oeuvre cette approche, faites-le moi savoir.

Déterminer les points de rupture à partir des requêtes les plus fréquentes

Lors d’une récente réunion du Responsive Images Community Group (RICG), Yoav Weiss et Ilya Grigorik ont discuté des différentes manières de choisir les points de rupture en fonction des tailles d’images les plus fréquemment demandées.

Pour Yoav, qui travaille chez Akamai, et pour Ilya, qui travaille chez Google, l’un des problèmes liés aux sources d’images multiples est le stockage de ces sources sur les serveurs périphériques (les CDN), généralement plus limité et plus coûteux.

Non seulement des sociétés comme Akamai et Google veulent diminuer le nombre d’images stockées sur les périphériques, mais l’idée même de ces CDN étant de réduire le temps de chargement d’une page, s’ils peuvent mettre en cache les tailles d’images les plus fréquemment demandées, ils donneront la meilleure expérience utilisateur à la plupart de leurs utilisateurs.

En s’appuyant sur la nouvelle fonctionnalité HTTP Client Hints défendue par Ilya, les serveurs pourraient devenir très intelligents dans leur façon de stocker les images dans les CDN et ils pourraient le faire d’une manière telle qu’elle ne demanderait aucun travail de décision du côté des designers et des développeurs.

Ce n’est pas aux humains de le faire

Je crois vraiment que dans quelques années personne ne parlera plus de la façon de choisir les points de rupture images responsifs, parce que personne ne le fera manuellement.

Certes, nous prendrons peut-être encore certaines décisions artistiques, mais même dans ce cas d’usage nous ne le ferons sans doute pas pour chaque image. Nous nous occuperons de ce qui requiert notre intervention et le reste sera laissé aux services automatisés de traitement d’images.

Le choix manuel des images à partir d’un budget de performance ou en fonction de la fréquence de requête peut apporter beaucoup, mais aucune de ces solutions n’est tenable si elle n’est pas automatisée. À l’avenir, notre workflow typique sera d’uploader nos images dans la meilleure qualité possible et de laisser notre CMS ou un système de traitement d’images s’en occuper sans que nous ayons à nous en soucier.

Partie #10

Cette série devait comprendre 9 parties, mais quand on commence à parler d’images responsives il y a toujours de nouvelles choses à dire. Dans la 10e partie de cette série, nous donnerons quelques ressources essentielles et nous verrons ce que l’avenir nous réserve.

La liste des articles de cette série (en cours) :

  1. Définitions
  2. Img requise
  3. Densité d’affichage srcset
  4. Descripteurs de largeur srcset
  5. Dimensions
  6. Élément picture
  7. Type
  8. Images responsives CSS
  9. Points de rupture image
  10. Conclusion

Intéressé par le Responsive Web Design ? Retrouvez une liste des meilleurs articles et ressources du web.

Articles sur les mêmes thèmes dans la Cascade :

Images responsives, picture et srcset
Images responsives : cas d’utilisation et snippets


original paru le dans Cloud Four Blog.

Sur l’auteur : passe bien trop de temps à réfléchir sur l’univers mobile. Il a fondé Mobile Portland, une organisation à but non lucratif qui se consacre à éduquer, promouvoir et soutenir la communauté mobile de Portland. Co-fondateur de Cloud Four, il est aussi co-auteur de Head First Mobile Web et il donne de nombreuses conférences sur la technologie et la stratégie mobiles. On peut le suivre sur Twitter, Facebook, Google+.

Traduit avec l’aimable autorisation de Cloud Four Blog et de l’auteur.
Copyright Cloud Four Blog © 2015.