InMy.Live

Dans The Cost of JavaScript, Addy fait un très bon point : 200 Ko de JavaScript sont plus “chers” que 200 Ko d’images, car le navigateur doit faire plus de travail pour utiliser du code que des images. De l’article :

Une image JPEG doit être décodée, pixellisée et peinte à l’écran. Un bundle JavaScript doit être téléchargé puis analysé, compilé, exécuté – et il y a un certain nombre d’autres étapes qu’un moteur doit accomplir. Sachez simplement que ces coûts ne sont pas tout à fait équivalents.

C’est encore très vrai, mais c’est un peu moins significatif à ce moment précis de l’histoire.

Avec une pandémie qui balaie le monde, j’ai constaté que mon Internet était devenu assez agité. Heureusement, parce que les ingénieurs en fiabilité du site sont à la fois brillants et infatigables, la majeure partie d’Internet est toujours opérationnelle, mais il se passe certainement quelque chose : j’ai une connexion de 100 Mbps, mais cela ressemble plus à de la 3G pour le moment.

Cela décale un peu le calcul. Nos appareils peuvent toujours analyser et compiler javascript à la même vitesse qu’il y a quelques semaines, mais les vitesses du réseau sont devenues plus lentes. Donc, le nombre brut de bits sur le fil est super important en ce moment !

Et les sites ont généralement chemin plus de 200 Ko d’images ; il n’est pas rare qu’une page ait plusieurs mégaoctets d’images. De nombreux développeurs (moi y compris !) ont tendance à ne pas trop penser à la taille des médias.

Heureusement, il y a de jolis fruits à portée de main ! Dans ce didacticiel, nous verrons comment tirer parti des formats d’image “nouvelle génération” tels que WebP. Ces images sont souvent 2-3x plus petit que les formats hérités que nous connaissons et aimons (jpg, png). Cela peut faire une énorme différence.

Il existe trois formats que nous pouvons utiliser :

• JPEG 2000 — une amélioration itérative des jpg. Développé en 1997 principalement pour une utilisation dans le cinéma et l’imagerie médicale. Permet de compresser davantage les images, avec moins d’artefacts.

• JPEG XR — Un cousin de jpeg2000développé par Microsoft en 2009

• Webp – un format développé pour le Web par Google en 2010, axé sur l’utilisation de techniques d’optimisation avancées pour réduire la taille des fichiers. Prend en charge la transparence et même l’animation.

Nous passerons la majeure partie de notre temps aujourd’hui à parler de webpmais nous reviendrons sur les cousins ​​jpeg lorsque nous discuterons de la compatibilité des navigateurs.

Il y a quelques mois, j’ai utilisé cette image dans un post :

J’ai fait quelques expériences, en utilisant les deux jpg et png pour l’image source. Je les ai optimisés à l’aide d’imagemin, pour voir à quel point ces formats “rétro” pouvaient être bons.

Les résultats sont assez spectaculaires :

Je l’ai testé sur de nombreuses images, et il produit presque toujours des fichiers 30 à 70 % plus petits que même les images optimisées !

.webp bénéficie d’un soutien dans la plupart navigateurs :

De manière critique, il nous manque Safari et Internet Explorer.

Qu’en est-il du JPEG 2000 ?

D’accord, nous avons donc rempli Safari, mais il y a toujours ce satané Internet Explorer…

Nous avons frappé caniuse bingo! Avec ces 3 formats d’image, nous avons une couverture parfaite sur l’ensemble du spectre des navigateurs.*

Regardons comment nous sélectionnons et choisissons différents formats pour différents navigateurs

HTML a deux éléments média d’image : la pop-star internationale imget l’artiste hipster de niche picture.*

picture est un ajout beaucoup plus récent au langage. Son objectif principal est de nous permettre de charger différentes sources en fonction de la résolution ou de la prise en charge d’un format d’image donné.

Voici à quoi ça ressemble :

Le picture balise prend en charge un tas de source enfants. Le navigateur analyse le source éléments en séquence, en recherchant le premier qu’il peut utiliser en fonction de la type. Quand il en trouve un, il détermine où vit l’image via srcsetet l’échange dans le imgc’est src

srcset peut faire beaucoup de choses compliquées, mais heureusement pour notre cas d’utilisation, nous pouvons le traiter de la même manière que src. Essentiellement, source est config, et il branche la valeur correspondante dans le img.

Dans Chrome, par exemple, nous nous retrouvons avec quelque chose de plus ou moins équivalent à ceci :

Cette cascade de sources signifie qu’il y en aura une sur chaque navigateur : la plupart des navigateurs utiliseront webpSafari utilisera jp2et IE utilisera jxr.

