Performance d’une page générée par IA : DOM, CSS inutilisé et Core Web Vitals

40 millisecondes : c’est la durée de mise en page ou de calcul de styles au-delà de laquelle l’analyse de la taille du DOM de Lighthouse signale un problème, d’après la documentation de Chrome. Ce chiffre est utile pour un article sur les pages générées par IA, car il rappelle une évidence souvent oubliée : un DOM volumineux n’est pas une faute en soi, il devient un défaut quand il coûte du temps. Cet article, dixième de la série « IA et constructeurs de pages », propose une méthode pour le vérifier. Il ne contient volontairement aucune mesure prétendument réalisée sur tel ou tel outil : il vous donne le protocole pour produire les vôtres.

Ce qu’il faut mesurer, et contre quoi

Une page produite par l’assistant d’un constructeur peut coûter plus cher qu’une page équivalente pour quatre raisons plausibles : davantage d’éléments et de conteneurs imbriqués, des feuilles de style chargées pour des fonctions absentes de la page, des images générées livrées à une taille bien supérieure à leur affichage, et des images sans dimensions réservées. Aucune n’est propre à l’IA : un intégrateur pressé produit les mêmes défauts. La seule façon honnête d’attribuer un surcoût à la génération est la comparaison.

Le protocole repose donc sur deux pages de même contenu : la page générée, et une page témoin, réalisée à la main avec le même constructeur ou avec des blocs natifs de WordPress. Mesurez les deux dans les mêmes conditions, plusieurs fois, et comparez les médianes. Une seule exécution de Lighthouse ne prouve rien, car les résultats de laboratoire varient d’une exécution à l’autre.

Les seuils de référence viennent de web.dev : pour être jugée bonne, une page doit avoir un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus, évalués au 75e centile des chargements, en séparant mobile et ordinateur. Ces seuils s’appliquent aux données réelles des visiteurs, pas à un test isolé.

Données de terrain et de laboratoire : ne pas les confondre

Commencez par les données de terrain si le site existe déjà et reçoit assez de visites : PageSpeed Insights affiche les valeurs réelles collectées auprès des utilisateurs de Chrome. Pour une page neuve, elles n’existent pas, et il ne reste que les mesures de laboratoire. Ce sont des estimations : utiles pour comparer deux versions, inutiles pour annoncer un résultat au client.

Un point technique important concerne l’INP. Il mesure la réactivité aux interactions réelles, ce qu’un chargement de page automatisé ne produit pas. En laboratoire, le temps de blocage total (TBT) sert d’indicateur indirect de la réactivité ; pour l’INP lui-même, il faut des données de terrain ou une session d’interactions enregistrée dans le panneau de performance des outils de développement.

Pour automatiser la collecte de laboratoire, la ligne de commande de Lighthouse suffit. Répétez-la cinq fois par page et conservez les fichiers.

for i in 1 2 3 4 5; do
  npx lighthouse https://exemple.test/page-generee/ \
    --only-categories=performance \
    --output=json --output-path=./generee-$i.json \
    --chrome-flags="--headless"
done

jq '{lcp: .audits["largest-contentful-paint"].numericValue,
     cls: .audits["cumulative-layout-shift"].numericValue,
     tbt: .audits["total-blocking-time"].numericValue}' generee-*.json

Le même jeu de commandes, appliqué à la page témoin, donne vos deux séries. Calculez la médiane de chacune : c’est elle qu’il faut comparer, pas la meilleure exécution.

Le DOM et l’imbrication : mesurer avant d’accuser

La documentation de Lighthouse fixait historiquement un avertissement au-delà d’environ 800 nœuds dans le corps de la page et une erreur au-delà d’environ 1 400. Depuis Lighthouse 13, cet audit est remplacé par un « insight » sur la taille du DOM qui ne raisonne plus en nombre absolu : il n’échoue que si un recalcul de styles touche plus de 300 éléments ou si une mise en page porte sur plus de 100 objets, et dure plus de 40 millisecondes. web.dev explique pourquoi : plus le DOM est grand, plus le rendu initial et chaque mise à jour du rendu coûtent cher, ce qui pèse sur l’INP.

Ce script, à coller dans la console, produit les trois grandeurs que l’analyse suit : nombre d’éléments, profondeur maximale et élément qui porte le plus d’enfants. Ajoutez la part de div, qui donne une idée de l’empilement de conteneurs.

const tous = [...document.body.querySelectorAll('*')];

