Consultant web performance back-end

Le TTFB, plafond de verre de la performance

Le Time To First Byte fixe le plancher de toute la chaîne de rendu. Le navigateur ne peut rien commencer tant que le serveur n'a pas répondu. Un TTFB de 800 ms signifie que même avec un front-end parfaitement optimisé, le LCP ne pourra pas descendre sous les 1.5 à 2 secondes.

C'est un constat que je fais régulièrement en audit : des équipes investissent des semaines sur du lazy loading et de la compression d'images, alors que le vrai goulot est un temps de réponse serveur de 1.2 secondes sur les pages catégories. Tant que le back-end n'est pas traité, les optimisations front-end ont un effet limité.

Les causes habituelles

Les problèmes de performance back-end se ressemblent d'un projet à l'autre. Des requêtes N+1 qui transforment l'affichage d'un catalogue de 50 produits en 200 appels à la base de données. Du cache applicatif configuré mais invalidé trop souvent, ou pas du tout. Des appels synchrones à des API tierces — ERP, moteur de recherche, service de stock — qui bloquent le rendu tant qu'ils n'ont pas répondu.

L'instrumentation est le point de départ. Sans visibilité sur ce qui se passe à l'intérieur d'une requête, on devine. Dynatrace, Datadog, NewRelic — l'outil importe peu, ce qui compte c'est de pouvoir tracer une requête HTTP de bout en bout et de voir exactement où le temps est consommé. Sur un checkout e-commerce, la différence entre "le serveur met 8 secondes" et "le serveur met 8 secondes dont 5 à attendre la réponse de l'ERP" change complètement l'approche.

Cache et stratégie d'invalidation

Le cache est probablement le levier le plus puissant et le plus sous-utilisé en back-end. Un page cache bien configuré peut diviser le TTFB par 10 sur les pages à forte audience. Mais la complexité est dans l'invalidation — quand un prix change, quand un produit passe en rupture, quand une promotion démarre.

La plupart des implémentations que je vois sont soit trop agressives (cache de 5 minutes qui sert des prix obsolètes), soit trop conservatrices (invalidation globale à chaque modification, ce qui revient à ne pas avoir de cache). Une stratégie efficace est granulaire — elle invalide précisément ce qui a changé, pas tout le catalogue.

Performance et coûts d'infrastructure

Un back-end qui consomme moins de CPU par requête a besoin de moins de serveurs pour absorber le même trafic. Sur des architectures cloud facturées à l'usage, l'optimisation du code se traduit directement sur la facture. Des requêtes SQL optimisées, un cache efficace, des appels externes parallélisés — ça se chiffre. Le gain en performance utilisateur est presque un bonus à côté de la réduction de coûts.