Sites web : à nouveau statiques ?
Si vous avez, comme moi, développé votre premier site web il y a 20 ans, vous serez certainement très intéressés par une tendance qui ne cesse de s’amplifier : le retour aux sites web statiques.
Au commencement du web, les serveurs d’applications – qui permettent de créer dynamiquement (c’est-à-dire à la volée) une page web – n’existaient pas. Les sites étaient développés à la main dans un simple éditeur de texte ou bien générés à l’aide de scripts, parfois à partir d’une base de données. Cette architecture minimaliste garantissait une excellente montée en charge, même pour de très grosses volumétries.
Puis, après avoir commencé à dynamiser le web avec des scripts de type *.cgi, les premiers serveurs d’applications – ASP, Cold Fusion, J2EE, et PHP – sont apparus à la fin des années 90.
Depuis, l’architecture technique des sites web n’a cessé de se complexifier. Aujourd’hui, un simple blog nécessite le plus souvent un serveur web, un serveur d’application, une base de données et un CMS (Drupal, ezPublish, WordPress, etc.) pour afficher « Hello world ! ».
Retour aux sources, mais nouveaux outils
Face à cette débauche de moyens et aux problèmes techniques rencontrés par des sites web à forte volumétrie, une frange entière de (jeunes) développeurs reviennent aux sources : ils génèrent à nouveaux des sites web statiques.
Si le résultat final est identique, les outils et les mentalités ont évolués. L’état d’esprit est de faire le plus sobre possible. Par exemple, le serveur web se résume souvent à GitHub Pages ou S3 d’Amazon (voir également BitBalloon) lorsque le site est très sollicité. Ce dernier propose de bons temps de réponse pour coût d’hébergement quasi nul.
Le site est généré à partir de moteurs comme Jekyll, Octopress, Middleman, Pelican, etc. Ces derniers génèrent les pages statiques à partir d’un ou plusieurs template(s) écrits en markdown (ou autre). Des éditeurs dédiés tels que Prose.io permettent de générer les templates sans connaissance spécifique.
Les traitements complexes ou la mise à jour dynamique des données sont déportés dans le navigateur (en Javascript) et sur des services en ligne via leur API REST. Par exemple : la mise à jour d’un cours de bourse ne se fera plus en rechargeant une page web crée dynamiquement mais plutôt en appelant une données en REST via un composant javascript statique basé sur une architecture AJAX.
Une approche minimaliste, en phase avec l’écoconception logicielle
Mis à part les traitements Javascript dans le navigateur, cette tendance au minimalisme côté serveur et à la génération de pages web statiques est complètement alignée avec celle de l’écoconception web.
S’il n’est pas toujours possible de générer un site – on pense par exemple à l’interface d’une banque en ligne – de nombreux sites institutionnels pourraient parfaitement bénéficier de ce retour aux sources. Reste à convaincre les entreprises par des retours d’expérience concluants, notamment d’un point de vue financier.
Si vous avez adopté cette démarche pour des sites d’entreprise, votre retour d’expérience nous intéresse.
Sources : http://developmentseed.org/blog/2012/07/27/build-cms-free-websites/
Frédéric Bordage
Expert en green IT, sobriété numérique, numérique responsable, écoconception et slow.tech, j'ai créé le collectif Green IT en 2004. Je conseille des organisations privées et publiques, et anime GreenIT.fr, le Collectif Conception Numérique Responsable (@CNumR) et le Club Green IT.