Optimisation des images générées par eZ Publish

• Publié le 14 juin 2009 à 01:47
• 6 commentaires

Google Page Speed (la presque copie conforme de YSlow) est sorti il y a quelques jours. Ces deux outils permettent de vérifier différents critères ayant un impact sur le temps de chargement ressenti par l'utilisateur. En utilisant Google Page Speed sur ma dernière création, Bioutifoul Photos, j'ai remarqué que les miniatures des photos générées par eZ PublishviaImageMagick n'étaient pas optimisées, en effet elles contiennent toutes les informations EXIF de l'image originale ce qui est rarement utile (a priori GD ne sait pas conserver les informations EXIF donc le problème ne se pose pas).

Pour remédier à cela, il est possible de configurer un filtre spécifique (par exemple nommé optimize) qui va rajouter l'option -strip à convert lors de la création des variations pour supprimer un maximum de choses dans l'image puis à rajouter ce filtre dans les filtres utilisés pour créer une variation donnée. Cette opération est faisable en écrivant les lignes suivantes dans settings/override/image.ini.append.php :

[ImageMagick]
IsEnabled=true
ExecutablePath=/usr/bin
Executable=convert
 
Filters[]=optimize=-strip
 
[mini]
Filters[]
Filters[]=geometry/scalewidthdownonly=200
Filters[]=optimize

Dans cet exemple, la seules les images générées en format mini seront optimisées. Une autre solution plus globale consiste à ajouter l'option -strip pour toutes les variations en utilisant le paramètre PreParameters dans le même fichier de configuration.

Dans les deux cas, pour que les images existantes soient régénérées, il faut lancer la commande suivante :

$ php bin/php/ezcache.php --clear-tag=image

Attention, sur un site avec beaucoup d'images et un peu d'audience, la régénération des variations peut être extrêmement gourmande en ressources.

Étude du Planet eZ Publish.fr (3/3) : performances, caches et compagnie

• Publié le 27 janvier 2009 à 23:09
• 5 commentaires

Suite et fin de la série d'articles sur la réalisation du Planet eZ Publish.fr avec les questions de performances et de caches.

I. Organisation et Import des articles
II. Modules/vues sur mesure et templates
III. Performances : caches et compagnie

Performances

Cache de vue et cache-block

