Passer au contenu

Compresser ses fichiers CSS pour optimiser le temps d’affichage de ses pages web

(cet article a été écrit par Camille Bouiller, voir son précédent billet pour plus d’informations) Il existe de nombreuses techniques, plus ou moins fiables, permettant d’optimiser…

(cet article a été écrit par Camille Bouiller, voir son précédent billet pour plus d’informations)

Il existe de nombreuses techniques, plus ou moins fiables, permettant d’optimiser votre site Web (et donc de réduire la bande passante). Mais je vais vous présenter une technique qui marche : le but est de compresser vos fichiers CSS.

Le principe est de réduire au maximum la taille de votre fichier CSS (en enlevant tous les sauts à la ligne, commentaires, etc.). Ce processus est notamment utilisé par les librairies Javascript qui font des milliers et des milliers de lignes de code. Certains sites importants l’utilisent mais ils sont encore rares.

1. Utilisez un outil pour compresser vos CSS en ligne

Comme je l’ai dit plus haut, nous allons utiliser un outil permettant de compresser nos fichiers CSS. Clean CSS, par exemple, fait ça très bien. Tout d’abord, il faut commencer par entrer le contenu ou l’URL de votre fichier CSS et choisir le mode de compression.

On a le choix : le plus compact, très compact, normal, peu compact ou sur mesure. Le mode de compression le plus important est très compact, il rendra votre CSS illisible mais vous gagnerez considérablement après la compression : de 20 à 30 % de gagnés sur la taille du fichier, c’est non négligeable !

Sur un fichier CSS de taille moyenne (plus de 500 lignes), les modes normale ou peu compact sont pas les plus efficaces, on gagne en moyenne une vingtaine de pourcents alors qu’on peut gagner presque 30 % avec les modes le plus compact et très compact – d’après mes tests.

En fait, le principe c’est de réduire considérablement le nombre de caractères dans votre fichier CSS pour y gagner, voici quelques exemples :

  • Réduction ou suppression (le plus compact) des retours à la ligne ;
  • Tri des priorités et sélecteurs ;
  • Fusion des priorités similaires (.center { text-align: center } et h3.titlepage { text-align: center } deviendront .center, h3.titlepage { text-align: center }) ;
  • Compression des couleurs et de font-weight : color: white et font-weight: bold deviendront respectivement color: #FFF et font-weight: 700 ;
  • Enlever le dernier point-virgule des priorités (pour gagner un caractère à chaque fois) ;
  • Etc.

Quelques exemples de CSS avant et après la compression

J’ai testé CSS Clean sur quelques sites que je visite quotidiennement :

Nom du site Mode de compression Avant compression Après compression % gagnés
Presse Citron Le plus compact 13.5 Ko 9.8 Ko 27.1 %
Techcrunch France Le plus compact 27.8 Ko 21.6 Ko 22.2 %
Site du Zéro Le plus compact 40.7 Ko 31.1 Ko 23.5 %
Digg Le plus compact 55.8 Ko 37.3 Ko 33 %
WordPress.org Le plus compact 18.7 Ko 15.3 Ko 17.8 %
PC INpact Le plus compact 35.5 Ko 25.7 Ko 27.9 %
Punbb.fr Le plus compact 11.5 Ko 5 Ko 56 %

2. Séparer le CSS source du CSS compressé

Je conseille fortement aux webmasters de compresser au maximum leurs fichiers CSS et de les inclure dans leurs pages, et de garder à côté les fichiers CSS sources, car modifier un fichier CSS illisible relève d’une mission commando (ou presque).

A ce propos, CSS Clean utilise CSS Tidy, le script permettant de compresser les fichiers CSS avec différents paramètres. Pour ceux qui ont quelques compétences en PHP, ce script peut être utile car il permet simplement d’automatiser la compression de votre CSS source, sans passer par un service tel que CSS Clean.

Vous aurez besoin de la version PHP 4.3.x ou PHP 5.0 supérieur pour que cela fonctionne. Voici quelques liens pour en savoir plus :

