Mod_pagespeed : un accélérateur de pages Web

Posté par  . Édité par Bruno Michel, Davy Defaud, Mouns, Benoît Sibaud et baud123. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
34
13
oct.
2012
Internet

Mod_pagespeed est un module libre pour Apache qui a été créé en 2010 par Google. Deux ans plus tard, il est utilisé sur 120 000 sites Web pour accélérer le rendu des pages Web, et a atteint la version 1.0.

L’accélérateur utilise une série de filtres transformant les pages Web et leurs contenus associés, dans l’objectif d’apporter un meilleur confort de lecture aux utilisateurs. Les techniques d’optimisation employées sont connues et documentées chez Google en tant que bonnes pratiques pour les performances Web. Elles couvrent la réduction du nombre de requêtes HTTP, la meilleure utilisation du cache, la diminution du poids des pages, le préchargement de contenus ou encore l’exécution différée de JavaScript. Les meilleurs développeurs Web employaient déjà ces techniques, et, pour les autres, il y a maintenant mod_pagespeed.

Pour les utilisateurs de nginx, un portage a commencé. Il est encore trop tôt pour l’utiliser en production, mais vous pourrez en suivre le développement sur GitHub.

Aller plus loin

  • # Réellement efficace ?

    Posté par  (site web personnel) . Évalué à 3.

    Bonjour,

    je n'ai jamais pris le temps de tester l'impact du module Apache, voyant plus ce module comme une démo technique qu'autre chose, voir à la limite un moyen rapide de montrer au client ce qu'il pourrait obtenir s'il faisait un effort sur son code.
    Mais si certains prennent la peine de porter la chose sous NginX, je me dis que l'outil doit avoir d'assez bon résultats. Donc, quelqu'un ici pourrait-il nous faire un retour d'expérience sur le module ?

    Est-ce que le résultat s'approche de ce qu'un dev «sérieux» ferait ?

    alf.life

    • [^] # Re: Réellement efficace ?

      Posté par  . Évalué à 5.

      Un exemple promotionnel là: http://googledevelopers.blogspot.fr/2012/06/edgecast-networks-makes-web-faster-with.htm

      Il faut garder en tête qu'il y a beaucoup de cas ou il n'est pas immédiatement possible "de faire un effort sur son code": responsabilités divisées, autres priorités, projet en maintenance etc.

    • [^] # Re: Réellement efficace ?

      Posté par  . Évalué à 2.

      Est-ce que le résultat s'approche de ce qu'un dev «sérieux» ferait ?

      Non, un dev sérieux n'aura pas le même résultat.
      En effet, certaines bonnes pratiques de développement sont à l’opposée de bonnes pratiques de performance telles qu'implémentées par ce module.

      Par exemple, un bon développeur indente son code, le commente, utilise des noms de variables explicite, etc. Le module, à l'inverse va supprimer l'indentation, les commentaires, raccourcir les noms des variables, etc.

      • [^] # Re: Réellement efficace ?

        Posté par  . Évalué à 1.

        Par exemple, un bon développeur indente son code, le commente, utilise des noms de variables explicite, etc. Le module, à l'inverse va supprimer l'indentation, les commentaires, raccourcir les noms des variables, etc.

        T'es sérieux ? Tu penses vraiment que quelqu'un pourrait penser à utiliser des noms de variable court pour gagner de la place ou n'utiliser qu'un seul fichier source ? Le bon développeur il ne livre pas le code source du repository en production. Il y a une phase de construction qui optimise toute la partie JS (ou plus) spécialement pour l'application finale, et produire un artifact qui sera utilisé pour la prod. Il faut bien distinguer le code source de ce qui est exécuté, même si dans le cas de JS le langage source et cible sont les mêmes.

        • [^] # Re: Réellement efficace ?

          Posté par  . Évalué à 4.

          T'es sérieux ?

          Oui, mais je peux reformuler.

          Il est vrai que dans le commentaire originel, j'ai pris "dev" comme "développeur" (rôle) et non comme "développement" (outil).

          Et donc je confirme, ce n'est pas le travail du développeur d'optimiser le javascript qui sera exécuté.
          Et je te rejoins: il ne faut pas confondre la source avec ce qui est exécuté.

          Dans le cas d'un langage compilé, c'est le travail du compilateur. Il faut donc trouver un outil équivalent pour le langage de scripting.
          Et cet outil peut très bien être "mod_pagespeed".

          • [^] # Re: Réellement efficace ?

            Posté par  (site web personnel) . Évalué à 1.

            Oui enfin comme beaucoup de monde je suppose, on a un outil de déploiement qui se charge de la «minimisation». Ca n'est donc pas fait à la volée, mais fait lors de la livraison.

            Mon propos concernait plutôt des points comme les sprites, qui pour moi peuvent difficilement être automatisées. Ou justement l'assemblage de fichiers CSS ou JS à outrance, qui serait contre productif si effectués systématiquement.

            Pour ce qui est de déplacer les fichiers statiques sur un domaine sans cookie, j'imagine mal mod_pagespeed s'en charger, mais je peux me tromper.
            Quant à déplacer les inclusions JS en fin de page, vu qu'il faut adapter les scripts en conséquence j'imagine mal un outil le faire de manière automatique, mais là encore, je peux me tromper.

            Bref, mod_pagespeed, il prend en charge quoi ? De ce qui a été dit ici, j'aurais tendance à dire :
            - il regroupe toutes les CSS d'une page en un seul hit, en construisant une URL basée sur un hash du contenu, et il en profite pour minimiser le dit contenu et mettre un temps d'expiration adapté (c'est à dire «illimité»).
            - il fait exactement la même chose avec le JS
            - il modifie à la volée le format de l'image pour les convertir au format WebP, si le navigateur le supporte
            - il remplace l'image par sa version inline si elle est «petite»
            - il redimensionne l'image à la volée, si nécessaire

            Bref, j'aurais aimé avoir une vision d'ensemble des principales fonctionnalités, avec un retour des utilisateurs. Je pense que j'ai une bonne partie des réponses, et pour ceux qui voudraient creuser un peu plus, ils peuvent se reporter à la liste des filtres de mod_pagespeed.

            Comme l'a fait remarquer titinux, si le framework utilisé sur le site gère tout ça, mod_pagespeed est nettement moins utile. Mais en même temps le module semble suffisamment configurable pour n'activer que les fonctionnalités non prises en charge par le framework.

            Pour ma part je me suis fait mon opinion : ça peut-être super utile pour combler les lacunes de développements mal branlés, ou même pour montrer rapidement à un client l'intérêt de travailler son code. Libre à lui de garder l'outil tel quel ou non après.

            alf.life

          • [^] # Re: Réellement efficace ?

            Posté par  . Évalué à 2.

            Ça s'appelle un javascript minifier et beaucoup existent. Ils supprime les espaces non signifiants et obfusquent le code.

            Il existe beaucoup de surcouches au JS (cappuccino) ou aux CSS (sass) qui font ces étapes également.

  • # Compatibilité avec les CMS et Framework ?

    Posté par  . Évalué à 3.

    Est-ce que ce module a été tester avec les principaux CMS et Framework disponibles ?
    Drupal ? Wordpress ? Symphony ? …

  • # Ce mod est vraiment excellent

    Posté par  . Évalué à 8.

    Une partie des "bonnes pratiques" sont compatibles avec le fait de faire un bon output. Une autre partie relève d'optimisations qui suivant où elles sont faites "perturbent" le développement.

    mod_pagespeed, en agissant comme un couche intelligente (il parse le html afin d'optimiser le reste) permet de ne plus se soucier de l'optimisation car la majorité va être déférée à ce module.

    Un autre exemple tout simple, le cache des objets statiques (comme des images par ex), vous avez /image.png, vous avez configuré Apache pour que le contenu soit caché 1 mois par les navigateurs. Si vous changer cette image, certains de vos visiteurs verront l'ancienne pendant 1 mois. Une solution était de rewriter les liens vers toutes les ressources statiques avec un /image.png?088ce4c616b1f4cd10ffe5346a4015b8, le code étant le md5 de l'objet réel. Cette solution ne s'intègre pas forcément très bien dans le développement et en PHP cela allourdit passablement le temps d'exécution.
    mod_pagespeed va faire la même chose mais avec plusieurs avantages: 1) vous pouvez mettre une expiration de l'image à 1h dans apache, cela va devenir l'interval ou mod_pagespeed va la vérifier 2) il va aussi réécrire l'image avec sa signature /image.pagespeed.jm.QlUHWmSp4d.png et mettre une expiration longue dans le cache des utilisateurs (en plus il fait attention à garder l'extension originale).

    Bref, mod_pagespeed permet de ne plus poluer le code avec des micro-optimisations car lui il va le faire, souvent en mieux:
    - toute sortes de minifications et groupements
    - il peux "inliner" du js/css/images directement dans le html
    - si vous avez spécifié le with/height d'une image dans le source, il peut réencoder l'image aux bonne dimensions/ ou changer son format.
    - …

    • [^] # Re: Ce mod est vraiment excellent

      Posté par  (site web personnel) . Évalué à 2.

      Un autre exemple tout simple, le cache des objets statiques

      Je ne comprends pas ton exemple. Pourquoi ne pas changer le nom du fichier et la valeur de la variable qui le contient tout simplement ? Je ne vois guère de cas ou cela s'avérer impossible.

      • toute sortes de minifications et groupements
      • il peux "inliner" du js/css/images directement dans le html
      • si vous avez spécifié le with/height d'une image dans le source, il peut réencoder l'image aux bonne dimensions/ ou changer son format.

      Pourquoi pas dans ce cas une approche de type compilateur, effectuant ces opérations une fois pour toute. C'est exactement comme pour la compression. Pourquoi la faire à la volée sur des ressources statiques qu'il est tellement simple de compresser à la main ? Il suffit ensuite que le serveur choisisse fichier.defalte, fichier.gz ou fichier suivant ce que demande le client.

      • [^] # Re: Ce mod est vraiment excellent

        Posté par  . Évalué à 1.

        Pour les webapp écrite java, il y a :
        http://alexo.github.com/wro4j/
        qui fonctionne à la volé, ou à la compilation.

      • [^] # Re: Ce mod est vraiment excellent

        Posté par  . Évalué à 4.

        Oui bien sûr on peut changer le nom du fichier, mais encore une fois, le design est (souvent) fait par des designers et quand ils veulent remplacer une image A par une image B qui à le même rôle, le plus simple est de garder le même nom. De toute façon c'est un problème général qui concerne aussi les changements dans les js et les css et dans ces cas là tu n'as certainement pas envie de les renommer.

        En fait, mod_pagespeed est extrémement avantageux car il inclut des dizaines d'optimisations qu'il implémente avec une grande efficacité: tous les traitements effectués sont cachés, il ne reste guère plus que l'analyse et le remplacement de l'output de la page qui nécessite du travail réél sur chaque requête.

        Je pense que si tu compares le nombre de cycles CPU pour produire une partie de ces optimisations en PHP et d'un autre côté la vitesse de mod_pagespeed (qui en fera certainement + en fait), il n'y a pas photo: mieux vaut laisser un module bien optimisé en C s'occuper de ça.

        Et pour finir sur un avis perso, le rendu des pages et le taux de CPU est un "faux" problème car la partie front d'une application passe très facilement à l'échelle horizontalement (donc en multipliant les serveurs front si besoin), mod_pagespeed sacrifie donc quelques ressources CPU du côté serveur pour sauver de la bande passante (et un peu de CPU) du côté client ce qui contribue à une meilleure expérience des visiteurs.

    • [^] # Re: Ce mod est vraiment excellent

      Posté par  . Évalué à 1.

      A propos de la réécriture avec la signature : parfois une page n'est pas traitée par mod_pagespeed pour une raison que j'ignore.
      Il semblerait que c'est le cas après un certain délais sans requête sur le serveur.

      Plus précisément :
      1. la page est donnée sans être traitée par mod_pagespeed
      2. seconde requête : la page est partiellement traitée par mod_pagespeed ; par exemple, tous les javascript ne sont pas regroupés.
      3. troisième requête : la page est entièrement traitée par mod_pagespeed.
      4. plus de problème pendant un certain temps.

      Sans solution, on risque de tomber sur problème intermittent : de temps en temps le visiteur tombe sur une page sans la signature, et potentiellement une vielle version des ressources. Sur la page d'après, paf tout remarche.

      D'ailleurs si quelqu'un à une solution, je suis preneur.

  • # performances

    Posté par  . Évalué à 7.

    Ce module fait quand meme beaucoup d'inspection du contenu a la volée, on a eu idee du surplus de ressources consommées ?
    J'ai peur que le CPU creve le plafond avec un site un peu chargé…

    • [^] # Re: performances

      Posté par  . Évalué à -1.

      Une page web "chargée" est souvent une mauvaise page web : temps de chargement long, grand nombre de requêtes http, beaucoup d'images, faible réactivité pour l'utilisateur, et parfois des pubs peu optimales; pour au final peu de contenu réellement "vu" par l'utilisateur.
      A mon avis, c'est justement sur ce genre de pages que les optims de pagespeed sont les plus intéressantes. Et n'oublies pas qu'il gère également un cache, donc il y a fort à parier qu'il fasse des optims partielles toutes les n requêtes.

      • [^] # Re: performances

        Posté par  . Évalué à 2.

        Quand je dis "un peu chargé", j'entends "pour un site qui commence a avoir pas mal de visiteurs" (genre 150000VU/j)

  • # Chaudière à uranium et caféine

    Posté par  (site web personnel) . Évalué à 10.

    L'effort de google pour diminuer ses frais de bande passanterendre le web plus rapide est vraiment louable. Ceci dit il pose quand même un léger problème dans la façon partielle (pas partiale) dont il est abordé. Pour beaucoup de Geeks à IPhone5webmasters ce que dit google est parole d'évangile et doit être appliqué sans se poser de question. Ceci dit google n'est pas responsable de ce fait et ce n'est donc pas son procès que je fais ici.

    Pour moi, modeste administrateur système ce qui fait la qualité et la rapidité d'un site web peut se résumer en deux points :

    1) Son workflow

    Un site web est une application et mérite d'être considérée comme telle. Et en tant que telle, il lui faut suivre un cycle de vie rigoureux comprenant notamment, une gestion des versions, des tests, une procédure de publication, un suivie des bugs, bref toutes les choses qu'on fait normalement et naturellement pour n'importe quelle application. C'est bien sûr souvent le cas lorsqu'il s'agit d'applications critiques développés pour des clients qui ont l'habitude de mener des projets informatiques, ou simplement par des gens sérieux qui savent ce qu'ils font. Mais beaucoup de web agencies ne fonctionnent pas ainsi. Le workflow le plus souvent constaté est :

    • On développe une charte graphique.
    • On colle un CMS sur la prod.
    • On colle quelques plugins.
    • On passe en prod et on oublie le truc jusqu'à survenue d'un problème.

    Lorsque le problème survient :

    • On essaye de faire une mise à jour du CMS directement sur la prod.
    • On restaure un backup.
    • On achète de plus gros serveurs jusqu'à ce que ça marche.
    • On débute un nouveau projet en changeant de CMS

    L'alibi le plus couramment admis est qu'il s'agit d'un CMS et donc que tout le wokflow de développement est assuré par ailleurs. Pourtant au quotidien je constate que là ou il faut un modeste serveur à certain pour faire tourner des dizaines de sites, certains peinent à en faire fonctionner un seul sur un cluster (toute chose égale par ailleurs) ou encore que l'absence de tests avec des données dans la base est sans doute la cause la plus fréquente de plantage. Notamment avec MySQL qui a des effets de seuil important.

    Pour faire un site web rapide et de qualité, il faut donc :

    • avoir un environnement de dev séparé de la prod.
    • utiliser un gestionnaire de version.
    • utiliser un gestionnaire de bugs.
    • écrire un jeu de test cohérent avec l'activité finale (et surtout un jeu de données conséquent).
    • suivre les résultats des tests pour en déduire des régressions.

    2) Le ressources

    La rapidité de la réponse renvoyée par un serveur web dépend avant tout de deux paramètres qui sont, le temps d'exécution du script et son empreinte mémoire. C'est peut être con à dire mais un script qui s'exécute vite permet au serveur de répondre rapidement. Moins un script occupe de mémoire, plus il peut être exécuté simultanément un grand nombre de fois et avec plus d'efficacité.

    Pour cela quelques conseils :

    • le contextes de dev doit limiter les ressources plus fortement que le contexte de prod

    Par exemple pour php, il est de bon ton de travailler en dev avec un memory_limit et un max_execution_time plus bas que sur la prod ainsi qu'avec l'open_basedir activé et strict, un nombre d'extensions réduites, suhosin activé et configuré très strictement. Sur la prod on peut alors lâcher du lest pour assurer une bonne fluidité et éviter des plantages imprévus.

    • toute évolution doit être évaluée en terme de ressources.

    L'impact d'ajout d'extensions ou d'augmentation des limites doit être soigneusement évalué. Ainsi que par exemple le moteur de stockage des sessions, la collecte de statistiques… La encore une évaluation sérieuse nécessite qu'il y ait des données dans la base.

    • Les réglages du serveur web doivent correspondre au cas général et pas au cas particuliers.

    Les scripts gourmands (type génération de rapports, export, reindexation …) doivent être isolés et exécutés dans un contexte privé séparé du site public. L'upload de gros fichiers doit être effectué par parties afin de s'adapter au contexte global … Le cas typique est l'augmentation du timeout d'apache (essentiel pour résister aux dos type slow lorris) simplement parce qu'un script d'export de base de données qui pourrait très bien s'éxécuter en cron ou sur une autre instance apache met 3 heures à retourner des données

    • Les ressources externes doivent être gérée correctement.

    Lorsqu'on fait appel à un web service, à une url externe, il faut s'assurer du comportement du script en cas indisponibilité de la ressource. Il faut écrire un vrai client, gérant les timeout, le cache, et les facilités prévues par le protocole (if-modified-since par exemple en http). Les simples fopen("http:// … sont à bannir.

    Côté client il n'est pas toujours évident qu'aller chercher jquery chez google soit beaucoup plus efficace que de l'héberger sois même. Cela doit être encore un fois évalué.

    3) Conclusion

    Vu ainsi ce type de conseils peuvent sembler démesurés pour une petite agence sortant du site à 500 euros. Pourtant il s'agit d'une simple habitude de travail. De nombreux outils existent pour lancer des tests, remplir les bases et finalement lorsque l'habitude est prise c'est plus un gain de temps qu'autre chose.

    Voilà c'était mes trois conseils à deux cents pour un web rapide. Ils n'ont rien d'incompatible avec ceux de google. Je pense juste qu'ils sont un préalable nécessaire. Comme il est dit dans l'article, mod_pagespeed est juste un moyen d'éviter de modifier immédiatement ses sites. Je n'ai pas de chiffres exacts mais j'imagine que le surcout machine est important, ne serais-ce que parce que le serveur doit avoir une vision globale de ce qu'est la page. Et c'est pour cela que je ne l'aime pas trop. Pour moi, le web rapide et qualitatif trouve son origine dans les consommateurs de caféine et pas dans ceux d'uranium.

    Joris

    • [^] # Re: Chaudière à uranium et caféine

      Posté par  . Évalué à 2.

      Étant moi même développeur de site web je ne peux qu'approuver ces considérations. Et j'ai trouvé mon bonheur depuis que j'ai laissé tombé PHP pour ruby/Rails.

      Tout y est prêt pour que même un "site à 500€" soit réalisé comme il se doit.

      • Mignification/Regroupement dans un seul fichier/Tag MD5 des ressources css/javascript/images est fait automatiquement.
      • Les environnements sont bien séparés dev/prod/test.
      • Les environnements de tests sont à porté de main à tout instant.
      • Langage cohérent, pratique, puissant.
      • La doc est maintenant bien fournie.
      • …

      De plus la communauté est un gros facteur positif pour moi. Je trouve que la proportion de gens rigoureux et compétant y est beaucoup plus importante que dans celle de PHP. J'en étais rendu à ne quasiment jamais prendre du code extérieur quand je travaillais en PHP (code horrible/buggé, standards web pas respectés, …) alors qu'en ruby je commence pas voir si quelqu'un à déjà fait une gem (portion de code avec installation centralisée, gestion des dépendances…) et je lis le code pour me renseigner et apprendre des trucs au passage. Travailler constamment avec des gens qui font les choses comme il faut incite fortement à faire pareil.

      Enfin bref tout y est pour faire du bon travail en se faisant plaisir.

      Concernant le module pour apache je suis assez mitigé. A la fois ça peut permettre d'accélérer certain site utilisant de mauvaises pratique déjà en production mais j'ai peur que ça incite les développeurs de tels site à ne surtout rien faire par ce que c'est plus facile d'installer un truc que de ce remettre en cause.

      • [^] # Re: Chaudière à uranium et caféine

        Posté par  . Évalué à 4.

        mais j'ai peur que ça incite les développeurs de tels site à ne surtout rien faire par ce que c'est plus facile d'installer un truc que de ce remettre en cause

        En même temps si ça fait le boulot… C'est comme tout, il faut analyser la chose pour voir ce que ça fait exactement et comment, puis décider de ce qu'on peut lui déléguer ou non. Dans l'évolution de toute technologie on commence par devoir tout maîtriser puis laisser petit à petit l’environnement certains tâches qu'il peut faire aussi bien que nous mais plus rapidement et pour moins cher.

    • [^] # Re: Chaudière à uranium et caféine

      Posté par  . Évalué à 4.

      le contextes de dev doit limiter les ressources plus fortement que le contexte de prod

      Mouais. La plus grosse différence entre les environnements de dev et la prod c'est que les devs bossent à latence 0 et ça ça change tout. Limiter les ressources sur les machines des devs ca ne sert vraiment pas à grand chose. On passe par des chemins d'exécutions qui n'ont rien à voir, des configurations très différentes et une charge ridicule. Faut juste faire les tests de charge sur des machines réalistes avec des scénarios réalistes.

      • [^] # Re: Chaudière à uranium et caféine

        Posté par  (site web personnel) . Évalué à 2.

        Limiter les ressources sur les machines des devs ca ne sert vraiment pas à grand chose.

        Ça te permet quand même de voir si tu as un script qui bouffe de la mémoire, ou est trop long à s'éxécuter ou part dans une boucle d'appels infinie. Ce n'est pas sensé remplacer des tests on est bien d'accord. Mais être dans un environnement strict quand tu développes ne me semble pas un aberration. C'est un peut comme compiler avec -Werror ou exécuter ton code avec valgrind. Bref s'impose un contexte dans lequel tout débordement est fatal.

        • [^] # Re: Chaudière à uranium et caféine

          Posté par  . Évalué à 3.

          C'est pourtant une mauvaise idée. Les environnements de développement n'ont pas les contraintes de la production, et heureusement.

          Les IDE ou les environnements de dév sont souvent lourds, les moteurs de tests bouffent pas mal, et surtout, le framework ou le serveur d'appli qui tourne différencie souvent bien les environnements dév/prod (bon, php je sais pas, mais…:)

          Pour RoR par exemple, les classes ne sont pas mises en cache sur le dév. Ça évite de redémarrer le serveur à chaque modif d'un fichier. Le gestionnaire de resource statiques (l'asset pipeline) est activé en dév et pas en prod (où les .js et .css doivent être pré-générés pour la prod). C'est pratique, mais ça nécessite du CPU. En Java sur les serveurs d'application, il y a le même principe.

          Brider le développeur sur son environnement, c'est je pense l'emmerder un peu trop alors qu'au contraire il devrait pouvoir travailler le plus vite possible. Son but n'est pas de faire des tests de perfs sur son appli (qui ne voudraient de toutes façons rien dire par rapport à la réalité de le prod). Le "on va le faire développer sur une machine lente avec peu de mémoire" pour éviter les bugs en prod, j'y crois pas une seconde.

          • [^] # Re: Chaudière à uranium et caféine

            Posté par  . Évalué à 1. Dernière modification le 14 octobre 2012 à 22:48.

            Il ne parlait pas de la machine locale sur laquelle tu travailles mais de la machine accueillant le serveur de validation…
            Enfin, c'est ce que j'ai compris.

            • [^] # Re: Chaudière à uranium et caféine

              Posté par  . Évalué à 2.

              Pour cela quelques conseils :
              le contextes de dev doit limiter les ressources plus fortement que le contexte de prod

              Enfin bref de toute facon on est au niveau hello world là.

              • [^] # Re: Chaudière à uranium et caféine

                Posté par  (site web personnel) . Évalué à 3.

                Enfin bref de toute facon on est au niveau hello world là.

                Tu peux préciser ?

                Bien évidement je parlais des machines sur lesquelles tu effectues la validation du code, les tests. Je parle pas de ta jolie station de travail dont je me fiche. Valider le code dans des conditions plus strictes que la prod, pour une application destinée à se faire défoncer sur le web, c'est quand même pas trop demandé ? non ? Mais de toute façon avec les devs c'est toujours pareil. Dès qu'on parle de limiter les ressources, c'est l'adminsys qu'est un gros nul.

                • [^] # Re: Chaudière à uranium et caféine

                  Posté par  . Évalué à 3.

                  Si déjà il y avait toujours une distinction claire entre dev et prod ce serait bien, si en plus il y a un environnement de validation entre dev et prod c'est byzance!

                • [^] # Re: Chaudière à uranium et caféine

                  Posté par  . Évalué à 3. Dernière modification le 15 octobre 2012 à 17:54.

                  Tu peux préciser ?

                  Bha ce sont juste des évidences. Si t'as besoin de préciser ca c'est même pas la peine d'aller plus loin; ca sera de la merde de toute façon les mecs seront incapable de te sortir un truc qui tient debout.

                  Maintenant limiter les machine de test/validation/intégration (et pas de dev…) tout seul ca sert à rien si t'as pas un scénario de test qui tient la route et les métriques qui vont bien. Et ca c'est pas évident surtout quand tu commences à bosser sur de vrais trucs qui font tout un tas de chose plus compliqués qu'un CGI à papa qui pisse un html à partir d'une petite db.

        • [^] # Re: Chaudière à uranium et caféine

          Posté par  . Évalué à 8.

          Ça te permet quand même de voir si tu as un script qui bouffe de la mémoire, ou est trop long à s'éxécuter ou part dans une boucle d'appels infinie.

          Non. La plupart du temps on bosse avec une pile logicielle, des configurations, et des environnements totalement différents de ce qui va tourner en prod. Penser que tu vas trouver quoi que ce soit de non trivial en bridant grossièrement les devs est plutôt une utopie.

          Pour te dire, quand tu bosses tu utilises souvent un OS différent de la prod, avec un serveur non supporté, avec une db non supportée, avec un browser non supporté, avec une config de l'appli, du serveur et des libs 100% différentes de la prod, avec des libs backend et frontend en debug, avec des ressources servies par des gros hack et le tout sans latence, en utilisant une seule page, avec un jeu de donnée ridicule, et en ayant tout hacké pour développer efficacement ton objectif en cours. Bref essayer de tirer une conclusion de ce que tu observes sur ton poste de travail en sachant qu'il est impossible d'extrapoler le comportement en situation réelle c'est perdre son temps.

          Ce genre de problèmes ça se réfléchi au moment de la conception et de l'implémentation et ça se valide en déployant et testant en condition déterminées. La façon de faire peut énormément varier selon le type de projet, la méthodologie et l'organisation des équipes.

          Après le web c'est plein de branle couilles, de PHP warriors et de serial cut&pasters. Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…

          • [^] # Re: Chaudière à uranium et caféine

            Posté par  (site web personnel) . Évalué à -3.

            Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…

            Parce qu'un ingénieur c'est toujours une garantie de qualité du code, c'est sûr :)

            • [^] # Re: Chaudière à uranium et caféine

              Posté par  (site web personnel) . Évalué à 3.

              Bah… s'il précise bons ingénieurs, ça sous entend qu'il y a aussi de mauvais ingénieurs, non ?

              alf.life

            • [^] # Re: Chaudière à uranium et caféine

              Posté par  . Évalué à 2.

              Ne me fait pas dire ce que je n'ai pas écris. La majorité sont plutôt mauvais, mais au moins ils sont censés avoir quelques rudiments d'informatique (au sens science) et de ne pas avoir appris à coder sur commentcamarche. Ce qui fait qu'au final ce que tu énonçais dans ton commentaire devrait n'être qu'un énorme enfoncage de porte ouverte, autrement c'est la porte.

              J'ai dit "bon ingénieur" ca veut dire ce que ca veut dire. Et ce n'était clairement pas le point intéressant de mon message…

    • [^] # Re: Chaudière à uranium et caféine

      Posté par  . Évalué à 2.

      Côté client il n'est pas toujours évident qu'aller chercher jquery chez google soit beaucoup plus efficace que de l'héberger sois même. Cela doit être encore un fois évalué.

      Si si:

      1) il y a bien des chances que le visiteur aie déjà le jquery/UI CDN google caché dans son browser.

      2) s'il ne l'a pas, il pourra le fetcher plus rapidement sans ralentir les autres fetch qu'il a déjà à faire sur ton serveur (il y a la fameuse limite de X connections vers un même serveur, donc utiliser plusieurs domaines, par exemple des CDN, améliore cela)

      Je n'ai pas testé la qualité du CDN google, j'ose espérer qu'il soit vraiment bon, mais les 2 raisons ci-dessus me font l'utiliser quand même.

      Après, de toute façon, on parle ici beaucoup d'optimisations qui concerne surtout le visiteur qui n'a rien en cache, une fois que tout est caché la vitesse ne change que très peu entre un mod_pagespeed et rien du tout.

  • # Est-ce compatible avec les licences d'utilisation ? (Minifying)

    Posté par  . Évalué à 3.

    Vu que les fonctions minify CSS/Javascript/HTML (Rewrite CSS/Minify/Remove Comments) retirent les commentaires, la licence des codes est retirée.
    Cela pose un petit problème de droit d'auteur non ?

    Enfin il y a toujours la solution de désactiver certaines fonctionnalités.

    L'idéal serait un système de détection des licences.

  • # mod_pagespeed et proxy

    Posté par  (site web personnel) . Évalué à 2.

    Il est possible d'utiliser mod_pagespeed avec un proxy, pour diminuer la quantité de données téléchargées, par exemple sur un smartphone.
    Voir ici par exemple: https://00f.net/2012/06/02/mod-pagespeed-as-a-proxy-for-your-phone/
    Quelqu'un a déja essayé?

    http://theotherdays.net

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.