Tout commence par un RT
Cette histoire croustillante commence par un ReTwitt d’un post de Dries Buytaert (pour ceux qui ne suivent pas, le créateur de Drupal) qui apparait dans ma timeline (http://twitter.com/Dries/status/15483730432) :
We should look into a « Facebook BigPipe »-like solution for Drupal 8 : http://bit.ly/9oFLaS #drupal #performance #todolist
Tiens qu’est-ce donc que cette solution magique de Facebook pour améliorer les performances d’un site, et qui intéresse Dries ?
La proposition de Facebook
Ni une, ni deux, je file sur l’article technique (attention, c’est du Facebook dedans, ne cliquez pas si vous tenez à votre vie privée).
En résumé, pour ceux qui n’ont pas activé leur TOR ou ne comprennent pas l’anglais, l’auteur propose de rendre disponible les pages web dans le navigateur plus rapidement en les découpant en morceaux :
- un morceau ossature principal envoyé au plus vite au visiteur ;
- plusieurs morceaux de contenu (appelés pagelet), calculés et envoyés séparément.
La page complète est reconstituée dans le navigateur par une fonction javascript.
Ainsi, le rendu et l’interprétation des CSS et JS peuvent démarrer plus tôt dans le navigateur, et la page complète peut être construite par plusieurs processus séparés, en parallèle, sur le serveur.
Mais ça me rappelle quelque chose ...
Intéressant, mais n’ai-je pas l’impression d’avoir déjà vu ça quelque part ?
Ah oui ! A tout seigneur, tout honneur, c’est à Fil que l’on doit la première initiative dans ce sens dans SPIP : http://zone.spip.org/trac/spip-zone/log/_plugins_/inclure-ajaxload
Son plugin inclure-ajaxload permet d’ajouter une condition {ajaxload} sur la balise INCLURE de SPIP.
Le principe ressemble à ce que facebook propose : au lieu d’assembler la page au moment de son calcul, l’inclusion est remplacée par un morceau de javascript envoyé au navigateur, qui va provoquer le chargement du morceau de page séparément de la partie principale de la page.
L’assemblage de la page n’est donc pas réalisée au moment du calcul, côté serveur, mais dans le navigateur, côté client.
Cette première expérimentation était intéressante, mais nécessitait de modifier le squelette pour en bénéficier.
Industrialisons avec Zpip
Le concept de Facebook « une ossature principale qui charge des morceaux de page », cela évoque, pour ceux qui ont commencé à le pratiquer, le concept de Zpip.
On retrouve dans Zpip cette idée d’ossature principale de page, organisée ensuite en blocs de contenus. Sauf que tout est assemblé côté serveur.
Alors justement, je me suis dit qu’il devrait être facile d’automatiser un fonctionnement proche de ce que propose Facebook.
De fait, quelque commit plus tard, Zpip contient une fonctionnalité appelée « Ajax Parallel Loading ».
Le plus intéressant est que cette fonctionnalité ne nécessite aucune modification de squelettes. Il suffit de l’activer par un define pour préciser quels blocs doivent être chargés en parallèle.
Voyons cela en exemple sur SPIP-Contrib. Le site est construit sur la base de Zpip, avec un bloc supplémentaire, nommé « more », qui contient en fait les commentaires en pleine largeur sur les pages d’article.
Ce bloc est ajouté en listant les blocs de Zpip dans une globale :
Ensuite, pour fluidifier le chargement des pages, on indique à Zpip que l’on veut charger les deux blocs ’contenu’ et ’more’ en parallèle du reste de la page :
Tout cela se retrouve dans http://zone.spip.org/trac/spip-zone/changeset/38626
Le résultat est visible directement sur http://www.spip-contrib.net. La page est d’abord chargé avec son ossature, puis le contenu principal, et enfin les forums.
Au final, le temps total de chargement de la page n’est pas plus rapide pour le visiteur, mais il se dégage une impression de fluidité. Au lieu d’attendre devant une roue qui tourne dans son navigateur, il voit tout de suite la page se charger, puis le contenu principal. De plus, ce contenu est disponible plus rapidement car il n’est pas nécessaire d’attendre les forums qui arrivent après, et sont traditionnellement plus lourds et longs à calculer.
Plus intéressant encore, et non évoqué par Facebook, le référencement du site n’est pas dégradé par cette méthode. En effet, les robots indexeur des moteurs de recherche sont connus. Et comme la méthode implémentée par Zpip est automatique, il est facile de leur servir la page complète, avec tout son contenu, au lieu d’une page coquille vide.
On peut donc sans hésiter affirmer que la solution implémentée est sur ce point meilleure que celle évoquée par FaceBook !
SPIP toujours en pointe !
Encore une occasion de démontrer que SPIP reste à la pointe. N’en déplaise aux mauvaises langues qui s’acharnent à le traiter de vieillot, confondant certainement maturité et obsolescence.
Mieux encore, ainsi qu’on avait déjà pu l’aborder à propos des requêtes SQL et de la charge serveur, son architecture interne, basée sur un langage de templating compilé et caché lui procure de nombreux avantages.
Exploitée au mieux par le modèle de squelettes Zpip, cette architecture permet au final des prouesses techniques dans un temps qui doit laisser Dries songeur...