Nouveautés Télé, thème sur mesure pour le média des séries télé

Un média avec de la publicité, et un INP qui se dégradait

À propos de Nouveautés Télé

Nouveautés Télé est un média en ligne consacré aux feuilletons et aux séries télé : résumés des prochains épisodes, critiques, audiences, et une communauté de lecteurs très active dans les commentaires. Le site, sous WordPress, est un média à fort trafic qui totalise plusieurs dizaines de milliers de visites par jour. Approche indépendante oblige, son business model est de type publicitaire, avec plusieurs régies qui y déploient leurs formats : lecteur vidéo, encarts intégrés aux images, enchères en temps réel, etc.

Pourquoi nous avoir contactés

Nous suivons le site chaque semaine. À la fin de l’été, sa réactivité sur mobile, mesurée par Google chez les vrais visiteurs, a commencé à se dégrader : l’INP (Interaction to Next Paint, le délai entre un geste et la mise à jour de l’écran) atteignait 207 ms au 75e centile, au-dessus du seuil de 200 ms qui sépare « bon » de « à améliorer ». Sur ordinateur, il restait à 57 ms. L’affichage, lui, était déjà rapide (LCP de 1,4 s) : le problème n’était pas la vitesse de chargement, mais le travail du navigateur. Avec Isabelle, qui édite le site, nous avons décidé d’une refonte complète du thème.

Performances attendues

Repasser durablement sous les 200 ms d’INP sur mobile, en réduisant tout ce qui occupe le fil principal du navigateur, l’unique file d’attente où s’exécutent les scripts, se calculent les styles et se traitent les gestes du lecteur. Le temps de blocage (TBT), qui additionne les tâches trop longues pendant le chargement, en est le témoin en laboratoire : 166 ms sur l’accueil mobile dans PageSpeed Insights.

Enjeux et contraintes

Les scripts des régies sont la plus grosse part de ce travail, et ils ne se retirent pas : ce sont eux qui financent le site. Les reporter au premier geste du lecteur, comme on le fait pour d’autres scripts tiers, ferait chuter les impressions et sauter la page à leur insertion. La seule marge restante était donc le code du site lui-même : chaque milliseconde rendue par le thème est une milliseconde de plus pour les publicités, sans gêner le lecteur. Il fallait aussi tout garder à l’identique pour les lecteurs et pour les régies : mise en page, emplacements publicitaires, articles relatifs, critiques et leur notation, adresses et référencement.

Les étapes du projet

Diagnostic : trois couches pour afficher une page

Le thème actif était une variante modifiée d’un thème de magazine (un thème parent et son thème enfant), complétée par quatre extensions d’affichage : un menu mobile et sa surcharge, et deux extensions de pagination. Chaque couche ajoutait ses scripts, ses styles et son HTML : jQuery et ses greffons chargés partout, un second menu complet dans chaque page pour le mobile, des polices d’icônes, des feuilles de style lourdes que WP Rocket devait réduire après coup page par page, et jusqu’à 1 927 éléments HTML sur une page de catégorie.

Un choix radical : un thème entièrement maison

Notre approche habituelle n’aurait pas suffi. D’ordinaire, nous optimisons l’existant (cache, chargement des scripts, images, polices), ou, en refonte, nous reconstruisons le site sur notre socle éprouvé : GeneratePress, GenerateBlocks et notre thème enfant GeneratePerf. Ici, le budget du navigateur était déjà consommé en grande partie par les régies, et rien ne devait s’y ajouter qui ne soit indispensable.

Un thème écrit de zéro, pour ce site seulement. Un thème classique en PHP 8.4, pour WordPress 7.1, sans cadre ni constructeur de pages :

• une seule feuille de style, de 10 Ko compressés, sous le budget de 14 Ko de nos règles internes ;
• un seul script en JavaScript natif, chargé en différé, et plus aucun jQuery ;
• la police système de chaque appareil : rien à télécharger ;
• des icônes dessinées en CSS ;
• un menu mobile unique, ouvert en dialogue natif, accessible au clavier ;
• le préchargement des pages suivantes par le navigateur (Speculation Rules).

Le calcul du CSS utilisé de WP Rocket a pu être coupé : la feuille du thème est déjà réduite.

Toutes les fonctions reprises, une à une.

• pagination identique ;
• articles épinglés par catégorie ;
• codes courts ;
• widgets réécrits avec leurs identifiants, pour garder leurs réglages ;
• règles d’indexation des pages de commentaires ;
• critiques, avec leur bloc « Notre avis » et leurs données structurées.

