Reprise du message précédent :

1. Le cache du navigateur, c'est lolzland. En pratique Yahoo avait montré des graphes pendant une conf il y a quelques temps et le cache du navigateur, pour les CSS comme pour le JS, était en moyenne utilisé dans 10 à 15% des requêtes. Donc en moyenne sur 10 visites ta CSS se fait charger 9 fois
2. En bonus, la bande passante, aux dernières nouvelles, c'est pas gratuit. CSS plus légère = moins de consommation de bande passante = potentiellement moins de coûts, surtout quand tu as un nombre appréciable de visiteurs

Tu fous le stripping des newlines, spaces et tabs dans ton script de build/déploiement, ça te coûte 10mn le temps de tout bien faire et de corriger une paire de bugs et c'est terminé

et on sait pourquoi? prob de config des navigateurs, "bug" des navigateurs, prob de config de serveurs, "bug" des applis deployées sur le server ?

Ouais, de nos jours, avec les mises en caches des navigateurs, c'est comme le combat des ms, de l'enculade de mouche...  

Probablement 1 & 2, parce que vu leur traffic je pense que chez Yahoo ils font gaffe à leur config

Sauf que le cache des navigateurs est une douce illusion, quand au combat des ms ce qui représente quelques ms pour un navigateur desktop c'est une misère pour e.g. un téléphone portable (y compris en 3G, il m'arrive de surfer sur HFR depuis mon portable, ben même avec un E70 en 3G c'est la dèche )

en 3G, c'est pas le débit qui fait ramer le tout, mais la latence

Ne t'inquiète pas pour ça, le débit n'arrange rien du tout (même si les problèmes principaux viennent effectivement de la latence, pour tout le web mobile en général)

Ah, correction par contre, je me souvenais de chiffres très différents mais je viens de retrouver les stats de Yahoo, ce ne sont pas 10 à 15% des visiteurs qui n'ont rien en cache mais 40 à 60%, ce qui est notablement mieux mais fait néamoins, en moyenne, 50% des utilisateurs qui n'ont pas les données en cache, et ils ajoutent que 20% des pages sont vues sans aucune donnée en cache.

http://yuiblog.com/blog/2007/01/04 [...] ch-part-2/

Sachant que la différence entre une page chargée avec le cache et une page chargée sans le cache chez Yahoo c'est:

(les temps sont mesurés sur une connection cable de 2.5MBps)

