Commentaires des personnes interrogées sur différentes techniques d'optimisation des images
Cet article liste les commentaires libres que l'équipe Google Web DevRel a reçus lors de son enquête sur les techniques d'optimisation des images de l'été 2019. Les réponses ont été sollicitées via Web Fundamentals et @ChromiumDev. L'objectif de l'enquête était de découvrir pourquoi la plupart des sites ne suivent pas les bonnes pratiques d'optimisation des images, même s'ils semblent être un moyen relativement simple d'améliorer les performances. Les données de réponse ne sont pas listées ici, car la méthodologie de l'enquête présentait des défauts.
Audience
- Si vous êtes développeur Web, cet article peut vous aider à découvrir de nouvelles techniques d'optimisation des images ou à comprendre comment d'autres développeurs Web ont résolu un problème auquel vous êtes confronté, ainsi que les coûts, les avantages et les limites de chaque technique.
- Si vous êtes un fournisseur de services d'images ou de CDN d'images, cet article peut vous aider à trouver de nouvelles opportunités de marché.
- Si vous êtes un développeur de framework, d'outil de compilation ou de CMS, cet article peut vous donner des idées de nouvelles fonctionnalités à implémenter.
Commentaires
WebP
- "J'aime bien le format WebP, mais il n'est pas encore tout à fait prêt. De plus, notre WordPress n'est pas compatible avec WebP. Photoshop, l'une des applications de retouche photo les plus populaires, n'est pas non plus compatible avec WebP par défaut. Nous ne pouvons donc pas nous appuyer sur des applications ou des services tiers pour la compression des images."
- "Rendre WebP utilisable sur Safari."
- "J'aimerais beaucoup utiliser WebP si je pouvais exporter des images dans ce format depuis Photoshop/Figma/Sketch et si tous les navigateurs le prenaient en charge." [Note: Sketch does support WebP]
- "Une solution de mise en forme de nouvelle génération serait formidable."
- "Arrêtez de pousser autant le format WebP alors que la compatibilité des navigateurs est faible, et tenez compte de la nécessité d'utiliser le format PNG au lieu du JPEG pour les captures d'écran."
- "Google Docs n'est pas compatible avec WebP."
- "Nous utiliserions exclusivement le format WebP, mais nous nous inquiétons de la compatibilité avec les navigateurs."
- "Corrigez d'abord la compatibilité des navigateurs et mettez à jour les anciens navigateurs ou ajoutez des correctifs pour les anciens navigateurs. Les utilisateurs seront alors plus enclins à adopter de nouveaux types d'images comme WebP…"
- "Encouragez les développeurs de plug-ins/thèmes à envisager de prendre en charge le format WebP et d'autres types d'images de nouvelle génération, afin que les non-développeurs n'aient pas à s'en soucier."
Images SVG et vectorielles
- "Si possible, j'utilise des SVG (animés). gatsby-image a résolu une grande partie de ce problème. Mais quand on regarde ce qu'ils ont fait, il est complètement irréaliste qu'un site Web normal doive créer quelque chose comme ça pour que les images fonctionnent correctement. Le navigateur devrait assumer davantage cette responsabilité."
- "Serait-il possible de documenter la création d'animations SVG avec lottie.js ?"
- "Nous essayons d'utiliser des images JPEG de grande résolution et de petite taille sur notre site Web la plupart du temps pour éviter les temps de chargement. Nous veillons également à utiliser des SVG lorsque cela est nécessaire pour garantir la qualité du responsive design."
- "Nous essayons d'utiliser des graphiques vectoriels optimisés pour tout, sauf pour les images, si possible."
Autres formats d'image
- "Nous [devons] mieux informer les gens pour qu'ils arrêtent d'utiliser le format GIF."
Chargement différé
- "Veuillez garder l'utilisateur à l'esprit lorsque vous envisagez des fonctionnalités telles que le chargement différé, car cela peut être agaçant pour de nombreuses personnes."
- "Faites en sorte que l'attribut de chargement différé fonctionne avec background-image, s'il vous plaît."
- "Les frameworks devraient mieux traiter les assets dès le départ."
- "Nous avons abandonné le chargement différé il y a longtemps. Les utilisateurs signalent que des millions d'images et de sites "NE CHARGENT PAS". C'est ainsi que notre équipe a résumé la situation. Il est difficile pour les utilisateurs non techniques de décrire les problèmes."
- "Je souhaite mieux comprendre comment utiliser l'API Intersection Observer pour le chargement différé plutôt que les techniques traditionnelles."
- "Celui-ci fonctionne bien pour moi : pwafire.org/developer/codelabs/progressive-loading."
Image de fond
- "Je charge généralement les images en tant qu'arrière-plans en CSS."
- "La balise
<img>est problématique et il est difficile d'en contrôler les détails de manière précise, en particulier avec le contenu envoyé par les utilisateurs. Nous utilisons beaucoup plus souvent<div>et le style background-image, car cela nous permet d'utiliser background-size et background-position, et d'empêcher l'enregistrement de l'image en effectuant un clic droit.
Transparence
- "Nous sommes en 2019. Comment se fait-il que les JPG ne gèrent toujours pas la transparence alpha ?"
- "Je n'utilise vraiment les PNG pour les photos que lorsque j'ai besoin d'un arrière-plan transparent."
Espaces réservés d'image de mauvaise qualité (LQIP)
- "Nous utilisons les LQIP, qui sont une excellente technique pour maintenir l'engagement des visiteurs sans charger d'images de haute qualité trop tôt."
Performances
- "Nous avons récemment rencontré un problème de performances avec les images. Lorsqu'un utilisateur fait défiler notre site, nous affichons les 60 fiches suivantes, qui incluent une miniature. En raison de la limite de six connexions sur le même domaine, les vignettes étaient bloquées, tout comme la requête AJAX suivante visant à obtenir les 60 fiches suivantes si un utilisateur continuait à faire défiler la page."
- "Nous aimerions utiliser HTTP/2, mais la plupart de nos clients utilisent IE11. Nous envisageons donc de partitionner le domaine ou de charger les requêtes de données AJAX JSON à partir d'un autre domaine."
Taille
- "Désolé pour intrinsicsize ; l'utilisation de height/width me semble préférable."
- "Je cherche un moyen de générer moins de tailles. Actuellement, il y en a environ 12."
- "Le redimensionnement dynamique des images est très difficile et impossible sans JS."
- "Un outil comme responsivebreakpoints.com est idéal pour web.dev :)"
Images de haute qualité et haute résolution
- "Comment télécharger des images compressées sans perdre en qualité PPP ?"
- "Nous sommes une entreprise de gestion de documents. Nos applications gèrent des MILLIONS d'images numérisées en haute résolution, généralement au format TIFF ou PDF."
- "C'est compliqué. Les fichiers d'image haute résolution sont nécessaires pour le format d'impression. Ils doivent être optimisés pour le Web. Il est fastidieux de réduire la taille des images pour le Web, mais il est impossible de publier des images destinées à l'impression si les auteurs ne fournissent que des fichiers légers. Nous finissons par donner des messages contradictoires sur les exigences de soumission de manuscrits avec des illustrations. Nous nous retrouvons alors avec des workflows complexes pour traiter ces documents."
Capacité du navigateur
- "La fonctionnalité de recadrage automatique de la source responsive à partir du navigateur serait très utile, car recadrer toutes les images en quatre tailles et écrire tout le balisage prend du temps. Si nous pouvions importer une seule grande photo et écrire une balise d'image simple pour que les navigateurs créent automatiquement les multiples attributs src, ce serait une fonctionnalité gagnante."
- "Personnellement, j'ai du mal à éviter les réorganisations de page lorsque la largeur de l'image est définie par CSS pour les images responsives (max-width: 100%; height auto ou height: width: 100%; height auto), en particulier en combinaison avec la direction artistique des images adaptatives/balise picture. La meilleure façon d'éviter cela semble être d'utiliser l'astuce de la marge intérieure négative pour un ratio d'image fixe, puis de positionner l'image dans cette zone de ratio. Une meilleure compatibilité avec les navigateurs et une meilleure gestion des images responsives seraient d'une grande aide. "
- "Veuillez désactiver la lecture automatique des GIF en ne récupérant que la première image."
CDN et services d'images
- Google devrait fournir un CDN sans frais comme Cloudflare.
- "Il serait peut-être utile de disposer de plus d'outils pour configurer le scaling dynamique et les CDN avec différents fournisseurs."
- "Une seule image surdimensionnée et surcompressée est une solution très correcte, sans coût de production supplémentaire. Vous avez besoin d'images d'environ 1 000 pixels de large pour les mobiles (largeur de rendu de 500 pixels), ce qui correspond également à la taille requise pour les grands écrans/écrans d'ordinateur non Retina. Je pense que les CDN de redimensionnement d'images sont une très mauvaise solution, même si je les ai utilisés par le passé. Le CMS doit gérer le redimensionnement. Si cela est trop complexe à configurer, une solution unique est un bon compromis (pour l'instant)."
- "Cloudflare redimensionne automatiquement nos images pour qu'elles s'adaptent au mieux à l'écran de l'utilisateur. Nous pouvons ainsi réduire le temps de chargement, car les images sont chargées en fonction de l'écran de l'utilisateur. Par exemple, si un utilisateur est sur un téléphone, l'arrière-plan ne se chargera pas au format ordinateur."
- "Cloudflare s'en charge en arrière-plan sans que nous ayons à faire quoi que ce soit, si ce n'est cocher une case dans notre panneau de configuration."
- "Je tiens à répéter que la seule raison pour laquelle je peux utiliser srcset, etc. est la facilité d'utilisation de Cloudinary. Mais Cloudinary devient très vite cher. C'est un gros point noir dans l'expérience de développement."
- "Nous avons besoin d'un moyen de recadrer automatiquement les images de manière intelligente pour qu'elles puissent s'adapter à différents formats dans différents contextes."
- "J'utilise également des images d'autres fournisseurs comme Unsplash, où le contrôle de la résolution, de la qualité et de la compression est très limité."
CMS, plate-forme et framework
- "Je ne sais toujours pas comment utiliser au mieux les images lorsque je crée un site à l'aide d'un CMS. Les auteurs ont tendance à configurer des images de différentes dimensions et s'attendent à ce qu'elles ne soient pas réduites ni mises à l'échelle. Je ne sais pas si je peux définir une largeur ou une hauteur maximale pour les images."
- "J'utilise gatsby-image pour mes derniers projets et je ne l'ai jamais regretté."
- "Les images sont souvent la partie la plus difficile, car elles sont placées dans le CMS par l'utilisateur final. Elles peuvent être de n'importe quelle taille et de n'importe quel format. Parfois, l'image d'origine n'est pas disponible dans le format et les dimensions idéaux."
- "Les images sont difficiles à gérer, car notre système est en libre-service. Il est difficile d'ajouter des contrôles, sauf si les choses se font automatiquement sans affecter la résolution. De plus, les images ne s'affichent pas correctement sur mobile par rapport à l'ordinateur."
- "J'aide les utilisateurs à optimiser leurs sites (WordPress). Les principaux problèmes que j'ai constatés pour les images sont les suivants : nécessité de dépendre d'un CDN ou de plug-ins pour créer des images WebP. srcset/picture doit être codé correctement par les développeurs de thèmes. La plupart des plug-ins de chargement différé se chargent lentement, ce qui nuit à l'expérience utilisateur. Les images de fond sont difficiles à charger de manière différée."
Rapport coûts/avantages
- "Les nouvelles pratiques sont efficaces, mais elles augmentent le temps de développement des sites."
- "De nombreuses entreprises du classement Fortune 500 ont mis du temps à adopter les nouvelles normes telles que srcset et WebP. Face à ce constat, de nombreuses entreprises ont résisté au changement, considérant qu'il s'agissait d'un coût de développement inutile pour les sites Web actuels. Les gains de performances ne sont pas largement discutés ni signalés par l'utilisateur final (UX). Au contraire, cela rend l'enregistrement d'images depuis le Web un peu plus difficile."
- "Créer et gérer plusieurs tailles et versions coûte cher."
- "Ils prennent beaucoup de place sur notre serveur."
SEO
- "Il est difficile de trouver un équilibre entre une qualité d'image acceptable et la taille du fichier. D'un côté, je veux un chargement rapide pour améliorer le SEO, mais de l'autre, des images de mauvaise qualité nuisent à l'UI/UX."
Le rôle des images sur le Web
- "Il y en a trop sur le Web. Arrêtez d'utiliser des images inutiles qui n'améliorent pas le contenu écrit."
- "Vous souvenez-vous de l'époque où le Web n'avait pas d'images et où nous partagions des selfies en art ASCII ?"
Outils, conseils, normes et bonnes pratiques : frustrations et demandes
- [Un participant a rédigé un article de blog en réponse à cette enquête]
- "Les exigences semblent changer constamment. En tant que développeur Web, c'est extrêmement frustrant, car l'enregistrement des images prend beaucoup de temps. Nous optimisons au mieux, nous vérifions le site, puis, des mois plus tard, Google décide que les images pourraient être encore plus compressées ou qu'elles doivent être dans un autre format. Cela nous empêche de fournir à notre client la meilleure solution possible qui dure, et cela crée plutôt une entreprise coûteuse pour lui et pour nous. Certains de nos clients, qui sont de petites entreprises, n'ont tout simplement pas le budget nécessaire pour que nous continuions à corriger les images et à les enregistrer à nouveau pour respecter les exigences. Nous n'avons pas le budget nécessaire pour effectuer ce travail dans le cadre de leurs packages de gestion. Écrire le code permettant d'appeler différentes tailles d'image pour différents appareils prend également du temps. Il serait formidable de mettre au point un système d'enregistrement des images qui soit cohérent sur une plus longue période."
- "Oui, je pense que vous n'avez pas bien compris la recommandation "Limiter le nombre de requêtes et la taille des fichiers" dans Lighthouse. Si un site utilise HTTP1.x, oui, mais s'il utilise HTTP2, le nombre de requêtes est moins important, voire ne pose pas de problème s'il provient du même nom d'hôte. J'ai un site Web léger, mais je charge 30 petits fichiers WebP sur un total d'environ 35 requêtes, via HTTP2 sur le même nom d'hôte. Lighthouse signale un problème de type "Keep Request Counts Low And File Sizes Small" (Limiter le nombre de requêtes et la taille des fichiers), alors que le chargement est ultrarapide et que le nombre de requêtes ne pose pas de problème en raison de l'utilisation de HTTP2 sur le même nom d'hôte. Et oui, les fichiers sont déjà petits (la plupart font entre 1 ko et 2 ko, voire moins). Je pourrais charger un sprite, mais cela nécessiterait davantage de calculs CSS. Veuillez donc mettre à jour le rapport "Keep Request Counts Low And File Sizes Small" (Limiter le nombre de requêtes et la taille des fichiers) dans Lighthouse pour prendre en compte HTTP2 sur le même nom d'hôte."
- "Les utilisateurs ont du mal à penser à compresser leurs images."
- "Le comportement des différents navigateurs reste imprévisible. Les solutions les plus simples sont donc souvent les plus sûres."