[LONG] Syntaxe HEREDOC et inclusion de javascript, je nage...
35 réponses
Eric Demeester
Bonjour,
Dans le but d'externaliser le code javascript inclus dans un script php
dont je ne suis pas l'auteur [*], j'essaye de comprendre comment il a
été construit, et ça commence à me faire mal à la tête...
Voici une fonction mélangeant php et javascript, il y en a plusieurs
comme ça dans le script en question.
Ce que fait la fonction a peu d'importance, ni le nom des variables, ce
qui m'intéresse, c'est la logique (?) de l'imbrication PHP/javascript et
comment réécrire ça proprement...
Mes commentaires concernant ce que je crois comprendre sont entre
crochets.
......................................................................
function rotator_fade_orig( $mod, $fileList, $_params, $speed,
$speed_fade, $number, $url, $url_class, $url_target )
{
$stamp1 = <<<EOT
<script type="text/javascript" language="javascript">
<!--
var j{$mod}=0;
var rotImg{$mod}=new Array();
if (document.images){
EOT;
[ j'en déduis que $stamp1 contient la chaîne littérale contenue entre
<<<EOT et EOT;, et que la valeur de la variable $mod passée en
paramètre à la fonction est affectée à deux variables du javascript,
et ci-dessous on revient au PHP, j'ai bon jusque là ? ]
[ Le foreach ci-dessus et le $_out, c'est bien du PHP qui continue à
construire la chaîne $stamp1, mais on est toujours dans le javascript,
puisqu'on a pas encore rencontré de </script>. Donc le bidule est en
train de construire dynamiquement du javascript à la volée, j'ai
toujours bon ? Ci-dessous, on repasse en syntaxe HEREDOC : ]
$stamp2 = <<<EOT
}
function rotator$mod() {
if (document.all){
document.images.rot_img{$mod}.style.filter="blendTrans(duration={$speed_fade})";
document.images.rot_img{$mod}.filters.blendTrans.Apply();
}
document.images.rot_img{$mod}.src=rotImg{$mod}[j{$mod}].src;
if (document.all)
document.images.rot_img{$mod}.filters.blendTrans.Play();
if (j{$mod}<({$number}-1))
j{$mod}=j{$mod}+1;
else
j{$mod}=0;
[ On s'intéresse maintenant à la chaîne littérale $stamp2, qui comme
$stamp1 est en fait du javascript assaisonné de variables passées par
le PHP. Puis vient la fin du script. {$_out} entre accolades juste
avant la réouverture d'un script appelant la fonction rotator, je ne
comprends pas sa syntaxe... ]
return $stamp1.$stamp2;
}
[ ici, fin de la fonction PHP, qui renvoie la concaténation des deux
chaînes à la fonction appelante, laquelle insérera le javascript
dans la page appelante ($_out je suppose) ]
......................................................................
En résumé, si j'ai compris la philosophie de la chose, je pourrais
résoudre mon problème de séparation des genres en écrivant le javascript
dans un fichier texte puis appeler ce fichier dans les en-têtes de la
page, plutôt que d'insérer directement le javascript dans le corps de la
page html générée ?
Tout ça parce qu'un spécialiste du référencement (sic) n'aime pas le
javascript dans les pages « parce que ça perturbe les robots » :(
Si vous avez des idées, des commentaires, des suggestions, cela me sera
d'un grand secours.
Merci aux personnes qui auront eu la patience de me lire.
[*] Il s'agit de function.image_rotator.php, qui est un plugin de
cms made simple :
http://dev.cmsmadesimple.org/project/files/172#package-220
C'est ce qui fait défiler les portraits en haut à droite sur :
http://www.opusinfide.com/
Dans la mesure ou j'ai activé la compression au niveau de php :
zlib.output_compression = On zlib.output_compression_level = 6
C'est vraiment utile d'aller en plus concaténer et compresser les css et les javascript en amont ?
zlib.output_compression, ça va compresser ce qu'interprète et renvoie PHP. Donc en gros, le contenu html. Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça devrait aussi compresser ces types de fichiers. Mais je n'ai jamais essayé (en fait, j'y ai pensé en te répondant.) Le reste n'étant pas interprété par PHP, c'est à apache que tu dois le dire. Pour example, mon deflate.conf de apache 2.2 (tout ça peut se mettre dans un .htaccess) : <FilesMatch ".(html|js|css)$"> <IfModule mod_deflate.c> SetOutputFilter DEFLATE </IfModule> </FilesMatch> Addtype font/opentype .otf .eot Addtype font/truetype .ttf AddOutputFilterByType DEFLATE font/opentype font/truetype font/eot DeflateCompressionLevel 9
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css. Je compresse aussi les webfont (très bonne chose aussi si tu en utilises.)
La concaténation, c'est tout autre chose : tu évites ainsi des requêtes serveur inutiles. Et quand tu sais le nombre d'échanges qu'il y a pour chaque requête, tu comprends qu'il est bon de réduire tout ça. Si en plus tes serveurs sont éloignés géographiquement, ça devient indispensable.
Hop, je viens d'installer Firebug et Pagespeed [*]. Sur la page d'accueil du site, j'obtiens 82%, sur les autres, 84% en moyenne. C'est donc encore améliorable, mais puisque tu sembles avoir de l'expérience dans l'utilisation de cet outil, est-ce un score excellent, bon, moyen, catastrophique ?
Catastrophique, il y a peu de risque. Je ne peux pas trop m'étendre car ça prendre un certain nombre de pages, mais disons que l'essentiel est de minimiser le nombre de requêtes et la taille du flux, donc : - bien configurer les expires headers - activer la compression sur php, html, js, css - prévoir un script de minification (!= compression) pour tes css et js - créer des sprites (toutes les images de déco agglomérées en une seule et même image, découpée ensuite par css : tu as des applis on/offline pour t'aider) - concaténer tes css et js (toujours, idéalement, avec un script histoire de garder tes fichiers sources distincts et intacts)
Tu trouveras beaucoup de détails et de bon conseils dans les aides de pagespeed et yslow.
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en place.
Ça ne va pas être possible pour le moment sur mon serveur, parce que je doute qu'il soit compatible avec l'Apache 1.3.27 antédiluvien qui y tourne, et que je me garderai bien de passer en 2.2. parce que ce serait trop compliqué (FreeBSD hors d'âge, dépendances, patin couffin, j'ai déjà galéré des heures pour le passer en php5).
Ouah en effet ! C'est encore maintenu la 1.3 ?
Ceci dit, grand merci pour tes explications et tes conseils !
[*] J'ai l'habitude d'utiliser web Developer, d'où l'absence de Firebug sur ma machine jusqu'à maintenant.
Firebug est absolument indispensable si tu fait du dev web. webdevelopper est parfois utile, mais il m'est très peu utile désormais.
Le 26/02/2011 13:38, Eric Demeester a écrit :
Dans la mesure ou j'ai activé la compression au niveau de php :
zlib.output_compression = On
zlib.output_compression_level = 6
C'est vraiment utile d'aller en plus concaténer et compresser les css et
les javascript en amont ?
zlib.output_compression, ça va compresser ce qu'interprète et renvoie
PHP. Donc en gros, le contenu html.
Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça
devrait aussi compresser ces types de fichiers. Mais je n'ai jamais
essayé (en fait, j'y ai pensé en te répondant.)
Le reste n'étant pas interprété par PHP, c'est à apache que tu dois le dire.
Pour example, mon deflate.conf de apache 2.2 (tout ça peut se mettre
dans un .htaccess) :
<FilesMatch ".(html|js|css)$">
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>
</FilesMatch>
Addtype font/opentype .otf .eot
Addtype font/truetype .ttf
AddOutputFilterByType DEFLATE font/opentype font/truetype font/eot
DeflateCompressionLevel 9
Ce qui permet de compresser à la volée les fichiers ayant comme
extension html, js et css.
Je compresse aussi les webfont (très bonne chose aussi si tu en utilises.)
La concaténation, c'est tout autre chose : tu évites ainsi des requêtes
serveur inutiles. Et quand tu sais le nombre d'échanges qu'il y a pour
chaque requête, tu comprends qu'il est bon de réduire tout ça. Si en
plus tes serveurs sont éloignés géographiquement, ça devient indispensable.
Hop, je viens d'installer Firebug et Pagespeed [*]. Sur la page
d'accueil du site, j'obtiens 82%, sur les autres, 84% en moyenne. C'est
donc encore améliorable, mais puisque tu sembles avoir de l'expérience
dans l'utilisation de cet outil, est-ce un score excellent, bon, moyen,
catastrophique ?
Catastrophique, il y a peu de risque. Je ne peux pas trop m'étendre car
ça prendre un certain nombre de pages, mais disons que l'essentiel est
de minimiser le nombre de requêtes et la taille du flux, donc :
- bien configurer les expires headers
- activer la compression sur php, html, js, css
- prévoir un script de minification (!= compression) pour tes css et js
- créer des sprites (toutes les images de déco agglomérées en une seule
et même image, découpée ensuite par css : tu as des applis on/offline
pour t'aider)
- concaténer tes css et js (toujours, idéalement, avec un script
histoire de garder tes fichiers sources distincts et intacts)
Tu trouveras beaucoup de détails et de bon conseils dans les aides de
pagespeed et yslow.
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en
place.
Ça ne va pas être possible pour le moment sur mon serveur, parce que je
doute qu'il soit compatible avec l'Apache 1.3.27 antédiluvien qui y
tourne, et que je me garderai bien de passer en 2.2. parce que ce serait
trop compliqué (FreeBSD hors d'âge, dépendances, patin couffin, j'ai
déjà galéré des heures pour le passer en php5).
Ouah en effet ! C'est encore maintenu la 1.3 ?
Ceci dit, grand merci pour tes explications et tes conseils !
[*] J'ai l'habitude d'utiliser web Developer, d'où l'absence de Firebug
sur ma machine jusqu'à maintenant.
Firebug est absolument indispensable si tu fait du dev web.
webdevelopper est parfois utile, mais il m'est très peu utile désormais.
Dans la mesure ou j'ai activé la compression au niveau de php :
zlib.output_compression = On zlib.output_compression_level = 6
C'est vraiment utile d'aller en plus concaténer et compresser les css et les javascript en amont ?
zlib.output_compression, ça va compresser ce qu'interprète et renvoie PHP. Donc en gros, le contenu html. Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça devrait aussi compresser ces types de fichiers. Mais je n'ai jamais essayé (en fait, j'y ai pensé en te répondant.) Le reste n'étant pas interprété par PHP, c'est à apache que tu dois le dire. Pour example, mon deflate.conf de apache 2.2 (tout ça peut se mettre dans un .htaccess) : <FilesMatch ".(html|js|css)$"> <IfModule mod_deflate.c> SetOutputFilter DEFLATE </IfModule> </FilesMatch> Addtype font/opentype .otf .eot Addtype font/truetype .ttf AddOutputFilterByType DEFLATE font/opentype font/truetype font/eot DeflateCompressionLevel 9
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css. Je compresse aussi les webfont (très bonne chose aussi si tu en utilises.)
La concaténation, c'est tout autre chose : tu évites ainsi des requêtes serveur inutiles. Et quand tu sais le nombre d'échanges qu'il y a pour chaque requête, tu comprends qu'il est bon de réduire tout ça. Si en plus tes serveurs sont éloignés géographiquement, ça devient indispensable.
Hop, je viens d'installer Firebug et Pagespeed [*]. Sur la page d'accueil du site, j'obtiens 82%, sur les autres, 84% en moyenne. C'est donc encore améliorable, mais puisque tu sembles avoir de l'expérience dans l'utilisation de cet outil, est-ce un score excellent, bon, moyen, catastrophique ?
Catastrophique, il y a peu de risque. Je ne peux pas trop m'étendre car ça prendre un certain nombre de pages, mais disons que l'essentiel est de minimiser le nombre de requêtes et la taille du flux, donc : - bien configurer les expires headers - activer la compression sur php, html, js, css - prévoir un script de minification (!= compression) pour tes css et js - créer des sprites (toutes les images de déco agglomérées en une seule et même image, découpée ensuite par css : tu as des applis on/offline pour t'aider) - concaténer tes css et js (toujours, idéalement, avec un script histoire de garder tes fichiers sources distincts et intacts)
Tu trouveras beaucoup de détails et de bon conseils dans les aides de pagespeed et yslow.
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en place.
Ça ne va pas être possible pour le moment sur mon serveur, parce que je doute qu'il soit compatible avec l'Apache 1.3.27 antédiluvien qui y tourne, et que je me garderai bien de passer en 2.2. parce que ce serait trop compliqué (FreeBSD hors d'âge, dépendances, patin couffin, j'ai déjà galéré des heures pour le passer en php5).
Ouah en effet ! C'est encore maintenu la 1.3 ?
Ceci dit, grand merci pour tes explications et tes conseils !
[*] J'ai l'habitude d'utiliser web Developer, d'où l'absence de Firebug sur ma machine jusqu'à maintenant.
Firebug est absolument indispensable si tu fait du dev web. webdevelopper est parfois utile, mais il m'est très peu utile désormais.
Olivier Masson
Le 26/02/2011 14:46, Olivier Masson a écrit :
zlib.output_compression, ça va compresser ce qu'interprète et renvoie PHP. Donc en gros, le contenu html. Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça devrait aussi compresser ces types de fichiers. Mais je n'ai jamais essayé (en fait, j'y ai pensé en te répondant.)
Et même, tu pourrais dire à ton apache : AddHandler application/x-httpd-php .css .js mais ça ne me parait pas idéal car les .css et .js seront interprétés par PHP donc c'est une perte de temps (même ridicule) voire un risque supplémentaire.
Le 26/02/2011 14:46, Olivier Masson a écrit :
zlib.output_compression, ça va compresser ce qu'interprète et renvoie
PHP. Donc en gros, le contenu html.
Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça
devrait aussi compresser ces types de fichiers. Mais je n'ai jamais
essayé (en fait, j'y ai pensé en te répondant.)
Et même, tu pourrais dire à ton apache :
AddHandler application/x-httpd-php .css .js
mais ça ne me parait pas idéal car les .css et .js seront interprétés
par PHP donc c'est une perte de temps (même ridicule) voire un risque
supplémentaire.
zlib.output_compression, ça va compresser ce qu'interprète et renvoie PHP. Donc en gros, le contenu html. Si tu crées tes css et js avec PHP - pourquoi pas -, j'imagine que ça devrait aussi compresser ces types de fichiers. Mais je n'ai jamais essayé (en fait, j'y ai pensé en te répondant.)
Et même, tu pourrais dire à ton apache : AddHandler application/x-httpd-php .css .js mais ça ne me parait pas idéal car les .css et .js seront interprétés par PHP donc c'est une perte de temps (même ridicule) voire un risque supplémentaire.
Mickaël Wolff
On 26/02/11 13:46, Olivier Masson wrote:
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le FS. Du coup, Apache peut les balancer directement sans avoir à les compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de compresser les fichiers PHP sur le disque, voir de créer des packages PHAR <http://fr.php.net/manual/en/intro.phar.php>
- prévoir un script de minification (!= compression) pour tes css et js
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que c'est une queue de cerise. La compression d'un fichier texte est déjà très performante pour réduire la taille. Y a-t-il une autre justification (amélioration des performances du moteur Javascript par exmple) ?
- créer des sprites (toutes les images de déco agglomérées en une seule et même image, découpée ensuite par css : tu as des applis on/offline pour t'aider)
Ce dernier point doit être considéré avec précaution. Dans certains cas (jeux dans le navigateur) il est possible que les performance soient désastreuses en utilisant cette technique. Comme souvent, quand on veut optimiser, il ne faut pas oublier de mesurer avant et après l'optimisation, histoire de ne pas perdre de temps à réduire les performances.
On 26/02/11 13:46, Olivier Masson wrote:
Ce qui permet de compresser à la volée les fichiers ayant comme
extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le
FS. Du coup, Apache peut les balancer directement sans avoir à les
compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de
compresser les fichiers PHP sur le disque, voir de créer des packages
PHAR <http://fr.php.net/manual/en/intro.phar.php>
- prévoir un script de minification (!= compression) pour tes css et js
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que
c'est une queue de cerise. La compression d'un fichier texte est déjà
très performante pour réduire la taille. Y a-t-il une autre
justification (amélioration des performances du moteur Javascript par
exmple) ?
- créer des sprites (toutes les images de déco agglomérées en une seule
et même image, découpée ensuite par css : tu as des applis on/offline
pour t'aider)
Ce dernier point doit être considéré avec précaution. Dans certains
cas (jeux dans le navigateur) il est possible que les performance soient
désastreuses en utilisant cette technique. Comme souvent, quand on veut
optimiser, il ne faut pas oublier de mesurer avant et après
l'optimisation, histoire de ne pas perdre de temps à réduire les
performances.
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le FS. Du coup, Apache peut les balancer directement sans avoir à les compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de compresser les fichiers PHP sur le disque, voir de créer des packages PHAR <http://fr.php.net/manual/en/intro.phar.php>
- prévoir un script de minification (!= compression) pour tes css et js
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que c'est une queue de cerise. La compression d'un fichier texte est déjà très performante pour réduire la taille. Y a-t-il une autre justification (amélioration des performances du moteur Javascript par exmple) ?
- créer des sprites (toutes les images de déco agglomérées en une seule et même image, découpée ensuite par css : tu as des applis on/offline pour t'aider)
Ce dernier point doit être considéré avec précaution. Dans certains cas (jeux dans le navigateur) il est possible que les performance soient désastreuses en utilisant cette technique. Comme souvent, quand on veut optimiser, il ne faut pas oublier de mesurer avant et après l'optimisation, histoire de ne pas perdre de temps à réduire les performances.
Olivier Masson
Le 26/02/2011 19:03, Mickaël Wolff a écrit :
On 26/02/11 13:46, Olivier Masson wrote:
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le FS.
Oui
Du coup, Apache peut les balancer directement sans avoir à les compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de compresser les fichiers PHP sur le disque, voir de créer des packages PHAR <http://fr.php.net/manual/en/intro.phar.php>
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que c'est une queue de cerise. La compression d'un fichier texte est déjà très performante pour réduire la taille. Y a-t-il une autre justification (amélioration des performances du moteur Javascript par exmple) ?
La minification consiste à supprimer tout ce qui est superflu dans le code. On pourrait avoir tendance à penser que le compression va faire ce boulot mais pas du tout puisque la compression est sans perte (heureusement !) donc les espaces redondants, les sauts de ligne mais surtout les commentaires ne seront pas supprimés. D'où l'intérêt de la minification, car vous faites tous du code exhaustivement commenté, bien sûr :) Les scripts de minification plus évolués, tels jsmin, yui compressor, etc. vont plus loin et permettent de réduire assez significativement le poids. Comme je suis nul en JS je ne pourrais dire comment, mais les bons codeurs JS optimisent leur code pour qu'il soit davantage /minifiable/.
Ce dernier point doit être considéré avec précaution. Dans certains cas (jeux dans le navigateur) il est possible que les performance soient désastreuses en utilisant cette technique. Comme souvent, quand on veut optimiser, il ne faut pas oublier de mesurer avant et après l'optimisation, histoire de ne pas perdre de temps à réduire les performances.
Pour un jeu, certes, mais ce n'est pas l'application la plus courante. Il y a rarement à tergiverser pour une utilisation classique. Par contre c'est une opération un peu délicate et il ne faut pas bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute la page. Séparer les types d'images, prendre en considération l'accessibilité...
Le 26/02/2011 19:03, Mickaël Wolff a écrit :
On 26/02/11 13:46, Olivier Masson wrote:
Ce qui permet de compresser à la volée les fichiers ayant comme
extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le FS.
Oui
Du coup, Apache peut les balancer directement sans avoir à les
compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de
compresser les fichiers PHP sur le disque, voir de créer des packages
PHAR <http://fr.php.net/manual/en/intro.phar.php>
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que c'est
une queue de cerise. La compression d'un fichier texte est déjà très
performante pour réduire la taille. Y a-t-il une autre justification
(amélioration des performances du moteur Javascript par exmple) ?
La minification consiste à supprimer tout ce qui est superflu dans le
code. On pourrait avoir tendance à penser que le compression va faire ce
boulot mais pas du tout puisque la compression est sans perte
(heureusement !) donc les espaces redondants, les sauts de ligne mais
surtout les commentaires ne seront pas supprimés.
D'où l'intérêt de la minification, car vous faites tous du code
exhaustivement commenté, bien sûr :)
Les scripts de minification plus évolués, tels jsmin, yui compressor,
etc. vont plus loin et permettent de réduire assez significativement le
poids. Comme je suis nul en JS je ne pourrais dire comment, mais les
bons codeurs JS optimisent leur code pour qu'il soit davantage /minifiable/.
Ce dernier point doit être considéré avec précaution. Dans certains cas
(jeux dans le navigateur) il est possible que les performance soient
désastreuses en utilisant cette technique. Comme souvent, quand on veut
optimiser, il ne faut pas oublier de mesurer avant et après
l'optimisation, histoire de ne pas perdre de temps à réduire les
performances.
Pour un jeu, certes, mais ce n'est pas l'application la plus courante.
Il y a rarement à tergiverser pour une utilisation classique.
Par contre c'est une opération un peu délicate et il ne faut pas
bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute
la page. Séparer les types d'images, prendre en considération
l'accessibilité...
Ce qui permet de compresser à la volée les fichiers ayant comme extension html, js et css.
Et le mieux, c'est encore que les fichiers soient compressés sur le FS.
Oui
Du coup, Apache peut les balancer directement sans avoir à les compresser à la volé. D'ailleurs, ça peut aussi être une bonne idée de compresser les fichiers PHP sur le disque, voir de créer des packages PHAR <http://fr.php.net/manual/en/intro.phar.php>
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
J'avoue que je n'ai jamais mesuré ça, mais j'ai l'impression que c'est une queue de cerise. La compression d'un fichier texte est déjà très performante pour réduire la taille. Y a-t-il une autre justification (amélioration des performances du moteur Javascript par exmple) ?
La minification consiste à supprimer tout ce qui est superflu dans le code. On pourrait avoir tendance à penser que le compression va faire ce boulot mais pas du tout puisque la compression est sans perte (heureusement !) donc les espaces redondants, les sauts de ligne mais surtout les commentaires ne seront pas supprimés. D'où l'intérêt de la minification, car vous faites tous du code exhaustivement commenté, bien sûr :) Les scripts de minification plus évolués, tels jsmin, yui compressor, etc. vont plus loin et permettent de réduire assez significativement le poids. Comme je suis nul en JS je ne pourrais dire comment, mais les bons codeurs JS optimisent leur code pour qu'il soit davantage /minifiable/.
Ce dernier point doit être considéré avec précaution. Dans certains cas (jeux dans le navigateur) il est possible que les performance soient désastreuses en utilisant cette technique. Comme souvent, quand on veut optimiser, il ne faut pas oublier de mesurer avant et après l'optimisation, histoire de ne pas perdre de temps à réduire les performances.
Pour un jeu, certes, mais ce n'est pas l'application la plus courante. Il y a rarement à tergiverser pour une utilisation classique. Par contre c'est une opération un peu délicate et il ne faut pas bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute la page. Séparer les types d'images, prendre en considération l'accessibilité...
Pierre Goiffon
On 26/02/2011 14:46, Olivier Masson wrote:
Tu trouveras beaucoup de détails et de bon conseils dans les aides de pagespeed et yslow.
Pour moi la référence est le site dédié chez Yahoo : http://developer.yahoo.com/performance/ Une vraie mine d'or !
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en place.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des sites sur plusieurs domaines qui partagent les mêmes resources...
On 26/02/2011 14:46, Olivier Masson wrote:
Tu trouveras beaucoup de détails et de bon conseils dans les aides de
pagespeed et yslow.
Pour moi la référence est le site dédié chez Yahoo :
http://developer.yahoo.com/performance/
Une vraie mine d'or !
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en
place.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des
sites sur plusieurs domaines qui partagent les mêmes resources...
Tu trouveras beaucoup de détails et de bon conseils dans les aides de pagespeed et yslow.
Pour moi la référence est le site dédié chez Yahoo : http://developer.yahoo.com/performance/ Une vraie mine d'or !
Oublie le cdn : c'est très bien, mais beaucoup moins simple à mettre en place.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des sites sur plusieurs domaines qui partagent les mêmes resources...
Mickaël Wolff
On 28/02/11 08:41, Olivier Masson wrote:
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
DotDeb permet de bénéficier des dernières versions de PHP et de MySQL, en étant compatible avec lenny. Mais bon, lenny est obsolète maintenant ;)
La minification consiste à supprimer tout ce qui est superflu dans le code. On pourrait avoir tendance à penser que le compression va faire ce boulot mais pas du tout puisque la compression est sans perte (heureusement !) donc les espaces redondants, les sauts de ligne mais surtout les commentaires ne seront pas supprimés.
En fait, c'est surtout que je m'inquiètes que ce soit une économie de bout de chandelle. Un fichier texte est compressé au delà de 90%, minifier pour gagner les deux ou trois octets sur ce résultat compressé, j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites rivières qui font les grands fleuves :p)
D'où l'intérêt de la minification, car vous faites tous du code exhaustivement commenté, bien sûr :)
J'ai arrêté, ça ne sert à rien. Et je suis sérieux. Je ne commente plus que sur les points délicats, ou éventuellement les interfaces. Je préfère écrire des tests, et utiliser des variables avec des noms explicites.
Les scripts de minification plus évolués, tels jsmin, yui compressor, etc. vont plus loin et permettent de réduire assez significativement le poids.
Il faudra que je teste un jour. Quand j'aurais des vrais problèmes de performance ;)
Comme je suis nul en JS je ne pourrais dire comment, mais les bons codeurs JS optimisent leur code pour qu'il soit davantage /minifiable/.
J'ai tendance à d'abord écrire du code fonctionnel, avant de m'inquiéter de la performance ^^;
Pour un jeu, certes, mais ce n'est pas l'application la plus courante. Il y a rarement à tergiverser pour une utilisation classique. Par contre c'est une opération un peu délicate et il ne faut pas bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute la page. Séparer les types d'images, prendre en considération l'accessibilité...
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé que le gain observé justifie le temps de développement ?
On 28/02/11 08:41, Olivier Masson wrote:
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
DotDeb permet de bénéficier des dernières versions de PHP et de
MySQL, en étant compatible avec lenny. Mais bon, lenny est obsolète
maintenant ;)
La minification consiste à supprimer tout ce qui est superflu dans le
code. On pourrait avoir tendance à penser que le compression va faire ce
boulot mais pas du tout puisque la compression est sans perte
(heureusement !) donc les espaces redondants, les sauts de ligne mais
surtout les commentaires ne seront pas supprimés.
En fait, c'est surtout que je m'inquiètes que ce soit une économie de
bout de chandelle. Un fichier texte est compressé au delà de 90%,
minifier pour gagner les deux ou trois octets sur ce résultat compressé,
j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites
rivières qui font les grands fleuves :p)
D'où l'intérêt de la minification, car vous faites tous du code
exhaustivement commenté, bien sûr :)
J'ai arrêté, ça ne sert à rien. Et je suis sérieux. Je ne commente
plus que sur les points délicats, ou éventuellement les interfaces. Je
préfère écrire des tests, et utiliser des variables avec des noms
explicites.
Les scripts de minification plus évolués, tels jsmin, yui compressor,
etc. vont plus loin et permettent de réduire assez significativement le
poids.
Il faudra que je teste un jour. Quand j'aurais des vrais problèmes de
performance ;)
Comme je suis nul en JS je ne pourrais dire comment, mais les
bons codeurs JS optimisent leur code pour qu'il soit davantage
/minifiable/.
J'ai tendance à d'abord écrire du code fonctionnel, avant de
m'inquiéter de la performance ^^;
Pour un jeu, certes, mais ce n'est pas l'application la plus courante.
Il y a rarement à tergiverser pour une utilisation classique.
Par contre c'est une opération un peu délicate et il ne faut pas
bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute
la page. Séparer les types d'images, prendre en considération
l'accessibilité...
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé
que le gain observé justifie le temps de développement ?
PHAR c'est 5.3, non ? Comme je suis toujours sous lenny...
DotDeb permet de bénéficier des dernières versions de PHP et de MySQL, en étant compatible avec lenny. Mais bon, lenny est obsolète maintenant ;)
La minification consiste à supprimer tout ce qui est superflu dans le code. On pourrait avoir tendance à penser que le compression va faire ce boulot mais pas du tout puisque la compression est sans perte (heureusement !) donc les espaces redondants, les sauts de ligne mais surtout les commentaires ne seront pas supprimés.
En fait, c'est surtout que je m'inquiètes que ce soit une économie de bout de chandelle. Un fichier texte est compressé au delà de 90%, minifier pour gagner les deux ou trois octets sur ce résultat compressé, j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites rivières qui font les grands fleuves :p)
D'où l'intérêt de la minification, car vous faites tous du code exhaustivement commenté, bien sûr :)
J'ai arrêté, ça ne sert à rien. Et je suis sérieux. Je ne commente plus que sur les points délicats, ou éventuellement les interfaces. Je préfère écrire des tests, et utiliser des variables avec des noms explicites.
Les scripts de minification plus évolués, tels jsmin, yui compressor, etc. vont plus loin et permettent de réduire assez significativement le poids.
Il faudra que je teste un jour. Quand j'aurais des vrais problèmes de performance ;)
Comme je suis nul en JS je ne pourrais dire comment, mais les bons codeurs JS optimisent leur code pour qu'il soit davantage /minifiable/.
J'ai tendance à d'abord écrire du code fonctionnel, avant de m'inquiéter de la performance ^^;
Pour un jeu, certes, mais ce n'est pas l'application la plus courante. Il y a rarement à tergiverser pour une utilisation classique. Par contre c'est une opération un peu délicate et il ne faut pas bourriner en utilisant des outils que j'ai pu voir, qui "spritify" toute la page. Séparer les types d'images, prendre en considération l'accessibilité...
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé que le gain observé justifie le temps de développement ?
Olivier Masson
Le 01/03/2011 10:35, Mickaël Wolff a écrit :
En fait, c'est surtout que je m'inquiètes que ce soit une économie de bout de chandelle. Un fichier texte est compressé au delà de 90%, minifier pour gagner les deux ou trois octets sur ce résultat compressé, j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites rivières qui font les grands fleuves :p)
Comme je le disais, assez clairement il me semble, le minification est totalement distinct de la compression gzip. La minification serait une sorte de compression avec perte : on vire tout ce qui est superflu, on réduit le nom de variables, expressions et je ne sais quoi d'autres au plus court. Etc (ça semble loin d'être simple, vu la complexité du code de yui compressor et le niveau des dev chez yahoo). C'est tout sauf de l'économie de bout de chandelle, mais tout dépend comme toujours du contexte. Pour un site statique avec 10 lignes de Js et CSS, en toute logique, ça ne sert à rien. Pour la version mobile d'un site sous Wordpress avec quelques JS imposant, on est à l'autre extrême.
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé que le gain observé justifie le temps de développement ?
Sur quasiment tous mes sites. Quitte à être à la limite de l'accessibilité (mais je m'arrange autrement.) Il n'y a aucun temps de dev ; j'ai juste installé en local css sprite generator, avec optipng. Jamais réussi toutefois à correctement installer la 4.0, avec leur MVC à la con qui rend tout très complexe. Ensuite, question d'habitude pour savoir immédiatement quelles images mettre en sprite. Version en ligne : http://spritegen.website-performance.org/ Le gain est loin d'être négligeable. Certains vont même jusqu'à utiliser les data-uri pour insérer les images de toutes petites tailles (style gif en 2 couleurs). Pourquoi pas, mais j'ai tendance à trouver ça un peu couillon (ou alors dans des cas très particuliers).
Le 01/03/2011 10:35, Mickaël Wolff a écrit :
En fait, c'est surtout que je m'inquiètes que ce soit une économie de
bout de chandelle. Un fichier texte est compressé au delà de 90%,
minifier pour gagner les deux ou trois octets sur ce résultat compressé,
j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites
rivières qui font les grands fleuves :p)
Comme je le disais, assez clairement il me semble, le minification est
totalement distinct de la compression gzip.
La minification serait une sorte de compression avec perte : on vire
tout ce qui est superflu, on réduit le nom de variables, expressions et
je ne sais quoi d'autres au plus court. Etc (ça semble loin d'être
simple, vu la complexité du code de yui compressor et le niveau des dev
chez yahoo).
C'est tout sauf de l'économie de bout de chandelle, mais tout dépend
comme toujours du contexte. Pour un site statique avec 10 lignes de Js
et CSS, en toute logique, ça ne sert à rien.
Pour la version mobile d'un site sous Wordpress avec quelques JS
imposant, on est à l'autre extrême.
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé que
le gain observé justifie le temps de développement ?
Sur quasiment tous mes sites. Quitte à être à la limite de
l'accessibilité (mais je m'arrange autrement.)
Il n'y a aucun temps de dev ; j'ai juste installé en local css sprite
generator, avec optipng. Jamais réussi toutefois à correctement
installer la 4.0, avec leur MVC à la con qui rend tout très complexe.
Ensuite, question d'habitude pour savoir immédiatement quelles images
mettre en sprite. Version en ligne :
http://spritegen.website-performance.org/
Le gain est loin d'être négligeable.
Certains vont même jusqu'à utiliser les data-uri pour insérer les images
de toutes petites tailles (style gif en 2 couleurs). Pourquoi pas, mais
j'ai tendance à trouver ça un peu couillon (ou alors dans des cas très
particuliers).
En fait, c'est surtout que je m'inquiètes que ce soit une économie de bout de chandelle. Un fichier texte est compressé au delà de 90%, minifier pour gagner les deux ou trois octets sur ce résultat compressé, j'ai quand même du mal à voir l'intérêt (et ne me parle pas des petites rivières qui font les grands fleuves :p)
Comme je le disais, assez clairement il me semble, le minification est totalement distinct de la compression gzip. La minification serait une sorte de compression avec perte : on vire tout ce qui est superflu, on réduit le nom de variables, expressions et je ne sais quoi d'autres au plus court. Etc (ça semble loin d'être simple, vu la complexité du code de yui compressor et le niveau des dev chez yahoo). C'est tout sauf de l'économie de bout de chandelle, mais tout dépend comme toujours du contexte. Pour un site statique avec 10 lignes de Js et CSS, en toute logique, ça ne sert à rien. Pour la version mobile d'un site sous Wordpress avec quelques JS imposant, on est à l'autre extrême.
Et dans quel cadre tu as mis en place cette technique ? As-tu trouvé que le gain observé justifie le temps de développement ?
Sur quasiment tous mes sites. Quitte à être à la limite de l'accessibilité (mais je m'arrange autrement.) Il n'y a aucun temps de dev ; j'ai juste installé en local css sprite generator, avec optipng. Jamais réussi toutefois à correctement installer la 4.0, avec leur MVC à la con qui rend tout très complexe. Ensuite, question d'habitude pour savoir immédiatement quelles images mettre en sprite. Version en ligne : http://spritegen.website-performance.org/ Le gain est loin d'être négligeable. Certains vont même jusqu'à utiliser les data-uri pour insérer les images de toutes petites tailles (style gif en 2 couleurs). Pourquoi pas, mais j'ai tendance à trouver ça un peu couillon (ou alors dans des cas très particuliers).
Olivier Masson
Le 28/02/2011 15:37, Pierre Goiffon a écrit :
Pour moi la référence est le site dédié chez Yahoo : http://developer.yahoo.com/performance/ Une vraie mine d'or !
C'est la doc de yslow, mais yslow filtre en ne donnant que la extraits susceptibles d'être intéressant pour l'optimisation du site testé.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des sites sur plusieurs domaines qui partagent les mêmes resources...
Là je ne vois pas en quoi le CDN serait plus utile qu'un serveur quelconque. Mais le CDN est évidemment une bonne chose, notamment en supprimant les cookies sur les images (yahoo ne place pas ce critère dans les CDN cependant.) On peut ainsi se faire son propre CDN. Quant aux vrais CDN, ils sont utiles pour les gros sites, internationaux et/ou avec de gros contenus multimédias. Histoire de répartir la charge et d'utiliser des ressources géographiquement situées au mieux.
Le 28/02/2011 15:37, Pierre Goiffon a écrit :
Pour moi la référence est le site dédié chez Yahoo :
http://developer.yahoo.com/performance/
Une vraie mine d'or !
C'est la doc de yslow, mais yslow filtre en ne donnant que la extraits
susceptibles d'être intéressant pour l'optimisation du site testé.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des
sites sur plusieurs domaines qui partagent les mêmes resources...
Là je ne vois pas en quoi le CDN serait plus utile qu'un serveur
quelconque. Mais le CDN est évidemment une bonne chose, notamment en
supprimant les cookies sur les images (yahoo ne place pas ce critère
dans les CDN cependant.)
On peut ainsi se faire son propre CDN.
Quant aux vrais CDN, ils sont utiles pour les gros sites, internationaux
et/ou avec de gros contenus multimédias. Histoire de répartir la charge
et d'utiliser des ressources géographiquement situées au mieux.
Pour moi la référence est le site dédié chez Yahoo : http://developer.yahoo.com/performance/ Une vraie mine d'or !
C'est la doc de yslow, mais yslow filtre en ne donnant que la extraits susceptibles d'être intéressant pour l'optimisation du site testé.
Le CDN n'apporte des avantages que pour certains cas non ? Si l'on des sites sur plusieurs domaines qui partagent les mêmes resources...
Là je ne vois pas en quoi le CDN serait plus utile qu'un serveur quelconque. Mais le CDN est évidemment une bonne chose, notamment en supprimant les cookies sur les images (yahoo ne place pas ce critère dans les CDN cependant.) On peut ainsi se faire son propre CDN. Quant aux vrais CDN, ils sont utiles pour les gros sites, internationaux et/ou avec de gros contenus multimédias. Histoire de répartir la charge et d'utiliser des ressources géographiquement situées au mieux.
SAM
Le 01/03/11 11:53, Olivier Masson a écrit :
Certains vont même jusqu'à utiliser les data-uri pour insérer les images de toutes petites tailles (style gif en 2 couleurs).
Je trouve ça assez rigolo et pourrait être pratique parfois. Mais ... je croyais que IE ne savait qu'en faire ?
-- Stéphane Moriaux avec/with iMac-intel
Le 01/03/11 11:53, Olivier Masson a écrit :
Certains vont même jusqu'à utiliser les data-uri pour insérer les images
de toutes petites tailles (style gif en 2 couleurs).
Je trouve ça assez rigolo et pourrait être pratique parfois.
Mais ... je croyais que IE ne savait qu'en faire ?
Certains vont même jusqu'à utiliser les data-uri pour insérer les images de toutes petites tailles (style gif en 2 couleurs).
Je trouve ça assez rigolo et pourrait être pratique parfois. Mais ... je croyais que IE ne savait qu'en faire ?
-- Stéphane Moriaux avec/with iMac-intel
Olivier Masson
Le 01/03/2011 17:32, SAM a écrit :
Je trouve ça assez rigolo et pourrait être pratique parfois.
Si tu automatises avec un base64_encode (PHP), pourquoi pas. Mais faire prendre du poids pour éviter une requête, faut voir. Je n'ai jamais fait de test.
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif. T'es sous IE, tu assumes notamment le fait d'attendre 30 secondes pour l'affichage d'une page. IE = 8 : kok. Les images dans les CSS en data uri fonctionnent. IE > 9 : probablement ok.
Le 01/03/2011 17:32, SAM a écrit :
Je trouve ça assez rigolo et pourrait être pratique parfois.
Si tu automatises avec un base64_encode (PHP), pourquoi pas. Mais faire
prendre du poids pour éviter une requête, faut voir. Je n'ai jamais fait
de test.
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif.
T'es sous IE, tu assumes notamment le fait d'attendre 30 secondes pour
l'affichage d'une page.
IE = 8 : kok. Les images dans les CSS en data uri fonctionnent.
IE > 9 : probablement ok.
Je trouve ça assez rigolo et pourrait être pratique parfois.
Si tu automatises avec un base64_encode (PHP), pourquoi pas. Mais faire prendre du poids pour éviter une requête, faut voir. Je n'ai jamais fait de test.
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif. T'es sous IE, tu assumes notamment le fait d'attendre 30 secondes pour l'affichage d'une page. IE = 8 : kok. Les images dans les CSS en data uri fonctionnent. IE > 9 : probablement ok.