Pourquoi un tube WordPress rame, et ce que 40 000 vidéos demandent

Un tube WordPress devient lent pour des raisons mécaniques, et presque jamais pour celle que son propriétaire accuse en premier. Ce n'est pas le thème. C'est la base de données à qui on demande de trier des dizaines de milliers de posts sur une valeur stockée en texte, des imports qui tournent pendant qu'un visiteur attend, un mutualisé qui n'a jamais été taillé pour ça, une grille de vignettes et de players tiers chargés d'un coup, et des fichiers vidéo servis entiers depuis la même machine. Chacun se corrige. À 40 000 vidéos, il faut tous les corriger, parce qu'à cette taille chaque raccourci se voit.

On a construit et fait tourner des sites WordPress adultes pendant des années avant Jimp. Ce qui suit, c'est ce qu'on a vu casser, dans l'ordre où ça casse en général.

Mesurer d'abord, avec le bon chiffre

Avant de toucher à quoi que ce soit, ouvre PageSpeed Insights sur trois pages, pas une : l'accueil, une page de catégorie et une page vidéo. Elles sont lentes pour des raisons différentes.

PageSpeed montre deux sortes de données, et sa documentation est claire sur la différence. Le bloc du haut, ce sont les données terrain, ce que de vrais utilisateurs de Chrome ont vécu sur tes pages pendant les 28 derniers jours. Le bloc du dessous, ce sont les données de labo, un chargement simulé de la page sur un seul appareil et avec des conditions réseau fixes. Les données terrain disent ce que tes visiteurs ont vécu ; celles du labo te disent pourquoi.

Les trois chiffres qui comptent sont les Core Web Vitals. Le Largest Contentful Paint doit rester sous 2,5 secondes, l'Interaction to Next Paint sous 200 millisecondes, le Cumulative Layout Shift sous 0,1, mesurés sur trois visites sur quatre. Sur un tube, le LCP, c'est en général la première vignette ou l'image du player, et le CLS, c'est une grille d'images sans dimensions qui saute pendant le chargement, ou une bannière qui arrive en retard et pousse tout vers le bas.

Note les chiffres. Chaque changement qui suit doit en faire bouger un, sinon annule-le.

Une base qui n'était pas faite pour ça

WordPress range tout ce qui n'est pas un titre, un contenu ou une date dans une table à part, wp_postmeta, à raison d'une ligne par clé et par post. Une vidéo importée par un plugin d'embed classique porte une douzaine de ces clés, voire plus : la source, l'identifiant de la vidéo chez la source, le code d'embed, la vignette, une série de captures, la durée, un trailer, un ou deux drapeaux. À 40 000 vidéos, cette table contient des centaines de milliers de lignes, et elle grossit à chaque import.

Lire les meta d'un post ne coûte rien. Trier ou filtrer dessus, si. « Les plus vues », « les plus longues », « HD seulement » : chacune de ces listes demande à la base de retrouver la bonne clé sur tous les posts, de lire sa valeur en texte, de la convertir et de trier le tout, et la colonne des valeurs n'est pas indexée pour ça. La documentation de WordPress VIP le dit franchement. La table a un index sur la clé, pas sur la valeur, et une partie de ces requêtes peut devenir des requêtes sur des taxonomies. Sur un accueil avec quatre blocs de ce genre, ça fait quatre de ces requêtes par affichage hors cache.

Les remèdes, du moins cher au plus cher. Un cache objet persistant (Redis ou Memcached, si l'hébergeur le propose), pour que la même requête ne tourne pas pour chaque visiteur. Transformer les filtres par lesquels tu listes en catégories ou en tags, que WordPress indexe. Et ranger le compteur de vues dans sa propre table si le thème trie dessus, au lieu de réécrire une ligne de meta à chaque lecture.

Des imports qui tournent pendant qu'un visiteur attend

Les plugins d'import vont chercher les flux à intervalles réguliers, et sur la plupart des WordPress, c'est WP-Cron qui s'en charge. Le manuel des plugins explique ce que c'est vraiment. Pas un planificateur système, mais une vérification lancée au chargement des pages. Quand une tâche est due, c'est la requête d'un visiteur qui la déclenche.

Sur un blog, personne ne le remarque. Sur un tube qui importe des centaines de vidéos par passage, télécharge leurs vignettes et crée les posts et les termes, le visiteur qui a déclenché la tâche attend, et tous ceux qui arrivent pendant que le serveur est occupé aussi. Le manuel donne le remède sur sa page consacrée au cron système : mettre DISABLE_WP_CRON dans wp-config.php et appeler wp-cron.php depuis un vrai cron système toutes les quelques minutes. Les imports tournent alors sur leur propre horloge, hors du chemin des visiteurs.

Regarde aussi ce que le plugin télécharge. Des vignettes recopiées en local, c'est un disque qui se remplit ; si la source les sert depuis son CDN et que le plugin te laisse garder l'URL distante, garde-la.

Le mutualisé a un plafond que tu ne vois pas

La plupart des tubes WordPress démarrent sur un mutualisé. Les offres mutualisées limitent le temps CPU, la mémoire et le nombre de processus PHP simultanés par compte, et ces limites ne sont pas toujours écrites sur la page de vente. Le symptôme se reconnaît : le site va bien la nuit, rame aux heures de pointe, et sort une 503 ou une page « limite de ressources atteinte » le jour où un post décolle.

Aucune optimisation ne déplace ce plafond ; elle recule seulement le moment où tu le touches. C'est le cache de page qui fait le plus (le guide d'optimisation de WordPress y voit le plus gros gain pour le moins d'effort), parce qu'une page en cache est servie sans lancer PHP du tout. Pour les visiteurs non connectés, c'est-à-dire presque tous sur un tube, un cache de page complète (chez l'hébergeur, dans un plugin ou dans un CDN devant) transforme la plupart des requêtes en lecture de fichier. Après ça, le vrai remède pour un site qui a dépassé le mutualisé, c'est d'en partir.

