Encore des outils

Je vous avais parlé il y a quelques temps d’un plugin wordpress pour smushit et d’un script en php pour gérer cache, minimisation et concaténation des fichiers statiques. Voici d’autres briques du même type.

Plus que les outils eux-même, qui n’ont rien de révolutionnaires, c’est la prise de conscience des questions de performance par les développeur d’applicatifs et de bibliothèques de code qui me réjouit. Il est vrai qu’on ne peut pas demander à tous de se préoccuper des performances. Beaucoup d’éditeurs n’ont pas vraiment de techniciens compétents et se contentent d’utiliser des solutions toutes faites.

Le fait qu’il existe des plugins ou des composants utilisables peut faire la différence entre « il faudrait » et « j’installe et configure ».

C’est dans cet esprit que je vois arriver trois plugins pour le framework PHP Symfony :

J’ai aussi vu passer Minify, un script PHP qui fait concaténation, minimification et cache, et mod_concat (doc), qui s’occupe de la concaténation au niveau du serveur Web Apache.

Je ne suis pas fana des systèmes PHP qui fonctionne à l’exécution de l’applicatif. Les performances sont rarement au rendez-vous et il s’agit au minimum de faire traiter toutes les requêtes statiques par PHP, ce qui est franchement dommage. Je préfère sérieusement des outils qui s’intègrent à votre processus de publication : un bouton qui concatène et minimise une fois pour toutes les fichiers en les versionnant correctement et qui les pose au bon endroit sur un serveur avec de bonnes entêtes de cache.

Seul le système de concaténation mod_concat, qui ne prend virtuellement pas de ressources inutiles, remporte mon adhésion. On rejoint ce que fait d’ailleurs Yahoo! avec son combo handler.

Publié par edaspet

Plus d'informations sur mon profil en ligne

13 réponses sur « Encore des outils »

  1. « Je ne suis pas fana des systèmes PHP qui fonctionne à l’exécution de l’applicatif. Les performances sont rarement au rendez-vous et il s’agit au minimum de faire traiter toutes les requêtes statiques par PHP, ce qui est franchement dommage. »
    => Dans ce cas précis (mod pour apache), il s’agit de faire traiter des requetes statiques par apache, ce qui aussi est franchement dommage aussi, quand il existe des serveurs « light » optimaux pour les ressources statiques justement (ex : thttpd) :/

  2. On n’est pas sur le même ordre de grandeur. Et un Apache avec uniquement les modules utiles n’est pas si mauvais que ça. Il y a de bien meilleures options pour servir des fichiers statiques mais en pratique il est assez fréquent de voir quand même du Apache, avec des résultats tout à fait honorables.

  3. n hesitez pas a vous equiper d un lexique wow, j ai du maal a comprendre, j avoue en tout cas merci pour ce billlet interessant ! c ets toujours sympathique de passer sur ce blog

  4. SPIP 2.0.6 a une réponse élégante au problème de la minification : les CSS et JS sont compressées au moment de la compilation des pages, et avant leur mise en cache de SPIP.
    Résultat : le calcul n’est fait qu’une fois.
    Et en plus, le nom du fichier minifié est un MD5 de son contenu ce qui permet de régler du même les problèmes de mise à jour côté client en cas de changement dans le Js ou les CSS.

  5. J’arrive un peu après la bataille, mais une question tout de même: pour des petits et moyens sites, les solutions de type Minify! (qui font passer par PHP toutes les requêtes aux fichiers CSS et JS) ne sont-elles pas utiles? Certes c’est moins bien que des fichiers statiques servis soit par Apache, soit par un serveur type lighttpd ou nginx, mais est-ce que ça ne représente pas un gain sensible malgré tout?

    Je pense notamment à tous les sites sur hébergement mutualisé, ou sur tout serveur sur lequel on n’a pas un contrôle suffisant pour une solution plus aboutie.

  6. Pour un petit site de base, faire la minimisation sur son poste avant publication n’est pas très complexe non plus.
    En général ce sont surtout sur ces serveurs mutualisés que passer par PHP a un coût important.
    Mais bon, tout ça charge le serveur, pas le client, donc c’est à vous de voir en fonction de votre hébergement et des sous que vous souhaitez mettre dedans (parce que plus de cpu c’est aussi un hébergement plus cher)

  7. Parmi les outils de minification, je viens de voir passer JSMin+ qui implémente en PHP le parser JavaScript Narcissus, et reprend des idées de YUI Compressor. Le but est d’avoir une minification non dépendante de Java, et selon l’auteur de limiter les contraintes que JSMin fait peser sur la rédaction des scripts (certaines syntaxes ou certains raccourcis de syntaxe étant «cassées» par JSMin).

    Côté CSS, je peine un peu pour trouver un minificateur léger qui se contente de retirer les commentaires et de supprimer (ou de combiner) les espaces. Ceux qui vont plus loin (refactorisation de code) cassent souvent des choses.

  8. Note en passant (et après je m’en vais): on peut mettre en place Minify! (par exemple), et faire un simple wget des contenus générés pour obtenir des fichiers statiques. Il suffit alors, pour un site moyen ou même assez gros, de configurer Minify! (en utilisant les groupes) et de s’écrire un script d’une dizaine de lignes ou moins pour semi-automatiser la chose.

    Sans accès shell (petit site sur mutualisé), on peut faire du copier-coller à la main plutôt qu’un wget, à la rigueur.

    Bien sûr la même chose est possible avec YUI Compressor, aussi bien sur le serveur (si accès shell + Java installé) qu’en local. J’ai juste trouvé que l’utilisation « manuelle » de Minify! était sympa.

  9. Pour des petits sites, l’installation d’une mécanique automatique est peut-être plus fastidieuse que d’utiliser des sites en lignes. Tout dépend de la fréquence de mise à jour.

Les commentaires sont fermés.