Voici une bonne année que je travaille avec Jelix, et je le trouve de mieux en mieux. Un grand merci à toute l'équipe.

Je me pose la question depuis quelques jours de compresser le résultat du template (celui qui se trouve dans les fichiers temporaire). Je pense qu'il serait intéressant de rajouter un script au moment de la génération pour tout compresser.

Ce n'est qu'une idée, et je voulais avoir votre avis

Bonjour,

Compresser dans quel sens ?

supprimer les espaces, produire une réponse compressée à la volée avec gzip ?

tout compresser (si c'est retirer les espaces inutiles), c'est chaud. Dans un template, tout n'est pas forcément compressibles. ça dépend déjà du type de contenu (text vs html par ex). Ensuite, même en html, y a des choses qu'il ne faut pas compresser, comme ce qu'il y a dans <pre>. si il faut tenir compte de ça, faut changer tout le moteur de template.

Sans compter que ça peut prendre pas mal de temps à le faire.

Et puis, au final, quel interet ?

Le but de la compression est de supprimer effectivement les espaces, les retraits (tabulation) etc etc ... qui ne servent à rien, attention pas n'importe lesquels biensur Il y a déjà quelques compresseur HTML / JS qui le font. L'intérêt est de réduire le temps et surtout le volume d'information envoyé au client.

J'avais donc pensé, au moment d'écrire le fichier généré par jelix temporaire (le template dans le répertoire Temp) de faire passer le résultat dans une classe permettant de supprimer tout ce qui est inutile. D'après certains tests on peut facilement réduire la taille du fichier envoyé sur le client. Je viens de faire un test avec la page de ce message, j'ai pris la source de la page et je l'ai compressé par un site (http://joliclic.free.fr/php/javascript-packer/en/index.php) Le nombre de caractères de début est de 23903 soit 23 ko environ avant compression, et après 15328 caractères soit environ 15 ko. Ce qui signifie que le serveur qui envoi gagner 8ko à chaque page envoyé. Lors d'une forte charge avec par exemple 1000 utilisateurs qui veulent afficher la même page (ce qui n'est pas beaucoup pour un site à forte charge) cela représente 8ko * 1000 = 8Mo à ne pas envoyer et qui servent à rien. Faites le calcul sur vos serveurs de production, vous verrez ce que vous allez gagner comme débit et donc comme rapidité. En plus l'utilisateur sera tout comptant car ça s'affichera encore plus vite.

Je pense donc qu'il serait intéressant de faire un système pour le compresser dans un premier temps dans le template mais uniquement à la demande du développeur (car pour les tests ça devient vite le bordel), mais laissez la possibilité d'appeler cette fonction pour le renvoi des réponses Ajax et donc améliorer la vitesse d'exécution. Et de moins saturer le réseau.

Je sais qu'à aujourd'hui on parle de vitesse qui absorbent ça très rapidement, mais préférez vous avoir une voiture sur une autoroute surchargé ou être sur la même route avec moins de monde.

Je viens d'étudier la classe qui est en LGPL2.1 (javascript-packer). Le principe est d'enlever les caractères via les expressions régulières, j'ai commencé à tester la classe en l'ntégrant dans une application Jelix. Je calcul en même temps le nombre de caractère que je gagne à chaque fois que j'affiche sur le client.

Je pense qu'il serait intéressant de modifier légèrement le moteur pour rajouter un événement juste après l'enregistrement du fichier temporaire et en passant un parametre le chemin du fichier qu'on vient de générer. Ce qui permettra aux développeurs de mettre en place un système de compression automatique s'il le désire.

Je pense que dans un premier temps ça serait vraiment intéressant. Je vous donnerai prochainement le nombre de caractère que j'économise avec ce système. La charge de travail du processeur n'est pas énorme car c'est uniquement lors de la création du fichier.

Je viens de faire un test avec la page de ce message, j'ai pris la source de la page et je l'ai compressé par un site

tu utilises un compresseur de javascript pour compresser du html. Ton test est totalement invalide donc.

Si tu veux compresser juste du js, je vois pas ce qui t'empeche de le faire en dehors de jelix. Après tout, les fichiers js sont en principe statiques, donc tu peux te faire un script qui, lors de la mise en production, te compresse tes fichiers js (tu peux même utiliser jbuildtools, qui comporte un tel packer)

Les solutions que l'on peut imaginer pour compresser les espaces dans le code html généré:

1) lors de la compilation du fichier tpl en fichier php, jtpl pourrait essayer de compresser ce qui n'est pas tag jtpl.

avantage : ce n'est compressé qu'un fois.

problème : le code html est supposé invalide, puisque généré ultérieurement par les fonctions de jtpl. donc super chaud pour compresser les espaces, étant donné qu'il sera très compliqué de détecter correctement la nature du contenu entre chaque tag.

Sans parler que cette compression ne doit se faire que pour du contenu html, et pas du texte (comme l'utilisation d'un template pour générer un mail etc). Et puis elle ne sera pas optimum. par exemple

foo {tag} bar

on ne peut savoir à l'avance si tag va générer du contenu, et lequel, donc on ne peut pas virer l'un des deux espaces entre foo et bar.

2) lors de la génération du contenu proprement dit, jtpl compresse le résultat.

Pourquoi pas, on résout des problèmes du 1). mais problème : les perfs. compresser à chaque fois, ça pompe pas mal de ressources, (les bons compresseurs HTML sont plutôt lourd), et c'est lent. Je doute que le gain en taille compense la charge supplémentaire sur le serveur que ça induit.

3) pour éviter de compresser à chaque utilisation de jtpl (qui peut être appelé plusieurs fois pour une même page), on compresse le résultat final généré par jResponseHtml

problème : cela nécessite de bufferiser le résultat, donc ça prend de la mémoire. sans compter la mémoire et la baisse de perf induite par le compresseur lui même.

Et au final, je ne trouve aucune de ces solutions satisfaisantes.

Je voterai plutôt pour une compression gzip à la volée des pages web. les navigateurs supportent très bien ça. Et la différence entre un html normal gzippé et un html gzippé avec espaces "compressé", est minime.

La meilleure solution serait donc d'installer l'extension zlib, ça serait ainsi à priori totalement transparent pour jelix.

Une autre solution un peu moins bonne, puisque nécessiterait de bufferiser le contenu généré par jResponseHtml, serait d'utiliser ob_gzhandler.

Bref, je suis plutôt favorable à un support de gzhandler (ou rien du tout avec zlib), que d'ajouter le support de bloatwares compressant les espaces. Ou au pire, une solution comme 1), si les problèmes peuvent être résolu (mais je doute)

Hello,

De mon cote, j'utilise un module apache mod_deflate qui fait le boutlot tres bien. Et qui est configurable via .htaccess. Donc rien à toucher cote PHP.

A+

Je préfère mettre en place, un système qui n'utilise qu'une seule fois le CPU, dans le cas de Jelix enregistrement dans le temporaire (dans la classe jTplCompiler) j'ai rajouté un évenement qui me permet si besoin d'enregistrer le fichier compressé. Ce qui me fait gagner aussi bien de la charge CPU (car je le fais qu'une seule fois) et de la bande passante. A terme je me ferais un script qui va générer les temporaires à la volée qui sera lancé lors de la mise à jour, ce qui me permettra de ne pas utiliser le CPU lors d'une utilisation en production, et d'avoir le gain de bande passante.

J'ai encore deux ou trois problèmes suite aux expressions régulières. J'ai pas beaucoup de temps, mais logiquement je pense que fin de semaine j'aurai quelque chose de fiable ou a peu près.