Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Referencement, javascript et autres preconisations

12 views
Skip to first unread message
Message has been deleted

SAM

unread,
Feb 25, 2011, 2:12:13 PM2/25/11
to
Le 25/02/11 17:27, Eric Demeester a écrit :
> [ Attention, suivi positionné sur fr.comp.infosystemes.www.auteurs et
> sujet changé parce que ça n'a plus rien à voir avec PHP ]
>
> Salut Olivier,
>
> dans (in) fr.comp.lang.php, Olivier Masson<sis...@laposte.net>
> ecrivait (wrote) :
>
>> Le 24/02/2011 21:45, Eric Demeester a écrit :
>>> 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 » :(
...
>> Eh bé ! Quel spécialiste !
...
> Oui, mais
...
>> Ce n'est pas le cas ici, donc c'est du gros pipeau


> J'y ai quand même trouvé un bon conseil, mais pas spécialement lié aux
> robots d'indexation, c'est l'utilisation systématique d'une balise
> <noscript> proposant un résumé de ce que fait le javascript, utile pour
> améliorer l'accessibilité et proposer une informations aux personnes
> ayant javascript désactivé.

Ha! Ben! les v'là bôs avec l'info leur disant que rien ne fonctionne !

Bêtas comme ils sont à pas savoir enabléder leur JS, ils ne s'étaient
rendus compte de rien les pôvrets.

Vaudrait peut-être mieux donner des conseils éclairés aux
javascripteurs, me semble ?!

> Autre préconisation du même spécialiste pour, je cite, « passer en
> tendance verte sur mes outils de monitoring » : gziper le site
> entièrement en paramétrant un php.ini.

Bon ... là ... on ne sait dequidequoi qu'on cause.


> Je suis loin d'être un spécialiste en référencement, mais je trouve tout
> ça un peu tiré par les cheveux, comparé à la proposition de contenus
> pertinents, sémantiquement corrects et organisés selon une arborescence
> claire, le tout présenté dans des pages valides w3c.
>
> Mais bon.

Certes.

--
Stéphane Moriaux avec/with iMac-intel

Olivier Masson

unread,
Feb 25, 2011, 2:13:13 PM2/25/11
to
Le 25/02/2011 17:27, Eric Demeester a écrit :

> J'y ai quand même trouvé un bon conseil, mais pas spécialement lié aux
> robots d'indexation, c'est l'utilisation systématique d'une balise
> <noscript> proposant un résumé de ce que fait le javascript, utile pour
> améliorer l'accessibilité et proposer une informations aux personnes
> ayant javascript désactivé.
>

> Autre préconisation du même spécialiste pour, je cite, « passer en
> tendance verte sur mes outils de monitoring » : gziper le site
> entièrement en paramétrant un php.ini.
>

> Je suis loin d'être un spécialiste en référencement, mais je trouve tout
> ça un peu tiré par les cheveux, comparé à la proposition de contenus
> pertinents, sémantiquement corrects et organisés selon une arborescence
> claire, le tout présenté dans des pages valides w3c.
>
> Mais bon.
>

On est hors charte mais je me permets sur cette réponse (si on continue,
ce sera sur fciw).

Le <noscript> est une bonne habitude, c'est certain mais son utilité
pour le référencement, franchement, jamais entendu parlé ni constaté.

Quant à la compression des pages, c'est une évidence (tu peux également
indiqué que tu compresses les css et les js), mais surtout pour la
performance. Tout comme la réduction du nombre de requêtes
(concaténation des css, des js, utilisation de sprites...)
Or, Google prend en compte la performance depuis l'année dernière pour
ajuster son positionnement. Google avait annoncé alors que ce critère ne
serait que peu pris en compte, mais certains tests effectués semble
montrer qu'il est parfois assez influent. Comme toujours dans le
référencement, c'est surtout dans un contexte de forte concurrence que
tous les critères doivent être optimisés au mieux.
Bref, installe pagespeed de Google ou YSlow de Yahoo sur ton firefox et
utilise une partie des conseils résultant.
Tu peux aussi installer le module mod_pagespeed de Google pour apache
qui pourrait être génial, sauf que j'ai parfois de fortes montées en
charge sur mes httpd. Je remonte les problèmes aux dev et les versions
s'améliorent peu à peu.

Olivier Masson

unread,
Feb 25, 2011, 2:14:09 PM2/25/11
to
Le 25/02/2011 20:13, Olivier Masson a écrit :

>
> On est hors charte mais je me permets sur cette réponse (si on continue,
> ce sera sur fciw).

:) tiens, on y est déją, je n'avais pas vu le cross-post...