Deux extensions écrites pour le site, les articles relatifs et l’injection des encarts publicitaires dans le texte, sont devenues des modules du thème : mêmes réglages, mêmes articles proposés, encarts devant les mêmes paragraphes. Les styles de 47 extraits de contenu, qui débordaient sur toute la page, ont été limités à leur tableau.

Une mise en ligne sans interruption

La bascule a été répétée de bout en bout sur une copie du site sous Docker : bascule, retour arrière, nouvelle bascule. Le nouveau thème a ensuite été affiché sur le vrai site par une adresse réservée, invisible des visiteurs et des moteurs, pour vérifier régies, outils de mesure et bandeau de consentement en conditions réelles. Cette recette a révélé un défaut que rien d’autre n’aurait montré : le lecteur vidéo d’une régie se plaçait grâce à un repère de l’ancien thème, défini dans la configuration de la régie. Le repère a été recréé avant la mise en ligne. La bascule elle-même a pris 1,4 s, avec un retour arrière testé en 3 s, jamais utilisé.

Des ajustements au fil des retours d’Isabelle

Dans les jours qui ont suivi, une quinzaine de versions du thème ont été mises en ligne, chacune fichier par fichier, avec une sauvegarde de la version précédente :

• couleurs d’accent et contrastes ;
• colonne de lecture ramenée d’environ 97 à 65 signes par ligne sur ordinateur ;
• intertitres plus lisibles ;
• chapô des articles ;
• écran de réglages de l’accueil et des emplacements publicitaires, recréé dans l’administration.

Compte-rendu d’intervention

Le compte rendu de 24 pages détaille ce qui a été conservé, retiré et changé, la méthode de mise en ligne, les mesures avant et après sur le même protocole, et les choix techniques à respecter pour la suite. Une annexe indique à tout futur prestataire où trouver chaque fonction dans le thème.

Performance d’un site sur lequel la publicité joue un rôle clé

Pourquoi un site média est-il moins réactif sur mobile ?

Parce que les régies travaillent sur le même fil que le lecteur. Leurs scripts mettent chaque emplacement aux enchères auprès de dizaines de partenaires, puis recommencent à intervalles réguliers pour afficher de nouvelles publicités. Pendant ce temps, un geste du lecteur attend son tour : c’est ce délai que mesure l’INP. Sur un téléphone, moins puissant qu’un ordinateur, la file d’attente s’allonge, ce qui explique en bonne partie l’écart entre 207 ms sur mobile et 57 ms sur ordinateur.

Faut-il différer les scripts publicitaires pour améliorer l’INP ?

Non. Reporter une régie au premier geste du lecteur fait chuter les impressions, donc les revenus, et provoque des décalages de mise en page quand la publicité s’insère enfin. Les leviers sont ailleurs : réduire tout le reste du travail du navigateur, comme ici, et régler avec chaque régie ce qui peut l’être sans perte de revenu, chiffres à l’appui.

Quand choisir un thème sur mesure plutôt qu’une optimisation ?

Quand le code du site est la dernière marge disponible. Pour la plupart des sites, optimiser le thème existant ou le reconstruire sur un socle éprouvé suffit. Un thème entièrement maison se justifie quand chaque milliseconde compte, comme sur un média financé par la publicité, et quand la mise en page est stable : il faut alors inventorier chaque fonction de l’ancien thème et la reprendre à l’identique, ce qui fait l’essentiel du travail.

La stack technique

Le résultat en chiffres

Mesures Lighthouse sur mobile, sur une copie du site : 11 pages types, deux passages avant et deux après, sans publicité ni outils tiers, pour isoler le code du site.

En moyenne par page, sur la copie du site :

• scripts du site : de 74 à 14 ms ;
• travail du navigateur : de 377 à 221 ms ;
• CSS transféré : de 66 à 10 Ko ;
• JavaScript transféré : de 85 à 29 Ko ;
• requêtes : de 72 à 23 ;
• score de performance : de 89 à 99.

En ligne, publicités comprises, sur un article mobile : score de 80 à 92, LCP de 4,7 à 3,1 s, CLS de 0,010 à 0. Le temps de blocage de cet article est resté stable (72 puis 75 ms) : en ligne, il dépend surtout des enchères publicitaires de chaque chargement, au point de monter jusqu’à 1,7 s sur un article mobile dans GTmetrix. C’est l’INP de terrain, mesuré par Google sur 28 jours glissants, qui donnera le verdict complet, vers le 10 novembre.

Votre média mérite le même traitement ? Découvrez notre accompagnement des éditeurs web.

La suite et fin en images