Group items tagged

Comme je suis chiant moi j'ai repassé ton image à pngnqi (http://pornel.net/pngnq, sous linux mieux vaut rester sur le pnqnq "normal", les sources sont à jours avec le pngnqi). Je suis tombé à 7397 octets (8321 octets pour l'original). C'est toujours un peu magique pour moi les outils d'optimisation d'image, très vaste comme sujet.

pngnq il ne fait pas une quantification et donc une modification de la qualité de l'image ? Peut être que visuellement elle n'est pas impactante, mais si c'est le cas ce n'est pas un outil utilisable en automatique et d'un coup le bénéfice/cout par rapport à optipng devient assez faible

oulà, je n'avais pas encore vu le lien, faire tourner pngcrush + optipng + advpng, ça fait lourd en cpu. Est-ce que vraiment le gain par rapport à un optipng (qui normalement fait tout ce que fait pngcrush) vaut le coup ? Quand j'avais tenté tous mes tests sur différents outils et différents paramètres, j'étais revenu à la raison : le surcout par rapport au optipng avec les options par défaut vaut rarement les différence de taille au résultat

Pour utilise pngnq en automatique, il faut contrôler le nombre de couleurs dans l'image, car si on lui passe un png24 il en fait un png8. En gros en dessous de 2500 couleurs, on peut tranquilement passer à un png8. Bien sûr il faut faire des vérifications derrière. Trop souvent on utilise du png24 là où on devrait utiliser du png8. Png8 sait faire la transparence alpha (IE6 ne la comprends pas = pixel transparent mais pas un pâté gris comme sur le png24). Il faudra que j'expose mon programme nodejs qui fait tous ces contrôles et est paramétrable Voir http://zeroload.net/blog/zeroload%20latest%20achievements%20in%20web%20performance%20%28with%20details%29/

Eric > Je ne comprends pas, ou plutôt je fais semblant de ne pas comprendre . Pourquoi le temps CPU pour optimiser les images est t'il si important ? Tu as déjà été confronté à des traitements supérieur à plusieurs jours (même parallélisés) ? Trois cas possible d'optimisation : 1. Optimiser par l'intégrateur (cas idéal) 2. Au moment de l'upload 3. Traitement par lot , en tâche de fond, N date / heure précise Dans le deuxième cas, mise à part des png supérieur à 3 - 4 mo, l'optimisation même maximum ne devrait pas poser de problème , si ? Dans le troisième cas, il y a toujours moyen de basculer les calculs pendant les heures creuses, voir d'utiliser temporaire des serveurs pour générer les nouveaux média (png, jpg). Une fois le média optimisé au maximum on n'y revient pas. Je dois probablement sous-estimer les temps de calculs, a t'on un ordre d'idée (Tps de calcul / Taille du png) ?

Les temps se calculent en minutes (donc quelques heures pour traiter un lot). Ce n'est pas tant le cpu en lui même, c'est que ça peut différer une mise en production, et que toutes les boites n'ont pas une machines qui pourrait faire ça. Oui, je sais bien que trouver quelques heures de CPU devrait être ridicule, mais ça nécessite dans pas mal de boites d'allouer une machine spécifique, et ça ce n'est pas si anodin que ça (même si c'est crétin). Et oui, normalement les releases sont prévues à l'avance, surtout les éléments graphiques, mais en pratique ce n'est pas aussi bien fait et devoir lancer un traitement de quelques heures c'est ultra pénible. Mais surtout, quand la différence avec un simple optipng est de moins de 10Ko sur une page, au final ça ne vaut pas le coup de lancer une grosse automatisation et laisser l'outil sur le poste de l'intégrateur web (où le temps cpu ça compte) suffit largement.

je suis pas d'accord avec tout. par exemple : "Don't [tag qualify] with class names either" => j'avais justement lu le contraire. Qu'un "a.toto" était plus efficace qu'un ".toto". Mais ça dépend aussi peut-être des moteurs... D'ailleurs, je ne comprends pas pourquoi les moteurs ne cherchent pas d'abord le bout le plus discriminant dans le sélecteur. Ça arrive souvent de commencer un sélecteur par un sélecteur d'ID, et il me semble que ce serait plus rapide que de commencer par lui, plutôt que par le tag qui se trouve à la fin (ex: #menu a { }).