Message has been deleted

Olivier Masson

unread,
Feb 26, 2011, 8:46:19 AM2/26/11
to
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.

Olivier Masson

unread,
Feb 26, 2011, 8:50:47 AM2/26/11
to
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.

Mickaël Wolff

unread,
Feb 26, 2011, 1:03:19 PM2/26/11
to
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.

Olivier Masson

unread,
Feb 28, 2011, 3:41:56 AM2/28/11
to
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é...

Pierre Goiffon

unread,
Feb 28, 2011, 9:37:32 AM2/28/11
to
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...

Mickaël Wolff

unread,
Mar 1, 2011, 4:35:34 AM3/1/11
to
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 ?

Olivier Masson

unread,
Mar 1, 2011, 5:53:00 AM3/1/11
to
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).

Olivier Masson

unread,
Mar 1, 2011, 6:04:33 AM3/1/11
to
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.

SAM

unread,
Mar 1, 2011, 11:32:44 AM3/1/11
to
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 ?

Olivier Masson

unread,
Mar 2, 2011, 5:03:06 AM3/2/11
to
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.

Mickaël Wolff

unread,
Mar 3, 2011, 11:52:02 AM3/3/11
to
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.

Olivier Masson

unread,
Mar 4, 2011, 3:00:18 AM3/4/11
to
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.

Pierre Goiffon

unread,
Mar 7, 2011, 10:01:12 AM3/7/11
to
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 :)

Pierre Goiffon

unread,
Mar 7, 2011, 10:08:55 AM3/7/11
to
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...

Pierre Goiffon

unread,
Mar 7, 2011, 10:10:20 AM3/7/11
to
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=data:... ?

Pierre Goiffon

unread,
Mar 7, 2011, 10:15:04 AM3/7/11
to
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 ?

Olivier Masson

unread,
Mar 8, 2011, 5:19:25 AM3/8/11
to
Le 07/03/2011 16:10, Pierre Goiffon a écrit :

> Hack pour afficher un "vrai" img src ?

Ah oui :)


> Et donc pas les img src=data:... ?

Euh si, mais ça me parait encore moins utile.

Olivier Masson

unread,
Mar 8, 2011, 5:23:53 AM3/8/11
to
Le 07/03/2011 16:08, Pierre Goiffon a écrit :

> 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

unread,
Mar 8, 2011, 5:38:27 AM3/8/11
to
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 !

-----
(1) http://sass-lang.com/
(2) http://lesscss.org/
(3) http://webperf-contest.com/leaderboard.html

Pierre Goiffon

unread,
Mar 8, 2011, 9:20:38 AM3/8/11
to
On 08/03/2011 11:19, Olivier Masson wrote:
>> Et donc pas les img src=data:... ?
>
> 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=data:.

Pierre Goiffon

unread,
Mar 8, 2011, 9:30:26 AM3/8/11
to
On 08/03/2011 11:38, Olivier Masson wrote:
> 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.

Ha je ne connaissais pas ces 2 framework, merci des liens !

Pour ce qui est du changement des habitudes de développement, je ne sais
pas trop où en est la situation actuelle. Vers 2001-2002-2003 beaucoup
de gens dans l'industrie (intégrateurs, mais même développeurs et
parfois graphistes) sont passés des "vieilles recettes" à séparation
fond/forme avec du html autant valide que possible et du css. Je crois
que tous ceux là ont déjà connu une transformation en profondeur de leur
environnement professionnel, et pour des avantages très concrets et
quais immédiats !

Mais depuis cette époque on peut imaginer que pas mal de "nouveaux
entrants" sont arrivés sur le marché et n'ont pas cet historique en tête ?
A l'inverse les arguments pas très pertinents ("plus propre") pour
basculer aux standards utilisés au début des années 2000 me paraissent
beaucoup moins répandus, j'ai l'impression que l'on parle plus de gains
concrets pour la production, les performances et l'évolutivité ?
Faut voir...

En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont
fini par être convaincus, et il est clair que même sans considérer les
problématiques de compatibilité CSS des navigateurs il y a encore
beaucoup à faire sur de nombreux domaines ! Les performances étant un
point vraiment critique, vu que les applications deviennent de plus en
plus complexe et que les développeurs s'éloignent de plus en plus des
réalités avec des tonnes de couches d'abstractions (frameworks serveur,
api JavaScript, moteurs de template et cache, ...).

