Frontend — Performance¶

Statut¶

CURRENT / CONTRACT pour les principes de performance Frontend.

Cette page ne prétend pas décrire toutes les optimisations actuellement actives. Elle définit surtout les règles qu’un mainteneur doit respecter pour améliorer les performances sans déplacer de logique métier dans le Frontend.

Principe¶

Le Frontend doit être rapide parce qu’il lit des représentations déjà préparées.

La bonne direction est :

traitement métier en amont
    ↓
projection stable
    ↓
Reader / cache de lecture
    ↓
Adapter
    ↓
rendu Frontend simple

La mauvaise direction consiste à compenser une projection insuffisante par du recalcul dans le thème ou par des requêtes SQL lourdes exécutées à chaque page.

Objectifs¶

Les optimisations Frontend doivent viser :

un temps de réponse prévisible ;
peu de travail dans les templates ;
des lectures stables et ciblées ;
une navigation rapide sur toutes les pages ;
une charge maîtrisée sur WordPress et MariaDB ;
une meilleure expérience utilisateur sans changement de sens métier.

Ce qui appartient au Frontend¶

Le Frontend peut optimiser :

le rendu HTML ;
la quantité de markup ;
le chargement CSS et JavaScript ;
les images et médias ;
le cache de présentation lorsqu’il est clairement dérivé ;
l’ordre de chargement des ressources ;
les composants visuels ;
les appels de lecture déjà autorisés.

Il ne doit pas optimiser en réimplémentant :

la résolution d’identité ;
les règles verticales ;
la construction des projections ;
la classification ;
la qualité métier ;
les règles de navigation canoniques.

Le header s’affiche sur un grand nombre de pages. Il ne doit donc jamais reconstruire la navigation depuis les offres à chaque requête.

La source canonique de l’architecture de navigation est :

plugins/ccx-feeds-industrial/includes/application/navigation-architecture.php

Le Frontend doit consommer une représentation de lecture adaptée, éventuellement cachée, plutôt que recalculer l’arbre.

Un cache de navigation peut accélérer la lecture, mais il reste dérivé : il ne devient pas la source de vérité.

Requêtes et données¶

Une optimisation sûre commence par mesurer ce qui est réellement lu.

Avant d’ajouter une nouvelle requête :

vérifier si la donnée existe déjà dans la projection ;
vérifier si le Reader peut l’exposer proprement ;
vérifier si une projection spécialisée est plus appropriée ;
éviter les jointures métier improvisées dans le thème ;
vérifier le volume et la fréquence de lecture.

Une requête rapide mais placée dans la mauvaise couche reste une dette d’architecture.

Caches¶

Un cache Frontend est acceptable lorsqu’il accélère une donnée dérivée sans changer son sens.

Il doit être :

invalidable ;
reconstruisible ;
limité à une responsabilité claire ;
indépendant de la vérité métier ;
observable lorsqu’il masque temporairement une donnée fraîche.

Lors d’un diagnostic, toujours comparer :

projection persistée
vs
valeur Reader
vs
valeur cache
vs
HTML rendu

Sans cette comparaison, un cache obsolète peut être confondu avec un défaut du Domain Core.

Images et médias¶

Les optimisations média doivent préserver la décision déjà prise par les couches amont.

Le Frontend peut agir sur :

tailles d’affichage ;
srcset ;
lazy loading ;
dimensions intrinsèques ;
format et priorité de chargement lorsque le pipeline média le permet.

Il ne doit pas :

remplacer arbitrairement une image jugée « meilleure » ;
vider une image en cas de doute ;
recalculer Media Quality ;
choisir un autre asset par une heuristique locale au template.

Media Quality reste audit-first et séparé du rendu.

CSS et JavaScript¶

Une amélioration de performance visuelle ne doit pas casser les frontières fonctionnelles.

Avant de supprimer ou différer une ressource :

identifier les composants qui en dépendent ;
tester desktop et mobile ;
tester navigation, filtres et overlays ;
vérifier les états sticky/fixed ;
vérifier les interactions clavier et focus ;
vérifier qu’aucun comportement n’est déplacé vers une dépendance implicite.

Mesurer avant d’optimiser¶

Une optimisation doit partir d’une preuve.

Mesurer selon le cas :

temps serveur ;
nombre de requêtes ;
poids HTML ;
poids CSS/JS ;
poids image ;
cache hit/miss ;
temps de génération du header ;
temps de lecture d’une projection ;
comportement sur plusieurs types de pages.

Éviter les optimisations « au feeling » qui augmentent la complexité sans corriger le vrai goulot.

Diagnostic d’une page lente¶

Procéder dans cet ordre :

confirmer que le problème est reproductible ;
distinguer temps serveur et temps navigateur ;
identifier les lectures et appels déclenchés ;
vérifier si le template reconstruit une donnée déjà projetée ;
vérifier les caches ;
vérifier les assets ;
corriger la première cause démontrée ;
mesurer à nouveau.

Ne pas commencer par modifier le Domain Core parce qu’une page est lente.

Anti-patterns¶

Éviter :

SQL direct dans les templates ;
lecture de tables Stage depuis le Frontend ;
reconstruction de navigation dans le header ;
N+1 évitable sur des projections ;
recalcul métier en JavaScript ;
cache sans stratégie d’invalidation ;
duplication de mêmes données dans plusieurs caches sans contrat clair ;
optimisation qui transforme unknown, ambiguous ou conflict en valeur supposée pour simplifier le rendu.

Intervention sûre¶

Pour une optimisation importante :

capturer une baseline ;
définir la métrique visée ;
modifier une responsabilité à la fois ;
vérifier l’absence de changement fonctionnel ;
tester plusieurs pages et viewport ;
comparer avant/après ;
documenter tout nouveau cache ou contrat de lecture.

Invariants¶

La performance ne justifie jamais de contourner les frontières métier.
Le Frontend lit des projections ; il ne les reconstruit pas.
Les caches restent dérivés et reconstruisibles.
Le header ne devient pas un moteur de catalogue.
Une optimisation doit être mesurable et réversible autant que possible.
Une amélioration de vitesse ne doit pas changer le sens des données.