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

Par : Daminoweb

Daminoweb — Wed, 06 Apr 2011 21:58:20 +0000

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.

Par : Maxime

Maxime — Fri, 13 Aug 2010 07:00:19 +0000

J’ai écrit un minifier libre en PHP qui est plus performant que CSS Tidy et qui ne fait que des optimisations syntaxiques (pas de risque de changement de comportement).

MAX CssMin
Licence GPL v3
http://libre.maxbusiness.fr/cssmin/

Par : Des Geeks et des lettres

Des Geeks et des lettres — Sun, 13 Dec 2009 21:57:37 +0000

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.

Par : Laurent

Laurent — Sat, 21 Nov 2009 08:32:55 +0000

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

Par : Digg tente de rendre son site encore plus rapide | Presse-Citron

Digg tente de rendre son site encore plus rapide | Presse-Citron — Fri, 09 Oct 2009 08:38:45 +0000

[...] réduire le nombre de requêtes HTTP et votre bande passante, une des solutions est de fusionner et compresser vos fichiers CSS / JavaScript. Tags : Digg, optimisation, [...]

Par : Netmee

Netmee — Tue, 25 Aug 2009 12:34:44 +0000

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.

Par : JOE

JOE — Sun, 19 Jul 2009 01:49:58 +0000

Merci, ce truc aide un peu les blogs à être chargés plus rapidement !

Par : monbouquet

monbouquet — Fri, 05 Jun 2009 10:56:44 +0000

Google a sorti Speed :

http://code.google.com/intl/fr/speed/page-speed/

Par : kaa

kaa — Tue, 26 May 2009 18:17:43 +0000

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.

Par : Les billets les plus commentés | Presse-Citron

Les billets les plus commentés | Presse-Citron — Sun, 10 May 2009 22:25:10 +0000

[...] Compresser ses fichiers CSS pour optimiser le temps d’affichage de ses pages web (37 commentaires) [...]