Contactez-nous

1

Trois plugins pour accélérer encore son site SPIP

8 octobre 2010
par ARNO*

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 :

  1. <INCLURE{fond=inc/footer}{id_rubrique} />

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 :

  1. [(#INCLURE{fond=inc/footer}{id_rubrique})]

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 :

  1. [(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload})]

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.

  • izo
    Octobre 2010

    énorme le CSS Sprite. Je teste ça

  • JLuc
    Octobre 2010

    Hello

    Dans la doc de inclure-ajaxload sur plugins.spip.net, tu ne parles que des appels en #INCLURE, et pas en <INCLURE

    Ici, tu dis que c’est valable pour les 2.

    C’est la même version ?

  • Loiseau2nuit
    Octobre 2010

    Joli florilège et qui tombe à pic, j’avais un serveur un peu à la masse de base, et ca ne s’arrangeait pas avec le gros site que j’avais mis dedans. Je vais tester tout ça !

    Merci ARNO* :-)

  • Arno*
    Octobre 2010

    @JLuc : non, je rappelle l’inclusion dynamique ici parce que c’est le code qui va bien normalement (puisque c’est un morceau de page utilisé sur plusieurs pages, donc autant partager le cache) ; mais le Ajaxload, lui, n’est prévu que pour l’autre #INCLURE (sauf erreur, pas testé).

  • JLuc
    Octobre 2010

    Oui c’est super Arno...

    Bon la lecture plus attentive de ton explication indique bien que c’est prévu pour les inclusions statiques seulement ! Désolé pour la question déplacée.

    Quand j’essaie cependant, les inclusions se traduisent toutes par un texte identique : "signature ajax bloc incorrecte"...

    Y a t il un moyen de diagnostiquer plus précisément l’origine du problème ?

  • Arno*
    Octobre 2010

    JLuc, tu as la toute dernière version de SPIP ? Qu’est-ce qui se passe si tu fais avec des critères très simples ? (genre pas env, juste id_article...)

  • Octobre 2010

    Non Arno, ce site n’a que spip 2.0.9
    Il est possible en effet que ça soit la cause du non fonctionnement.

  • Octobre 2010

    Hello Arno,
    j’ai upgradé à SPIP 2.0.11
    il n’y avait plus le message "signature ajax bloc incorrecte" mais le sablier rond tournait sans fin sans que rien ne se charge. Les autres blocs sont bien affichés.
    j’ai upgradé inclure_ajaxload, mais il nécessite maintenant spip 2.1
    à suivre...

  • Octobre 2010

    Avec spip 2.1.2, ça marche parfaitement ! Merci pour ton indication.

    Il faudrait juste modifier le "necessite spip" du plugin dans plugin.xml et sur plugin.spip.net ?

  • Octobre 2010

    je constate que ça gère bien les ancres et les liens vers des ancres sur la même page... sauf pour les ancres et liens du sommaire autamatique du Couteau Suisse. Les liens vont vers spp.php Dommage ! Car je ne connais pas d’alternative pour cette fonctionnalité...

  • edouard
    Décembre 2010

    woa. je visite régulièrement ton site et je suis impressionné à chaque fois par les innovations sur SPIP que tu proposes ou partages. À chaque fois que viens ici, je suis sûr de trouver un bijou.

    Merci. Je vais essayer tout ça !

  • JLuc
    Novembre 2011

    Hello,

    le lien pour inclure_ajaxload a changé, c’est désormais http://plugins.spip.net/inclureajaxload.html

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.