Drupal 8, rapide comme l'éclair !

Et s'il était possible d'avoir un site qui se charge instantanément ou presque avec Drupal 8 sans configuration particulière ?

Cette question taraude les développeurs depuis de nombreuses années et toutes les grandes entreprises et communautés ont déjà eu cette réflexion à propos de leurs outils et services. Certaines ont réussi à améliorer les choses par des procédés très spécifiques d'optimisation et d'autres ont créé des principes qui pourraient être appliqués à tous les projets. Aujourd'hui, l'éventail de solutions est large mais leur mise en œuvre reste souvent très complexe d'autant qu'une unique solution ne résoudra jamais tous les problèmes.

Drupal 8 ou la révolution du cache

La chose est passée relativement inaperçue côté grand public mais cela a fait grand bruit dans la communauté des développeurs Drupal et je suis persuadé que cela fera des émules dans les autres CMS. Durant la fin de son cycle de développement, lorsque l'accent a été mis sur les performances, Drupal s'est doté d'un nouveau module intégré au cœur : Dynamic Page Cache. La promesse de ce dernier était de permettre d'émuler un fonctionnement proche de celui des ESI directement dans le CMS, sans avoir besoin d'un reverse proxy (même si son usage reste possible). 

Avec Dynamic Page Cache, chaque élément significatif de la page se voit doté de métadonnées de cache qui se cumulent les unes aux autres au fur et à mesure de l'aggrégation des éléments dans la page finale pour constituer une sorte de profil de cache. Avec ce profil, le cœur est capable facilement de gérer des variantes d'un contenu en fonction de critères concrets et d'éviter au maximum d'avoir à reconstruire des élements à moins que cela ne soit nécessaire. De la même manière, ce profil de cache permet de gérer les dépendances entre les données et leur affichage pour très facilement invalider un rendu lorsque la donnée a été modifiée, sans toucher aux autres rendus constituant la même page.

Avant cela, il était fréquent de voir des pages entièrement reconstruites alors qu'une simple et minuscule donnée y avait été modifiée. Maintenant, ces ressources serveur sont économisées et on peut constater des gains de performances réellement significatifs. De même, avant cela, avoir un élément hautement dynamique sur la page, comme par exemple un bloc indiquant le nombre d'objets dans un panier d'achat, imposait de ne pas mettre en cache la page pour éviter qu'un visiteur ne voit les informations d'un autre. Désormais, ces éléments sont gérés nativement et toute la partie commune à tous les utilisateurs de la page peut être mise en cache, indépendament des portions spécifiques qui sont stockées séparément.

J'ai déjà évoqué le fonctionnement de ce système de cache en détail dans un article dans le magazine Programmez! et cela fera également l'objet d'un prochain article issu de notre formation Drupal 8 à destination des développeurs Drupal 7 donc je n'approfondirai pas ce sujet ici. Sachez cependant que le système derrière Dynamic Page Cache est à la base des deux revolutions qui suivent.

BigPipe pour les nuls

Inventée par Facebook pour améliorer les performances de leur site, cette technique s'explique très simplement mais peut-être incroyablement complexe à mettre en place. Il s'agit de fournir au visiteur d'un site une réponse la plus rapide possible, même si elle est incomplète, puis de charger les éléments restants dans un second temps. De cette façon, on améliore les performances perçues plus que les performances réelles. Le temps de chargement total de la page restera inchangé mais avec BigPipe l'utilisateur verra quelque chose apparaître sur son écran beaucoup plus rapidement. La vidéo suivante compare le rendu des deux techniques :

Si l'on reprend l'exemple d'un site e-commerce, la structure de la page sera renvoyée très rapidement car elle est commune à tous les utilisateurs et mise en cache. La partie spécifique (le bloc panier) sera chargée et affichée dans un second temps. Sans BigPipe, c'est le serveur web qui va attendre que chaque partie de la page soit générée avant d'envoyer l'ensemble au navigateur. Avec BigPipe, c'est le navigateur qui est chargé de reconstituer les divers éléments. Bien qu'il soit possible de réaliser un équivalent à l'aide de requêtes Ajax après la fin du chargement de la page, le génie de BigPipe repose sur le fait qu'il ne nécessite qu'une seule requête HTTP pour récupérer tous les éléments d'une même page, ce qui ne serait pas le cas en passant par de l'Ajax classique.

