Articles avec le tag ‘compression’

Experience de voici.fr

Vendredi 13 novembre 2009

J’aime bien apporter un peu de retours d’expérience, pour montrer que toute la théorie fonctionne aussi en pratique. Certes il y a Yahoo!, Google, Amazon, mais ce sont des trop gros sites pour que le développeur moyen se sente impliqué.

Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear. (Lire la suite…)

Pngrewrite sous linux

Lundi 7 septembre 2009

Je fais encore le tour des outils de compression d’image pour faire la comparaison et trouver le bon compromis entre ressources consommées et efficacité. Un de mes problème c’est punypng qui annonce des performances exceptionnelles mais qui ne détaille pas son fonctionnement et ne propose même pas d’API. Je vérifierai leurs affirmations et tenterai de m’en approcher mais en attendant je fouille.

Un des outils que je regarde c’est pngrewrite. La rumeur voudrait qu’il ne gagne pas grand chose mais qu’il est capable de le faire même après un passage par optipng ou pngcrush. Bref, un petit ajout rapide, juste pour grappiller un peu plus.

Je vais vérifier tout ça là aussi, mais en attendant le code proposé sur le site officiel ne compile pas sur mon linux récent. Pour ceux qui ont le même problème, la distribution gentoo a un patch disponible. Il suffit de le télécharger là où vous aurez décompacté le code source de pngrewrite et de lancer patch -p0 < pngrewrite-1.3.0-gcc44.patch puis de taper l’habituel make.

Voilà, maintenant vous savez.

J’aurai bien fait des paquets Ubuntu pour pngrewrite et pngout mais je ne trouve pas la licence du premier et le second interdit explicitement de reditribuer l’exécutable résultat. Si j’ai le courage je tenterai peut être des paquets « tricheur»  qui téléchargent sur Internet lors de leur installation mais ça perd un des intérêts.

Punypng, un smushit-like

Lundi 3 août 2009

Smushit a disparu, ou presque. On nous parlait d’ouvrir le code source. Il y avait une API pour faire des tests automatisés. Il était possible d’optimiser tout un site web. Le site a été repris sur un hébergement interne à Yahoo! et depuis il y a eu des indisponibilités et plus de régressions que d’améliorations. Le concept est toujours très intéressant mais finalement très limité.

J’ai annoncé il y a quelques temps que je comptais développer un outil similaire avec un code source ouvert et au moins une version en ligne de commande pour être intégré dans des mécanismes automatisés de publication (plutôt que d’attendre publication pour ensuite corriger image par image). Ca viendra, mais ça prend du temps parce que je veux faire les choses bien. Je compare donc tous les outils que j’ai pu voir pour comparer leurs résultats, avec différentes options. Il faut tenter de prendre un échantillon d’images représentatif, repérer les avantages et les défauts de chaque outil suivant le format mais aussi le type d’image (taille, transparence, nombre de couleurs, etc.) puis faire un choix en fonction du temps de traitement (prendre le plus efficace sur la taille finale n’est pas forcément la meilleure idée). Bref, ça viendra mais ce n’est pas pour demain.

Par contre vous avez désormais punypng. Je n’ai pas vu de code source, il n’y a pas de version en ligne de commande, ça n’accepte pas une URL de page HTML pour en extraire toutes les images (quoi qu’il doit être assez simple d’adapter l’ancienne extension smushit pour cela) mais ils innovent. Ils ont repris l’idée d’optimiser les images contenant des pixels avec une information RGB mais totalement transparents, ils font plus de travail sur les jpeg, et ils tentent d’avoir une interface plus efficace que smushit. C’est déjà ça et c’est bien.

Petit exemple de mise en pratique

Vendredi 26 juin 2009

Voici un petit exemple de comment mettre en place les bonnes pratiques de cache et de concaténation des fichiers javascripts. L’article date de 2006 mais n’a pas pris une ride.

On y retrouve une réflexion sur comment regrouper les fichiers javascripts entre eux et comment les compresser. La note sur mod_gzip est toutefois assez contestable. Il est désormais sans risque d’activer mod_gzip ou mod_deflate, et ceux qui veulent absolument éviter tout risques peuvent trouver facilement sur internet des listes d’exclusions pour cibler les navigateurs défectueux.

La politique de cache est intéressante à étudier. Ils ont évité les paramètres en ?xxx et ont choisit de versionner le nom de fichier directement. Pour éviter d’avoir à créer un fichier par version, c’est à mod_rewrite qu’il revient de faire la liaison entre l’url et le fichier à jour. Les adresses main.v27.css et main.v256.css mènent toutes vers le même fichier main.css, toujours à jour.

Au final ils passent encore par un script PHP pour délivrer leurs fichiers javascript et css au lieu d’utiliser mod_expires, mais vous avez une expérience concrête, et reproductible en une journée pour améliorer vos performances.

Optimisation JPEG (encore)

Vendredi 19 juin 2009

je vous ai parlé plus d’une fois de recompression des images PNG. Mais … et les jpeg ?

Les jpeg ont aussi des métadonnées importantes et des informations inutiles dans un contexte web. Vous y trouverez plusieurs version de l’image à différentes résolutions pour gérer des miniatures, ou même des pistes audio. Stoyan Stefanov a trouvé un gain moyen de 12 % avec des transformations sans pertes sur l’image elle-même, loin d’être négligeable.

C’est Jpegtran dont j’avais parlé la dernière fois, l’outil utilisé par smushit. En plus de retirer les blocs de méta données (moins précisément que JHead), il permet de retoucher un peu la compression sans toucher à la qualité de l’image ni subir de pertes par rapport à l’image originale.

Jpegtran permet aussi de créer des images jpeg progressives, ce qui parfois est légèrement plus petit en taille (mais pas tout le temps, et en particulier pas pour les petites images).

Attention toutefois, cela retirera aussi les mentions de copyright éventuelles. Ne le faites que sur vos images ou prévoyez d’extraire d’abord cette information pour la réinjecter dans l’image finale ensuite.

JHead manipule lui aussi les entêtes et les métadonnées EXIF, IPTC et XMP. Je peux vous proposer les options -du -dc -de -di -dx. Jpegoptim propose aussi une optimisation sans perte et la possibilité de supprimer les entêtes EXIF et commentaires. Je n’ai pas de retour sur la performance de l’outil. Pour ceux que ça intéresse il y a une option pour diminuer la qualité de l’image (non activée par défaut).

Maintenant, comme on me le faisait remarquer il y a peu à propos des PNG, la meilleure compression s’obtient toujours en travaillant l’image avant de la fixer dans un format particulier. En particulier il est généralement appréciable de gérer la qualité par zones, pour avoir les détails là où c’est utile.