Yann "Bug" Dubois

Développeur WordPress freelance à Paris
Flux RSS

Accélérer WordPress – Partie 5 – Optimisation des images

27 May 2009 Par : Yann Dubois Catégorie : Français, WordPress

La Joconde (c) Musée du LouvreOptimiser la livraison des images

Maintenant que nous avons supprimé le superflu (les plugins inutilisés, les appels externes trop lourds et le code redondant) et optimisé l’essentiel (le contenu dynamique et le fonctionnement de WordPress), il nous reste un travail important à faire sur l’autre partie du contenu, à savoir les éléments “statiques”.

Qu’est-ce qu’un élément statique ?

– Monsieur de La Palice nous aurait bien indiqué que “ce qui est statique c’est tout ce qui n’est pas dynamique” 8-); autrement dit tout ce qui n’est pas généré à la volée par du code (PHP ou Javascript). En résumé, il s’agit donc de la plupart des images (GIF, JPEG, PNG ou encore .ico), des feuilles de styles (.css), des fichiers contenant du code JavaScript à faire exécuter par le navigateur du visiteur (en général fichiers .js), des éventuelles pages XML statiques (dont le contenu ne change jamais), et par extension, on pourrait même y inclure les contenus multimédias du type vidéo, sons (mp3), etc. Ces derniers ayant en général vocation à être servis selon des modalités particulières, nous n’en parlerons pas ici.

Tous ces éléments sont évidemment essentiels à la présentation de vos pages web (à moins que votre blog ne contienne que du texte, sans habillage ni illustration ?). Ils représentent même en général, et de loin, le plus gros volume des données constituant une page web. Il faut y attacher une importance particulière lors de l’optimisation des performances de tout site web, et ce sera donc vrai aussi pour un blog WordPress.

Taille, type et taux de compression

Notre premier objectif va précisément être de réduire au maximum le volume de données à envoyer au navigateur pour construire la page. Donc de trouver la façon d’envoyer tous les éléments statiques strictement nécessaires (et pas plus), en codant ceux-ci de la façon la plus “légère” possible.

1) Les images du contenu

Le premier point à considérer avec attention est la taille des images qui font partie du contenu des pages et billets : il est important de travailler la maquette des pages pour y inclure, en quantité et en format, la juste proportion d’iconographie. Sur un blog, il est d’usage, et c’est une bonne pratique encouragée par le fonctionnement par défaut de WordPress, d’inclure dans le texte des versions en taille réduite des photographies, qu’il sera possible de consulter en plus grand format en cliquant. Cela permet au visiteur de ne télécharger en haute définition que les images qui l’intéressent. Il est donc important d’utiliser systématiquement ce mécanisme au moment de l’incorporation des images dans le corps d’un billet. Nous verrons ci-dessous qu’il y a moyen d’optimiser techniquement le fonctionnement par défaut de WordPress au moment de la restitution de ces images.

Revoir la maquette d’un blog pour rationaliser les formats d’images est souvent une source importante de gain en performance d’affichage : réduire de 30% la “surface” d’image affichée par page, permet de diminuer d’autant la taille des fichiers et donc le temps d’affichage total de la page (car dans de nombreux cas les fichiers d’image représentent 90% des données transférées vers le navigateur).

Par ailleurs, la plupart des images inclues dans le contenu d’un blog étant au format JPEG, il convient, au moment de la mise en ligne de ces images, de régler avec soin le niveau de compression (encore appelé coefficient de qualité) : en JPEG, la compression de l’image engendre la dégradation de la qualité, mais la plupart des photographies courantes à joindre à un blog supportent une compression à 85% qui est souvent un bon compromis.

2) Les images de l’habillage

Les images composant l’habillage (ou la maquette graphique) d’un site sont à considérer avec un intérêt particulier. Elles constituent, en volume, une part minoritaire des données constituant une page (du moins il faut l’espérer, sinon votre blog a un problème de conception, donnant l’avantage au contenant par rapport au contenu, ou encore sur la forme au détriment du fond !) – et pourtant, ce sont ces images qui ont pour vocation d’être le plus souvent téléchargées par vos visiteurs, puisqu’elles sont nécessaires à la construction de toutes les pages de votre site. Le visiteur qui arrive pour la première fois sur votre site doit d’ailleurs en général les télécharger en intégralité avant de pouvoir accéder à votre contenu.