const profondeur = (el) => {
  let n = 0;
  while (el !== document.body) { el = el.parentElement; n++; }
  return n;
};

console.log({
  elements: tous.length,
  profondeurMax: Math.max(...tous.map(profondeur)),
  enfantsMax: Math.max(...tous.map((el) => el.children.length)),
  partDeDiv: (document.body.querySelectorAll('div').length / tous.length).toFixed(2),
});

Lancez-le sur la page générée et sur la page témoin. Si l’écart est faible, le DOM n’est pas votre sujet. S’il est net, confirmez qu’il coûte réellement : enregistrez un profil dans le panneau de performance et cherchez de longues tâches de calcul de styles ou de mise en page. Si elles existent, pistes de correction : aplatir l’imbrication à l’endroit le plus profond, et, pour les sections très longues situées sous la première vue, la propriété CSS content-visibility: auto, que web.dev recommande pour différer le rendu des éléments hors écran.

CSS inutilisé et images : deux diagnostics distincts

Pour le CSS, l’onglet de couverture du code des outils de développement indique, pour chaque feuille de style, la part d’octets utilisée au chargement. Lighthouse signale les feuilles dont l’économie potentielle atteint 2 Kio ou plus. Deux réserves à connaître. D’abord, la couverture dépend de ce que vous avez déclenché : un menu déroulant jamais ouvert apparaîtra comme inutilisé. Ensuite, une feuille partagée par tout le site est peut-être utile sur d’autres pages : ne supprimez rien sans avoir parcouru les gabarits concernés.

Pour les images, comparez la taille naturelle à la taille affichée, et vérifiez que les dimensions sont déclarées, faute de quoi le navigateur ne peut pas réserver la place et le CLS monte. Lighthouse 13 regroupe ses audits d’images dans un insight de livraison d’images, mais vous pouvez obtenir l’essentiel avec ce script.

console.table([...document.images].map((img) => ({
  fichier: img.currentSrc.split('/').pop(),
  naturelle: img.naturalWidth + 'x' + img.naturalHeight,
  affichee: img.clientWidth + 'x' + img.clientHeight,
  chargement: img.loading,
  dimensionsDeclarees: img.hasAttribute('width') && img.hasAttribute('height'),
})));

• Une image naturelle largement plus grande que l’image affichée signale un fichier surdimensionné à régénérer.
• Une image sans width ni height est une source probable de décalage de mise en page.
• Une image au chargement différé (loading="lazy") qui est aussi l’élément du LCP retarde l’affichage principal : donnez-lui plutôt l’attribut fetchpriority="high".
• Une image générée dans un format lourd peut être convertie en un format moderne plus compact avant l’import dans la médiathèque.

Pour savoir ce qui retarde le LCP, l’insight de phases du LCP de Lighthouse 13 découpe le délai en étapes (attente du serveur, découverte de la ressource, téléchargement, rendu) : corrigez l’étape la plus longue, pas la première venue.

Un score de performance mesure une page, pas un outil : sans page témoin, vous ne savez pas si c’est l’IA, le thème ou l’hébergement que vous accusez.

Quand ne pas optimiser

N’optimisez pas un DOM qui ne ralentit rien : l’insight ne signale rien tant que les recalculs restent brefs, et aplatir des conteneurs à la main peut casser des réglages d’espacement ou de responsive du constructeur pour un gain invisible. Ne comparez pas non plus des pages de contenu différent. Méfiez-vous enfin des résultats d’une seule exécution et de ceux obtenus sur une machine de développement puissante : ils ne représentent pas le téléphone moyen de vos visiteurs.

Si le site a déjà des données de terrain bonnes sur les trois indicateurs, une mesure de laboratoire médiocre n’est pas une urgence : vérifiez d’abord ce qu’elle reflète. Et si le client n’a aucune donnée de terrain, dites-le dans le rapport plutôt que d’extrapoler.

Conclusion

La mesure tient en quatre gestes : une page témoin, cinq exécutions par page avec comparaison des médianes, trois scripts de console pour le DOM, les images et l’imbrication, puis un profil de performance pour confirmer qu’un écart de structure coûte réellement du temps. Ce protocole ne dépend d’aucun outil de génération précis, et il vous évite de présenter comme un fait ce qui n’est qu’une impression. Les seuils à retenir sont ceux de web.dev sur les Core Web Vitals, et la définition actuelle du critère sur le DOM se trouve dans la documentation Chrome de l’insight sur la taille du DOM. La suite de la série aborde ce qui quitte le site quand on utilise ces assistants.