Oui si .toto est présent sur le même type de tag à savoir "ul" ..inutile d'écrire ul.toto. " .toto" suffit et est apparement plus rapide à interpréter. C'est le cas pour les nouveau parseurs DOM il me semble (firefox). Après savoir si tous la navigateurs se comportent de la même façon sur ce point, je l'ignore.

mais par exemple, dans un jQuery, c'est le contraire, semble-t-il. Si la perf de querySelectorAll est la même que celle utilisée pour appliquer les CSS, on doit pouvoir tester avec jsperf.com.

"Use class selectors instead of descendant selectors." http://code.google.com/intl/fr/speed/page-speed/docs/rendering.html "It's clear that CSS selectors with a key selector that matches many elements can noticeably slow down web pages." http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/

Oui, c'est l'opposé sur jquery, parce que jquery ne peut pas utiliser les index du navigateur efficacement. Ceci dit ça peut changer à l'avenir pour jquery au fur et à mesure qu'ils pourront utiliser les API querySelector et ce genre de choses. Deux règles : - finir de préférence sur le sélecteur #id, ou .classe, éventuellement un nom de balise (mais si possible pas un trop fréquent), pas de sélecteurs plus complexes (attribut seul, pseudo sélecteur, *) - éviter de surspécifier le sélecteur à gauche

"finir de préférence sur le sélecteur #id" : si on peut faire ça, autant le mettre directement tout seul, non ?

Non, car ton élément #id peut avoir un style différent selon le contexte

Sachant que la plupart (tous) des navigateurs lisent les règles CSS de droite à gauche, il vaut mieux éviter de spécifier le tagName. Dans des librairies comme jQuery le problème est un peu différent même si jQuery (sizzle) lit aussi de la droite vers la gauche. Sur les navigateurs qui n'implémentent pas certaines fonctionnalités comme getElementsByClassName (IE6-8), sélectionner $('.maclasse') sera plus long que $('a.maclasse'). Le mieux étant de faire $('.maclasse', noeudDomDeDepart) si on sait a peu près où sont les classes pour éviter de traverser tout le DOM. Autre différence $('#mydiv span');sera plus rapide que $('span'); Alors qu'on pourrait croire que jQuery lit toujours de la droite vers la gauche, il effectuera une exception ici et sélectionnera d'abord $('#mydiv') puis regardera les "span". (http://forum.jquery.com/topic/about-selectors-right-to-left#14737000000472293) Enfin si on travaille sur des noeuds qui ne sont pas encore dans le DOM (pas de append()) , les méthodes employées pour parcourir le noeud seront de simples boucles qui regardent tous les noeuds, pas d'accès à getElementsByClasseName ni getElementbyId. Là dans ce cas il vaut mieux spécifier carrément le tagName + la classe (voire l'ID) ça évite de faire des tours de boucle pour rien. ça reste des cas franchement spécifiques qui ne devraient pas exister, on ne parcourt pas des noeuds html qui ne sont pas dans le DOM dans une application classique et on évite de faire des sélections brutes de $('.classe') si on connait a peu près la structure DOM. Edit: jquery (sizzle) utilise querySelectorAll quand disponible, sinon des méthodes perso combinées avec getElementbyId, className, tagname. http://www.neeraj.name/2010/02/15/how-jquery-selects-elements-using-sizzle.html

Comme j'aime bien embêter : Jquery et le natif utilisent les algos aux propriétés presque opposées dans certains cas. Comme le jquery peut renvoyer vers le natif, si vous cherchez trop la bête, vous irez forcément dans le mur sur certains navigateurs. Bref, faites simple. Un "#xxx .yyy" sera à peu près acceptable sur jquery comme sur le natif pour peu qu'on n'utilise pas trop souvent la classe en dehors de l'arbre #xxx. C'est peut être le compromis qui passera le mieux partout (simple pour le navigateur parce qu'il utilise son index pour trouver le .yyy, que remonter au #xxx sera rapide, et qu'il ne remontera pas trop souvent inutilement ; et simple pour jquery parce que grâce à #xxx il peut isoler un arbre DOM restreint sur lequel lancer sa recherche)

Comme cette discussion est oriente vers le js: Des selecteurs optimisés c'est bien, un bon design d'application c'est mieux. selection d'une collection - binding d'une fonction sur ces éléments ---> anti-pattern. Event Delegation ----> pattern (lors de l initialisation) selection d'une collection - modification de propriétés css ----> anti-pattern insertion d'html préstylé (classes) ---> Pattern