Le module Apache mod_pagespeed de Google

Bonjour,

Je viens de voir ça. C'est quelque chose qui va se greffer directement sur le serveur si j'ai bien compris, donc un hébergement mutualisé chez Ovh par ex c'est cuit?

 

J'imagine qu'ils l'implémenteront prochainement.

Sinon, d'après ce que j'ai compris, l'extension modifie la source à la volée. j'ai bien peur que ça rende invalide le code généré...
Après faut faire un choix, pour ma part, si le gain est intéressant, je suis pour

 

Merci Olivier.

A tester.

S'il y a des testeurs, les retours sont les bienvenus :wink:

 

Ça me plairait bien moi, étant donné que je n'ai pas les compétences pour compresser mes CSS et compagnie pour gagner en rapidité

 

C'est un module qui s'occupera de faire le boulot de différents modules Apache comme mod_deflate ou de gzip ou alors c'est une couche supplémentaire?

 

Bon, je viens de faire des tests de mon côté, et si le site est codé pour être optimisé, ce mod_pagespeed ne fait rien.
Bon, pour des sites "pas optimisé" (pour pas être méchant) j'ai eu un "bon" gain de perf (de l'ordre de 10%) de mon côté quand même.
Apache consommait un peu plus (très léger toutefois)

Page speed rajoute toutefois un header

Code:

X-Mod-Pagespeed

Bon, j'espère qu'ils vont pas améliorer le positionnement de ceux qui auront ce mod sinon on va le rajouter en PHP

Sinon, pas encore de version Lighttpd alors pas pour moi, mais ça peut être pas mal pour des joomla blindé de module.

 

Merci Julia41 pour ce retour

 

