Oui enfin comme beaucoup de monde je suppose, on a un outil de déploiement qui se charge de la «minimisation». Ca n'est donc pas fait à la volée, mais fait lors de la livraison.
Mon propos concernait plutôt des points comme les sprites, qui pour moi peuvent difficilement être automatisées. Ou justement l'assemblage de fichiers CSS ou JS à outrance, qui serait contre productif si effectués systématiquement.
Pour ce qui est de déplacer les fichiers statiques sur un domaine sans cookie, j'imagine mal mod_pagespeed s'en charger, mais je peux me tromper.
Quant à déplacer les inclusions JS en fin de page, vu qu'il faut adapter les scripts en conséquence j'imagine mal un outil le faire de manière automatique, mais là encore, je peux me tromper.
Bref, mod_pagespeed, il prend en charge quoi ? De ce qui a été dit ici, j'aurais tendance à dire :
- il regroupe toutes les CSS d'une page en un seul hit, en construisant une URL basée sur un hash du contenu, et il en profite pour minimiser le dit contenu et mettre un temps d'expiration adapté (c'est à dire «illimité»).
- il fait exactement la même chose avec le JS
- il modifie à la volée le format de l'image pour les convertir au format WebP, si le navigateur le supporte
- il remplace l'image par sa version inline si elle est «petite»
- il redimensionne l'image à la volée, si nécessaire
Bref, j'aurais aimé avoir une vision d'ensemble des principales fonctionnalités, avec un retour des utilisateurs. Je pense que j'ai une bonne partie des réponses, et pour ceux qui voudraient creuser un peu plus, ils peuvent se reporter à la liste des filtres de mod_pagespeed.
Comme l'a fait remarquer titinux, si le framework utilisé sur le site gère tout ça, mod_pagespeed est nettement moins utile. Mais en même temps le module semble suffisamment configurable pour n'activer que les fonctionnalités non prises en charge par le framework.
Pour ma part je me suis fait mon opinion : ça peut-être super utile pour combler les lacunes de développements mal branlés, ou même pour montrer rapidement à un client l'intérêt de travailler son code. Libre à lui de garder l'outil tel quel ou non après.
[^] # Re: Réellement efficace ?
Posté par Kioob (site web personnel) . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 1.
Oui enfin comme beaucoup de monde je suppose, on a un outil de déploiement qui se charge de la «minimisation». Ca n'est donc pas fait à la volée, mais fait lors de la livraison.
Mon propos concernait plutôt des points comme les sprites, qui pour moi peuvent difficilement être automatisées. Ou justement l'assemblage de fichiers CSS ou JS à outrance, qui serait contre productif si effectués systématiquement.
Pour ce qui est de déplacer les fichiers statiques sur un domaine sans cookie, j'imagine mal mod_pagespeed s'en charger, mais je peux me tromper.
Quant à déplacer les inclusions JS en fin de page, vu qu'il faut adapter les scripts en conséquence j'imagine mal un outil le faire de manière automatique, mais là encore, je peux me tromper.
Bref, mod_pagespeed, il prend en charge quoi ? De ce qui a été dit ici, j'aurais tendance à dire :
- il regroupe toutes les CSS d'une page en un seul hit, en construisant une URL basée sur un hash du contenu, et il en profite pour minimiser le dit contenu et mettre un temps d'expiration adapté (c'est à dire «illimité»).
- il fait exactement la même chose avec le JS
- il modifie à la volée le format de l'image pour les convertir au format WebP, si le navigateur le supporte
- il remplace l'image par sa version inline si elle est «petite»
- il redimensionne l'image à la volée, si nécessaire
Bref, j'aurais aimé avoir une vision d'ensemble des principales fonctionnalités, avec un retour des utilisateurs. Je pense que j'ai une bonne partie des réponses, et pour ceux qui voudraient creuser un peu plus, ils peuvent se reporter à la liste des filtres de mod_pagespeed.
Comme l'a fait remarquer titinux, si le framework utilisé sur le site gère tout ça, mod_pagespeed est nettement moins utile. Mais en même temps le module semble suffisamment configurable pour n'activer que les fonctionnalités non prises en charge par le framework.
Pour ma part je me suis fait mon opinion : ça peut-être super utile pour combler les lacunes de développements mal branlés, ou même pour montrer rapidement à un client l'intérêt de travailler son code. Libre à lui de garder l'outil tel quel ou non après.
alf.life