La méthode s'appuie sur la technologie Chunked Encoding disponible depuis HTTP 1.1. Celle-ci autorise le serveur à renvoyer sa réponse en plusieurs fragments de la taille qu'il souhaite. Le serveur peut donc renvoyer un premier fragment contenant la structure de la page puis ensuite renvoyer, généralement sous la forme d'un appel Javascript enrichi de données JSON, un fragment par bloc jusqu'à ce que tous soient générés.

Dans Drupal 8, grâce aux métadonnées de cache, il est aisé de savoir quelle partie de la page est suceptible de varier beaucoup et quelle autre devrait pouvoir être identique d'un utilisateur à l'autre. Avec Dynamic Page Cache, le cœur construit la page intégralement en récupérant certaines parties du cache et en générant les autres à la demande avant de renvoyer la réponse au visiteur. Avec BigPipe (intégré dans le cœur de Drupal 8.1), il utilise les mêmes métadonnées pour remplacer les parties plus longues à charger par un élément de substitution (placeholder) puis renvoie immédiatement le rendu de la page. Ensuite, une fois chaque sous-éléments prêt, il renvoie une instruction au navigateur lui indiquant de remplacer le placeholder par le code correspondant au bloc finalisé. Une fois le module activé (téléchargeable ici pour Drupal 8.0 et inclus dans le cœur de Drupal 8.1), aucune configuration supplémentaire n'est nécessaire hormis un éventuel ajustement très mineur côté serveur pour s'assurer qu'il n'utilise pas une mémoire tampon et qu'il expédie bien les éléments au navigateur dès que possible. La magie opére donc extrêmement rapidement et sans surcoût !

RefreshLess pour délivrer plus (et plus vite)

Cette fois-ci c'est de la communauté Ruby on Rails dont provient cette technique, nommée Turbolinks, qui consiste à ne recharger que les éléments changeant dans une page web lors du clic sur un lien au lieu de recharger toute la page. Elle part du principe qu'un site a généralement une structure globale identique ou presque d'une page à une autre et que celle-ci n'a pas besoin d'être rechargée par le navigateur lors du changement de page. Cela permet d'économiser les ressources à la fois du serveur et du navigateur. Le premier n'a pas à générer les parties communes de la page, le second n'a pas à reconstruire visuellement ces mêmes parties.

L'intégration des Turbolinks n'est à ce jour qu'un prototype sous la forme d'un module Drupal 8 mais son potentiel est  énorme car il se base sur les mêmes mécanismes que BigPipe pour fonctionner à savoir, vous l'aurez deviné, les métadonnées de cache ! En effet, lors du clic sur un lien interne, une requête Ajax est envoyée au serveur qui va calculer, à partir de ces métadonnées, les régions du site qui sont suceptibles d'avoir changé. Il ne génèrera et ne renverra que ces régions là sous la forme de plusieurs commandes indiquant au navigateur quelles sections remplacer. Il est très probable qu'à l'avenir ce système s'appuie aussi sur la technologie BigPipe pour renvoyer et rendre les blocs sans attendre que la génération de tous les éléments soit terminée.

Comme le montre la vidéo suivante, les premiers résultats sont tout bonnement impressionnants et très encourageants :

Conclusion

Ces deux sujets démontrent qu'une utilisation intelligente des métadonnées de cache peuvent entrainer des applications inatendues améliorant les performances de nos sites à moindre coût. Les solutions présentées ci-dessus sont activement soutenues et développées par Wim Leers pour le compte d'Acquia dont l'objectif est toujours de rendre l'écosystème Drupal plus solide et compétitif. L'aboutissement de ces techniques permettra à l'ensemble du marché de profiter de performances améliorées. Cela bénéficiera à la fois aux visiteurs mais aussi aux éditeurs des sites qui auront besoin d'une architecture serveur moins puissante et donc moins chère, sans toutefois avoir à investir la différence dans des coûts de développement.

Crédit photo © Bert Koopman