Cédric
Le 24 oct. 08 à 18:19, Committo,Ergo:sum a écrit :
Le 24 oct. 08 à 17:59, cedric.morin@yterium.com a écrit :
On y gagne :
1 - en minifiant le js/css par le filtre de compactage -> reduction du poids de l'ordre de 30% environ. En particulier à partir du moment ou on utilise cette minification, on hésite plus à commenter ses feuilles de style, ce qui est tout bénéfice
Mettre un filtre qui vire les commentaires aurait le même effet.
C'est ce que fait essentiellement le compacteur de CSS, plus eliminer les espaces inutiles.
Mais le mécanisme étant là, on va pouvoir y ajouter d'autres optimisation, comme y inclure inline les images de background lorsque le navigateur le supporte (toujours dans l'objectif de réduire le nombre de hit)
2 - en réduisant le nombre de requetes client/serveur qui passent de N à 1 pour le js et M à 1 par média pour le Css
Ca n'est pas illusoire car même au délà de la première page vue, si le navigateur stocke les css et les js en cache, il produit un hit à chaque page pour chaque fichier pour vérifier que le fichier n'a pas changé.
La stratégie must-revalidate (au lieu d'un délai minimmum) a été amenée lors de la 1.9, et Ouvaton nous l'a assez reprochée.
Sans faire un complet retour en arrière en ce qui concerne les articles etc (à cause de l'activité des forums surtout),
on peut tout de même se demander si elle est bien raisonnable pour des pages aussi pérennes que les Css ou les biblis JS.
Oui un Expire niveau serveur permet déjà de gagner des hits (un wrapper php sur une css statique est par contre une mauvaise idée).
Mais je t'assure que quand tu fais de l'optimisation sur un site à fort trafic, il n'est pas rare de constater plus de 70% de rebond sur la première page chargée. C'est à dire que 70 % des visiteurs ne voient qu'une page.
Et pour eux les directives Expire n'amènent aucun gain.
L'enjeu est aussi de réduire le nombre de hit sur le serveur, car chaque hit a un coût non nul en terme de charge.
Cette stratégie qui peut paraître accessoire pour des petits sites ne l'est pas si on se place du point de vue du serveur complet, donc sur les hébergements mutualisés.
Tout cela est significatif à partir du moment où on utilise de multiples css et/ou js, donc en particulier dès qu'on installe des plugins qui ajoutent chacun qui leur feuille de style, qui leur javascript.
Oui mais quand on met au point ses feuilles de style, le fait que Firebug ne puisse plus dire de quel fichier vient telle classe est vraiment pénible. Et le code actuel est absurde parce que l'éclatement des feuilles de styles en plusieurs ne rime à rien à cause du bug corrigé par 13208 mais aussi parce que les balises FORMULAIRE_* référence des classes qui sont dans toutes les feuilles, et pas uniquement dans formulaire_css. Alors leur réunions par le compacte-css, c'est vraiment pourquoi faire simple quand on peut faire compliqué. Déjà que les CSS ont été conçu dans cet esprit, là c'est le délire.
Pour la mise au point, on désactive le compacteur (il y a un define pour le faire cote ecrire/, car cela ne concerne que le core a priori)
Et tu raisonne là uniquement à périmètre fixe et connu qui est le core.
Dès qu'on charge N plugins, chacun est suceptible d'amener ses ajouts et surcharges (au sens CSS) de style, y compris dans l'espace privé.
L'atomisation en de nombreuses CSS plutôt qu'une grosse permet par ailleurs la personnalisation et la surcharge (au sens SPIP) ciblée des CSS alors qu'une grosse feuille unique oblige à tout forker.
Jusqu'ici cela se traduisait par un rallongement du temps de chargement des pages de l'espace privé, ce qui n'est plus le cas avec la 2.0
Je t'assure que ce n'est pas le délire, et qu'un projet type actuel comporte de nombreuses CSS et js, et que cette optimisation répond vraiment à un besoin.
Va sur n'importe quel site web moderne, et compte le nombre de hit js et css au chargement...
Cédric