> Tu parlais de E.Daspet

Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien
dommage qu'il ait arrêté de poster, c'était une source d'information
quasi idéale !

Pierre Goiffon

unread,
Mar 8, 2011, 9:31:09 AM3/8/11
to
On 08/03/2011 11:23, Olivier Masson wrote:
> 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/

Je m'abonne au rss, merci !

Olivier Masson

unread,
Mar 8, 2011, 9:44:55 AM3/8/11
to
Le 08/03/2011 15:20, Pierre Goiffon a écrit :

> 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=data:.

Flash peut pas générer d'image directement ?

Olivier Masson

unread,
Mar 8, 2011, 9:45:03 AM3/8/11
to
Le 08/03/2011 15:30, Pierre Goiffon a écrit :

> En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont
> fini par être convaincus, et il est clair que même sans considérer les
> problématiques de compatibilité CSS des navigateurs il y a encore
> beaucoup à faire sur de nombreux domaines ! Les performances étant un
> point vraiment critique, vu que les applications deviennent de plus en
> plus complexe et que les développeurs s'éloignent de plus en plus des
> réalités avec des tonnes de couches d'abstractions (frameworks serveur,
> api JavaScript, moteurs de template et cache, ...).
>

Ben maintenant, la grosse mode c'est d'être Agile. T'es pas scrummaster,
t'es nase :)

>> Tu parlais de E.Daspet
>
> Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien
> dommage qu'il ait arrêté de poster, c'était une source d'information
> quasi idéale !

Il publie toujours, mais plus sur son blog. De temps en temps
directement sur Google Docs. Sinon twitter @edasfr pour les infos.

Pierre Goiffon

unread,
Mar 8, 2011, 12:34:38 PM3/8/11
to
On 08/03/2011 15:44, Olivier Masson wrote:
>> 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=data:.
>
> Flash peut pas générer d'image directement ?

Les choses ne sont jamais complètement simples :) Le cas le plus courant
est l'impression, mais on peut également imaginer bien plus.

Message has been deleted

Paul Gaborit

unread,
Mar 9, 2011, 6:40:26 PM3/9/11
to

À (at) Wed, 09 Mar 2011 21:43:01 +0100,
Eric Demeester <eric+...@galacsys.net> écrivait (wrote):

> Moi, à la base, je suis développeur et je ponds du code via divers
> outils et sous divers systèmes d'exploitation depuis... 1983.
>
> Mon objectif a toujours été de produire un code aussi propre, rapide et
> maintenable que possible.
>
> Alors quand je lis qu'il faut minifier, concaténer, compiler, bzipper,
> créer des sprites, whatever, ma première réaction est « pourquoi pas,
> mais ça va me pourrir la vie parce qu'il faudra passer par n scripts
> intermédiaires, qu'une fois mes sources moulinés par ces scripts ils
> deviendront probablement illisibles par un humain, que tout ça va me
> faire perdre du temps parce qu'à chaque fois que je ferai une
> modification il faudre remouliner, et que si c'est juste pour monter de
> quelques crans dans le référencement de Google, de mon point de vue, le
> jeu n'en vaut pas la chandelle, parce que le référencement n'est pas ma
> préoccupation principale[*] ».

On dirait la réaction d'un spécialiste du langage machine à l'arrivée
des langages super-évolués et génériques tels que le C ou le Fortran !

;-)

Au fait, êtes-vous sûr que le but de toutes ces transformations qui vous
fatiguent déjà rien que d'en parler soit un meilleur référencement ?

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Olivier Masson

unread,
Mar 10, 2011, 2:55:33 AM3/10/11
to
Le 09/03/2011 21:43, Eric Demeester a écrit :

> Moi, à la base, je suis développeur et je ponds du code via divers
> outils et sous divers systèmes d'exploitation depuis... 1983.
>

Les pires (développeurs)... ;)

> Mon objectif a toujours été de produire un code aussi propre, rapide et
> maintenable que possible.
>
> Alors quand je lis qu'il faut minifier, concaténer, compiler, bzipper,
> créer des sprites, whatever, ma première réaction est « pourquoi pas,
> mais ça va me pourrir la vie parce qu'il faudra passer par n scripts
> intermédiaires, qu'une fois mes sources moulinés par ces scripts ils
> deviendront probablement illisibles par un humain, que tout ça va me
> faire perdre du temps parce qu'à chaque fois que je ferai une
> modification il faudre remouliner, et que si c'est juste pour monter de
> quelques crans dans le référencement de Google, de mon point de vue, le
> jeu n'en vaut pas la chandelle, parce que le référencement n'est pas ma
> préoccupation principale[*] ».
>

