Pourquoi publier mod_pagespeed est une erreur de Google

Il y a déjà quelques années, Yahoo! bousculait bien des idées reçues en affirmant que les potentialités de gains de performance des applications web se situaient davantage du côté client que du côté serveur.

La prise de conscience

Menée par Steve Souders, une équipe baptisée Exceptional Performance team était constituée dans le but de mener des recherches sur les technologies web et leur gestion par les navigateurs. A l’issue de ces longs tests empiriques,  l’équipe a publié une liste de préconisations qui a bousculé certaines idées reçues.

Dans la foulée, l’équipe publiait Yslow, une extension pour Firefox qui permet de tester très simplement l’application de ces préconisations. On obtient une note entre A et F qui permet de situer son site par rapport à d’autre en terme de performances et de lister les améliorations possibles.

Google entre dans la danse

Google ne pouvait rester longtemps étranger à cette problématique, le géant américain recrute donc Steve Souders début 2008 pour monter une équipe similaire en son sein.

L’équipe publie rapidement sa propre liste de préconisations ainsi qu’une extension pour Firefox nommée PageSpeed. La filiation avec Yslow et les préconisations de Yahoo est évidente même si chacun conserve ses particularités.

Un choix contre-productif

Pour aller plus loin, Google a annoncé hier la sortie de mod_speedpage, un module Apache qui permet de mettre en place simplement ces préconisations. L’intention est louable mais elle me semble contre-productive au final.

Proposer des préconisations sous un format facilement compréhensible avec à la fois les raisons qui amènent à prodiguer ce conseil et les manières de l’implémenter me semble être une bonne manière d’éduquer les développeurs web et les administrateurs de serveurs en partageant avec le plus grand nombre le fruit des recherches complexes effectuées par des équipes de pointe.

Au contraire, empaqueter l’application des ces préconisations dans un module Apache prêt à l’emploi me semble être une fausse bonne idée car les plus fainéants (et qui ne l’est pas au fond ?) vont préférer installer ce module à l’étude puis l’implémentation manuelle des préconisations. On perd au passage la prise de conscience et la compréhension fine des problématiques sous-jacentes.

On risque également de se retrouver avec des modules mal configurés qui n’apporteront pas grand chose, donnant une fausse impression de travail accompli.

Il est important de rappeler au passage qu’en matière de performance, chaque évolution doit être validée par des mesures précises. Les benchmarks montrent souvent que les problèmes ne se situent pas vraiment là où on le pense intuitivement. Par ailleurs, modifier un élément pour améliorer la vitesse d’affichage d’une application web ne doit pas être basé sur l’intuition au risque de ne rien gagner voire même de perdre en performances.

Tout n’est pas à jeter

Il faut cependant veiller à ne pas jeter le bébé avec l’eau du bain car il y a également de bonnes choses dans ce projet de Google.

Tout d’abord mod_speedpage est très paramétrable et peut être utilisé en complément des optimisations manuelles notamment pour ce qui concerne du code dont on n’aura pas la maîtrise (contenu généré par des utilisateurs, code géré par une équipe tierce ou un prestataire, code intégré dynamiquement depuis une source non maîtrisée, etc.)

Le module propose également un mécanisme permettant de déterminer la vitesse d’affichage des pages dans le navigateur des visiteurs de manière automatisée. Cela permet d’aller plus loin que les tests de performances menées par l’équipe de développement et qui sont forcément limitées par les configurations à disposition.

En conclusion, je trouve l’initiative intéressante sur certains aspects mais j’ai bien peur qu’elle ne vienne annihiler une partie des efforts fait par Yahoo! et Google depuis quelques années pour promouvoir les performances web.

Ce contenu a été publié dans Développement Web, avec comme mot(s)-clé(s) , , , , , . Vous pouvez le mettre en favoris avec ce permalien.

