Images Web : redimensionnez et convertissez parfaitement (et automatiquement)

Presque tous les développeurs front-end savent que nous devons fournir les images les plus petites possibles aux utilisateurs sans affecter leur qualité. Nous savons tous comment y parvenir. Mais c’est une corvée que personne n’aime faire. D’un point de vue commercial également, cela prend du temps, et le temps, c’est de l’argent. Donc, « assez bien » est juste assez bien.

Permettez-moi de vous expliquer comment nous avons amélioré et automatisé la diffusion d'images parfaites sans créer davantage de travail pour les développeurs.

Comment cela se fait habituellement

Ce n'est peut-être pas vous, mais c'est nombreux, probablement la plupart d'entre nous.

Vous exportez une image au format PNG à 2 × la taille prévue pour répondre aux écrans haute densité et vous l'utilisez dans un format étiqueter. Si vous êtes prêt à consacrer 30 secondes supplémentaires (ou plus), vous faites mieux : vous le convertissez en WebP et placez les deux versions dans un fichier élément, permettant au navigateur de sélectionner le meilleur (enfin, pas le meilleur, juste le format le plus récent pris en charge et le format préféré du navigateur).

C'est le "assez bien", et c'est souvent le cas.

Mais ce n'est pas parfait. Les nouveaux iPad sont grands et peuvent utiliser des images 2,5 × ou même 3 ×. D'un autre côté, un Lenovo ThinkPad d'entreprise standard n'a pas besoin de ces détails supplémentaires, et une image 1× est parfaite.

Et honnêtement, tout ça est bien pour le travail manuel. Personne ne peut passer 15 minutes sur une seule photo.

Automatiser à la perfection

Pour mon cerveau perfectionniste, « assez bien » n’est pas ce que dit l’expression. De plus, certains de nos clients évoluent dans des domaines très compétitifs, nous avons donc commencé à rechercher des options. Cela n'a pas pris longtemps. Nous savions déjà que les navigateurs envoient des en-têtes HTTP indiquant les formats d'images qu'ils prennent en charge.

Ce dont nous avions besoin, c'était de découvrir que la L'élément peut charger des images en fonction de la densité de pixels d'un écran donné. C'est quelque chose que vous pouvez difficilement faire avec le rendu côté serveur, et ajuster src via JavaScript est hors de question pour une multitude de raisons.

Avec cela, nous avons tout ce dont nous avons besoin :

• Formats que le serveur peut servir.
• Dimensions de l'image demandée par le développeur front-end.
• Densité de pixels de l'écran.

Le processus

Voici comment nous avons automatisé le processus d'optimisation des images :

