Google a sorti mod_pagespeed, un nouveau module pour Apache permettant d'optimiser les ressources du serveur, une nouvelle possibilité pour accélérer la vitesse de chargement des pages.
Détails
Détails
Le module Apache mod_pagespeed de Google
- Auteur de la discussion WebRankInfo
- Date de début
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
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.
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-PagespeedSinon, pas encore de version Lighttpd alors pas pour moi, mais ça peut être pas mal pour des joomla blindé de module.
WRInaute accro
Merci Julia41 pour ce retour
WRInaute impliqué
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 ?
- 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 ?
WRInaute impliqué
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!
WRInaute impliqué
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 ?
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 ?
Bigb06 a dit:
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
WRInaute impliqué
nza2k a dit:
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).nza2k a dit:
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).nza2k a dit:
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.
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.
WRInaute impliqué
Les sources sont dispo ici (en plus c'est pas mal commenté):
http://code.google.com/p/modpagespeed/source/browse/
http://code.google.com/p/modpagespeed/source/browse/
WRInaute impliqué
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.
WRInaute impliqué
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.
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.
Discussions similaires
