WordPress
Contexte
Telebari est une chaîne de télévision régionale basée à Bari. Son site, construit avec WordPress, publie chaque jour des actualités sur les faits divers, la politique, le sport et l’actualité de la région, avec des archives qui ne cessent de grossir. C’est le profil type d’un site éditorial : de nombreuses pages construites sur quelques modèles, des pics de trafic liés aux informations de dernière minute et des lecteurs qui arrivent surtout depuis des smartphones, souvent depuis les réseaux sociaux et Google Discover.
Le site tournait sur un serveur LiteSpeed avec le plugin LSCache, qui gérait à la fois le cache de page et les optimisations du front-end : regroupement et chargement asynchrone du CSS, génération automatique de styles, optimisation des polices et des images. Une configuration pratique, mais dans laquelle de nombreuses décisions étaient laissées à un traitement automatique, page par page.
Ce que disaient les données
Dans les données d’utilisateurs réels, les Core Web Vitals mobiles échouaient, avec un LCP au 75e percentile d’environ 3,6 secondes et un CLS de 0,24. Les tests de laboratoire sur mobile confirmaient le tableau : First Contentful Paint à 3,2 secondes, Largest Contentful Paint à 6,4 secondes, Total Blocking Time à 540 millisecondes, Cumulative Layout Shift à 0,31 et Speed Index à 5,1 secondes.
Au-delà des chiffres, le problème se voyait à l’œil nu. À l’ouverture d’une page, le contenu apparaissait d’abord sans style, ou avec des styles partiels, puis se réorganisait : menus, en-têtes et blocs d’actualités changeaient de forme et de position avec un flicker évident. Un défaut désagréable pour les lecteurs et peu en phase avec l’image d’un média d’information.
Le diagnostic
L’analyse a attribué le flicker et le CLS à quelques causes qui s’additionnaient :
- CSS chargé de façon asynchrone sans CSS critique adéquat : la page était affichée avec des styles incomplets puis recomposée à l’arrivée du reste du CSS ;
- polices web lourdes et non optimisées, qui remplaçaient les polices de repli aux métriques différentes et faisaient bouger le texte une fois chargées ;
- éléments sans espace réservé, comme les images, les bannières et les blocs chargés plus tard ;
- ressources critiques découvertes tardivement : l’image principale et les polices n’étaient demandées qu’après l’analyse du CSS, ce qui retardait le LCP.
Travail côté serveur
La première étape a été de déplacer le cache de page du plugin vers le serveur. Le site a été migré de LiteSpeed avec LSCache vers NGINX avec Varnish Cache en frontal, avec une invalidation ciblée : quand un article est publié ou mis à jour, seuls cet article, la page d’accueil et les catégories concernées sont purgés, et non l’ensemble du site. Les pages les plus lues restent toujours en cache, les pages d’archives y entrent à la première visite, et la réponse du serveur est devenue rapide et prévisible, même pendant les pics de trafic.
Travail côté application
Sur le front-end, nous avons renoncé aux optimisations automatiques et travaillé à la main, modèle par modèle :
- CSS critique généré et vérifié pour la page d’accueil, les catégories et les articles, intégré dans le head, le reste du CSS étant chargé sans bloquer le rendu et sans recomposition visible ;
- subsetting des polices, qui réduit les fichiers aux caractères réellement nécessaires et aligne les métriques des polices de repli, pour que le remplacement ne déplace plus le texte ;
- preload et preconnect ciblés, uniquement pour les ressources vraiment critiques comme l’image principale et les polices, et pour les origines dont elles dépendent ;
- espace réservé pour les images, les bannières et les blocs chargés plus tard.
Résultats
Comparaison des tests de laboratoire sur mobile, avant et après les travaux :
| Métrique (laboratoire, mobile) | Avant | Après |
|---|---|---|
| First Contentful Paint | 3,2 s | 1,4 s |
| Largest Contentful Paint | 6,4 s | 2,6 s |
| Total Blocking Time | 540 ms | 130 ms |
| Cumulative Layout Shift | 0,31 | 0,001 |
| Speed Index | 5,1 s | 1,4 s |
Le CLS est pratiquement nul et le flicker à l’ouverture des pages a disparu : le contenu apparaît déjà dans sa forme définitive. Le temps de chargement de l’élément principal a plus que diminué de moitié et le thread principal est bien moins sollicité. Il n’a pas fallu un plugin plus puissant, mais déplacer le cache au niveau du serveur et réaliser quelques optimisations ciblées, modèle par modèle.
Comment nous maintenons le résultat
Le CSS critique doit être mis à jour quand un modèle de page change, et non quand un article est publié : c’est pourquoi il est lié aux versions du thème et vérifié à chaque modification. Les tests de laboratoire sur les pages principales sont répétés à chaque mise en production, et les données d’utilisateurs réels sont suivies dans le temps, en sachant que le Chrome UX Report reflète les améliorations avec une fenêtre glissante de 28 jours.