Qui a installé le mod apache Google page_speed ?

[1-sponsor]

Pas moi, je me tâte et j'ai peur que ça ne change pas grand chose et vous ?

http://code.google.com/intl/fr/speed/page-speed/

[loran750]

Hello

je me suis dit que je pouvais faire un test, pourquoi pas.
J'ai fait ça sur 4 sites : 1 joomla bien chargé, 1 joomla léger, 1 forum, 1 statique html.
j'ai fais des screenshots de Firebug avec

• Ligne 1 :
  • Camembert de gauche = charge de la page en accès direct
  • Camembert de droite = charge de la page AVEC cache navigateur
• Ligne 2 :
  • Camembert de gauche = charge de la page en accès direct
  • Camembert de droite = charge de la page AVEC cache navigateur

4e site : j'ai merdé dans les screenshots donc je ne le propose pas, c'était une homepage assez légère sous Joomla 1.5.x et le résultat était assez similaire à Joomla 1.0.X au niveau des proportions.

Bref. Le constat (rapide) est :
- les pages sont parfois plus lourdes (mais pas tout le temps)
- mais il y a moins d'appels HTTP.
Cela a du bon

Conclusion : ça peut aider, ça ne peut pas faire de mal. Je le laisse, je vais pas faire de test supplémentaire, je vais me contenter du graphique de la vitesse d'accès et de téléchargement des pages par GoogleBot dans les Webmasters Tools.

[1-sponsor]

Super partage, merci ! Tu ne sais pas si ça fait consommer plus de ram ou du cpu au serveur ?

[loran750]

Hello 1-sponsor

non, j'ai vraiment fait un truc rapide.
A mon avis, il est super facile d'activer/désactiver le module pour faire les tests et vérifier ce que tu demandes.

En tout cas ça m'a pris 30 secondes pour le faire, en laissant les options par défaut.
Sous Debian/Ubuntu/CentOS/Fedora, il y a 2 lignes à lancer et ça se trouve sur la page Downloads

Faudrait voir non seulement la RAM et le CPU mais aussi le temps d'accès total de la page. Firebug le fait...
Mais j'ai pas envie de le faire, je vais attendre quelques jours et voir le résultat dans GWT :p :p :p


Entre nous, je pense que ça sert lorsqu'il y a pas mal de connexions. Comme il y a moins d'appels HTTP, et si tu as un CPU et une RAM qui tiennent la route, ça soulage Apache.
Sur mon Kimsufi avec un processeur Atom de m****, je préfère charger Apache que de charger mon CPU... donc je suis intéressé par des tests complémentaires.

lolo

[1-sponsor]

Pas mieux :

Sur mon Kimsufi avec un processeur Atom de m****, je préfère charger Apache que de charger mon CPU... donc je suis intéressé par des tests complémentaires.

[Julia41]

Perso je viens de faire le test sur le site d'un client qui est très lourd (1Mo pour la page d'accueil, environ 200 requêtes HTTP, 25 CSS et j'en passe). On gagne "un peu" mais pas autant que je voudrais.
Ca ne remplace pas un site bien codé.
Certaines optimisations, genre la compilation des CSS sont une charge inutile et peuvent être fait en 2 minutes à la main par le développeur. Pour les CSS c'est pareil.
Il n'y a que pour les images où ça peut être un gros plus (+) je pense.
J'attends aussi le résultat de GWT avant de voir si ça a vraiment un impact positif ou négatif:

Code: Tout sélectionner

En moyenne, les pages de votre site se chargent en 4,6 secondes (dernière mise à jour : 16 nov. 2010). Plus lent que 71 % des sites

[Bigb06]

Tout est faisable à la main, mais pour un outil automatique simple à installer, ca reste impressionnant. Pour les résultats il faut bien comprendre quelles options activer, et qu'est ce qu'on doit mesurer : le module n'est pas fait à la base pour décharger le serveur, mais pour améliorer la vitesse de chargement COTE CLIENT. Il suffit de faire des tests sur des sites comme http://www.webpagetest.org/ pour avoir des résultats probants.

#loran : il y a un problème au niveau des Etags à mon avis sur ton serveur (ils doivent être activés, mais avec le mod page_speed ce n'est plus la peine et ca permet d'économiser 21 requêtes sur 22 en primed cache).

[loran750]

@bibg6 : etags ? Je ne sais pas ce que c'est. Google va m'aider

Je n'ai optimisé ni apache ni mysql sur mon kimsufi (debian/ispconfig).

Etags, un peu de lecture et de conseils :
http://nicolas.steinmetz.fr/journal/post/2008/09/16/Optimisation-apach ... pires-ETag
http://cyrilgodefroy.com/fr/index.php/2007/09/30/82-la-verite-sur-les-etags

Apparemment, c'est vivement conseillé par contre cela va à l'encontre du mode Gzip.
Quelqu'un peut confirmer ?

[Julia41]

Bon, je l'ai installé sur 2 serveurs avec des sites important et en fait ça a cassé pas mal au niveau du javascript.

Sinon, pour les perfs pour un gros site rien ne vaut une optimisation manuelle.
Pour pleins de petits sites, ça peut devenir rentable oui.

[1-sponsor]

Par "ça a cassé pas mal" ? Ça a été un plus tu veux dire ?

Sinon, à ton avis, ça pompe sur le Ram et le Cpu cette histoire ? (tu sais que ça me préoccupe pas mal en ce moment )

[Julia41]

Ca a cassé le javascript donc certaines fonctions ajax (mais elles étaient pas trop trop bien codées) ne fonctionnait plus.

Sinon, oui ça consomme "vachement" tout dépends bien sûr du type d'optimisation faites et si elles sont faciles à faire.
Genre compresser les CSS, ça se fait facilement à la main, alors pourquoi le faire faire par quelque chose d'autres.

Bon, ça reste quand même plus performant et moins consommateur que les .php qui font ça "tout seul".

[Bigb06]

Apparemment, c'est vivement conseillé par contre cela va à l'encontre du mode Gzip.
Quelqu'un peut confirmer ?

C'est totalement indépendant et le fait de désactiver les etags ne change rien à la compression.

Pour les js, si c'est mal codé, ca risque de poser des problèmes, mais l'avantage de l'outil c'est de pouvoir activer ou désactiver que ce que l'on a vraiment besoin : compression d'images, des js, des css, désactivation etags et ajout des expire headers. Rien que ca devrait augmenter sensiblement le chargement.

[polweb]

Bonjour,

c'est un module à installer sur un serveur dédié c'est çà ? Cela ne marche pas sur les mutu ?


Merci.

[loran750]

@polweb : tout juste. C'est pour les dédiés

Cependant, je pense et je crois que les mutualisés [des grands hébergeurs] sont bien optimisés... C'est leur intérêt. Comme on dit toujours, à caractéristiques égales, un bon mutualisé vaut un dédié de base. Donc ne t'en fais pas.