Des vignettes et des players tiers, tous en même temps

Une page de catégorie affiche une grille, et chaque case est une image, souvent hébergée par le tube source sur son propre domaine. Quarante vignettes, c'est quarante requêtes, souvent vers plusieurs hôtes différents, chacun avec sa connexion à ouvrir. Ajoute des aperçus au survol chargés d'avance, et la page est lourde avant que quiconque ait cliqué sur quoi que ce soit.

Le navigateur peut faire l'essentiel du travail. Donne à chaque vignette sa largeur et sa hauteur pour que la grille ne bouge pas. Charge la première rangée normalement et ajoute loading="lazy" aux autres, comme le recommande le guide de web.dev sur le chargement différé, mais jamais sur la première image, qui est souvent ton LCP. Charge les aperçus au survol, pas avant.

Le player est le problème le plus lourd. Un player de tube embarqué, c'est une iframe qui tire les scripts, les pubs et le tracking de la source dès le chargement. L'audit de Lighthouse lui-même propose une façade : afficher l'image de la vidéo avec un bouton de lecture, et ne charger la vraie iframe que quand le visiteur clique. Sur les pages vidéo sur lesquelles on a travaillé, c'était le plus gros gain à lui seul, et il coûte un clic que le visiteur allait faire de toute façon.

Un MP4 entier n'est pas un flux

Si ton WordPress héberge lui-même de la vidéo, des MP4 uploadés ou des trailers recopiés d'un sponsor, il les sert comme des fichiers. Un navigateur qui lit un MP4 depuis un serveur web ordinaire le télécharge au fil de l'eau, depuis la machine qui fait aussi tourner PHP pour chaque page, en une seule qualité quelle que soit la connexion du visiteur. Sauter au milieu ne marche que si le serveur accepte les requêtes partielles, ce que toutes les installations devant PHP ne font pas proprement. Sur un mutualisé, quelques spectateurs simultanés suffisent à ralentir tout le site.

La vidéo à l'échelle se sert autrement. Le fichier est découpé en courts segments, en plusieurs qualités, listés dans une playlist (HLS est le format courant), et servi depuis un stockage fait pour ça plutôt que depuis le serveur de l'application. Le player choisit la qualité que la connexion tient et ne charge que les segments qu'il lit. C'est une chaîne à part, pas un réglage de WordPress, et c'est pour ça que les sites qui hébergent leur vidéo finissent par la mettre ailleurs que dans wp-content/uploads.

Ce qu'un site de 40 000 vidéos demande

Un gros tube a besoin de cinq choses, et aucune n'est un thème. Des listes filtrées sur des données indexées, pas sur des meta. Des imports sur un vrai calendrier, loin des visiteurs. Des pages servies depuis un cache sans lancer PHP. Des vignettes et des players qui se chargent quand on les voit, pas avant. Et la vidéo, si tu en héberges, en segments depuis un stockage fait pour ça.

Tu peux y arriver sur WordPress, avec du travail, un bon hébergeur et de la discipline sur les plugins. Ou déménager. Quand un site Jimp prend le relais d'un tube WordPress, la migration WordPress recopie les fichiers que l'ancien site hébergeait et sert les MP4 en HLS, pendant que les vidéos embarquées restent chez leur tube, et la page Domaines perso de la doc explique le jour de la bascule. Quel que soit ton choix, mesure les trois pages avant et après. Les chiffres sont le seul avis qui compte.