Après avoir développé l'extension Page Speed pour Firefox, qui permet aux webmasters de tester la vitesse de chargement de leurs pages et d'obtenir des conseils d'optimisation, Google vient de lancer un module Apache sensée leur faciliter le travail.
En effet, plutôt que de devoir faire manuellement les optimisation dans leur code, les webmasters pourront s'appuyer sur ce module Apache pour appliquer à la volé certaines optimisations. Baptisé mod_pagespeed, ce module propose propose une petite vingtaine de filtres :
- ajout de la balise <head> si elle est absente,
- ajout d'un tracker permettant de mesurer le temps de chargement chez les visiteurs,
- suppression des espaces inutiles,
- combinaison de tous les fichiers CSS en un seul,
- combinaison des balises <head> multiples en une seule,
- augmentation des durées de cache,
- intégration des petits fichiers CSS directement dans le code HTML,
- intégration des petits fichiers JS directement dans le code HTML,
- minimisation du code JavaScript,
- déplacement des inclusions CSS dans l'en-tête,
- optimisation des images,
- extraction des styles CSS,
- extraction des JavaScripts,
- suppression des commentaires,
- suppression des délimiteurs inutiles,
- minimisation du code CSS.
Attention tout de même à ne pas trop se reposer sur ce module : non seulement, son utilisation risque d'augmenter la charge processeur sur le serveur, mais en plus, il est toujours préférable d'effectuer le plus possible d'optimisations à la main, pour garder un maximum de contrôle sur le code généré, et donc pouvoir s'assurer au mieux de son bon fonctionnement.
\o/ 1000ème news sur Infobidouille \o/
Posté par Matt le 05/11/2010 à 00h21
5 commentaires
Source : Generation NT
Posté par Ptit_boeuf le 05/11/2010 à 15h00 - Citer
Félicitations !
Si je comprends bien, ce module optimise les données envoyées pour qu'elles soient le plus facilement possible affichables par le client? Et cela au détriment du serveur.
Comme tu dis, je pense qu'il vaut mieux optimiser son code "à la main" que de se reposer sur ça.
Ici on ne fait que déplacer le problème, sachant que le maillon faible est souvent le serveur en lui même, je pense qu'il vaut mieux utiliser pages peed sur un client que de mettre ce module sur apache.
En tout cas, merci pour cette news, elle m'a permis de découvrir page speed for ff !
kstor a écrit :
Si je comprends bien, ce module optimise les données envoyées pour qu'elles soient le plus facilement possible affichables par le client? Et cela au détriment du serveur.
Oui, c'est ça. L'idée, c'est de limiter :
- le volume transféré,
- le nombre de fichiers transférés.
kstor a écrit :
Comme tu dis, je pense qu'il vaut mieux optimiser son code "à la main" que de se reposer sur ça.
La plupart des optimisations (quasiment toutes) peuvent être faites à la main. Mais y en a pour lesquelles c'est plus pratiques de les faire à la volée plutôt qu'en dur, et je vais sans doute l'installer pour ça, parce que c'est des choses que tu peux pas faire au niveau du code sans le rendre illisible :
- suppression des commentaires,
- suppression de l'indentation du code HTML et des délimiteurs.
La minimisation du code JS/CSS, c'est pareil, tu peux pas le faire en dur parce que ça devient illisible et donc impossible à maintenir (tout sur une ligne, sans espace : http://static.infobidouille.com/design/css.php ), donc le module peut être utile pour ça. Perso je le fait avec un script PHP qui regroupe les fichiers CSS et les minimise, mais si y avait eu le module Apache avant que je fasse ça en PHP, j'aurais pris le module :-)
L'ajout du tracker permettant de mesurer le temps d'affichage chez les clients, c'est pas mal aussi, ça permet de mesurer l'impact des modifications qu'on fait à la main :-)
Par contre, le truc qui me gêne, et que j'activerais donc sans doute pas, c'est toute la partie redimensionnement/recompression des images, parce que là si on fait pas gaffe on peut se retrouver avec des grosses pertes de qualité. Mais la doc du module est pas mal faite, pour chaque filtre elle indique le risque qu'il peut y avoir à l'utiliser, les effets de bord que ça peut induire, etc... Bon de toute façon, je pourrais pas l'activer, vu que mes contenus statiques sont servis par lighty pas par Apache, et ça sera toujours plus rapide qu'avec un Apache, même optimisé à mort ^^
kstor a écrit :
Ici on ne fait que déplacer le problème, sachant que le maillon faible est souvent le serveur en lui même
Tout dépend du dimensionnement du serveur. Souvent, il y a beaucoup de temps CPU en rabe, alors que la bande passante est limitante.
Et côté client, la bande passante est souvent limitante.
Donc sacrifier un peu de temps CPU pour soulager de la bande passante, c'est pas forcément un mauvais plan. Faut juste pas le faire à la légère sans avoir pris le temps de regarder si les ressources sont suffisantes.
Dans le cas d'Infobidouille par exemple, y a vraiment pas de souci côté CPU, les pages se génèrent en moyenne en moins de 20ms, donc je peux activer cette extension sans risque : si le temps de génération d'une page augmente de 5ms, mais que derrière on économise une requête (quelques dizaines de ms) et 10 Ko (160ms sur une ligne 1 Mbits/s), c'est tout bénef pour le confort global des visiteurs. C'est juste les effets de bord indésirables de certains filtrent qui m'embêtent, donc je vais pas tout activer.
Bien compris
C'est vrai que j'ai tendance à regarder ça du coté de mon site qui tourne sur un p3 avec pas mal de calculs sur des bases bien lourdes (courbes de corrélation sur 16000 valeurs...)
Du coup chez moi c'est clairement le serveur qui est limitant avec parfois plusieurs minutes pour afficher les calculs sur une page (merci les set_time_limit).
Si je peux gagner du temps niveau serveur ça fait du bien.
C'est sûr que quand ça mouline plusieurs minutes pour afficher une page, c'est plus la bande passante qui limite ^^
Sur Infobidouille, j'ai pas mal travaillé la mise en cache pour limiter l'usage de ressources sur l'ancien serveur (Dedibox avec un Via C7 et seulement 1 Go de RAM, c'était vraiment très très tendu par moments...), du coup avec le code actuel y a quasiment plus de requêtes en base de donnée, moins d'une par page en moyenne, le gros du traitement, c'est quelques lignes de PHP pour aller lire les fichiers de cache.
Cela dit, même dans ton cas, ça peut valoir le coup de sacrifier un peu de temps CPU pour limiter le volume à transférer : c'est pas forcément lui qui limite les perfs, ça peut aussi être les I/O.