Coder un système qui s’occupe de compresser automatiquement votre CSS source à chaque modification n’est pas bien compliqué, il suffit de jouer avec les informations du fichier CSS source et de lancer une compression au bon moment.

3. Réduire le nombre de caractères par ci par là

Outre les sauts à la ligne/espaces retirés et les diverses optimisations effectuées par CSS Tidy, on peut encore réduire le nombre de caractères d’un fichier CSS. C’est un constat que j’ai fait en lisant le code source de certains sites. Par exemple, la propriété CSS background peut contenir les valeurs des priorités background-color, background-image, background-repeat et background-attachment.

De ce fait, le code suivant :
[sourcecode lang=css]#header {
background-color: #000;
background-image: url(images/header.png);
background-repeat: no-repeat;
background-position: top left;
}[/sourcecode]
Devient :
[sourcecode lang=css]#header {
background: #000 url(images/header.png) no-repeat top left;
}[/sourcecode]

L’opération peut se répéter pour quelques autres propriétés : comme font par exemple. Avec l’exemple ci-dessus, on réduit le nombre de caractères de moitié (passant de 143 à 73 caractères).

La question que l’on peut se poser : doit-on privilégier la rapidité d’exécution (en compressant les fichiers CSS) à la lisibilité du code source ? Par ma part je pense que l’on peut garder les deux en gardant 2 fichiers CSS distincts (le fichier source et le fichier compressé), comme je l’explique dans la partie 2.

📍 Pour ne manquer aucune actualité de Presse-citron, suivez-nous sur Google Actualités et WhatsApp.

