Les sites universitaires fonctionnent sans difficulté la plus grande partie de l'année et peinent lors d'une poignée de journées chargées. La cause est rarement un serveur sous-dimensionné. C'est que, ces jours-là, la plupart des pages ne peuvent plus être servies à partir d'une copie stockée. Cet article explique en termes simples comment Drupal stocke les pages, ce qu'un CDN accélère et ce qu'il n'accélère pas, et par où commencer pour que le site tienne le choc.
Une page se charge en une demi-seconde en mars et met dix secondes le premier matin des inscriptions. Même site, même code. La seule chose qui a changé, c'est le nombre de pages que le serveur a dû construire de zéro ce jour-là. Accélérer un site sous Drupal consiste avant tout à réduire ce nombre.
Quand un site universitaire ralentit-il vraiment ?
La plus grande partie de l'année, la majorité des visiteurs ne sont pas connectés. Les futurs étudiants parcourent les formations, les parents ouvrent la page de contact, les moteurs de recherche explorent la rubrique actualités. Toutes ces visites peuvent être servies à partir d'une copie stockée, et le serveur ne travaille presque pas.
Les jours chargés, cette répartition change. Une grande partie des visiteurs sont désormais des étudiants connectés. Dès qu'une personne se connecte, la page lui devient personnelle, et une copie stockée pour tout le monde ne convient plus. Le serveur se met à construire des milliers de pages de zéro en même temps.
Deux autres facteurs s'y ajoutent. Les places disponibles et les emplois du temps sont lus depuis un autre système et ne peuvent pas être conservés longtemps, car ils ne doivent pas devenir obsolètes. Et lorsque le calendrier universitaire ou une annonce destinée à toute l'université change, chaque page affichant ces informations doit être reconstruite.
Quand ces trois facteurs tombent la même semaine, le site ralentit. L'objectif n'est pas de gagner quelques millisecondes un jour ordinaire. Il est de passer ces journées sans panne.
Comment Drupal stocke les pages
Après avoir construit une page, Drupal en garde une copie. La personne suivante qui demande la même page reçoit la copie stockée au lieu d'attendre qu'elle soit reconstruite. C'est la principale raison pour laquelle un site sous Drupal paraît rapide, et cela fonctionne dès l'installation.
Pour les visiteurs non connectés
C'est le cas facile. Tout le monde voit la même page, donc une seule copie stockée sert tout le monde. Les pages de formations, les actualités et les coordonnées sont envoyées à des milliers de personnes depuis la même copie, et le serveur ne fait presque rien.
Pour les utilisateurs connectés
Dès qu'une personne se connecte, une partie de la page n'appartient qu'à elle : son nom, ses notifications, ses cours. Une copie unique stockée pour tout le monde ne peut plus être utilisée.
Drupal gère cela en divisant la page en deux. Il continue de stocker les parties identiques pour tous et ne reconstruit que les parties personnelles à chaque visite. Seule une fraction de la page est donc reconstruite, et non la page entière.
Si ces parties personnelles restent lentes, BigPipe prend le relais. Cette approche a d'abord été développée chez Facebook, puis Drupal l'a intégrée à son cœur. Son principe est simple : les parties communes de la page sont envoyées immédiatement, et les parties personnelles suivent dès qu'elles sont prêtes. Le visiteur voit ainsi la page se remplir au lieu de fixer un écran vide. Selon la documentation de Drupal, BigPipe est activé par défaut dans l'installation standard depuis la version 8.5, ce qui signifie qu'il fonctionne déjà sur la plupart des sites.
| Visiteurs non connectés | Utilisateurs connectés | |
|---|---|---|
| Comment la page arrive | Depuis une copie stockée | Parties communes stockées, parties personnelles reconstruites |
| Coût pour le serveur | Quasi nul | Un peu de travail à chaque visite |
| Risque un jour chargé | Faible | C'est ici que se concentre la charge |
Ce qui se passe quand le contenu change
Le plus difficile, quand on stocke des pages, n'est pas de remplir le stock. C'est de rafraîchir les bonnes pages au bon moment. Sur un site universitaire, la même information apparaît à des dizaines d'endroits. Le nom d'un enseignant-chercheur figure à la fois dans la liste d'un département, sur la page d'un cours et dans une actualité.
Drupal enregistre de quel contenu dépend chaque page stockée. Lorsque ce contenu change, il ne rafraîchit que les pages qui en dépendent et laisse le reste intact. Un changement de nom ne se répercute donc pas sur tout le site.
La véritable erreur, ici, est l'habitude de tout vider après chaque modification. Cela oblige à reconstruire le site entier, et c'est généralement fait au pire moment possible. La solution consiste à cesser de traiter ce bouton comme un geste quotidien.
Ce qu'un CDN accélère, et ce qu'il n'accélère pas
Un CDN sert les fichiers d'un site depuis des serveurs répartis dans le monde entier, si bien que les images, les vidéos et les polices arrivent d'un endroit proche du visiteur. Sur les sites universitaires, ces fichiers représentent l'essentiel du poids des pages : le gain est donc réel.
Côté Drupal, c'est le module CDN qui s'en charge. Un détail compte pour la planification : la version stable fonctionne avec Drupal 9 et 10, tandis que la prise en charge de Drupal 11 est encore en cours de test. Un établissement qui utilise déjà Drupal 11 doit le savoir à l'avance.
Une erreur courante suit l'installation : une fois le CDN en place, on considère le problème de performance comme réglé. Mais un CDN distribue des fichiers finis, il ne construit pas de pages. La page personnelle que voit un étudiant connecté est construite à chaque fois sur le propre serveur de l'établissement, et c'est là que se concentre la charge un jour chargé.
Les pages des services informatiques universitaires le disent clairement. Les consignes Drupal d'une grande université publique indiquent aux responsables de sites que son CDN ne s'applique qu'aux visiteurs non connectés, et que les utilisateurs connectés le contournent entièrement. Stanford pousse la distinction plus loin. Ses services informatiques décrivent une plateforme Drupal gérée de façon centralisée pour les sites des départements et des services, avec une option d'hébergement distincte pour les sites à fort trafic. Tous les sites ne sont pas traités de la même façon.
Les pages qui affichent des données en temps réel
Les places disponibles, les emplois du temps et les résultats proviennent d'un autre système et ne doivent pas devenir obsolètes. Comme ils ne peuvent pas être stockés, ce sont les pages les plus coûteuses du site.
Trois mesures simples aident. D'abord, séparez l'élément en temps réel du reste de la page, afin que seul ce petit morceau soit reconstruit à chaque fois tandis que tout ce qui l'entoure reste stocké. Ensuite, donnez-lui une durée de vie courte plutôt qu'aucune. Un nombre de places datant d'une minute au plus est acceptable dans la plupart des situations, et cette minute épargne à l'autre système des milliers de requêtes. Enfin, décidez de ce que la page affiche quand l'autre système ne répond pas. Afficher le dernier chiffre connu avec un horodatage vaut mieux que ne rien afficher.
Nous avons traité la partie données de ces pages dans l'article Intégrer Drupal au système d'information étudiant.
Faire tourner de nombreux sites sur une seule plateforme
De nombreuses universités font tourner des dizaines de sites de facultés et de services sur une installation commune. Une hypothèse courante en découle : puisque les sites partagent une plateforme, les copies stockées doivent être partagées elles aussi. Ce n'est pas le cas. Chaque site conserve les siennes.
Cela a deux conséquences. Une amélioration apportée à un site ne se répercute pas d'elle-même sur les autres. Et comme les sites qui partagent un serveur en partagent aussi les ressources, une semaine chargée pour un département peut ralentir les pages d'un autre.
Les avantages et inconvénients plus larges de cette configuration sont abordés dans l'article Gérer les sites universitaires avec Drupal multisite. Côté performance, la conclusion pratique est d'identifier les sites qui connaissent des pics et de les planifier séparément.
Ce qu'il faut mesurer
Les outils de mesure ont un angle mort qu'il vaut la peine de connaître. La plupart testent le site sans se connecter, ce qui signifie qu'ils ne voient jamais les pages qui peinent un jour chargé. Une page d'accueil peut obtenir un score parfait pendant que l'écran de choix des cours s'effondre.
Il faut donc deux angles de vue. Le premier couvre les pages que les visiteurs voient sans se connecter. Les indicateurs de vitesse de Google évaluent ce volet et influencent le classement dans les résultats de recherche ; nous les avons présentés dans l'article Le SEO sous Drupal. Le second couvre les pages que voient les utilisateurs connectés, mesurées sur le serveur plutôt que dans un navigateur, et c'est généralement là que se trouve le vrai problème.
La mesure la plus utile est déjà à votre disposition. Les journaux du serveur de votre semaine la plus chargée de l'an dernier vous en apprendront plus que n'importe quel outil de test. On y trouve quelles pages ont été demandées à quelle heure, et quelles requêtes n'ont jamais abouti.
Par où commencer
Commencer au moins un mois avant le pic et suivre l'ordre ci-dessous donne de bons résultats.
Commencez par vérifier que les réglages de cache sont activés. C'est une vérification d'une demi-heure, mais sur les sites où quelque chose avait été désactivé, c'est l'étape qui fait la plus grande différence de toute la liste.
Passez ensuite en revue les pages que voient les utilisateurs connectés et déterminez quelles parties sont réellement personnelles. Sur la plupart des sites, elles sont moins nombreuses qu'on ne le pense, et tout le reste peut être rendu stockable.
Puis séparez les éléments qui affichent des données en temps réel, donnez à chacun une durée de vie raisonnable et décidez de ce que chacun affiche quand l'autre système est indisponible.
Enfin, lancez un test calqué sur l'heure la plus chargée de l'an dernier. Ce test doit tourner en tant qu'utilisateur connecté, sinon les pages à l'origine du problème ne sont jamais sollicitées.
Il est utile de cadrer les attentes en parallèle du travail. Drupal vous donne ici des outils puissants, mais ils n'arrivent pas réglés pour votre établissement. Décider à quel point chaque information peut être ancienne relève d'un choix institutionnel plutôt que technique, et il se fait en présence du service de la scolarité.
Les plateformes Drupal que l'équipe Drupal4edu de Drupart conçoit pour des établissements comme l'Université Yeditepe, l'Université Istinye et l'Université Medipol sont configurées pour absorber ces pics exactement de cette manière. Pour en savoir plus sur notre approche, consultez la page Drupal dans l'enseignement supérieur.
Questions fréquentes sur la vitesse des sites Drupal
Un serveur plus puissant réglera-t-il le ralentissement ?
Jusqu'à un certain point, mais c'est la voie la plus coûteuse. La plupart des pages qui peinent les jours chargés sont reconstruites parce qu'elles ne peuvent pas venir d'une copie stockée. Avec des réglages de cache corrigés, le même serveur accueille bien plus de visiteurs. L'ordre logique est de vérifier d'abord les réglages, de rendre stockable tout ce qui n'est pas personnel, puis seulement de parler matériel si cela ne suffit toujours pas.
Un CDN suffit-il à lui seul ?
Non. Un CDN distribue les images, les vidéos et les polices, ce qui réduit nettement le poids des pages. Mais la page personnelle que voit un étudiant connecté est de toute façon construite sur le propre serveur de l'établissement, et c'est là que se concentre la charge un jour chargé. Considérer le CDN comme un complément utile plutôt que comme la réponse principale donne un résultat plus réaliste.
Peut-on stocker des données en temps réel comme les places disponibles ?
Brièvement, oui, et dans la plupart des cas il le faut. Un nombre de places datant d'une minute au plus est généralement acceptable, et cette minute évite que des milliers de requêtes n'atteignent l'autre système. L'essentiel est de choisir cette durée de vie délibérément et de la valider avec le service de la scolarité. Il est tout aussi important que la page ne s'affiche pas vide quand l'autre système est indisponible, mais montre le dernier chiffre connu avec un horodatage.
Faut-il vider le cache après chaque modification ?
Non, et c'est une habitude à perdre. Drupal enregistre de quel contenu dépend chaque page stockée, et rafraîchit donc de lui-même les pages concernées quand quelque chose change. Tout vider oblige à reconstruire le site entier, et cela arrive généralement au moment le plus chargé. Réservez ce bouton aux situations exceptionnelles au lieu d'en faire un réflexe quotidien.