SQLI : Génération de site statique et CDN, les frères ennemis ?

Si vous avez en tête les premiers sites internet, il s'agissait effectivement de sites web statiques, sans exécution PHP côté serveur, sans fonction de recherche, sans AJAX, sans… quoi que ce soit, in fine ! C'était du code HTML écrit à la main, puis du CSS pour la mise en page. Et tout cela était simplement entreposé sur un serveur web afin de mettre à disposition ce contenu et l'afficher dans un navigateur internet. Alors est-ce la mode du vintage et du « c'était mieux avant » qui fait émerger aujourd'hui cet intérêt pour la génération de sites statiques ? Ou bien cette approche renferme-t-elle un fabuleux secret ?

Non, ce n'est pas le but ! Les CMS sont de formidables outils pour une contribution riche et structurée, avec des workflows, de la gestion de médias et j'en passe. Ce qui nous intéresse particulièrement ici, c'est la génération d'un site statique à partir de la contribution réalisée dans un Drupal. La logique consiste à « sauvegarder » le code HTML généré lorsque le site est affiché, une fois l'ensemble de la contribution réalisée. Puis de mettre uniquement en ligne cette copie carbone du site, et ainsi de laisser notre Drupal dans les ombres, inaccessible au monde extérieur, en dehors de votre équipe de contribution.

Techniquement parlant, plusieurs outils s'offrent à vous :

Le module Tome est complètement intégré à l'interface Drupal. Il permet de générer la copie carbone du site web en utilisant le moteur de rendu de Drupal, ce qui laisse toute latitude à votre équipe technique habituelle de modifier le thème qu'elle a déjà construit. Ce module a également l'avantage de se connecter avec les hébergements AWS, GitPages ou encore Netlify, et de réaliser simplement le déploiement de la nouvelle version de votre copie carbone.

L'ensemble des solutions suivantes se reposent sur des outils de génération statique qui ne sont pas spécifiques à Drupal mais que des modules permettent de lier.

Ici, la logique revient à utiliser Drupal uniquement comme source de contenus et de laisser le rendu final à Gatsby. Nous laissons donc complètement de côté notre thème Drupal et les fonctionnalités qui pourraient lui être associées. L'échange entre les deux outils est assuré par la couche API de Drupal, et la mise en page par Gatsby. Mais comme Drupal ne se résume pas uniquement à des contenus, il faudra également utiliser l'API pour récupérer les blocs, les views ou encore les menus afin de pouvoir réorganiser la navigation des visiteurs. Là encore, un module Drupal permet une intégration simplifiée des deux outils et de son hébergement. Gatsby documente également son intégration avec les différents CMS sur son site.

Une dernière solution s'offre à nous, très simple à imaginer mais un peu moins évidente au quotidien : la génération de la copie carbone avec les outils HTTrack ou wget à exécuter côté serveur. Ces deux outils sont complétement agnostiques de la technologie utilisée et n'offriront aucune interface avec l'hébergement ou de page dans l'administration de votre CMS préféré.

Malheureusement, non ! Il faut plutôt considérer la génération de sites statiques comme un outil supplémentaire dans la construction de votre stratégie de communication, et comme pour chaque outil il faut connaitre ses points forts :

La page est chargée instantanément par le serveur web : pas de calcul PHP, pas de requêtage en base de données, rien ! Comme à l'origine du web, mais en mieux habillé. Le visiteur accède donc plus rapidement à son contenu. D'un point de vue rendu de page, nous nous rapprochons du fonctionnement d'un serveur Varnish qui mettra en mémoire tampon les pages déjà générées afin de les servir sans faire appel à un nouveau calcul de la page via PHP.

Le serveur web de type Apache étant la seule chose nécessaire pour assurer le bon usage du site, le coût en infrastructure du projet est dérisoire. Il est malgré tout essentiel que le projet sous Drupal soit exécuté quelque part, cela peut aller de l'installation locale dans le cadre d'un unique contributeur à une installation sur un serveur de très petite taille, car celui-ci n'aura aucune charge à encaisser.

Tous les applicatifs Drupal, PHP ou MySQL n'étant pas accessibles publiquement, alors qu'ils sont généralement les points faibles du projet, il sera difficile à toute personne malveillante de trouver une faille. Point supplémentaire, dans le cas où notre back-office n'est pas public, les mises à jour de sécurité de ces outils ne sont plus critiques, car elles ne mettent pas en péril le site en production. Mais si votre projet doit continuer à vivre, prévoyez tout de même de vous en occuper !

La mise à jour du site se limitant à remplacer des fichiers HTML par d'autres fichiers HTML, toute la complexité d'un script qui s'exécuterait de façon incorrecte sur l'environnement de production passe à la trappe et au cas où, revenir en arrière est également très simple. La gestion de fichiers GIT peut encore simplifier ces processus.

Une technologie qui n'est pas adaptée dès qu'il est besoin de visiteurs connectés. C'est bien là, la grosse limitation de cette technologie, mais ce n'est pas une surprise, car tout tient dans son nom : « statique ». Dès que nous abordons des problématiques de gestion de compte, de personnalisation ou de fonctionnalités dynamiques, nous dépassons le cadre de cette technologie. Il est bien sûr possible d'utiliser du Javascript pour recréer ces fonctionnalités, mais cela se fera sans l'appui du CMS. En résumé, si vous comptez offrir une expérience fonctionnelle à vos visiteurs, un site statique n'est pas la bonne solution.