(edit: d'ailleurs pour les problèmes de latence et pour améliorer la compressibilité gzip, il me semble que les dernières versions de Rails combinent les fichiers JS et CSS avant de les servir)

 
Ça peut être marrant si tu strippe un whitespace nécessaire à un hack CSS
 
( Non, je n'ai pas vérifié la liste des hacks pour savoir si c'est vraiment le cas, perds pas 20min à faire une recherche de tout les hacks pour me démontrer que ça ne peut pas arriver )

• Tu utilises pas de hack CSS nécessitant un espace
• Tu vérifies tes hacks et si il y en a qui utilisent des espaces, tu les prends en compte en créant ton script de stripping

Bon, en comptant ça je monte le temps pris par la création du script de stripping à 20mn, ça te va?

nan, à partir du moment ou tu dois ouvrir un navigateur pour chercher une info tu va forcément checker le forum, tes mails et suivre 2-3 liens au passage, faut bien 2h pour faire ton truc, et encore c'est si t'arrive à éviter wikipedia

Surtout que certains éditeurs PHP permettent en 1 clic d'adapter la forme du CSS directement, soit pour prod tout compacté, soit pour développement tout espacé/lisible et encore y a plein d'options (genre virer les ; inutiles, les espaces avant/après {, etc.)

Les caractère pour les hacks les plus utilisés c'est :

"_" IE6
"//" IE6 et 7
":first-child+html" IE7
"#" Opera
"@media" Safari

@The-Shadow : Tu dois connaitre firebug, t'as un onglet net, et le nombre de fois ou il écrit 'from cache' dans une session de surf, c'est lolant
Quand tu fais des sites à grosses fréquentations, une css ou un code bien foutu, c'est pas 0.4 secondes  en 1600 jours - j'ai mis en jour pour bien relever l'énormité de ta phrase - que tu fais gagner à l'internaute, c'est juste des coûts bp que t'économises. Mais bon on s'en branle hein? Les memory leaks aussi on s'en branle, c'est de l'optimisation qui te fait gagner 100mo par ci ou par la

Nan, les memory leaks, c'est bon mangeai-zen !
Bah oui, on consomme plus de mémoire, donc achat de RAM pour augmenter la capacité, donc production, donc concurrence, donc guerre des prix -> tout benef

Non mais tu me diras ce que tu veux, c'est du vent. Demander de retirer les retours à la ligne, on atteint des sommets dans l'art de la masturbation de mouche.
Tu prends 3 gifs, tu les recadres d'un pixel et hop, t'as 12 ko d'avances pour tes CSS.
 
Et dans vos CSS, plutot que d'appeler vos blocs "menu" vous les appelez "mn" ? Non parce que bon, ça vous ferait gagner 2 octects, c'est pas négligeable.  

 
ça me rapelle un époque lointaine ou je codé en C (95) et on fesait tout pour économiser, style, sur un char donc 1 octet, on pouvait utiliser 8 flags  

Taille des gif sur mon système (grosse quantité de page web via de la doc + divers projets ) :

Sachant que dans tout ceux à 4k y'a ceux de taille inférieure mais qui occupent 4k sur le disque...

Qui réduit de 25% la taille des fichiers alors que le truc est automatisé

Je comprend pas comment tu refuses un gain net alors que le coût est de 0

On doit pas avoir les mêmes gifs dans ce cas, parce que chez moi un gif ça fait moins de 300 octets, au dessus c'est du PNG 95% du temps, et pour gagner 12k sur des gifs de 300 octets et moins il va faloir y aller

Sauf que la perte en maintenabilité n'est pas non plus négligeable, le dégageage d'espace dans les CSS de prod ne change pas la maintenabilité du site, il ne fait que réduire la taille des données à transférer, strictement aucun rapport donc.

Si tu veux faire un parallèle, on peut comparer ça à activer la compression GZIP dans Apache.

Tu désactives la compression GZIP parce que "c'est de l'enculage de mouches" toi

Ne racontes pas n'importe quoi non plus, la compression Gzip c'est un gain qui peut aller jusqu'à 900%, rien à voir avec ton cache misère pour gagner 3 octets.
Et en ce qui me concerne, je trouve que la suppression des retours à la ligne ne favorise aucunement la maintenabilité. A moins bien sûr de conserver l'original et le "nettoyé". Bonjour la praticité de la chose.

Tu as un fichier CSS de prod sans les retour à la ligne. Et tu as un fichier CSS "source" tout beau avec lequel tu travailles.

Whoa, tu veux dire qu'un fichier de 10k fait -80k quand tu le gzippe

ptin c'est cool, un fichier qui prend de la bande passante négative

J'ai donné les chiffres, sur le fichier CSS concerné on gagne 25% si le fichier n'est pas gzippé (5k sur 19k) et 15% si il l'est (0.5k pour 3k), et encore l'indentation est faite à coup de tabs, avec des espaces on gagnerait plus sur le fichier non gzippé

Vas sérieusement faloir que tu t'achètes des lunettes, je n'ai jamais dit que ça favorisait la maintenabilité le fichier final est un paté illisible, donc ça va avoir du mal), j'ai dit que ça ne la modifiait pas

Je sais pas comment tu bosses, mais chez moi il y a d'un côté le code de dev stocké dans le gestionnaire de sources (SVN, Darcs, Mercurial), et de l'autre le code de prod généré et déployé proprement via un script de build qui se charge de tout packager, de faire des tests si besoin (tests unitaires ou autres) et de balancer les fichiers "de prod" sur le serveur. Le stripping de whitespace se fait à ce moment là et est donc totalement automatique et invisible pour le dev

Ce que tu veux.
 
Alors déja, je perdrais moins de temps à nettoyer ma css et mon qu'a retailler des images, respectivement j'ai écris un script ruby qui s'en charge, et le js sera compressé.
Et si tu perds 20 minutes à retailler des images, tu peux perdre 3 minutes à nettoyer tes css  

Attendez vous enflammez pas avec vos chiffres!
 
Masklinn, du 900% ça veut dire que:
 
10/ (1 + 900/100) = 1
 
Donc ton fichier de 10k se gzip en fichier de 1k.  
 
EDIT:

Tu ferais pas un de rails toi par hasard  

 
Ca c'est un gain de 90% (10 * (1 - 90/100) = 1), un gain de 900% sur un fichier de 10k c'est (10 * (1 - 900/100)) qui renvoie -80

edit: et pour clarifier: http://fr.wikipedia.org/wiki/Pourc [...] _courantes

et ce n'est pas parce que l'erreur est courante qu'elle n'est pas une erreur.

Bah ça dépend comment tu définies ton gain. Pour toi un gain de 100% ça veut dire quoi?
 
Chez moi, ça revient à diviser par 2. Avec ton calcul ça fait zéro.
 
EDIT: pour passer de 10 à 1, effectivemment ça fait 90%. Mais pour passer de 1 à 100, il faut 900%. Voilà l'explication  

Ben tu te plantes et tu ne sais pas utiliser les pourcentages

Et c'est le résultat correct, cf l'article que j'ai lié tu te plantes de méthode.

Et donc? Ca n'a aucun rapport avec le calcul effectué ici, un fichier qui passe de 10k à 1k c'est un gain de 90%, pas un gain de 900%.

Non, ça veut dire qu'un fichier de 20ko après une compression Gzip peut tomber à 2Ko, 2Ko x 900% = 18Ko.
C'est vrai que j'aurais pu compter dans l'autre sens, comment ai-je pu avoir l'affront de penser que tu ferais un effort de plus de 4 secondes pour comprendre ma façon de compter, c'est tellement plus drole de prendre 6 secondes pour compter dans l'autre sens et lancer une tentative de cassage.

Bon, sujet clos pour moi, encore la masturbation intellectuelle habituelle de l'élite.

Oh j'ai très bien compris ce que tu voulais dire, et ça ne change rien au fait que ta "façon de compter" est totalement incorrecte, un gain de 900% sur un fichier de taille N ça donne une taille de -(8*N), de même qu'une augmentation de 120% sur ce même fichier ça donne une taille de (2.2*N) et pas une taille de (1.2*N) qui correspond à une augmentation de 20%

 
BashFr !
 
Et quand ya les soldes à 50%, ça divise par combien, dans ton pays ?

Bah si, même si je vois pas le rapport avec le nettoyage de css  

 
Tu sais pas compter là

Moi quand j'ai un gain de 100%, j'ai deux fois plus de pognon.  
 
D'un autre côté, j'ai bien vu des fausses promos du genre "20% de réduction" qui servent à masquer une vrai augmentation de 25%.
 
Enfin bon, est ce que le calcul de gain sur un fichier vaut le coup de perdre deux heures sur comment le calculer?

Bon vogueules, le forum de clubic sent le caca, c'est le sujet.

Nan, Masklinn raconte nawak

Hey, le noob, retourne sur Developpez.com

Tu ne sais pas mieux que the_shadow utiliser les pourcentages, c'est ton problème, ma version est correcte  
 

Mais wé

Mais c'est fini oui?

 
Ouais enfin on va pas rappeler tes résultats au bac en maths    

J'en ai passé un 2nd où j'ai tout roxxé

Bon t'as fini ?
Si 2k = 100%
20ko = 1000%
Si tu retires 18ko = 900% du poids total, tu gagnes donc 900% en bande passante.
Arrêtes d'être bête et de chercher toujours la petite bête comme ça, c'est saoulant de te voir vouloir jouer les intellectuels sur un truc si futile.
 

En fait, tu devrais revoir tes cours du cycle inferieur... Masklinn a totalement raison.

18ko = 90% (pour relancer )

edit: grilled