Opera One - Navigateur web boosté à l’IA
Opera One - Navigateur web boosté à l’IA
Par : Opera
48 commentaires
48 commentaires
  1. Salut,

    personnellement, j’utilise Clean CSS pour tous les sites que je mets en production. Cependant, si la compression des css ne pose aucun problème avec les navigateurs “modernes”, notre cher ami IE est parfois plus récalcitrant à cette méthode!J’ai noté souvent certains problèmes qui peuvent se résoudre en ne fusionnant pas les propriétés, mais j’ai dans certain cas du tout simplement renoncé à compresser mes css, IE plantant tout simplement!
    Cependant, je pense qu’en ayant validé ses css auparavant, on doit largement limiter ce problème (ce que je n’ai pas fait 🙁 ).
    En tout cas, ajouter à cela la compression des js, puis un bon paramétrage de son serveur web comme le préconise Yahoo! et notre site se charge à vitesse grand V!

  2. Il faut énormément se méfier de ces méthode de compression, autant sur les fichiers CSS que Javascript. Au final elles se révèlent la plupart du temps totalement inutiles voir néfastes au poids du fichier total téléchargé par l’utilisateur lorsque la compression gzip est activée sur le serveur. C’est transparent pour l’internaute et le développeur.

    Un fichier CSS ou Javascript compressé automatiquement en GZIP par le serveur peut faire gagner jusqu’à 70% de poids de fichier téléchargé sans avoir à gérer de fichiers illisibles. En plus ce type de fichier n’aide vraiment pas à suivre le processus d’intégration continue pour ceux qui s’y conforme. Non plus d’aider l’ouverture du code aux autres.

  3. Merci pour cette information qui me semble utile je vais creuser le sujet.

    Cependant es que gagner 3ko en moyenne est vraiment utile ? Il faut vraiment avoir un énorme souci d’optimisation pour en arriver à ce stade ! Ce genre d’optimisation rajoute surement des contraintes qui ne sont surement pas justifié pour 95% des sites web …

    Bastien
    Porteur de projet “Viuc.fr” http://www.vicus.fr
    twitter : http://twitter.com/vicus
    blog : http://blog.vicus.fr

  4. Franchement, quelle est l’utilité de gagner 15ko en rendant son code illisible ? Je pense qu’il n’y a plus beaucoup de monde en 56k de nos jours… Et que la problématique du poids des pages est de moins en moins importante. Réduire des grosse bibliothèque JS genre Jquery ou alors bien optimiser la taille de ses images : ok.

    Mais gagner moins de 50 % sur la taille d’un css et gagner 15 ko… Personnellement, je trouve que c’est de la br…

  5. > Je pense qu’il n’y a plus beaucoup de monde en 56k de nos jours
    Non seulement il y en a encore beaucoup, mais également à moins d’être très spécifique, tout le monde n’a pas la fibre optique à 100Mo.
    Dans mon exemple en Guyane, malgré l’ADSL, certaines fois les sites prennent des 10aines de secondes à s’afficher. Et 15ko gagnés sont loin d’être négligeable.

    Qui plus est, pour des sites à fort trafic, cela peut permettre de gagner pas mal coté serveur !

  6. Utiliser un outil ne remplacera jamais un code css propre et bien saisi lors de la création du fichier.

    Pour avoir tenté d’utiliser plusieurs fois des outils de ce genre sur des codes non propre, le résultat final n’était jamais convainquant. Car il y avait une telle différence entre le fichier d’origine et le fichier compressé que cela augmente au final le travail de maintenance.

    Lorsque vous écrivez un fichier css, fixez vous une règle d’écriture pour que votre fichier soit lisible par tous et qu’un outil de compression puisse ensuite repasser derrière éventuellement. Un outil de compression ne rendra jamais un code plus propre quand il est mal écrit à l’origine.

  7. A choisir entre

    – gagner 3 ko, risquer de foutre en l’air mon design sur des navigateurs spécifiques et décompresser/maj à chaque modification mon CSS

    OU

    – faire télécharger 3 ko de plus à mes visiteurs qui pour la plupart ont des vitesses de connexion suffisantes

    => Le choix est vite fait 🙂 Il faurdait un outil qui ne fasse QUE supprimer les espaces blancs, sans fusionner ni modifier le contenu des CSS

  8. @Nicolas G : tu confonds lisibilité du code et taille du code. Le navigateur n’a que faire de la lisibilité, au contraire du poids qui permettra d’accélérer le chargement le chargement et de diminuer la consommation de bande passante.

    Dans le même style http://performance.survol.fr/ un blog très complet écrit par une référence en la matière.

  9. Très intéressant cet article. Il est vrai qu’on gagne pas grand chose, quelques Ko, mais c’est un début. C’est une méthode à ajouter à tous les autres moyens pour optimiser le chargement d’une page (optimisation du code, du poids des images, des requêtes SQL…). De plus, avec le web mobile, gagner même 50 Ko, c’est utile.

  10. Je suis un peu surpris par ta partie 3, car cela me semble la base même de tout. Avant de se lancer dans les manoeuvres de compression, savoir écrire ces CSS me semble être la base.

  11. Article tres intéressent.
    Cependant je doute assez de son efficacité(demande a voir/essayer). Par contre, cote serveur, pour un site a tres fort passage, cela peut être utile.

  12. Compresser un css, je vois pas franchement l’intêret quand on a un code bien structuré, et optimisé, pas besoin de foutre le bordel dans nos fichiers pour gagner quelques ko, qui au final ne feront gagner que quelques miettes face à une meilleures gestion des requêtes SQL et une organisation plus saine des fichiers php. Et franchement quand on met les mains dans le cambouis du code de WordPress, on comprend que certains cherche desespérément à accélerer leur affichage, avec une bouillie pareil, meme dieu ne retrouverait pas ses moutons 🙂

    Mais est-il utile de rappeller que Drupal par exemple propose une optimisation automatique des css, et plus généralement des sites en global, en pré-chargant l’éxecution des pages à intervalle fixe, pour au final ne faire travailler le serveur que lorsque c’est nécéssaire.

    Non ceci n’est pas un troll XD

  13. Au mieux on gagne 10Ko sur un fichier qui n’est téléchargé qu’une fois par visite (placé dans le cache du navigateur) … Sur les statistiques du serveur ça doit baisser d’un poil de zob de mouche la conso en bande passante et pour l’utilisateur je suis sûr que ce n’est pas visible…
    Enfin bon, ça à le mérite d’éxister

  14. [mode reloud on]
    Moi je dis qu’avant de faire ce genre de micro optimisation il vaut mieux regarder du cotés de la compression gz, 304, Expire … Last-Modified … Etag …. N’est ce pas Eric 😛

    Et pour info ce n’est pas de la compression (contrairement à gz) mais de la “minification” (CF : http://en.wikipedia.org/wiki/Minify).
    [mode reloud off]

    Sinon pour ce qui veulent minifier automatiquement il y a YUI Compressor (http://developer.yahoo.com/yui/compressor/) de Yahoo encore eux 😀

  15. Vous savez que dans les DOM (et accesoirement les TOM), l’ADSL n’a adsl que le nom : prix prohibitif et vitesse du 19ème siècle. Donc oui la compression et surtout l’optimisation des codes css, javascript, php… est utile.

    liberté, égalité, fraternité qu’ils disent… moi je dis foutaise !

  16. Hmmm comme beaucoup, le gain ne me semble pas énorme. Avec de plus en plus de sites dynamique, les images et les appels en base + taille du code PHP est de loin (de treeeeeeeeees loin) plus important.

    Compression GZip directement sur le serveur? Jamais entendu parler… il faut que je creuse car ca pourrait résoudre pas mal de mes problemes…

  17. je sais qu’on le critique pas mal sur ce site, mais des cms tel que joomla intègre une compression gzip automatique depuis belle lurette… alors au lieu de se faire #+%* avec des tools tierces…

  18. C’est effectivement quelque chose que je pratique mais plus généralement quand on utilise des CMS, les CSS sont conçu pour pouvoir s’adapter or parfois il y a beaucoup de chose qui peuvent être négligée, définir une police unique sur l’ensemble du site permet de supprimer quelques lignes de codes.
    Supprimer les commentaires également est un vrai gain.
    Cependant comme tu le soulignes si on est amené à modifier la feuille de style c’est pas toujours très clair…

  19. Sinon pour optimiser, on peut remplacer les blogs par Twitter aussi, ça serait mieux ;))
    optimiser de 10ko la CSS sur, par exemple, la home d’un blog qui va charger 2Mo de texte, 5Mo d’image et 20 de vidéo, c’est un peu prendre le pb à l’envers, non ?

  20. 4 Ko c’est peut-etre pas beaucoup, mais multiplie par le nombre d’utilisateur cela doit representer quelques mega par jour de bande passante economisee.
    Diminuer le temps de reponse est un element essentiel.

  21. J’ai écrit un article qui explique comme résoudre les différents problèmes d’optimisation (en me basant notamment sur le fameux YSlow) :

    http://blog.monbouquet.com/index.php/blog/comment-optimiser-un-site-web/

    Merci pour le coup de réduction des caractères dans le CSS, c’est futé !

    Pour répondre aux commentaires : bien qu’un grand nombre de sites (Visiteurs/jours < 10 000) n’aient pas un réel besoin d’optimisation, c’est toujours bon pour le pagerank & co.

  22. Bien dit.
    j’ajouterais également les CSS shortands (ie: margin: top right bottom left au lieu de margin-top margin-right etc.)
    les sprites pour reduire les requêtes http
    Plusieurs éditeurs (PSPAD par exemple) permettent à volonté de reformater le css en structuré ou en ligne.

    Quant à GZIP, plus de 90% des navigateurs l’acceptent aujourd’hui (ou du moins en 2008)

    Pour vérifier tout ça la barre Yslow pour firefox est bien efficace.

    Pour les bonnes pratiques, yahoo a publié ça : http://developer.yahoo.com/performance/rules.html et tout est développé dans “high performance web sites ” chez o’reilly

  23. Il ne faut également pas confondre compression, optimisation et “minification”. (ca se dit, ca?)

    Les propriétés raccourcies telles celles pour background, border ou encore font, ne sont pas seulement un gain de poids (on pinaillera sur ce point), mais surtout d’efficacité et de lisibilité.
    Pourquoi s’embêter à écrire 5 lignes quand une seule suffit, et est plus lisible (pour autant qu’on ait un minimum de bases)

  24. @monbouquet : J’aimerai bien savoir quelle est ta source pour : “c’est toujours bon pour le pagerank & co” … outre le fait que plus un site est rapide plus il est potentiellement crawlé par les moteurs, je me demande d’ou tu sors cette théorie, une petite source d’autorité STP ?

  25. Salut,

    Je ne vois pas trop l’intérêt d’une telle compression. Gagner 15Ko est un maximum car signifierait entre 30 et 45Ko de style css ce qui est non négligeable. Ensuite 15 Ko avec de l’ADSL 512, ca fait gagner environ 1/4s sur le téléchargement (différent du temps de réponse et d’affichage). Qui plus est ce temps réduit est compt&é une fois sur style.css car il est mis en cache (c’est l’intérêt d’avoir une feuille de style détachée).

    Non là c’est vraiment se prendre la tête pour rien.

    Surtout qu’une image mal optimisé fait aisément perdre là ce qui a été gagné ici.

    Enfin merci pour cette idée, cela valait sûrement le coup de l’exposer.

  26. Le débit théorique d’une connexion adsl ne présage en rien de la bande passante disponible pour un site en particulier.
    La page de presse citron vient en l’occurrence de prendre 20 s à se charger (affluence de visiteurs?) et j’ai failli aller voir autre chose.
    Donc gagner quelques ko de ci de là quant ont vit de son blog (ou site) ça peut toujours permettre de garder quelques visiteurs supplémentaires susceptibles d’aller cliquer là ou il faut!
    Bien sur, ça doit s’inscrire dans une démarche globale et ça ne va pas compenser des visuels lourds.

  27. @Tortue facile peut être je me suis mal exprimé ou tu as mal compris mes propos, mais je ne confonds pas lisibilité et poids du code.

    Un code lisible n’est pas incompatible avec un code optimisé. Un code propre selon moi doit être pensé à la fois en terme de maintenance pour que les gens qui passent derrière toi puissent le lire et à la fois en terme d’optimisation pour faire gagner de la bande passante. D’ou la nécessité sur des gros projets de se fixer une règle d’écriture avec documentation à l’appui pour se faire comprendre et d’optimiser son code.

  28. Ah ! c’est pas mal comme billet, j’avais déjà lu ici est là que l’on pouvait compresser ses fichiers css mais sans explication pratique pour le faire.

    Merci !

  29. Plutôt que de ‘compresser’ de façon destructive les CSS, il serait plus intéressant de générer des codes optimisés qui seraient bénéfiques aussi bien coté client que coté serveur.
    L’utilisation des frameworks semble permettre de réduire les couts de développement, mais clairement au détriment de l’optimisation des ressources…
    Je me demande toujours pourquoi pas mal de sites tournent par exemple sur des CMS comme JOOMLA alors que quelques lignes de PHP feraient souvent la même chose…?

  30. Déjà en “factorisant” certaines propriétés, en utilisant correctement les CSS (#bandeau li et pas #bandeau #un_id_à_chaque_fois), et en utilisant des notations qui permettent d’avoir plusieurs propriétés sur une ligne (margin: 0 15px 1em 350px; au lieu de margin-top:0; etc…) j’arrive à des CSS entre 4 et 8 Ko… allez, 10 Ko pour les sites vraiment très complexes !

    En optimisant correctement les éléments graphiques qui vont être chargés, on peut arriver à gagner encore qq Ko.

    Je trouve que c’est déjà correct : au moins, on évite d’avoir une CSS illisible, et gagner 20% sur 10 Ko… ça fait quand même que 2 Ko. Une image bien optimisée donne de meilleures économies.

    Pour les sites ayant une TRES forte fréquentation, pourquoi pas, mais pour un site lambda, je ne suis pas sur que ce soit indispensable.

  31. @monbouquet je te remercie du lien, (même si j’étais déjà au courant, c’est toujours bon a prendre ;)) mais jusqu’à preuve du contraire adwords n’a pas encore de lien entre PR et les positions dans les SERPS.

    Enfin ça c’est ce que mon ami google :o) veut bien nous faire croire, mais je voulais juste savoir si une news qui “officialisait” la chose m’aurait échappé.

    Mais bon pour l’instant on est toujours à supposer. Ça me fait penser aux suspicions sur le fait que google inclue les données Analytics dans les algos de classement de SERPS .

    La SEO est vraiment une “science” pleine de mystères non élucidés 😀

  32. Désolé j’arrive avec 3 semaines de retard, mais je voulais signaler que l’optimisation ou la recherche de la performance des pages Web est une science complexe, qui a rempli des bouquins, et que la compression des fichiers ASCII/binaires n’en est que la portion congrue.

    Et ici tout le monde oublie la notion de paquets :

    Les paquets TCP-IP sont les petits blocs d’informations qui transitent entre navigateur et serveur lors de la connexion : tout fichier transmis est divisé en paquets de 567 à 1500 octets (selon la vitesse la connexion), à moins qu’il ne tienne dans un paquet unique. Le nombre total de paquets transmis peut s’avérer déterminant, et une page optimisée va s’afficher plus rapidement qu’une page non optimisée (le poids total des fichiers restant égal par ailleurs).

    Pour les connexions moins rapides (128 kilo-octets/s et inférieures), l’optimisation des fichiers par rapport à la taille des paquets a peu d’importance. En revanche, pour les connexions rapides (supérieures à 128 kilo-octets/s), il est démontré [http://www.cmg.org/downloads/JingZhi.pdf] que le nombre de paquets envoyés détermine davantage le temps de chargement que le poids du contenu.

    Il est donc recommandé de faire en sorte que tous les fichiers (images, CSS, script, …) soient adaptés au poids d’un paquet ou d’un multiple de ce poids.

    On peut estimer ce “poids-étalon” à 1160 octets : les 1500 octets du paquet TCP-IP desquels il faut retrancher les informations contenues dans l’entête TCP-IP (40 octets) et les informations contenues dans la réponse HTTP du serveur au client (250-300 octets : informations sur la date, la taille, le type de fichier, …) qui sont incluses dans le (ou les deux) premier(s) paquet(s). Ainsi, lors d’une connexion haut-débit, un fichier dont la taille dépasse 1160 octets peut nécessiter l’envoi d’un second paquet, doublant le temps d’attente même pour quelques octets supplémentaires.

    La prépondérance du nombre de paquets sur la taille totale de la page devrait être plus largement prise en compte, d’autant que le nombre d’utilisateurs de connexions haut-débit est en augmentation.

  33. Je pense en effet qu’il ne faut pas confondre compression (changement de format du fichier vers zip ou autre), optimisation (réduction le code CSS au plus prêt du standard [suppression du code mort, du code redondant, …]) et minification (suppression des espaces, renvois à la ligne et commentaires).

    Dans tous cas je ne pense pas que ces opérations soient incompatibles avec le problème de maintenabilité des CSS. C’est juste une histoire de process. Le code lisible est pour le développeur, le code compressé, optimisé et minifié est pour le navigateur. En appliquant ces opérations entre le développement et la publication (avec des tests de non-régression [attention à IE 6 ;-)]) on réconcilie ces 2 point de vue.

    Donc une version des CSS pour le développement, un petit traitement puis une version pour la publication. Et il se trouve en effet que certains CMS effectuent ce type de traitements automatiquement.

  34. Eric, tu dis un peu plus haut: “modifier un fichier CSS illisible relève d’une mission commando (ou presque)”, c’est sans compter sur ce super petit outil permettant de décompresser et de classer hiérarchiquement les sélecteurs, sous-sélecteurs et autres propriétés: http://www.styleneat.com/index.php

  35. Merci pour l’article ! Je viens justement d’écrire un article sur mon blog sur un mod permettant de fusionner le plugin Super-Cache et le plugin Minify de façon à accélerer de façon drastique les blogs WordPress.

  36. OUlala le vieux sujet … C’est pas grave je commente tout de même.
    Je ne trouve pas vraiment pertinent de vouloir compresser les fichiers CSS qui représentent dans la majorité des cas pas ce qui ralentit le plus.
    Le gros du boulot aujourd’hui il est surtout au niveau des images à optimiser. Et là ça devrait vraiment faire perdre du poids à la page.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *