[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/
Comme je le disais, assez clairement il me semble, le minification est totalement distinct de la compression gzip.
En fait c'est moi qui n'ai pas été assez clair, pensant que ce à quoi je pensais était évident. La compression sans perte utilise un algorithme statistique qui détermine un ensemble de patterns qui se répètent régulièrement. À partir de ces statistiques, il créé un catalogue de patterns et associe un code qu'il utilisera pour se substituer au pattern. Mon point concernait surtout le code source en lui-même. Il y a des pattern qui reviennent souvent. La compression devrait donc avoir un effet équivalent à la minification. Quand aux commentaires et autres textes inutiles à l'exécution du programme, ce sont malgré tout du texte, qui se compresse bien.
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
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.
C'était tout à fait l'objet de mon interrogation.
Et merci pour toutes les informations que tu as partagé dans ta réponse.
On 01/03/11 10:53, Olivier Masson wrote:
Comme je le disais, assez clairement il me semble, le minification est
totalement distinct de la compression gzip.
En fait c'est moi qui n'ai pas été assez clair, pensant que ce à quoi
je pensais était évident. La compression sans perte utilise un
algorithme statistique qui détermine un ensemble de patterns qui se
répètent régulièrement. À partir de ces statistiques, il créé un
catalogue de patterns et associe un code qu'il utilisera pour se
substituer au pattern.
Mon point concernait surtout le code source en lui-même. Il y a des
pattern qui reviennent souvent. La compression devrait donc avoir un
effet équivalent à la minification. Quand aux commentaires et autres
textes inutiles à l'exécution du programme, ce sont malgré tout du
texte, qui se compresse bien.
Donc oui, je comprends tout à fait ce que font respectivement la
minification et la compression. Je me posais surtout la question de la
justification du coût de la manœuvre et du risque d'introduction de bogue.
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.
C'était tout à fait l'objet de mon interrogation.
Et merci pour toutes les informations que tu as partagé dans ta réponse.
Comme je le disais, assez clairement il me semble, le minification est totalement distinct de la compression gzip.
En fait c'est moi qui n'ai pas été assez clair, pensant que ce à quoi je pensais était évident. La compression sans perte utilise un algorithme statistique qui détermine un ensemble de patterns qui se répètent régulièrement. À partir de ces statistiques, il créé un catalogue de patterns et associe un code qu'il utilisera pour se substituer au pattern. Mon point concernait surtout le code source en lui-même. Il y a des pattern qui reviennent souvent. La compression devrait donc avoir un effet équivalent à la minification. Quand aux commentaires et autres textes inutiles à l'exécution du programme, ce sont malgré tout du texte, qui se compresse bien.
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
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.
C'était tout à fait l'objet de mon interrogation.
Et merci pour toutes les informations que tu as partagé dans ta réponse.
Olivier Masson
Le 03/03/2011 17:52, Mickaël Wolff a écrit :
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les jours !). C'est en fait à force de voir les tailles indiquées en "minified+gzipped" que j'ai fait des tests. Et le gain est bel et bien réel. C'est aussi étonnant de voir les améliorations que certains opèrent pour rendre leur scripts davantage "minifiable". Par contre, concernant les bogues, il est clair que je n'utilise que les niveaux /safe/ et toujours le même compresseur (YUI) ; les niveaux élevés et certains autres compresseurs plantent les scripts immédiatement.
Le 03/03/2011 17:52, Mickaël Wolff a écrit :
Donc oui, je comprends tout à fait ce que font respectivement la
minification et la compression. Je me posais surtout la question de la
justification du coût de la manœuvre et du risque d'introduction de bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les
jours !). C'est en fait à force de voir les tailles indiquées en
"minified+gzipped" que j'ai fait des tests.
Et le gain est bel et bien réel. C'est aussi étonnant de voir les
améliorations que certains opèrent pour rendre leur scripts davantage
"minifiable".
Par contre, concernant les bogues, il est clair que je n'utilise que les
niveaux /safe/ et toujours le même compresseur (YUI) ; les niveaux
élevés et certains autres compresseurs plantent les scripts immédiatement.
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les jours !). C'est en fait à force de voir les tailles indiquées en "minified+gzipped" que j'ai fait des tests. Et le gain est bel et bien réel. C'est aussi étonnant de voir les améliorations que certains opèrent pour rendre leur scripts davantage "minifiable". Par contre, concernant les bogues, il est clair que je n'utilise que les niveaux /safe/ et toujours le même compresseur (YUI) ; les niveaux élevés et certains autres compresseurs plantent les scripts immédiatement.
Pierre Goiffon
On 01/03/2011 12:04, Olivier Masson wrote:
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.
La majeure partie du temps ceux qui parlent de CDN pensent simplement à un serveur dédié à servir les resources statiques, et pas de solutions comme Akamaï ou autre qui prennent en compte plus que ça (dont le lieu de l'utilisateur etc).
Si l'on est simplement sur un serveur de resource statique, le premier intérêt est de servir des resources communes sous la même url (bref remplacer domaineA.fr/image.png domaineB.fr/image.png domaineC.fr/image.png etc par domainecdn.fr/image.png).
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.
Oui, ça a un coût et ça n'est pas pour rien :)
On 01/03/2011 12:04, Olivier Masson wrote:
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.
La majeure partie du temps ceux qui parlent de CDN pensent simplement à
un serveur dédié à servir les resources statiques, et pas de solutions
comme Akamaï ou autre qui prennent en compte plus que ça (dont le lieu
de l'utilisateur etc).
Si l'on est simplement sur un serveur de resource statique, le premier
intérêt est de servir des resources communes sous la même url (bref
remplacer domaineA.fr/image.png domaineB.fr/image.png
domaineC.fr/image.png etc par domainecdn.fr/image.png).
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 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.
La majeure partie du temps ceux qui parlent de CDN pensent simplement à un serveur dédié à servir les resources statiques, et pas de solutions comme Akamaï ou autre qui prennent en compte plus que ça (dont le lieu de l'utilisateur etc).
Si l'on est simplement sur un serveur de resource statique, le premier intérêt est de servir des resources communes sous la même url (bref remplacer domaineA.fr/image.png domaineB.fr/image.png domaineC.fr/image.png etc par domainecdn.fr/image.png).
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.
Oui, ça a un coût et ça n'est pas pour rien :)
Pierre Goiffon
On 01/03/2011 10:35, Mickaël Wolff wrote:
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)
J'ai assez vaguement mémoire d'un article de Eric Daspet qui donnait des chiffres autour de ces problématiques. Je n'ai pas réussi à le retrouver malheureusement (mais son blog contient cependant des articles passionnants : http://performance.survol.fr). De mémoire je ne me souviens pas d'une moyenne de taux de compression à 90% mais plutôt un peu plus que 50%, et d'une vraie efficacité en conséquent de la minification (surtout sur des librairies comme la YUI ou JQuery UI). Mais c'est un peu trop vague dans ma mémoire et je manque de temps pour me livrer à des recherches plus fouillées.
De mon côté je n'ai pas mis en place la compression gzip très souvent, c'est parfois pas si simple dans une infrastructure avec déjà beaucoup de couches. La minification et concaténation est une première étape et ça n'est pas rien...
On 01/03/2011 10:35, Mickaël Wolff wrote:
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)
J'ai assez vaguement mémoire d'un article de Eric Daspet qui donnait des
chiffres autour de ces problématiques. Je n'ai pas réussi à le retrouver
malheureusement (mais son blog contient cependant des articles
passionnants : http://performance.survol.fr). De mémoire je ne me
souviens pas d'une moyenne de taux de compression à 90% mais plutôt un
peu plus que 50%, et d'une vraie efficacité en conséquent de la
minification (surtout sur des librairies comme la YUI ou JQuery UI).
Mais c'est un peu trop vague dans ma mémoire et je manque de temps pour
me livrer à des recherches plus fouillées.
De mon côté je n'ai pas mis en place la compression gzip très souvent,
c'est parfois pas si simple dans une infrastructure avec déjà beaucoup
de couches. La minification et concaténation est une première étape et
ça n'est pas rien...
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)
J'ai assez vaguement mémoire d'un article de Eric Daspet qui donnait des chiffres autour de ces problématiques. Je n'ai pas réussi à le retrouver malheureusement (mais son blog contient cependant des articles passionnants : http://performance.survol.fr). De mémoire je ne me souviens pas d'une moyenne de taux de compression à 90% mais plutôt un peu plus que 50%, et d'une vraie efficacité en conséquent de la minification (surtout sur des librairies comme la YUI ou JQuery UI). Mais c'est un peu trop vague dans ma mémoire et je manque de temps pour me livrer à des recherches plus fouillées.
De mon côté je n'ai pas mis en place la compression gzip très souvent, c'est parfois pas si simple dans une infrastructure avec déjà beaucoup de couches. La minification et concaténation est une première étape et ça n'est pas rien...
Pierre Goiffon
On 02/03/2011 11:03, Olivier Masson wrote: (les url data)
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif.
Hack pour afficher un "vrai" img src ?
IE = 8 : kok. Les images dans les CSS en data uri fonctionnent.
Et donc pas les img srcÚta:... ?
On 02/03/2011 11:03, Olivier Masson wrote:
(les url data)
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif.
Hack pour afficher un "vrai" img src ?
IE = 8 : kok. Les images dans les CSS en data uri fonctionnent.
On 02/03/2011 11:03, Olivier Masson wrote: (les url data)
Mais ... je croyais que IE ne savait qu'en faire ?
IE < 8 : ko. Commentaires conditionnels ou hack pour lecture du gif.
Hack pour afficher un "vrai" img src ?
IE = 8 : kok. Les images dans les CSS en data uri fonctionnent.
Et donc pas les img srcÚta:... ?
Pierre Goiffon
On 04/03/2011 09:00, Olivier Masson wrote:
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les jours !). C'est en fait à force de voir les tailles indiquées en "minified+gzipped" que j'ai fait des tests.
Personnellement j'étais assez dubitatif (en tant que développeur on a plus l'habitude de penser que le prb est côté serveur et optimiser uniquement ça) et puis en regardant la vue réseau de Firebig avec les ajouts que YSlow y ajoute, on est assez scié ! On a très souvent des secondes entières consacrées aux téléchargements des resources et rendu, et le temps de traitement serveur est souvent absolument minime !
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même quelques outils, j'ai l'impression que c'est un peu comme produire du code valide en fait : c'est avant tout un changement d'habitudes non ?
On 04/03/2011 09:00, Olivier Masson wrote:
Donc oui, je comprends tout à fait ce que font respectivement la
minification et la compression. Je me posais surtout la question de la
justification du coût de la manœuvre et du risque d'introduction de
bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les
jours !). C'est en fait à force de voir les tailles indiquées en
"minified+gzipped" que j'ai fait des tests.
Personnellement j'étais assez dubitatif (en tant que développeur on a
plus l'habitude de penser que le prb est côté serveur et optimiser
uniquement ça) et puis en regardant la vue réseau de Firebig avec les
ajouts que YSlow y ajoute, on est assez scié ! On a très souvent des
secondes entières consacrées aux téléchargements des resources et rendu,
et le temps de traitement serveur est souvent absolument minime !
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont
la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même
quelques outils, j'ai l'impression que c'est un peu comme produire du
code valide en fait : c'est avant tout un changement d'habitudes non ?
Donc oui, je comprends tout à fait ce que font respectivement la minification et la compression. Je me posais surtout la question de la justification du coût de la manœuvre et du risque d'introduction de bogue.
Je comprends ta circonspection (p'tain celui-la je le case pas tous les jours !). C'est en fait à force de voir les tailles indiquées en "minified+gzipped" que j'ai fait des tests.
Personnellement j'étais assez dubitatif (en tant que développeur on a plus l'habitude de penser que le prb est côté serveur et optimiser uniquement ça) et puis en regardant la vue réseau de Firebig avec les ajouts que YSlow y ajoute, on est assez scié ! On a très souvent des secondes entières consacrées aux téléchargements des resources et rendu, et le temps de traitement serveur est souvent absolument minime !
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même quelques outils, j'ai l'impression que c'est un peu comme produire du code valide en fait : c'est avant tout un changement d'habitudes non ?
J'ai assez vaguement mémoire d'un article de Eric Daspet qui donnait des chiffres autour de ces problématiques. Je n'ai pas réussi à le retrouver
Daspet est un chouette gars, qui fait son boulot à fond et très bien. Mais un peu trop parfois.
A voir surtout : http://www.websiteoptimization.com/
Olivier Masson
Le 07/03/2011 16:15, Pierre Goiffon a écrit :
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même quelques outils, j'ai l'impression que c'est un peu comme produire du code valide en fait : c'est avant tout un changement d'habitudes non ?
Il est clair qu'utiliser Yslow et consort, surtout sur l'onglet "Réseau", ça fait prendre conscience de l'importance du problème. On habitue les internautes à l'immédiateté : il faut donc savoir optimiser au mieux et faire dans l'efficace (par exemple donner une impression de vitesse, en chargeant des éléments visuels importants avant le reste, pour calmer l'impatiente de l'internaute.)
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne sert à rien. Or, ça apporte un gain de productivité réelle ET une maintenance grandement facilitée. Faut juste s'y mettre. Un jour j'utiliserai même peut-être Symfony ou ROR :)
Tu parlais de E.Daspet : il avait, avec d'autres, lancé un concours d'optimisation(3) sur une page de la FNAC (qui s'est portée volontaire). Les résultats ont été scotchant puisque le gagnant a obtenu *moins d'une seconde* alors que, de mémoire, la page d'origine se chargeait en plus de 20 secondes !
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont
la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même
quelques outils, j'ai l'impression que c'est un peu comme produire du
code valide en fait : c'est avant tout un changement d'habitudes non ?
Il est clair qu'utiliser Yslow et consort, surtout sur l'onglet
"Réseau", ça fait prendre conscience de l'importance du problème.
On habitue les internautes à l'immédiateté : il faut donc savoir
optimiser au mieux et faire dans l'efficace (par exemple donner une
impression de vitesse, en chargeant des éléments visuels importants
avant le reste, pour calmer l'impatiente de l'internaute.)
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou
LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne
sert à rien. Or, ça apporte un gain de productivité réelle ET une
maintenance grandement facilitée.
Faut juste s'y mettre. Un jour j'utiliserai même peut-être Symfony ou ROR :)
Tu parlais de E.Daspet : il avait, avec d'autres, lancé un concours
d'optimisation(3) sur une page de la FNAC (qui s'est portée volontaire).
Les résultats ont été scotchant puisque le gagnant a obtenu *moins d'une
seconde* alors que, de mémoire, la page d'origine se chargeait en plus
de 20 secondes !
Et c'est drole mais tous les collègues développeurs à qui j'en parle ont la même attitude. Un coup de firebug et ça ne dure pas longtemps :)
Pour ce qui est du coût des solutions à employer, il existe quand même quelques outils, j'ai l'impression que c'est un peu comme produire du code valide en fait : c'est avant tout un changement d'habitudes non ?
Il est clair qu'utiliser Yslow et consort, surtout sur l'onglet "Réseau", ça fait prendre conscience de l'importance du problème. On habitue les internautes à l'immédiateté : il faut donc savoir optimiser au mieux et faire dans l'efficace (par exemple donner une impression de vitesse, en chargeant des éléments visuels importants avant le reste, pour calmer l'impatiente de l'internaute.)
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne sert à rien. Or, ça apporte un gain de productivité réelle ET une maintenance grandement facilitée. Faut juste s'y mettre. Un jour j'utiliserai même peut-être Symfony ou ROR :)
Tu parlais de E.Daspet : il avait, avec d'autres, lancé un concours d'optimisation(3) sur une page de la FNAC (qui s'est portée volontaire). Les résultats ont été scotchant puisque le gagnant a obtenu *moins d'une seconde* alors que, de mémoire, la page d'origine se chargeait en plus de 20 secondes !
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.
On 08/03/2011 11:19, Olivier Masson wrote:
Et donc pas les img srcÚta:... ?
Euh si, mais ça me parait encore moins utile.
Ca peut servir pour des applications en ligne, typiquement des
générations de graphiques qui évoluent en ajax. Par exemple OpenFlash
Chart permet d'exporter les graphiques en générant dynamiquement un img
srcÚta:.
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.