Carnet Wiki

Optimiser les performances de SPIP

Ceci est une ébauche que chacun est invité à compléter...

Voici une tentative de synthèse de ce que l’on peut lire ici et là pour aider chacun à optimiser son site sous SPIP pour qu’il soit plus rapide.

Dans un premier temps, il faut préciser que SPIP embarque déjà, sans ajouts particuliers, une multitude d’outils automatiques d’optimisation des performances [1]. Cela signifie que la plupart des webmestres n’auront rien à faire pour obtenir des performances proches d’optimales. Mais, il y a certains cas, comme des sites à très fort trafic (combien ?... à définir), ou quand le(s) serveur(s) est(sont) sous-dimensionné(s), il est nécessaire de mettre la main à la pâte pour optimiser encore. Souvent, ces ajustements sont spécifiques du site, et c’est parce que leur généralisation n’est pas possible que ces méthodes ne sont pas intégrées par défaut dans SPIP.

À comprendre : les étapes du calcul d’une page par SPIP

À partir d’une page de squelette (ex. : squelettes/sommaire.html), SPIP va interroger la base de données pour récupérer le contenu nécessaire et construire une page HTML qu’il renvoie au navigateur. Ce calcul se fait en plusieurs étapes, notamment rappelées ici : Optimisation de la charge serveur, SQL et var_profile

  • Première étape : la transformation du fichier squelette en code PHP.
    SPIP « compile » le squelette pour le transformer en code PHP contenant des requêtes SQL. Il transforme donc boucles et balises en code PHP/SQL capable d’effectuer dynamiquement les actions nécessaires pour construire la page HTML finale. Ce script PHP est ensuite mis en cache par Spip, c’est-à-dire inscrit sur le disque dur du serveur. Ce cache est le cache dynamique, car il contient du PHP qui devra être exécuté (et nécessiter du temps de calcul). Ainsi, cette étape de compilation n’est pas refaite systématiquement. Il est seulement nécessaire de la faire quand le fichier squelette lui-même a changé. Si seules les données de la base de données changent, mais pas le squelette, alors on pourra réutiliser directement ce fichier PHP. Par contre, si le squelette change, il est nécessaire de refaire la compilation. C’est ce que l’on provoque en indiquant « var_mode=recalcul » dans l’URL d’une page.
  • Deuxième étape : La génération d’une page HTML contenant les données de la base.
    Le code PHP qui a été compilé et stocké dans le cache dynamique par SPIP est exécuté. Avec lui sont exécutées les requêtes SQL qui permettent de récupérer les données. Ce code PHP permet de construire la page HTML qui sera retournée au navigateur. Cette page est à son tour stockée dans le cache statique. On l’appelle ainsi, car il contient des pages qui seront directement retournées au navigateur, sans exécution de PHP, sans requête SQL, donc sans calcul complexe. Tant que les données dans la base ne changent pas SPIP peut retourner les pages du cache statique puisqu’il contient des données à jour. Par contre, si les donnés dans la base changent, les pages du cache statique désormais obsolètes doivent être régénérées à partir de celles du cache dynamique et donc les requêtes SQL refaites. C’est ce que l’on provoque avec un « var_mode=calcul ».
  • Troisième étape : le service du cache.
    Si les données et les squelettes n’ont pas changé (et que la durée du cache n’est pas dépassée), SPIP se contente de renvoyer le contenu du cache statique.

Pour une page donnée, on peut connaître les temps de ces trois calculs (je cite : Optimisation de la charge serveur, SQL et var_profile) :


-   ?var_profile=1 (service du cache)
-   ?var_profile=1&var_mode=calcul (prise en compte des nouveautés de la base de donnée)
-   ?var_profile=1&var_mode=recalcul (recompilation = prise en compte des modifications du squelette)

Optimiser son site SPIP c’est donc travailler à réduire ces temps de calcul quand le visiteur veut afficher une page :

  • rendre le cache le plus efficace possible : éviter que SPIP ait besoin de refaire les calculs de l’étape 1 (c’est à dire la compilation du squelette et création du cache dynamique) et 2 (c’est à dire l’exécution du PHP, des requêtes SQL et création du cache statique) de donc limiter l’action de SPIP à l’étape 3 (service du cache).
  • réduire les temps de calcul de la compilation : étape 1 du calcul pour créer le cache dynamique
  • réduire les temps de calcul de l’exécution du PHP et des requêtes SQL : étape 2 du calcul pour créer le cache statique
  • réduire le temps de service du cache : étape 3 du calcul pour renvoyer la bonne page du cache, elle est toujours effectuée son optimisation est donc primordiale

Quand un visiteur tente d’afficher une page d’un site sous SPIP, il existe d’autres temps d’attente que ces temps de calcul que l’on peut aussi souhaiter réduire :

  • Le temps de téléchargement des éléments de la page : cela dépend surtout du poids (en ko) de la page (Images !) et du débit réseau du serveur (mais aussi à la marge de ses performances de calcul) ;
  • le temps de calcul des positionnements dans la page par le navigateur : qui dépendent à la fois de la structure de la page (layout HTML/CSS), du type de navigateur utilisé et bien sûr de la performance générale de la machine cliente ;
  • et le temps d’exécution du JavaScript de la page par le navigateur : comme ci-dessus, cela dépend à la fois du JS embarqué dans la page, du navigateur et de la performance de la machine cliente.

Le cache et les inclusions : #INCLURE ou <INCLURE> ?

-  #INCLURE
-  <INCLURE>
-  la question des #MODELES
-  la question du PHP directement dans les squelettes
-  la question des balises #SESSION

Plus loin avec les caches de SPIP : temps de cache et invalidation, URL & cache, etc.

-  Le cache est déterminé par un temps de cache
-  chaque URL avec des paramètres différents provoque la génération d’un cache spécifique
-  chaque visiteur identifié provoque la génération d’un cache spécifique lorsque les balises #SESSION ou #AUTORISER sont utilisées
-  la question de la taille du cache vs performance

Mesurer les performances de son SPIP : var_profile et autres techniques

-  var_profile
-  Page Speed
-  http://www.webpagetest.org/

Optimiser avec des plugins : agir sur le cache

-  memoization
-  cache cool
-  Fastcache
-  Expresso
-  microcache (utilisation ???)
-  fulltext
-  inclure ajaxload
-   ?

De la performance des plugins : pipelines et autres considérations

Les plugins utilisent des pipelines ou rajoutent des « fonctions » et des « options ». Si les calculs rajoutés sont lourds, cela peut avoir un impact sur le site.

-  mes_options à chaque hit
-  mes_fonctions à chaque calcul

Optimiser ses squelettes : la base de données

-  critères et index SQL
-  Champs extra/jointures

Optimiser ses squelettes : des boucles plus légères

-  inclusions (factorisation)
-  jointures
-  ajax
-  doublons ou array ?

Bibliographie :

à compléter, bien sûr !

[1Selon http://www.spip-blog.net/Drupal-et-..., SPIP optimise les requêtes SQL lors de la compilation, en plus de son système de cache à plusieurs étages.

Beurt - Mise à jour :20 mai 2018 à 23h40min