La gestion des caches « standards » est un point important pour les performances. La vue full (zone entourée de jaune dans la capture d'écran ci-dessus) est assez logiquement l'affichage de la liste des articles, elle est automatiquement mise en cache (cache de vue ou cache de contenu). Pour que la page d'accueil et les pages Blogs et Planétarium soient à jour sans opération manuelle, il m'a fallu ajouter deux règles dans une surcharge du fichier viewcache.ini pour que le cache de vue soit vidé lors de l'ajout d'un objet de la classe Post ou de la classe Site.

Les menus (menu horizontal, liste des blogs, liste des planets) sont chacun entourés d'une instruction cache-block (cadres rouge) expirant avec la partie de l'arborescence qu'ils affichent. Et pour aller encore un peu plus loin, chaque article est lui-même individuellement mis en cache par un cache-block. Cela permet de limiter le nombre de requêtes SQL nécessaires à la re-génération de la vue full lors de l'ajout ou de la mise à jour d'un article ainsi que sur l'affichage des résultats de recherche.

Cache statique

Compte tenu du faible nombre de pages, j'ai choisi d'ajouter du cache statique en plus des caches classiques sur l'ensemble du site. 0,05 seconde pour sortir une page les mauvais jours, difficile de faire mieux ! Une des limitations du cache statique est l'impossibilité de pré-générer les pages avec paramètres (par exemple /page/(offset)/10), pour éviter ce problème, j'ai ajouté les pages principales (avec ou sans paramètres) dans les URLs à générer systématiquement. Ainsi à la moindre modification de contenu, le script de cronjob staticcache_cleanup.php génère la quinzaine de pages du site. Ce qui a aussi l'avantage de pré-générer les zones en cache détaillées précédemment pour les résultats de recherche par exemple.

Optimisations côté navigateur

Le temps de génération (ou de distribution) des pages n'est qu'une petite partie du temps total d'affichage de la page. Les Yahoo! Performances Rules ou le livre High Performances Web Sites listent les principales recommandations pour améliorer ce point.

Planet eZ Publish.fr est hébergé sur ma Dédibox, la configuration des entêtes d'expiration et de la compression GZip des éléments textuels sont effectifs. La charte graphique simple a également simplifiée la mise en place de la technique CSS Sprites pour limiter le nombre de requêtes HTTP nécessaire à l'affichage d'une page. Tout ceci donne un beau Performance Grade A(97) dans YSlow.

Optimiser son site : limiter le nombre de requêtes HTTP

• Publié le 30 août 2008 à 15:36
• 0 commentaire

Limiter le nombre de requêtes HTTP est la première règle (la plus efficace) pour l'optimisation d'un site bien avant la configuration de l'entête d'expiration et la compression gzip des contenus textuels, mais il peut aussi s'agir de la plus complexe à mettre en place. Si il est assez simple de rassembler les feuilles de style CSS et les fichiers Javascript pour limiter le nombre de téléchargements, le cas des images est un peu plus complexe. On peut appliquer la technique dite des CSS Sprites sur les images utilisées pour la décoration via la propriété CSS background. Cette technique consiste à rassembler les images en un seul fichier et à jouer avec la position pour n'afficher que la zone voulue. En effet un navigateur mettra moins de temps à télécharger 1 fichier que 6 petits fichiers de taille totale équivalente et en plus le fichier réunissant les 6 premiers est généralement plus petit, double bénéfice donc. Au niveau montage, il faut par contre savoir qu'une dimension doit nécessairement être fixée ou au moins contrôlée (par exemple le texte contenu est toujours le même), il ne me semble pas possible de remplacer des images qui se répètent sur les axes X et Y à la fois.

J'ai donc expérimenté cela sur ce site dont le design est suffisamment simple. Le design utilise 8 images via la feuille de style, mais 2 restent un peu à part :

1. le logo RSS est un PNG 24 bit pour que les arrondis soit vraiment arrondis, il restera donc seul
2. l'image utilisée en fond des citations est assez large alors que toutes les autres le sont beaucoup moins ou sont répètées sur l'axe horizontale, elle reste intacte également.

Les 6 images restantes sont à l'origine des GIF, j'en ai profité pour les convertir en PNG pour comparer les tailles des différents agencements, ce qui donne le tableau récapitulatif suivant (les tailles sont en octets) :

Je suis très étonné par la taille du GIF rassemblant les 6 images d'origine. Pour le reste, le PNG est légèrement plus efficace presque partout et le CSS Sprites à base de PNG est 11% plus petit que les 6 GIF originaux (et presque autant avec les 6 PNG), j'ai aussi l'impression que l'affichage du site est un peu plus rapide avec ou sans cache navigateur. Il faut quand même noter que cette technique fait légèrement grossir la feuille de style mais comme celle-ci est compressée l'augmentation est plus que faible (1 octet !) et en m'y replongeant j'ai trouvé quelques optimisations qui ont largement compensées cet écart et je n'ai pas encore réellement minifié la feuille de style...

Finalement sur ce site rien de très compliqué, la mise en page est très simple, le plus dur étant d'ordonner correctement les images pour ne pas se retrouver avec une belle mosaïque. Pour voir un exemple un peu plus complexe, on peut étudier le montage du site Yahoo.fr par exemple même si il ne s'agit pas non plus de la page la plus complexe du monde...

Optimiser son site (sous Ubuntu et ailleurs...) : Compresser avec gzip

• Publié le 18 août 2008 à 00:24
• 8 commentaires

Notes aux grincheux de service : la manipulation exposée dans ce billet fonctionne évidemment ailleurs que sous Ubuntu (en fait partout où Apache2 est installable), néanmoins elle a été testée et mise en place sous Ubuntu et fonctionne telle quelle avec l'installation d'Apache2 par défaut sur cette distribution.

Après avoir appliqué la règle 3 en ajoutant et configurant l'entête Expires, passons à la règle 4 du Livre High Performances Web Sites (ou des recommandations de performances Yahoo!) en compressant avec gzip les données transmises par le serveur web, ici Apache2. Comme son nom le suggère, cette règle vise à limiter au maximum le poids des contenus distribués en réduisant de près de 70% la taille des fichiers textes. Cela permet d'accélérer le premier chargement du site avant la mise en cache par le navigateur. Pour cela, on peut configurer Apache2 pour utiliser le mod_deflate qui va se charger de compresser ce qui peut l'être pour un sur coût CPU faible.

La première étape consiste à activer ce module ainsi que le module headers avec a2enmod et à recharger Apache pour prendre en compte ce nouveau module :

$ sudo a2enmod deflate
$ sudo a2enmod headers
$ sudo /etc/init.d/apache2 reload

Le module headers est nécessaire pour envoyer des entêtes spécifiques aux proxy caches de manière à ne pas envoyer de documents compressés à certains navigateurs buggés mais populaires...

La configuration par défaut, stockée dans le fichier /etc/apache2/mods-available/deflate.conf, fait en sorte de compresser les fichiers texte brut, HTML et XML ce qui est déjà bien, mais on peut aller plus loin en traitant tout ce qui est texte. Il est en effet inutile de compresser les images (JPG, PNG, GIF, ...), les PDF et bien d'autres types de fichier qui sont déjà compressés par nature. J'utilise la configuration suivante dans /etc/apache2/conf.d/deflate pour compresser en plus les feuilles de style et les scripts Javascript tout évitant certains bugs connus de quelques navigateurs.

 AddOutputFilterByType DEFLATE text/plain text/css application/x-javascript text/xml text/html
 
# gestion des navigateurs buggés
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 
# gestion des proxy caches
Header  append Vary User-Agent

Pour faire prendre en compte cette configuration, il ne reste plus qu'à recharger Apache et le tour est joué.

Livre : "High Performances Web Sites"

• Publié le 11 août 2008 à 00:29
• 3 commentaires

Only 10-20% of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page.

Traduction libre :

Seulement 10 à 20% du temps de réponse ressenti par l'utilisateur provient du téléchargement du document HTML. Les 80 à 90% restant viennent du téléchargement des autres composantes de la page.

Voila la Performance Golden Rule qui sert de base à ce court mais excellent bouquin High Performances Web Sites de Steve Souders (employé chez Yahoo!) expliquant 14 règles pour améliorer la rapidité d'affichage d'un site web. En fait ce livre reprend les 14 premières bonnes pratiques listées par Yahoo! pour améliorer les performances générales d'un site web. Ces points sont applicables à quasiment tous les sites (à part peut être l'utilisation d'un Content Delivery Network qui est hors de porté du commun des mortels...) quelque soit la technologie employée puisqu'il s'agit essentiellement de configuration au niveau du serveur web ou dans la construction des pages.

Ces 14 règles sont les suivantes :

1. Limitez le nombre de requêtes HTTP
2. Utilisez un content delivery network
3. Ajoutez l'entête Expires
4. Compressez avec gzip
5. Placez les feuilles de styles en haut de page
6. Placez les scripts javascript en bas de page
7. Évitez les expressions CSS
8. Externalisez les feuilles de styles et les scripts Javascript
9. Réduisez les résolutions DNS
10. Réduisez la taille les scripts Javascripts
11. Évitez les redirections
12. Supprimez les scripts en double
13. Configurez l'entête ETags
14. Rendez vos appels AJAX cachables

En plus de ces règles, le livre explique succintement quelques concepts du protocole HTTP liés aux performances et propose une analyse des 10 plus gros sites américains (MSN, Google, Yahoo!, CNN, Wikipedia, MySpace...). Si ces règles sont assez connues (et pour certaines de l'ordre du bon sens), l'intérêt principal du livre réside dans la quantification des gains éventuels ainsi que dans les explications amenant à ces règles sur le fonctionnement des navigateurs sur la construction d'une page, la parallélisation des téléchargements ou le cache DNS.

Bref, il s'agit vraiment d'un très bon livre pour tout développeur ou administrateur où la plupart des recettes sont applicables en quelques minutes seulement pour un résultat immédiat et assez spectaculaire.