1. Accepter tout téléchargement d'image

   Nous laissons les développeurs et les administrateurs télécharger et enregistrer l'image qu'ils souhaitent (bien sûr, les développeurs sont plus prudents, ils doivent l'être). Notre système peut tout gérer - même ce fichier JPEG de 250 Mo provenant directement d'un appareil photo reflex numérique que nous avons réussi à convertir et à redimensionner, puis à éclater de rire lorsque nous avons vu les journaux.

2. Conversion et compression automatisées

Une fois qu'une image est téléchargée, notre système automatiquement :

• Le convertit en plusieurs formats : PNG, WebP et AVIF.
• Compresse chaque version en utilisant un paramètre de qualité de 90 %.

Pourquoi 90% ? Parce que les derniers 10 % de qualité se traduisent souvent par des rendements très décroissants. Vous économisez un espace de stockage et une bande passante importants sans aucune différence visible de qualité visuelle.

1. Générer plusieurs résolutions

   Pour chaque image, nous générons plusieurs tailles en fonction de multiplicateurs de densité de pixels :

• 1×
• 1,5×
• 2×

• 3×

  Cela garantit que les appareils dotés d'écrans haute résolution obtiennent des images nettes, tandis que les autres reçoivent des images de taille appropriée.

  Et pour assurer la pérennité, nous ajoutons ou modifions simplement des numéros et tout est automatique à gérer (nous ne faisons pas encore de contenu VR/AR, mais je soupçonne que c'est la technologie où cela sera utile).

1. Diffusion d'images dynamiques

   Dans nos modèles HTML, nous précisons les dimensions de l'image souhaitées (largeur ou hauteur). Notre code côté serveur alors :

• Vérifie si les images optimisées existent.
• Sinon, mettez-les en file d'attente pour traitement.

• Génère l'image élément avec srcset pour les densités de pixels.

  Le navigateur sélectionne automatiquement la meilleure image en fonction des capacités de l'appareil.

Le résultat ressemble à ceci :

<picture>
  <source srcset="/Upload/2024/03/11/tn-w200-frantisek.webp 1x,
                   /Upload/2024/03/11/tn-w300-frantisek.webp 1.5x,
                   /Upload/2024/03/11/tn-w400-frantisek.webp 2x,
                   /Upload/2024/03/11/tn-w600-frantisek.webp 3x">
  <img src="/Upload/2024/03/11/frantisek.jpg" width="2222" height="2963" loading="lazy" alt="Video poster">
</picture>

Gestion des images volumineuses

Si nous, en tant que développeurs, évitons le redimensionnement et la conversion parfaits des images, nous ne pouvons pas nous attendre à ce que les administrateurs ou les clients courants le fassent. Par conséquent, nous laissons les gens télécharger ce qu’ils veulent et nous le traitons (bonnes relations UX et clients).

Au départ, nous ne nous attendions pas à ce que le redimensionnement soit aussi intensif et nous avons complètement tué notre serveur de démonstration à plusieurs reprises. Nous avons donc développé cette approche :

• Nous avons construit un service API simple sur un VPS bas de gamme distinct dédié au traitement d'images.
• Nos serveurs de production envoient l'image et les formats/tailles souhaités à ce service.
• Les images traitées sont renvoyées et stockées pour être servies.

Le résultat

• Les utilisateurs sont satisfaits : les images se chargent rapidement et s'affichent parfaitement sur n'importe quel appareil.
• Les administrateurs sont satisfaits : ils n'ont pas à se soucier du redimensionnement ou de l'optimisation des images avant de les télécharger.
• Les développeurs sont satisfaits : Le processus est automatisé, sans travail supplémentaire requis.
• Les serveurs sont satisfaits : consommation de bande passante et charge CPU réduites pour la diffusion des images.

Je sais que nous pourrions utiliser n'importe lequel des services commerciaux publics pour le redimensionnement des images, mais pour être honnête, c'était un après-midi de travail (c'est-à-dire - beaucoup moins cher) et nous avons tous les aspects sous contrôle.

Le publions-nous commercialement ?

Nous sommes tellement satisfaits de cette solution que nous envisageons de peaufiner ce service de redimensionnement et de conversion et de l'activer pour votre utilisation. Y a-t-il un intérêt à un tel service ? Fais-moi savoir. Peut-être que nous pouvons réduire considérablement.

Pour les développeurs, par les développeurs - peut-être un mème à ce stade, mais dure vérité dans ce cas.

Le Code (simplifié)

Je ne peux pas partager les aspects redimensionnement, mais je peux vous montrer la sélection et création. Nous travaillons en PHP, et voici comment nous procédons.

Génération de l'image Élément

<picture>
  <source srcset="/Upload/2024/03/11/tn-w200-frantisek.webp 1x,
                   /Upload/2024/03/11/tn-w300-frantisek.webp 1.5x,
                   /Upload/2024/03/11/tn-w400-frantisek.webp 2x,
                   /Upload/2024/03/11/tn-w600-frantisek.webp 3x">
  <img src="/Upload/2024/03/11/frantisek.jpg" width="2222" height="2963" loading="lazy" alt="Video poster">
</picture>

Nous utilisons un système de modèles personnalisés où HTML est mélangé avec PHP (je sais que ce n'est pas courant, mais cela fonctionne mieux pour nos besoins).

<div>



<p>Ce code montre une logique. En réalité, nous disposons d'une base de données de fichiers et de leurs variantes. Ainsi, au lieu de chemins, nous travaillons avec des tableaux et des objets. Mais, comme je l'ai dit, cela montre magnifiquement la logique de ce que nous faisons.</p>

<p>Et comme vous pouvez le voir, si le développeur front-end écrit ce code ou <img> tag, peu importe le temps passé.</p>

<h2>
  
  
  Soulignons les problèmes
</h2>

<p>Cette méthode est conçue de telle sorte qu'elle ne pose aucun problème dans le monde réel. Mais il y a deux domaines d’amélioration que j’ai hâte de cerner (encore une fois, juste par point de vue perfectionniste).</p>

<ol>
<li>
<p><strong>Double file d'attente</strong></p>

<p>Il est mis en file d'attente pour être redimensionné après le premier chargement de cette image sur le front-end. Si le site Web a un trafic élevé, il peut en fait le mettre en file d'attente deux fois. Dans le monde réel, tout va bien ; donc il traite deux fois. Cela ne s'est produit que deux fois par an sur des sites Web à fort trafic.</p>
</li>
<li>
<p><strong>Affichage initial des grandes images</strong></p>

<p>Si un administrateur télécharge de grandes images, le redimensionnement et la conversion prennent 5 à 10 minutes, car cela se produit dans le cadre de tâches planifiées. Pendant ce temps, les grandes images sont affichées sur leurs pages Web. Dans le monde réel, seul l'administrateur le voit, car le nouveau contenu prend souvent un peu de temps avant que les utilisateurs ne le visitent. Sur les sites Web à fort trafic, nous réduisons ce délai à 1 minute seulement, donc encore une fois, ce n'est pas un problème.</p>
</li>
</ol>

<h2>
  
  
  Considérations de stockage
</h2>

<p>Vous pourriez souligner que nous disposons désormais de plusieurs images pour chaque taille et format, ce qui peut nécessiter beaucoup de stockage. Si votre site Web regorge de photos et de galeries et que vous avez besoin de miniatures et d'images détaillées pour chacune, oui, cela utilisera beaucoup de stockage.</p>

<p>Mais l’espace disque est le composant le moins cher de nos jours. Les avantages en termes de performances et d’expérience utilisateur dépassent généralement de loin les coûts. Et ainsi, vous avez réduit la charge de votre processeur et de l'ensemble de votre infrastructure.</p><p><strong>Une remarque -</strong>Pourquoi se soucier des infrastructures ? Quelqu’un d’autre s’en occupe, n’est-ce pas ? C'est ce que j'entends souvent. Le simple fait est que ce n’est pas vrai. Si une société d'hébergement doit ajouter du matériel pour une bande passante plus élevée en raison de charges accrues sans plus de clients, elle ne sera pas en mesure de le maintenir et se fera un plaisir de répercuter ces coûts sur les locataires du serveur.</p>

<h2>
  
  
  Nos résultats et notre expérience dans le monde réel
</h2>

<p>Dans Google Search Console, les Core Web Vitals sont plus écologiques que jamais, les temps de chargement sont généralement beaucoup plus courts et les durées de session des visiteurs sont plus élevées (quelques pour cent, mais je vais le prendre !). Et il n'y a pas de travail supplémentaire pour les développeurs ou les administrateurs : tout fonctionne correctement.</p>

<p>Je recommande fortement à chaque développeur d'utiliser quelque chose comme ça. Cela a fait beaucoup pour nous alors que nous pouvions oublier que cette chose en arrière-plan existe et fait son travail. Et j'écris littéralement cet article plus longtemps qu'il ne l'était pour mettre en place et peaufiner tous les systèmes.</p>

<h2>
  
  
  Conclusion
</h2>

<p>En automatisant l'optimisation des images, nous avons obtenu :</p>

• Livraison d'images parfaites adaptées à chaque appareil.
• Amélioration des temps de chargement des pages et de l'expérience utilisateur.
• Travail manuel réduit pour les développeurs.

Si vous en avez assez de la corvée d'optimisation des images, pensez à automatiser le processus. C'est gagnant-gagnant pour toutes les personnes impliquées.

Utilisez-vous des solutions systémiques pour vos images ?

Ou les convertissez-vous manuellement ?

Avez-vous essayé les AVIF ? Ils présentent des avantages incroyables pour les images plus grandes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!