Zend FR

Je suis en train de bosser sur la même chose.
Je peux déjà te faire part des idées que je creuse et écueils potentiels que j'ai identifié.

1/ Je souhaite conserver la liberté de codage, je ne veux donc pas imposer de méthode pour appeler un css ou un js. J'envisage donc de faire un parsing du code html en fin de génération pour récupérer les appels aux script externes css et js.

2/ Je souhaite réduire le nombre de hit css et js a 2 max (1 pour chacun), le temps de résolution dns à souvent un cout plus important que le temps de transfert en lui même. Néanmoins, je veux pouvoir converser un nombre de fichiers sources css et js libre (pour des raisons de maintenance et de clarté). Pour cela, je compte  effectuer la concaténation de tous les css et de tous les js. C'est, à priori sans soucis pour le JS, c'est plus délicat pour les CSS (du fait que les chemins indiqués au sein d'un css sont relatif à l'emplacement du fichier css lui même, il faut donc possiblement faire une mise a jours des path).

3/Je n'ai pas spécialement identifié les algos à utiliser pour le css ou le js, je verrai plutôt une interface dans laquelle on pourra implémenter ou utiliser ce que l'on souhaite. Si demain un algo révolutionnaire sort, cela ne remettra pas en cause la classe.

4/ Il faut envisager la possibilité que les css/js puissent être générés par des scripts php.

5/ Quid des cas ou le js charge d’autre JS (ex : scriptaculous)

5/ La mise en cache doit impérativement faire partie de la classe dès le départ. Pour moi, le but est d'améliorer les perfs d'affichage chez l'utilisateur mais aussi de faire baisser la charge serveur (et donc de servir plus d'utilisateur). Le surcoût de la gestion des js/css par un contrôleur n'est pas viable amha s'il a lieu systématiquement.
J'envisage donc d'avoir plusieurs phases distinctes.
-    Analyse et maj du source html pour recherche des css/js.
-    Vérification des dates de modifications des sources js/css
-    Si cache dispo, on sert le css/js avec un max-age de 1an, sinon on poursuit
-    Concaténation, compression et mise en cache dans un fichier  nommé avec la date de dernière modif la plus récente. (prévoir le nettoyage des entrées du cache).
De ce fait, pour éviter une surcharge CPU, je souhaite que les css et js soit vu comme des ressources statiques et servis par apache comme tels (les performances pour servir une ressource statique sont sans commune mesure avec une ressource php, gain en cpu et en ram).
Je pense donc plutôt a un plugin ou un filtre en post-traitement plutôt qu’à un controleur dédié.

Ex :
Source html avant traitement
<script src=’js/monjs1.js’ type=’text/js’>
<script src=’js/monjs2.js’ type=’text/js’>
<style src=’css/moncss1.css’ type=text/css">
<style src=’css/moncss2.css’ type=text/css">

Source html en sortie
<script src=’cache/js/jscache5515151511.js’ type=’text/js’>
<style src=’cache/css/csscache5521212121.css’ type=text/css">
(Le numéro correspond au timestamp du fichier le plus récent.)

6/ Concernant la compression. Le fait d’effectuer une concaténation devrait apporter un léger gain. Il est plus efficace de compresser unseul gros fichier que plusieurs petits.
Concernant le transport, la compression d’une ressource statique peut etre fait par apache qui s’occupe aussi de la négociation (gzip/pas gzip) voir le module gzip de apache. (Dans mon cas, la compression est effectuée par des proxy hardware). En revanche, on peut effectuer un travail sur les sources afin de maximiser la compression en passant un algo type jsmin ou yiu compressor. L’intéret est que c’est juste de la réécriture. Il n’y a donc pas besoin de javascript pour décompresser le truc coté client et c’est autant de gagner en temps de rendu coté client.

7/ Bien configurer apache pour que le max-age soit important pour cette zone de cache. Le nom de la ressource étant unique, il n’y a aucun interret à la faire recharger par le client.

je ne faisais part que de mes idées, rien de plus. On a pas forcement la même approche et c'est bien là l'intérêt non ?

Ajouter une route de plus ou de moins n'as que peu de conséquence sur le routage. On est d accord la dessus.
En revanche, servir via un MVC une ressource statique type css ou js n'est pas du tout la même chanson. Fait quelques benchs si tu veux t'en assurer. La conso ram et la conso cpu n'ont vraiment rien a voir et je ne serait pas surpris du tout qu'il y a un ratio de 100 mini entre une page css servi par apache et une page css servir par un MVC.

