Au temps où internet était utilisé via un modem 28.8, on se posait la question du poids des pages. Et puis, l’ADSL aidant, beaucoup ne se la pose plus. C’est un tort. Je ne vais pas revenir sur les études montrant la perte de visiteurs lorsque la page d’accueil reste trop longue à charger, c’est une évidence désormais. Il existe également d’autres solutions pour ne pas perdre ses visiteurs (tunnel de commande, fidélisation, …) mais aujourd’hui, c’est la performance dont je souhaite parler.
L’optimisation de site internet reste pour moi une obligation lorsque je conçois un site. Cela commence par l’optimisation du code afin qu’il soit valide (mais surtout respectueux des normes). J’évite au maximum les « hacks » par exemple. Je ne fais pas de tableau pour placer mes éléments de décors. Les tableaux étant fait pour afficher des données tabulaires.
Il faut savoir qu’un tableau ne s’affiche que lorsque sont contenu est entièrement chargé. D’ailleurs, dans le même ordre d’idée, il est préférable de placer le Javascript en fin de page, pour la même raison.
Il est préférable également de ne charger qu’un seul fichier CSS plutôt que 3. Et pareil pour les fichiers Javascript. Également pour les images, il est possible de faire des « sprites » : ancienne méthode très utilisée dans les jeux afin de réunir sur une même image plusieurs petites images. J’en parlai justement dans un précédent billet dédié à la performance des sites web.
D’ailleurs, je parlai également, dans ce billet, de la compression GZIP des fichiers au niveau du serveur. Et je me posai une question : est-ce que la compression d’un fichier côté serveur était compatible avec la minimisation de ce fichier ?!
Car il est tout à fait possible de minimiser un fichier CSS ou Javascript en retirant les commentaires, les blancs, …
Il existe des solutions online :
- Javascript compressor : pour compresser vos fichiers Javascript
- CSS Compressor : devinez 🙂
Il y en a pas mal d’autres, mais vous connaissez Google. Enfin, si vous en avez un particulièrement bien, n’hésitez pas à l’indiquer ici.
Bref. Je me demandais si un fichier compressé par ce système allait être compressé plus ou moins qu’un fichier non minimisé.
J’ai donc procédé à des tests. J’ai utilisé la librairie jQuery comme fichier de test. J’ai pris la version minimisée et la version non-minimisée et j’ai envoyé ça sur un serveur IIS avec compression GZIP installé. J’ai comparé ensuite dans YSlow la taille des fichiers d’origine et après compression par le serveur :
Fichier minimisé, taille d’origine : 72.1Ko
Fichier minimisé, taille après compression : 23.9Ko
Fichier non-minimisé, taille d’origine : 163.8Ko
Fichier non-minimisé, taille après compression : 44.1Ko
Le résultat est sans appel, on gagne pas loin de 50%
Donc, il est préférable de minimiser vos fichiers CSS et Javascript en plus de la compression serveur. Et, quoiqu’il en soit, il est préférable d’activer la compression serveur plutôt qu’une minimisation. Il est vrai que la minimisation ne permet pas de travailler ensuite sur les fichiers. La minimisation rendant la lecture très compliquée, voir impossible.
Bon à savoir également, il est possible de régler le taux de compression côté serveur afin de ne pas surcharger le serveur si vous avez beaucoup de visiteurs. Pour apache, vous pouvez indiquer la directive « DeflateCompressionLevel« .
Quelques manques dans cet article.
Pour commencer, la compression JavaScript utilisée pour le test utilise l’outil Packer de Dean Edwards. Cet outil donne de meilleurs résultats qu’une simple minification avec JSMin ou YUI Compressor, mais la contrepartie est que le moteur JS du navigateur doit «décompresser» le code reçu avant de l’analyser. On gagne donc du temps de téléchargement, mais on perd du temps d’exécution (de manière plus sensible que la compression gzip, qui est négligeable). Avec une simple minification, on n’a pas ce problème.
jQuery.com recommande d’utiliser JSMin (le site propse d’ailleurs des fichiers déjà minifiés), et la compression gzip.
Je recommanderais donc de refaire le test avec JSMin, JSMin+ ou YUI Compressor, plutôt que Packer.
Ensuite, concernant CSS, il est dit «il est préférable de minimiser vos fichiers CSS (…) en plus de la compression serveur». Sur quelle expérience ou essai se fonde cette affirmation? En l’état, l’article laisse penser que minifier les CSS fera gagner 50% de taille de téléchargement pour ces fichiers. À ma connaissance, ce n’est pas le cas. J’ai même vu des tests qui montraient que le fichier CSS non minifié donnait de meilleurs résultats avec gzip que la version minifiée et gzippée.
Au final:
– Compression gzip (mod_deflate ou mod_gzip avec Apache, par exemple) pour les fichiers CSS et JS: oui, toujours.
– Minification du JS avec JSMin ou YUI Compressor: à priori oui. À noter que concaténer les fichiers est tout aussi important, si ce n’est plus.
– Compression du JS avec Packer: plutôt non.
– Minification du CSS: à priori non.
Oui, bonnes précisions.
J’ai utilisé plusieurs compacteurs (dont ceux que tu cites) et aucun ne donne de résultats probants. Le résultat final reste le même.
Il faut savoir doser la compression côté serveur ou client et prendre les bonnes décisions en fonction de ses visiteurs. Tout bon serveur doit mettre en cache les fichiers compressés histoire de ne pas surcharger le serveur.
Reste que surcharger le client n’est pas forcément sympa.
Je n’ai pas testé pour les CSS. Je testerais à l’occasion (sauf si une bonne âme le fait avant…)
Voici ma réponse, j’essaye d’y présenter une autre façon de compresser ses fichiers : http://adrian.gaudebert.fr/blog/pos…