Comme le dit Paul ensuite, le référencement n'est pas le but de ces
bonne pratiques.
Mais c'est une possible conséquence, puisque Google aime la vitesse.

1/ Le but est avant tout accélérer l'affichage de tes pages.
2/ En allant un peu plus loin, mais toujours avec le même type de
méthode, tes scripts et tes css concaténés porteront un numéro de
version, ce qui permet de mettre des expires lointain tout en
garantissant le chargement des nouvelles versions. Sans avoir à - trop -
te préoccuper des innombrables méandres de la gestion de cache

Bien évidemment, tout ceci ne se fait pas au détriment de la lisibilité
de ton code (ce sont de nouveaux fichiers qui sont crées : ils ne
remplacent pas les tiens), sauf si tu mets un point d'honneur à ce que
tes visiteurs voient l'intégralité de tes JS et CSS, avec commentaires
et indentation.
Sinon, tout ceci s'effectue en un lancement de script, voire aucun si tu
utilises (avec prudence) mod_pagespeed sous Apache 2.2.

Comme je l'ai dit, si tes sites font 4 pages, statiques, avec 3 images
et un poids total de 50ko, tu peux très bien ne rien faire de plus.

Et, bien entendu, tout ceci ne dispense pas de réfléchir ! Si tu
concatènes 5 fichiers JS mais qu'il y en a un qui est modifié souvent,
il est plus efficace de le laisser à part : tu n'auras pas à relancer le
script d'optimisation chaque jour et tes visiteurs n'auront pas à
charger à nouveau tout ton bloc de 5 scripts concaténés pour une petite
modif effectuée.

Bref, si ce type d'optimisation est clairement pertinent, il convient de
réfléchir un minimum à la façon de le mettre en place et à ce que ça
entraine comme conséquence.
Se poser aussi des questions sur la créa de sprites donc (qui est une
partie plus sensible car moins automatisable). Regarde les sprites
utilisés par Google par exemple et constate qu'ils sont différents de
ceux utilisés par iGoogle : les besoins ne sont pas les mêmes et iGoogle
étant plus lourd, ils allègent leur sprite.

Pierre Goiffon

unread,
Mar 10, 2011, 10:42:30 AM3/10/11
to
On 10/03/2011 08:55, Olivier Masson wrote:
>> Mon objectif a toujours été de produire un code aussi propre, rapide et
>> maintenable que possible.
>>
>> Alors quand je lis qu'il faut minifier, concaténer, compiler, bzipper,
>> créer des sprites, whatever, ma première réaction est « pourquoi pas,
>> mais ça va me pourrir la vie parce qu'il faudra passer par n scripts
>> intermédiaires, qu'une fois mes sources moulinés par ces scripts ils
>> deviendront probablement illisibles par un humain, que tout ça va me
>> faire perdre du temps parce qu'à chaque fois que je ferai une
>> modification il faudre remouliner, et que si c'est juste pour monter de
>> quelques crans dans le référencement de Google, de mon point de vue, le
>> jeu n'en vaut pas la chandelle, parce que le référencement n'est pas ma
>> préoccupation principale[*] ».
>
> Comme le dit Paul ensuite, le référencement n'est pas le but de ces
> bonne pratiques.
>
> 1/ Le but est avant tout accélérer l'affichage de tes pages.
> 2/ En allant un peu plus loin, mais toujours avec le même type de
> méthode, tes scripts et tes css concaténés porteront un numéro de
> version, ce qui permet de mettre des expires lointain tout en
> garantissant le chargement des nouvelles versions. Sans avoir à - trop -
> te préoccuper des innombrables méandres de la gestion de cache
>
> Bien évidemment, tout ceci ne se fait pas au détriment de la lisibilité
> de ton code

Exactement. Et ces gains sont tout à fait conséquent dans les nombreux
exemples cités sur les blogs dont nous avons parlé. Olivier Masson
citait (message-id : <4d76072c$0$10712$426a...@news.free.fr>) une page
dont l'affichage passait de 20s à moins d'1s...

Vraiment, j'encourage tout le monde à regarder la vue réseau d'un
firebug avec yslow et de constater comme sur la très large majorité des
pages web on pourrait gagner des secondes et des secondes de chargement
avec ces actions !

> Bref, si ce type d'optimisation est clairement pertinent, il convient de
> réfléchir un minimum à la façon de le mettre en place et à ce que ça
> entraine comme conséquence.

Exact :)

Message has been deleted
0 new messages