Pour ceux que ca intéresse, voici ce que fait principalement ce module (chaque filtre est désactivable, et l'on peut créer ses propres filtres) :
- mesure du temps de chargement via un code js : on peut ainsi connaître les temps de chargement réels sur les navigateurs des visiteurs (inutile si on utilise Jiffy).
- concaténation des fichiers CSS et ajout d'un entête d'expiration
- ajout d'entête d'expiration pour les fichiers spécifiés (images, CSS, JS) pour améliorer la mise en cache.
- minification du code javascript (pour l'instant l'algorithme utilisé est proche de JSMin, mais on peut imaginer que l'équipe Google redéveloppe le moteur de YUI compressor par la suite).
- compression des images PNG et JPG à la volée, et ajoute les attributs height et width à tous les tags img (permet d'accélérer le rendu de la page).

Autres petites améliorations:
- supprimer les espaces multiples dans le code source, les quotes des attributs ainsi que les commentaires HTML
- supprimer les attributs par défaut dans les tags HTML
- copie des petits fichiers javascript directement dans le code source de la page (évite des requêtes supplémentaires).
- copie des petites images directement dans le code source de la page (évite des requêtes supplémentaires - inline images).


Je suis impressionné par la qualité du module et les améliorations apportées, il y a un énorme gain de temps pour les visiteurs, ce qui peut améliorer à la fois la navigation et le référencement. Par contre il ne faut pas croire que ces optimisations sont gratuites, elles prennent un certain temps côté serveur (plusieurs passes sont nécessaires pour analyser/parser/modifier les fichiers/requêtes). A mon avis cette solution est idéale pour les novices qui veulent accélérer leur site rapidement, ainsi que les nouveaux sites. Pour les autres qui avaient déjà commencer à optimiser, ce n'est pas nécessaire. Selon l'article Go Daddy pourrait activer le module pour les sites qu'il héberge, donc pourquoi pas demain les autres hébergeurs français, OVH en tête ?

 

Ca m'étonne qu'il n'y ait que 10%... Est ce que le mod était configuré en full options?

 

Merci beaucoup Bigb06 pour la description, dès que j'ai le temps ce soir j'installe ce module sur mon serveur

Sinon l'optimisation n’entraîne pas de problème d'affichage sur certain navigateur ?

 

A mon avis il faut obligatoirement un serveur de préprod pour tester car ca peut effectivement faire des choses étranges... Après certaines options sont sures, comme la compression des images, la minification des js, l'ajout d'entete d'expiration. Mais dès qu'on concatène ou que l'on remplace le code source, mieux vaut tester!

 

Hello,

Merci à Olivier pour l'info, et merci à Bigb06 pour la synthèse des modifs.

Ca veut dire quoi "suppression des attributs par défaut dans les tags html" ? "Copie de petites images" ?
Est-ce que les balises alt des images, qu'on a tant pris soin d'optimiser, sont concernées ??? Est-ce que les images ajoutées ne viennent pas polluer le code HTML (d'un point de vue sémantique) ?

Bref, selon vous, pensez-vous que l'optimisation technique se fasse sans nuire à l'optimisation SEO ?

 

c'est ce que je fais actuellement avec des modules PHP que j'ai développé moi même, et j'admet que ca permet de gagner pas mal.
maintenant si je peux déléguer cette tache au serveur c'est encore mieux : moins de codes PHP = moins de failles potentielles et + de performances.

je fais un test ce soir

 

Par exemple :
- les balises input sont de type text par defaut, donc inutile de rajouter l'attribut type="text", ou pour le tag form l'attribut method est par defaut get... (il y en a une vingtaine dans le code source)
- les attributs "doublés" : <option selected="selected"> est réécrit en <option selected>

Si une image est petite en taille (moins de x octets), le fait de l'ajouter directement dans le code source encodée en base64 évite de faire une requête supplémentaire au serveur (une autre solution serait de créer un sprite CSS regroupant plusieurs petites images).

Les balises alt ne sont pas touchées, les images ne gènent pas. Par contre je pense que le code peut ne plus être valide XHTML si on enlève les quotes par exemple (à vérifier).

 

Code:

<option selected>

Ça fait une erreur en XHTML :?

Pas prêt de l'utiliser si ça destroy le code comme ça.

 

On peut choisir les filtres à activer, ainsi que le fait de garder la compatibilité XHTML (de toute façon cette optimisation est vraiment mineure).

 

Comme je le disais ailleurs, je suis septique sur le base 64, les benchs ne sont pas vraiment à l'avantage du base64 et encore plus quand celle-ci sont dans un sprite. En utilisant "outils de développement" dans chrome, le base64 a toujours une ligne dans le "size" même après un second affichage (base 64 se trouvant dans le CSS). Evidemment ce n'est pas le cas pour un sprite. Du coup, j'ai un fort doute sur l'intérêt de le passer en base 64. En cherchant un peu sur GG (en anglais), je n'ai quasiment trouvé personne qui semblait être pour. Si vous avez fait des tests sprite/base64 comme comparaison, ça m'intéresse (voir sprite + base 64, ce que j'avais essayé aussi, mais vu la taille minime des images, le bench n'est pas évident à faire).

J'oubliais, à moins d'utiliser mhtml en plus, IE6 et IE7 n'affiche rien avec le base64 (ce qui n'est évidemment pas le cas du sprite).

Du coup, je suis resté sur du sprite pour le moment.

 

Moi je pense qu'il ne faut pas oublier qui publie le module. Google veut réduire sa consommation en ressources. A voir si ça nous sert aussi.

 

Dès qu'il y a plusieurs petites images (à partir de 3 ou 4), le sprite remporte les benchs, rien que par la possibilité de mise en cache.

La aussi ce filtre est désactivable dans le module apache si on utilise les sprites par ailleurs.

 

Merci pour les retours, c'est vraiment utile de voir ce que ça donne.

En gros si on a déjà fait de gros efforts sur les sprites, min css et tout ça, ça n'apporte pas forcément un plus.

 

Je ne veux pas faire la fine bouche, mais avant même de tester cette gracieuse optimisation offerte par google, je souhaiterais jeter un oeil sur les sources, mais je dois vieillir car je ne les trouve pas, si quelqu'un a le lien :wink:

 

Les sources sont dispo ici (en plus c'est pas mal commenté):
http://code.google.com/p/modpagespeed/source/browse/

 

merci

 

C'est vraiment un gros plus que nous propose là Google. Espérons qu'OVH & co mettent ça rapidement partout !

 

Ça je n'y crois pas trop.

 

Pourquoi ? A priori c'est l'utilisation la plus intéressante. Après c'est comme pour PHP au départ, les hébergeurs vont définir les options "safe" et n'activer quelles ci (minification des fichiers, mise en cache, compression des images). Rien qu'avec ces optimisations on peut réduire le temps de chargement et la consommation de bande passante.

 

Bonjour,

C'est incroyable cette nouveauté,
je ne connais pas les performances de ce module, mais le coeur y est.
Faut voir si c'est un outil qui apporte réellement un plus ou une manière simplifié d'optimiser Apache pour les néophytes .

Le 2ème réflexe (le 1er a été "rolala !") qui m'est venu de suite c'est
"Ce module n'est-il pas un petit apéritif, une mise en bouche avant de lancer un plus grand projet dans les middleware et concurrencer directement Apache ?
"

A l'époque il avait soutenu le dév de Firefox pour freiner IE,
et en arrière-plan ils planchaient déjà sur Chrome.