Tout ce qui est implémenté en AJAX sur un front Drupal ou qui nécessite un retour serveur devient, de fait, inutilisable : plus de filtres dans les views, plus de pagination dynamique, plus de fonction de recherche. Il faudra donc, par exemple, implémenter disqUs pour les commentaires ou encore appeler un serveur ElasticSearch via Javascript (ou via des solutions tierces comme Algolia)

Nous avons observé que la rédaction et la publication s'exécutent forcément en deux temps, que l'environnement sur lequel nous contribuons n'est pas forcément le même que celui sur lequel le public consulte le contenu... Bref, quelques rouages supplémentaires à prendre en considération et plus compliqués à gérer que de simplement appuyer sur le bouton « enregistrer » de votre contenu. Nous avons aussi vu qu'il est possible d'automatiser une bonne partie de ce workflow selon les outils que vous aurez sélectionnés. Mais ces étapes ne sont pas à négliger, selon le degré technique de l'équipe qui animera votre projet.

Réaliser un site statique offre des avantages certains, pour autant, cette solution ne convient pas à tous les projets. Elle correspond parfaitement dans le cadre de la mise en ligne d'un site corporate "classique", d'un site personnel pour afficher son CV, d'un site one-page pour un évènement particulier ou encore d'un blog. Cependant, pour un site de pari sportif ou le prochain Facebook, il faudra envisager une autre solution !

Si votre projet se trouve à cheval entre les deux, je vous invite à réfléchir à une solution hybride reposant sur des pages générées statiquement afin de couvrir les visiteurs déconnectés, puis de basculer sur des pages générées dynamiquement par Drupal pour la partie dédiée à un visiteur connecté.

Il faut voir un CDN (Content Delivery Network) comme un réseau de point d'accès à votre site. Lorsque vous avez mis en place un CDN et qu'un visiteur souhaite se rendre sur votre site, sa requête se fera automatiquement via l'intermédiaire du point d'accès le plus proche. Deux solutions se dessinent :

• Un visiteur visite cette page via ce point d'accès pour la première fois : dans ce cas, le CDN demandera la page au serveur principal (celui sur lequel vous faites vos déploiements), puis l'ouvrir au visiteur, mais surtout il va la garder en mémoire.

• La page a déjà été requêtée précédemment via ce point d'accès : le CDN ouvrira directement la page demandée, depuis sa mémoire, sans avoir à échanger avec le serveur principal.

Le CDN tire son intérêt des divers points d'accès dispersés tout autour du globe. Il détient l'énorme avantage de placer physiquement le contenu au plus près du visiteur afin de gagner ce précieux temps d'affichage que nous recherchons tous quand nous naviguons. En effet, le transfert de données entre San Francisco et Paris sera forcément plus long qu'entre Lille et Paris, par exemple.

Mais que se passe-t-il lorsque nous modifions un contenu sur son site ? Toute la subtilité de l'utilisation d'un CDN sera de gérer ce renouvellement. Il faut savoir que lorsqu'une page est générée par un serveur web, celle-ci s'accompagne d'un TTL "Time to Live", qui exprime le temps pendant lequel l'information portée par cette page restera valide. A partir de cette information, le CDN peut savoir si le contenu qu'il a en mémoire est toujours pertinent ou non. Si ce n'est pas le cas, il lui suffit de requêter à nouveau le serveur d'origine pour obtenir l'information à jour.

Il est certes compliqué de savoir quand vous aurez besoin d'actualiser votre contenu en avance, et si jamais votre TTL a été paramétré à une journée, il est difficile d'expliquer qu'il faudra attendre demain pour qu'une erreur dans votre contenu ne soit plus affichée. C'est pourquoi il est possible d'invalider tout ou partie de ce qui est mémorisé par le CDN.

Notons également que le CDN peut être paramétré pour ne mémoriser qu'un certain type de données, par exemple les images et les feuilles de style CSS, et qu'il est nécessaire de paramétrer les chemins qui ne doivent pas être mémorisés par le CDN, comme vos pages d'administration et les pages de gestion de compte des visiteurs.

Après ces quelques explications, nous comprenons donc que notre CDN crée, de lui-même, des copies carbones de notre site (ou d'une partie de notre site) sur chacun des points d'accès à travers le monde, rendant notre site à la fois plus rapide et en réduisant la sollicitation de notre serveur en lui faisant calculer moins de pages.

Evidemment, je ne vous donnerai pas de réponse aussi tranchée que cela !

Si votre public est international, le CDN réduira toujours la distance entre le contenu et le visiteur, générateur de site statique ou non. Les deux solutions ne sont pas du tout antinomiques, donc pas besoin de choisir entre les deux. 

Nous pouvons même imaginer n'utiliser le CDN que pour les images, les documents et les feuilles de style (ce qui est le plus volumineux à transmettre) mais que la page HTML reste distribuée par le serveur d'origine. Les deux solutions offrent chacune des avantages complémentaires, et c'est le contexte de votre projet qui vous fera choisir vos outils. La mise en place d'un CDN peut facilement être réalisée sur un large éventail de typologies de projets et rapidement vous faire gagner de précieuses secondes. Un générateur de site statique, lui, pourra vous offrir un maximum de sécurité pour des coûts d'infrastructure réduits, mais avec une logique qui diffère des outils habituels de contribution.

Publié le 14 Avr 2022 par

Partager

• Partager sur Linkedin
• Partager sur Facebook
• Partager sur Twitter
• Envoyer par email