J’ai déjà consacré deux articles à l’amélioration de la vitesse d’un site sous SPIP. Le premier expliquait comment mettre en place, assez simplement, la parallélisation des chargements d’images sur plusieurs sous-noms de domaine ; assez simple, mais demandant tout de même d’accéder à la configuration du serveur Apache. Le second présentait différents réglages que l’on peut effectuer (soit dans SPIP, soit dans Apache, soit dans .htaccess pour améliorer son score PageSpeed, c’est-à-dire améliorer la vitesse de chargement et de rendu de ses pages.

Ce troisième article est consacré à trois plugins de SPIP qui me permettent encore d’augmenter la réactivité d’un site. Le résultat est, dans certains cas, spectaculaire. À nouveau, j’ai testé ces solutions sur Flip-Zone, notre site de mode, qui a les caractéristiques suivantes :
— beaucoup de pages (près de 2000),
— énormément d’images (environ 50 000), et traitements sur toutes les images,
— beaucoup d’images à afficher sur chaque page du site,
— une fois publiée, une page ne changera quasiment plus jamais.

Cache cool

Le plugin Cache cool, développé par Cédric Morin, s’installe sur une version récente de SPIP (au minimum 2.1). Il nécessite l’installation du plugin Job Queue (qui n’est pas, à ma connaissance, documenté).

Une fois installé, le plugin est immédiatement effectif.

Le principe du cache de SPIP est le suivant :
— lorsque j’arrive sur une page du site, SPIP regarde s’il existe une version déjà sauvegardée de la page (un cache),
— il regarde la date de création de ce fichier ;
— si cette date est récente (par exemple, moins de deux heures), SPIP considère que ce cache est utilisable, et l’expédie tel quel au visiteur ;
— en revanche, si ce cache est trop ancien, SPIP lance un nouveau calcul de la page, sauvegarde la nouvelle version calculée en cache, et expédie le résultat au visiteur.

C’est la dernière entrée qui peut poser problème : recalculer la page peut prendre du temps. Sur Flip-Zone, quand le serveur est chargé, cela peut prendre plusieurs secondes. Pendant ce temps-là, le visiteur ne voit rigoureusement rien s’afficher.

Or, sur un site avec beaucoup de pages, cette situation n’est pas rare : il suffit de visiter une page un peu ancienne du site, donc peu visitée, pour être à peu près certain que SPIP va lancer un recalcul avant de servir la page.

C’est là qu’intervient Cache cool. Au lieu de faire attendre le visiteur (parce qu’il recalcule le cache avant d’envoyer quoi que ce soit), il va alors (généralement) envoyer directement le contenu du cache « périmé », et enregistrer le fait qu’il faut recalculer cette page. Le visiteur reçoit donc quasiment instantanément sa page (« périmée »), et le calcul du nouveau cache est renvoyé à plus tard, et cela en tâche de fond.

Sur un site comme Flip-Zone, le résultat est spectaculaire : dès l’installation du plugin, une navigation dans le site semble instantanément beaucoup plus réactive.

Le plugin n’est sans doute pas adapté :
— aux sites ayant trop peu de trafic (la liste de pages à recalculer s’allonge, sans qu’il y ait assez de visiteurs pour provoquer les calculs),
— aux sites dont le contenu de chaque page est censé être mis à jour souvent.

Inclure-Ajaxload

Le plugin Inclure-Ajaxload a été développé par Fil. Je l’ai repris récemment pour rendre son utilisation plus générique, et introduire quelques automatismes supplémentaires.

Son utilisation implique de modifier ses squelettes. Mais cela est particulièrement simple.

Cédric a décrit une utilisation du chargement Ajax en parallèle du contenu des pages dans un article du Spip Blog, technique décrite à l’origine par Facebook, que Cédric résume ainsi :

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.

Cédric a inclut cet automatisme (sous le nom d’APL) directement dans ses squelettes Zpip. Malheureusement, le code est difficilement utilisable en dehors de Zpip, car il repose largement sur la structure même des squelettes.

L’évolution de Inclure-Ajaxload est donc destinée à pouvoir adopter ces méthodes dans ses propres squelettes, sans devoir en passer par Zpip.

Le principe est le suivant.

— Dans mes squelettes, j’installe des morceaux de mes pages dans des squelettes séparés. Par exemple, le pied de page est installé dans un squelette inc/footer.html, et appelé ainsi depuis chacun de mes squelettes :

Cette forme d’inclusion est « dynamique », c’est-à-dire que le morceau de cache correspondant à ce footer (commun à de nombreuses pages) est indépendant du cache principal.

Je pourrais également l’appeler ainsi :

Dans cette inclusion (dite « statique »), le footer n’a pas de cache indépendant, et est stocké dans le cache global de la page qui l’appelle.

Pour utiliser Inclure-Ajaxload, je vais ajouter le critère {ajaxload} dans l’appel de l’inclusion statique :

Le code généré est alors totalement différent. Le contenu de cette inclusion n’est plus du tout présent dans la page envoyée au visiteur. Seul un code très court (quelques caractères) est inséré.

Ensuite, dans l’entête de la page (il faut donc bien utiliser #INSERT_HEAD), un petit morceau de Javascript est inséré par le plugin. Dès le chargement de la page par le visiteur, ce Javascript va détecter le petit code très court, et demander au serveur de lui envoyer le contenu réel de l’inclusion, pour l’insérer correctement dans la page.

Ainsi, la page est envoyée en deux temps au visiteur :
— la page « allégée » de ses inclusions est envoyée ; comme elle est plus courte et plus simple que la page complète, elle s’affiche beaucoup plus rapidement ;
— dès l’affichage de la page allégée, les différents morceaux manquants sont appelés par Javascript et réinsérés (très rapidement) dans la page affichée.

Pour le visiteur, il y a une meilleure impression de réactivité : quand il arrive sur une page, quelque chose s’affiche beaucoup plus rapidement. Et l’information se complète rapidement après cet affichage initial.

Pour ma part, je n’utilise pas la technique complète (j’ai d’autres impératifs qui limitent mes possibilités de ce côté), mais je charge, en gros, ce qui apparaît à l’écran « sans scroller » ; tout ce qui est en bas de page (et qui est assez lourd) est chargé dans un second temps.

Les quelques dizièmes de seconde gagnés à l’affichage initial donnent réellement une meilleure impression de réactivité.

J’ai documenté le plugin sur Plugins.SPIP. Cette documentation indique encore quelques recommandations (difficultés avec les paginations, pas de publicités dynamiques, mutualiser le cache entre plusieurs pages, etc.).

Créer Sprites CSS

Pour ma dernière intervention sur le site, j’ai développé un plugin qui regroupe automatiquement plusieurs « petites » images en une seule grande image, selon le principe des « Sprites CSS ».

Le plugin est désormais disponible au téléchargement, et je vous invite à lire sa documentation sur Plugins.SPIP. J’ai essayé de faire une doc assez complète.

Pour résumer à l’extrême : j’ai à plusieurs endroits des pages des éléments graphiques générés par SPIP (images typographiques, vignettes de navigation des documents), qui insèrent beaucoup de petites images dans la page. Pour le visiteur, cela revient à charger en moyenne 30 petites images différentes à chaque page (c’est-à-dire autant d’interrogations du serveur). Grâce à ce plugin, avec des modifications de code minimes et simples, ces 30 petites images sont regroupées en deux « grandes » images, et le visiteur ne lance donc plus que deux interrogations du serveur.

La vitesse de chargement et d’affichage des pages est améloriée de manière spectaculaire (à noter que PageSpeed apprécie beaucoup la manip...).

Voilà, ce sont les trois techniques que j’ai utilisées dernièrement pour tenter d’améliorer la réactivité de Flip-Zone. Les deux derniers plugins sont assez expérimentaux, mais ils fonctionnent bien (sur un site en production, donc). Il est à noter que les gains sont spectaculaires, sans demander autre chose que l’installation de plugins dans SPIP et la modification (assez simple) des squelettes. Il n’y a ici ni besoin de modifier la configuration générale du serveur, ni de toucher au .htaccess.