Concernant la concaténation des fichiers, je me suis peut être mal exprimé, mais telle que je l'envisage, elle serait dynamique. Donc, a priori, je ne voie pas pb de modularité.
Quand à paramétrer le même bloc différemment dans 2 fichiers, je doit bien avouer que je ne te suis pas. Si tu choisis de charger 2 fichiers css, il n'y aura aucune différence d'un point de vue DOM si tu charges un fichier équivalent a la concaténation des 2 même fichiers (au pb de path près que j'ai déjà évoqué si les 2 fichiers ne sont pas dans le même répertoire que le fichiers concaténé). Les dernières règles définies ont toujours préséance. Ce qui est surchargé dans un cas l'est de la même façon dans l'autre.
Quand a utiliser N fichiers css avec les N combinaisons possible entre les pages. Tout est affaire de balancier.
D'un coté tu vas avoir n requete dns avec n hits serveur mais des transferts plus petit, d'un autre tu n'auras qu'une requete dns avec 1 hits serveur et un transfert plus gros. En haut débit, la seconde méthode donne de meilleur résultat d'après mes tests.

Pourquoi penses-tu que les dates de modif ne sont pas fiable ? Sauf a explicitement restaurer une date antérieure par un outils externe, quand tu mets a jours un fichier, la date est aussi mis a jours. Faire un hash d'un fichier pour voir s'il a été modifié est certes encore plus fiable, mais extrêmement coûteux, et le surcout est-il réellement justifiable ?

>>Ben pas moi car le principe n'est pas le même. Moi c'est un controleur qui compresse puis basta. Pas de parsing ou de truc freseestyle. C'est toi qui gère si tu veux compressé ceci ou cela> Pas de mauvaise surprise.

J'ai un peu de mal a comprendre ta démarche. Tu postes sur un forum public et cette phrase ne me donne pas l'impression que tu soit disposer à échanger des points de vues. Mais peut etre que j'interprète mal tes propos.

Np.
Pour l'instant, je n'ai fais que des tests et un squelette général. Je n'ai donc rien de concret à montrer pour l'instant. Néanmoins, je te tiens au courant quand j'aurai avancé un peu ou si je trouve d'autre truc sur le sujet.

J'avais lu cet article mais il me semble qu'il y a vraiment très longtemps...
Il couvre bien plus de domaine que la partie que l'on discute traiter ici. C'est beaucoup plus général mais toujours d'actualité.

On pourrait à la limite ouvrir un autre thread voir une section pour traiter des différentes méthodes d'optimisation. Je suis assez porté sur le sujet ...
Mais si certaines techniques sont valable pour tous les sites, d'autre sont très dépendante de la nature du site. Cela reste néanmoins un sujet passionnant et sujet à fortes discussions...

Ca me plait pas mal ton approche Titerm. En revanche pourquoi parser le output html en post dispatch, j'ai peur que cela prenne de la ressource serveur pour pas grand chose. Il serait peut être plus judicieux de demander via le/les controlleurs les fichiers css et js à inclure au doc ...

Good tiens nous au courant ca m'interesse pas mal, et si besoin d'aide hésite pas ...

Dernière modification par Isilgawen (07-01-2008 14:21:39)

MoOx, au début, je faisais aussi plusieurs css et plusieurs js. Et en fonction des besoins, j'incluais ou pas ce qu'il fallait.
Depuis, et après pas mal d'analyse et de test divers. On se rend compte qu'un seul css et un seul JS est plus efficace. Ce sont des sources qui évolue rarement. Une fois chargés par le client, il sont valable pour tous le site et pour les visites futurs. Si en plus on joue sur du cache avec un nom unique, on peut mettre un max age d'un an et tant que il n'y a pas de modif des sources, le nom ne change pas, et donc pendant un an potentiellement, il ne seront pas rechargés. C'est de l'optimisation long terme basé sur le principe que le mec vas revenir sur le site une autre fois ou vas au moins surfer sur plusieurs page durant sa session.
C'est vrai que si le mec charge une page et se barre, il a chargé tous les css et les js mais il avait qu'à pas partir d'abord.

J'aime bien ton idée de regroupe dans des blocks. Je la note

@Titerm: Je prends l'expemple du site que je fais pour ma boite.  Pour l'instant si je prends le code CSS que j'ai j'en ai autant en commun (pour le design global du site) que pour ma page d'accueil. Et nou savons tous que Google ne nous renvoi pas forcément sur la page d'accueil d'un site. Dans le cas où un internaute arrive d'un page quelconque et qu'il navigue sur quelques pages (qui elles aussi auront un code css spécifique peut être aussi grand que le design commun) il aura charger un bon paquet de codes CSS pour rien.
Ceci est bien sur à prendre en compte uniquement pour les site qui ont un design complexe.

De même pour les Javascript. Sur ma page portfolio, j'aurais un code spécifique qui sera complètement inutile sur les autres pages de mon site. Ce cas peut se reproduire pour d'autres pages ayant un comportement bien particulier.

Bien entendu ce genre de cas n'arrive pas pour des sites "basiques"... A méditer.

Sinon à part ça, j'aimerais bien que tu fournisse ton squelette. Ca serait pas bête de bosser en commun. Je me propose de bosser sur la partie compression.

@Phoenix17: Comme tu le dis, c'est à la vue de gérer les CSS. C'est bien pour cela que je fais $this->view->addXXX() plutot que $this->addXXX() au niveau du controller. On peut donc utiliser $this->addXXX() directement depuis la vue...
Dans la même optique je suppose que très souvent tu fais des $this->view->data = 'quelques choses' dans tes controller. Ca se recoupe non?

Question à part est il bete/pas malin/pas judicieux d'utiliser un script PHP4 et de faire une interface pour le ZF? Sachant que ce code PHP4 (http://csstidy.sourceforge.net/) est pas mal du tout.

Merci masi t'inkiète pas les rudiments de ce genre je les connais
Je me suis porté sur CSSTidy car il ne fait pas que minimiser le code. Il est bien plus puissant que cela et n'utilise aucune expressions régulières (les traitements sont donc plus rapide!)

Sans regex = parsing du fichier.
En même temps je me fou à moitié de savoir comment ça marche tant que ça marche . C'est le but de la POO ^^

Sinon pour le coup du margin tu as bien raison. Mais il arrive des fois de coder du CSS pas forcément optimisé. CSSTidy est là pour le faire à notre place

Réponse avec un peu de retard...

@MoOx: La concaténation a ses avantages et ses inconvénients. Il faut faire des tests empiriques pour voir selon les cas de figure ce qui sera le mieux pour chaque site. Mais si on gère des blocks comme tu l'as suggéré, le pb sera gérable. Sur un de nos sites, a un moment, on avait un css global et un css par section de jeux. On a fini par gérer ca autrement et n'avoir qu'un seul css global. En faisant une analyse réseau, on se rendait compte que le coût réseau (dns + protocole http) pour 2 scripts css était très largement supérieur au coût de transfert des données. Et une fois le coût réseau absorbé, il n'y avait pas grande différence entre un transfert de 1ko ou 5ko.
De tte facon, la gestion de css distinct sera obligatoire à cause des médias (css pour impression par exemple).
C'est pour toute ces raisons que je disais au début que pour la partie css, c'était pas si facile que ca. Il y a beaucoup de choses auxquelles  il faut penser. Je pense que le plus sage est d'abord de s'attaquer au js cas c'est beaucoup plus simple. Une fois le mécanisme en place, l'étendre ou l'adapter pour le css.

Je n'ai rien de vraiment propre a présenter, mais je vais essayer de faire une synthèse présentable asap (il faut que je finisse un autre truc avant).

Concernant la compression. Autant je n'ai aucun apriori sur un système de minify (supression des blancs, des commentaires, etc..), autant un truc qui vas trop loin genre optimisation de css, je ne suis pas trop pour. Parfois pour ne pas dire souvent, les css sont vraiment touchy et une syntaxe passe pour un navigateur et pas une autre, c'est relativement complexe a mettre en oeuvre, et si tu te choppes des bugs suite a une optimisations automatique, ca risque d'étre très galère a en trouver la cause. C'est pour cela que je pensais plutot a faire une interface vers un système de compression externe, libre a chacun par la suite d'adapter le système qu'il souhaites  via l'interface. Quitte à fournir 1 ou 2 système de base avec leur adaptations.

NB. Quand j'ai parlé de helper pour la gestion des blocs ou autre, je pensais bien sur a des helpers de vue, pas de controlleur.

C'est sujet qui m'intéresse pas mal donc j'ai effectuer quelques recherches.
Durant mes recherches j'ai trouvé php-speedy http://aciddrop.com/php-speedy/.
En espérant que cela vous sera utile