Ergonomie, Rails et Architecture de l'information web (2.0)

S’il existe un grand nombre de manières de déployer et de faire tourner des applications développées avec Ruby on Rail, comme, au hasard, ce blog, l’hébergement de masse reste encore un vrai problème, principalement pour des raisons de complexité de configuration côté serveur. L’absence sous Apache d’un modrails comme il existe un modphp y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé modrails. Enfin terminés les atermoiements entre mongrel + modproxy, ou fastcgi, avec tous les inconvénients inhérents à ces deux solutions. Il existe certes d’autres solutions logicielles, parmi lesquelles ma préférée va à Nginx + Thin, cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues (à moins que quelqu’un ne me porte les quelques 500 rewrite rules qui restent encore ici et là).

Mais sans plus attendre, rentrons immédiatement dans le vif du sujet, l’installation de mod_rails pour Apache 2 sous Debian.

Typo, le blogware en Ruby on Rails dont je suis mainteneur depuis un an et demi souffre malgré lui d’une réputation de bloatware, qui n’a – malheureusement – pas toujours été injustifiée, au point de lui coller à la peau comme le sparadrap du Capitaine Haddock. Un des très gros efforts du passage de la 4.0 à la 5.0 a porté sur une refonte complète de la back end afin d’en éliminer les lourdeurs.
Il semble que nous ayons réussi notre pari, comme l’explique cet article de Kevin Williams, utilisateur de Typo et heureux de l’être dont je vous donne la traduction ci-dessous :

Les problèmes de montée en charge sont choses courantes pour un site ou une application web une fois atteint un certain succès. Ces derniers sont bien trop souvent négligés, généralement jusqu’au jour où se trouve atteinte la limite critique entre l’inconfort et l’instabilité. Le trend actuel veut qu’il soit à la fois plus simple et moins cher de rajouter des machines que de reprendre son code en profondeur pour l’optimiser. Encore faut-il que l’application permette un redimensionnement de ce genre sans rentrer dans une phase de refactoring complet. Évidemment, avant d’en arriver à une solution aussi lourde, il vaut mieux s’assurer que tout a été fait pour exploiter au mieux les ressources disponibles, et cela passe notamment par un peu d’optimisation côté serveur.

Les problèmes de performances sur un site ou une application web proviennent plus souvent d’erreurs de développement que de soucis de montée en charge. Développée par Yahoo, Yslow, littéralement “pourquoi ça rame” est une extension Firefox qui permet d’effectuer des contrôles de performances sur 13 points clés d’un site web. Chaque point testé reçoit une note pouvant aller de A à F, et les problèmes rencontrés s’accompagnent de conseils tournés vers une optimisation du code. Plus la note est élevée, et plus votre site est rapide.

Pas moins de 13 points de contrôle

YSlow met en avant 13 bonnes pratiques fondamentales dans l’optimisation d’une page web :

1. Minimisez le nombre de requêtes HTTP.
2. Utilisez un réseau spécialisé dans la fourniture de contenus.
3. Ajoutez un en-tête d’expiration.
4. Compressez les contenus côté serveur.
5. Placez les feuilles de style en haut de la page.
6. Déplacez les Javascript en bas de page.
7. Proscrivez les expressions CSS.
8. Placez un maximum de javascript et de CSS dans des fichiers externes.
9. Minimisez les besoins en requêtes DNS.
10. Optimisez le javascript.
11. Évitez les redirections HTTP (301, 302).
12. Supprimez les scripts redondants.
13. Configurez les etags

Un premier test de performances me montre que la refonte en cours du site ne devra pas seulement être ergonomique ou graphique, mais qu’un gros travail d’optimisation est aussi nécessaire. Comme quoi les histoires de cordonnier…

Actualys, société de service parisienne spécialisée dans l’accompagnement des projets web en grands compte – qui s’équipera bientôt d’un site conforme aux standards – recherche actuellement un administrateur système UNIX indépendant connaissant bien les serveurs JBoss et Tomcat pour une missions de longue durée.

Ça y est, les grands travaux de rentrée sur ce blog me semblent terminés, du moins les plus gros, on n’est jamais à l’abri de petites retouches à faire ici et là. La preuve, le simple fait de les évoquer m’en fait venir deux ou trois à l’esprit.

Au menu des grands travaux, on a pu noter, dans le désordre :

Alexander Kirk propose un excellent document envisageant 10 pistes réalistes pour optimiser la rapidité d’un site Internet, et plus encore d’une application Web dont les besoins en réactivité égalent les applications en client lourd.