L’extrait ci-dessus excelle dans sa capacité à faire correspondre tous les navigateurs possibles avec un format d’image moderne de “nouvelle génération”. Mais il suppose que ces images existent dans ces formats.

Si nous créons ces images à la main, c’est beaucoup de travail manuel. Et si nous les générons automatiquement, cela peut allonger considérablement notre temps de construction ; le traitement d’image est notoirement lent lorsqu’il est effectué à grande échelle.

Sur mon propre blog, qui reçoit très peu de trafic Internet Explorer*j’ai opté pour une solution plus paresseuse :

Je sers les gentils et les petits webp aux navigateurs qui le supportent (Chrome, Firefox, Edge), et se rabattre sur un legacy jpg pour les navigateurs qui ne le font pas (IE, Safari).

Pour moi, c’est un exemple de amélioration progressive. Tout fonctionne toujours sur les anciens navigateurs, mais les images seront un peu plus lentes à charger. C’est un compromis avec lequel je suis d’accord.

(J’espère qu’Apple montera bientôt dans ce train ! 🤞🏻)

Les outils de développement du navigateur pense toujours que l’image a quoi que ce soit src vous l’avez donné au départ. Si vous l’inspectez dans le volet des éléments, vous verrez qu’il utilise un .jpg.

Pour vérifier si cela fonctionne réellement, la meilleure astuce que j’ai trouvée est de faire un clic droit et “Enregistrer sous…”. Sur Chrome, vous devriez obtenir un format de fichier “Google WebP”, alors que sur Safari ou IE, vous devriez obtenir un format “JPEG”.

Vous pouvez également consulter l’onglet réseau pour voir lequel a été réellement téléchargé.

Google a créé une suite d’outils pour nous aider à travailler avec webp des dossiers. L’un de ces outils est cwebp, qui nous permet de convertir d’autres formats d’image en webp.

Si vous êtes sur MacOS, vous pouvez installer la suite avec Homebrew :

Sur d’autres plates-formes, je pense que vous devrez télécharger le package libwebp approprié à partir de leur référentiel.

une fois installé, vous pouvez l’utiliser comme ceci :

• -q 80 est un drapeau pour définir la “qualité”, de 1 (la pire) à 100 (la meilleure). Vous pouvez tester différentes valeurs. J’ai trouvé que 70-80 est le sweet spot.

• cereal.png est le chemin d’accès au fichier d’entrée que vous souhaitez convertir.

• -o cereal.webp est le chemin de sortie.

Un composant est un excellent moyen d’abstraire une partie du funky avec le <picture> élément. Voici ce que j’ai utilisé, pour un effet glorieux :

On peut utiliser ImgWithFallback très similaire à la façon dont nous utiliserions un img étiqueter:

Si tu utilises styled-components ou Emotion, vous avez peut-être l’habitude d’emballer les images dans un wrapper stylé :

Heureusement, cela fonctionne toujours avec notre ImgWithFallback composant. Nous pouvons l’envelopper comme n’importe quel autre composant :

Si vous développez avec Gatsby, le gatsby-image package fait déjà un tas d’optimisations prêtes à l’emploi, y compris la conversion en webp (bien que vous deviez vous y inscrire).

Gatsby Image n’est pas destiné à remplacer immédiatement img; il peut y avoir un peu plus de friction à utiliser, mais il est également livré avec un parcelle de tours de magie supplémentaires pour votre problème.

Consultez la documentation pour plus d’informations.

Le seul véritable inconvénient que j’ai trouvé jusqu’à présent est que webp est un format ennuyeux avec lequel travailler en tant qu’utilisateur.

La plupart des logiciels de bureau ne le prennent pas encore en charge. Je ne peux pas l’ouvrir dans Preview sur MacOS, par exemple. Cela signifie que si je clique avec le bouton droit de la souris et “Enregistrer sous…” un webp image, je ne pourrai pas la voir !

Convertir un webp à un jpg est relativement indolore, et une recherche sur Google révèle de nombreux fournisseurs en ligne qui le feront gratuitement. Mais encore, c’est un peu de friction supplémentaire. Si votre site/application encourage les utilisateurs à télécharger des images, vous ne voudrez peut-être pas faire ce changement.

Je suis assez content d’avoir réduit la taille des images sur mon blog d’environ 50 %. En plus des avantages pour l’expérience utilisateur à un moment critique, je m’attends également à ce que cela me fasse économiser de l’argent en termes de bande passante.

Bien sûr, il ne semble pas pratique de convertir manuellement chaque image que j’utilise pour webp. J’étudie déjà comment je peux générer ces images automatiquement à partir de la source jpg et png des dossiers. Idéalement, ce n’est pas quelque chose auquel je devrais avoir à penser, cela devrait se produire automatiquement lorsque je crée mon site. Attendez-vous à voir quelque chose à ce sujet bientôt =)