Bref, il est utile de se pencher en détail sur le cas particulier de chaque image d’habillage (notre outil de prédilection, l’extension Firebug de Mozilla, nous sera ici encore d’une aide précieuse.) Il faudra à chaque fois se poser 3 questions :

  • Cette image est-elle nécessaire, a-t-elle une utilité réelle en terme de “service ergonomique rendu” pour mon site, peut-elle éventuellement être remplacée par un texte, un applat de couleur, ou une autre image déjà chargée car utilisée ailleurs dans la page ?
  • Cette image est-elle au bont format (nombre de pixels en largeur et hauteur), peut-on réduire son format sans nuire à sa lisibilité ou à son esthétique ?
  • Cette image est-elle encodée avec la bonne technologie ? – ici le plus simple est de faire un essai pour chaque image de l’habillage, de la convertir en JPEG, en GIF et en PNG (avec l’outil gratuit GIMP par exemple), et de voir quel encodage procure le meilleur rapport qualité/poids. C’est souvent le GIF qui est gagnant pour les images d’habillage de petite taille et sans dégradés, tels que textes de titrages, icônes, etc.

L’objectif le plus important est la réduction du nombre total d’objets à télécharger pour composer la page, pour les raisons que nous avons déjà évoqué dans la Partie 3 (appels externes).

Pour aller plus loin dans l’optimisation du nombre des images d’habillages ou icônes, on pourra d’ailleurs envisager la technique des “sprites” qui permet, par un procédé ingénieux, de réduire le nombre d’images à télécharger pour construire la page… nous en reparlerons séparément dans un billet détaillé, avec un exemple concrêt à l’appui.

3) Les vignettes (ou thumbnails)

Pour le cas particulier de ces petites images qui viennent souvent en rappel d’un lien vers un autre contenu (image plus grande, ou autre billet ou page du site), nous allons parler ci-dessous des outils TimThumb et PHPThumb qui sont des utilitaires tout indiqués pour générer dynamiquement des thumbnails, automatiquement mis en cache, et donc n’envoyer à chaque fois que le strict nécessaire pour l’affichage d’une image au format vignette.

Timthumb ou PHPThumb

Ces deux utilitaires disponibles en shareware permettent, très simplement, de bénéficier d’un retaillage/recadrage automatique de toutes vos image de petites ou moyenne taille, de façon à n’envoyer dans chaque cas au navigateur que la quantité de donnée strictement nécessaire pour l’affichage de votre image au format choisi.

Ces deux technologies, basées sur PHP et ses bibliothèques complémentaires GD et Imagemagick, s’occupent également de mettre automatiquement en cache chaque format d’image généré, ce qui évite de charger inutilement votre serveur : chaque objet graphique ne sera généré dynamiquement qu’une fois pour chaque format utilisé. Apache s’occupera d’envoyer aux internautes suivants un fichier sauvegardé sur le disque dur, sans solliciter le serveur d’application. Les images retaillées avec Timthumb et PHPThumb restent donc bien en pratique des fichiers statiques, vues depuis le navigateur de vos visiteurs.

Je diffuserai d’ici peu un plugin WordPress spécialement dédié à la mise en oeuvre automatique de Timthumb ou PHPthumb afin de réduire automatiquement au maximum le volume des données graphiques envoyées avec le contenu de chaque page (par défaut, WordPress ne génère en effet que 3 ou 4 formats d’image, qui ne sont pas toujours utilisés à bon escient dans le code des pages envoyées). Pour les plus curieux, j’utilise déjà cet outil avec d’excellents résultat sur le blog local Nogent-Citoyen.com (sur la page d’accueil et toutes les pages d’archives et de listings).

A noter que la prochaine version, 0.9, de mon plugin YD Recent Posts Widget, mettra également automatiquement en oeuvre la technologie Timthumb pour générer toutes ses vignettes (option qui sera activée par défaut).