10 réponses à Pourquoi publier mod_pagespeed est une erreur de Google

  1. Olivier BOISSIN dit :

    On va expérimenter ça en frontal d’instances SAP Business Warehouse qui a tendance à coller des tartines de code dans tous les sens, et ça pourrait être un bon moyen d’optimiser sensiblement l’expérience utilisateur. Je trouve au contraire que c’est une bonne idée de la part de Google ; de toute façon on faisait déjà ça avec plus ou mons de succès via des scripts maison ou des pizzabox type Bluecoat.

  2. Manolo1011 dit :

    Juste pour bien préciser les choses :

    Yslow est une extension à Firebug, lui-même extension propre au navigateur Firefox de la fondation Mozilla

  3. Manolo1011 dit :

    Sinon l’article est interresant mais comme tu dis, il ne faut pas tout jeter.
    J’ai déjà remarqué pour ma part le filtre combine_css qui est peut se reveler utile.
    Ainsi que les classiques suppresseur d’espace/commentaires en tout genre.

    Par contre je ne suis pas fan de la suppression des quotes et des modifications html à la volée

    Voilou

  4. jmfontaine dit :

    @Manolo1011: Tu as tout à fait raison de faire cette précision dont j’ai bien connaissance.

    Je voulais simplement ne pas compliquer mon propos avec ce qui reste un détail par rapport au sujet évoqué ici.

  5. Florian dit :

    @jmfontaine: Je ne crois pas que confondre une extension PHP avec un addon Firefox soit un détail qui facilite la compréhension de l’article, au contraire.

  6. Florian dit :

    Par contre je suis entierement d’accord avec le fond du sujet.

  7. jmfontaine dit :

    @Florian: Tu as tout à fait raison d’attirer mon attention sur ce point. C’est une typo de ma part. J’avais bien entendu voulu écrire « Firefox » et non « PHP ». C’est corrigé.

    J’étais tellement persuadé d’avoir écrit ça correctement que j’ai mal compris le commentaire de Manolo1011. Je pensais qu’il voulait préciser que c’était plus précisément une extension pour Firebug au-delà d’être une extension pour Firefox.

    Bref, merci de m’avoir signalé mon erreur ! 🙂

  8. metagoto dit :

    Et si c’était le contraire?
    mod_pagespeed fait parler de lui et indirectement des recommandations sur lesquelles ce module est basé. N’est-ce pas l’essentiel?

    Une fois installé, les devs/admins en charge du site ne manqueront pas de lancer les batteries de tests usuels. Si la note obtenu est bonne (note A, score 100 etc) , je ne vois pas où est le problème? Les personnes qui auront été au bout de cette démarche auront tout autant appris des bonnes pratiques que les autres éclairées. Du moins, c’est mon avis.

    A-t-on besoin de compresseurs CSS ou javascript? Ne vaut-il mieux pas écrire ces codes directement compressés? Après tout, les techniques de minimisations sont connues. Il est bien sûr hors de question de faire ce travail à la main. Pour mod_pagespeed, je pense que c’est un peu la même chose: si un programme peut faire le boulot, autant le lui déléguer.

  9. jmfontaine dit :

    @Metagoto: Je suis d’accord que c’est surtout le résultat qui compte ici mais je crains qu’à ne pas étudier les causes du problème, on applique imparfaitement la solution.

    Je suis d’accord sur le fait qu’il faut déléguer au maximum à des programmes les tâches sans valeur ajoutée. Cependant, si certaines préconisations simples peuvent être automatisées, comme la minification et la compression de CSS et de JS, tout ne peut pas l’être. Ainsi, il est difficile de déplacer automatiquement en bas de page le code Javascript car parfois un ordre ou un positionnement précis dans la page sont nécessaires.

    Par ailleurs, pour moi l’opposé d’utiliser mod_pagespeed n’est pas écrire du JS minifié manuellement. 😉
    Je suis partisan du JS extensif et commenté en développement (celui qui est stocké dans le dépôt de code) et de déléguer le travail de préparation à la production (suppression des commentaires, minification, concaténation, etc.) au script de déploiement.
    Ainsi, on développe confortablement sans sacrifier les performances en production tout en gardant un contrôle fin sur le code et ses éventuelles particularités.

  10. Joris dit :

    Je pense cerner ta crainte Jean-Marc : une utilisation systématique de ce module Apache sans y comprendre l’intérêt et surtout ses origines.

    Comme Metagoto, je suis bien et évidemment pour la création de tels outils qui pourront faire économiser certaines sommes en audit pour des sociétés souhaitant optimiser un peu leur perf’ Web mais il adviendra des situations où l’utilisation sans l’aide d’une étude de performance sera peu fructueuse et dans ce cas-ci, alors il sera véritablement nécessaire de faire appel à des conseillers.
    Je ne sais pas si je me suis fait comprendre…

    Peut-être que Google a sorti cette extension trop tôt pour un public pas assez sensibilisé aux problèmes de performances… ?

Les commentaires sont fermés.