Le , par Julien Wilhelm - Écoconception
Temps de lecture estimé : 6 minutes.
Vous l’avez peut-être vu passer : Google est en train de faire peau neuve. Et avec lui, il est fort probable qu’une fois de plus nos interfaces utilisateurs rentrent dans le rang pour observer la tendance du géant de la tech.
« Non, mais… C’est qu’un logo, hein ! »
Oui et non.
- Google, c’est aussi une myriade de produits et de services. Et comme il est dans l’intérêt de l’image de marque de suivre les règles dictées par le logo mère, attendez-vous à en manger, du dégradé.
- Google, c’est aussi Android. À l’échelle mondiale, sur mobile, on parle de 72 % de parts de marché. Quelqu’un a parlé de domination ?
- Enfin, Google, c’est aussi du design system. « Material Design », ça vous rappelle quelque chose ? Une nouvelle mouture est sur le point d’être révélée et s’il est encore un peu tôt pour se prononcer quant à l’usage des dégradés, flous et autres ombres, le changement est en marche.
C’en est donc probablement bientôt terminé du flat-design (en tout cas, tel que nous l’exploitions jusqu’alors).
« Bon, et alors, un peu de changement, c’est pas si mal, hein ? »
Justement : découvrons-le ensemble.
État des lieux, preuves à l’appui
En ce qui me concerne, ce nouveau logo m’a immédiatement alarmé.
Je m’appuie ici sur une série d’expérimentations que j’ai pu mener avec l’outillage habituel (SVGO pour l’optimisation SVG, TinyPNG pour l’optimisation PNG, cWebp pour la compression vers WebP). Les résultats sont visibles sur notre portail pédagogique de formation à l’écoconception de services numériques. Profitez-en !
1. Comparatif avant / après au format vectoriel
| Item | Année | Format | Poids |
|---|---|---|---|
| Item n°1 | 2015 | SVG | 712 octects |
| Item n°2 | 2025 | SVG | 2,2 Ko |
Dans ce premier tableau, le résultat est sans appel : dans un format vectoriel optimisé pour le Web (SVG), la nouvelle version du logo de Google est 67 % plus lourde que l’ancienne. Est-ce un problème ? C’est ce que nous verrons un peu plus loin.
2. Comparatif avant / après au format matriciel, avec PNG
| Item | Année | Format | Dimensions | Poids |
|---|---|---|---|---|
| Item n°1 | 2015 | PNG | 48 x 48 pixels | 1 Ko |
| Item n°2 | 2025 | PNG | 48 x 48 pixels | 1,7 Ko |
| Item n°3 | 2015 | PNG | 96 x 96 pixels | 1,7 Ko |
| Item n°4 | 2025 | PNG | 96 x 96 pixels | 2,5 Ko |
| Item n°5 | 2015 | PNG | 192 x 192 pixels | 3 Ko |
| Item n°6 | 2025 | PNG | 192 x 192 pixels | 4,2 Ko |
| Item n°7 | 2015 | PNG | 300 x 300 pixels | 4,2 Ko |
| Item n°8 | 2025 | PNG | 300 x 300 pixels | 6,4 Ko |
| Item n°9 | 2015 | PNG | 600 x 600 pixels | 8 Ko |
| Item n°10 | 2025 | PNG | 600 x 600 pixels | 13,9 Ko |
Dans ce second tableau, le constat est à nouveau évident : quelles que soient les dimensions retenues pour l’export, la version 2025 du logo de Google produit des images PNG se révélant systématiquement plus lourdes qu’avec la version 2015.
Et c’est plutôt logique : l’optimisation d’un PNG passe par la réduction du nombre de couleurs enregistrées dans la palette du fichier. Là où les aplats profitent de ruptures franches, les dégradés reposent sur quantité de couleurs intermédiaires qu’il faut embarquer pour garantir la qualité du résultat.
Plus de couleurs = plus d’informations = plus de poids en sortie.
CQFD.
3. Comparatif avant / après au format matriciel, avec WebP
| Item | Année | Format | Dimensions | Poids |
|---|---|---|---|---|
| Item n°1 | 2015 | WebP | 48 x 48 pixels | 928 octets |
| Item n°2 | 2025 | WebP | 48 x 48 pixels | 890 octets |
| Item n°3 | 2015 | WebP | 96 x 96 pixels | 1,8 Ko |
| Item n°4 | 2025 | WebP | 96 x 96 pixels | 1,7 Ko |
| Item n°5 | 2015 | WebP | 192 x 192 pixels | 3,5 Ko |
| Item n°6 | 2025 | WebP | 192 x 192 pixels | 3,4 Ko |
| Item n°7 | 2015 | WebP | 300 x 300 pixels | 5,5 Ko |
| Item n°8 | 2025 | WebP | 300 x 300 pixels | 5,5 Ko |
| Item n°9 | 2015 | WebP | 600 x 600 pixels | 11 Ko |
| Item n°10 | 2025 | WebP | 600 x 600 pixels | 11,1 Ko |
Ce dernier tableau change la donne : selon les dimensions retenues pour l’export, la version 2025 du logo de Google produit des images WebP se révélant d’abord plus légères qu’avec la version 2015, puis plus lourdes, à mesure que l’on monte en pixels.
Ici, je compresse les logos Google vers WebP avec un facteur de qualité à 75 %, une moyenne passe-partout pour l’automatisation à grande échelle (peu de risques d’en faire trop, ou trop peu). En compressant davantage, il y a fort à parier que l’avantage aurait encore plus été à WebP, le rendu visuel restant toutefois à valider. Mais c’est la tendance qui est intéressante ici : avec WebP, nous sommes bien capables de générer un logo avec dégradés plus léger qu’avec les aplats.
Point de magie cependant : s’agissant de compression avec pertes, WebP profite de la saturation des couleurs, qui est moins souvent prononcée avec les dégradés qu’elle ne l’est avec les aplats.
« Du coup, c’est bon : il suffit de faire du WebP partout, tout le temps ! »
Pas si binaire, à mon avis !
Impact probable d’un petit changement
Qu’il s’agisse de Web ou de mobile, nous allons pouvoir rencontrer 3 cas d’usage :
- Logos
- Éléments d’interface
- Images de contenu
Les logos et éléments d’interface sont les plus concernés par le changement opéré par Google. Pour ceux-là, la tendance est au vectoriel depuis quelques années. À cause des écrans retina, nous sommes en effet contraints de proposer des images matricielles faisant le double des dimensions rendues à l’écran pour garantir leur netteté. À titre d’exemple, une image PNG ou WebP de 48 x 48 pixels, et rendue à 48 x 48 pixels à l’écran, sera nette sur un écran d’ordinateur portable moyen (DPR1), quand elle apparaîtra floue sur un écran retina (DPR2). La solution de facilité pour les équipes de développement est, souvent et à raison, d’exploiter du vectoriel (et donc, SVG).
Comme il y a peu de chance de voir disparaître les écrans retina, deux futurs possibles si le nouveau design de Google tend à ce propager tel que je le pressens :
- Déployer des vectoriels, by design, plus lourds qu’auparavant.
- Multiplier les variantes matricielles pour assurer la netteté selon DPR de l’écran de l’utilisateur.
Aucune des deux solutions n’est préférable à l’autre. Et puisque la première reste la plus facile à mettre en production, nous pouvons prochainement nous attendre à voir grimper le poids de nos interfaces utilisateurs. Un bien mauvais signal pour celles et ceux qui cherchent à faire mieux avec moins.
J’espère donc me tromper.