Pour ceux qui s’interrogent sur la différence entre TimThumb et PHPThumb, il faut retenir que TimThumb est plus léger et rapide à mettre en oeuvre, et suffisant pour déployer les techniques d’optimisation d’un blog WordPress évoquées ici. PHPThumb est plus complet et plus puissant, avec de nombreuses options de filtrage et la capacité à gérer des images hébergées “en externe”. Les deux outils partagent une même syntaxe pour les principaux paramètres de fonctionnement, ce qui simplifie le passage de l’un à l’autre.

La compression à la volée des fichiers

Il ne faut pas oublier d’activer l’option de compression à la demande des fichiers statiques (mode “gzip”), qui est disponible dans WP Super cache. Bien qu’elle demande un peu plus de travail à votre serveur web au départ, elle permet d’accélérer notablement les temps de chargement pour tous les navigateurs modernes qui la supportent.

Je ne parle pas ici de la mise en oeuvre des modules “Mod_gzip” ou “Mod_deflate” d’Apache, qui peuvent également être une bonne idée dans certains cas de figure, mais dépassent le cadre de ce billet. Voir le guide d’installation du site Luxpopuli pour l’installation de mod_deflate sous Apache2. Quoi qu’il en soit, si votre serveur (par exemple sur un hébergement mutualisé) est déjà configuré pour utiliser ces modules, sachez que WP Super Cache et PHPThumb sont également conçus pour en tirer parti au maximum.

La minification des scripts et bibliothèques JavaScript

Bien que très efficace, je ne parlerai pas de cette technique ici, car elle demande de bonnes compétences et du temps pour être mise en oeuvre correctement avec WordPress et son foisonnement de plugins hétérogènes. Je la mentionne uniquement pour être exhaustif, et vous trouverez plus d’informations (en anglais) sur le site du Google Code.

Serveur séparé et dédié aux statiques

Nous entrons ici dans une technique de mise en euvre plus avancée, qui ne sera vraiment utile que pour les sites à fort volume, et que je ne détaillerai donc pas non plus ici.

En résumé, il s’agit de mettre en oeuvre un serveur web “allégé”, plus efficace encore qu’Apache, pour servir les contenus statiques. Ce serveur doit être accessible avec un nom de domaine différent, idéalement un sous-domaine de votre domaine principal (par exemple du type img.mondomaine.com).

Il peut s’agir du serveur Lighttpd (la solution que je recommande), ou encore d’un proxy-cache Squid ou Varnish spécialement configuré pour ce faire… nous en reparlerons peut-être un jour dans un billet détaillé, si je suis amené à mettre en oeuvre ces systèmes avec WordPress, ce qui n’est pas le cas pour mes besoins actuels.

Les systèmes de CDN

Autre technique “professionnelle” en plein développement, l’usage de réseaux de diffusion de contenus statiques, ou “Content Delivery Networks”. Ce sont en général des prestations payantes (Les leaders de ces services étant Akamaï, Panther Express, Limelight Networks, etc.), qui ne se justifient pour l’instant aussi que pour des sites à très large audience, ou des problématiques de diffusion internationale… Mais l’arrivée probable de réseaux gratuits fondés sur le peer-to-peer pourrait changer la donne à cet égard pour les blogueurs. Une technologie à surveiller de près, donc ?

Le versionnage

La mise en cache des fichiers statiques, que l’on passe par des serveurs proxy dédiés, des systèmes de CDN, ou que l’on souhaite optimiser la durée de vie des fichiers statiques dans le cache des navigateurs web des visiteurs de votre site, passe souvent par le versionnage des noms de fichiers (afin que les fichiers puissent avoir une durée de vie “infinie” dans les cache, il faut changer leur nom à chaque fois qu’on en change le contenu.)

Il s’agit, encore une fois, d’une technique avancée sur laquelle je reviendrais peut être un jour dans un autre billet… en attendant il est temps de conclure :

Lire la suite : Résultats et conclusion

A lire également...

{"code":"internal_server_error","message":"

There has been a critical error on your website.<\/p>

Learn more about debugging in WordPress.<\/a><\/p>","data":{"status":500},"additional_errors":[]}