Novembre 2023. La cérémonie des Latin Grammys vient de commencer et j’ouvre les DevTools sur le site officiel. LCP qui flirte avec les 8 secondes, des blocs entiers qui apparaissent après 5 bonnes secondes de page blanche, un fil d’exécution complètement saturé. Le budget et les compétences ne manquaient pas. La performance d’un site événementiel ne se joue pas sur la puissance du serveur. Elle se joue sur le nombre de dépendances externes bloquantes qu’on a laissé s’inviter dans le <head>.
Pourquoi le TTFB n’a jamais été le vrai coupable
Le TTFB du site tournait autour de 600 ms, même sous charge. Largement acceptable. Le vrai problème se situait après ce premier octet : 6 à 7 secondes de plus avant d’afficher quoi que ce soit d’utile.
Dans la cascade réseau, l’enchaînement est limpide. Une dizaine de scripts tiers se chargent en parallèle, mais tous dépendent d’un tag manager qui lui-même attend une bannière de consentement cookie hébergée sur un CDN tiers. Le navigateur ne commence à parser le contenu principal qu’après avoir résolu cette cascade. Le serveur n’a rien planté ; le render-blocking a tout fait.
⚠️ Attention : un bon TTFB peut parfaitement cacher un désastre de rendu. Le serveur qui répond vite n’est qu’une moitié de la mesure. Le delta TTFB → LCP raconte le reste.
Des widgets sociaux qui coûtent plus cher qu’ils ne rapportent
Six iframes tierces rien que pour les boutons de partage. Twitter, Facebook, Instagram, TikTok, un player Spotify intégré en fond, et un widget de live tweet. Chacune charge son propre bundle JavaScript, ses propres polices, et pour certaines, une vidéo en autoplay silencieux.
Le pire, c’est que ces widgets n’apportent quasiment rien en engagement. Personne ne partage la page d’accueil officielle pendant la cérémonie ; les gens partagent les vidéos des gagnants sur les réseaux sociaux natifs. On alourdit la page de 800 Ko de JavaScript parsé et exécuté pendant la phase critique de chargement, pour un taux de clic sur « Partager » probablement inférieur à 0,1 %.
Un simple <details> avec des liens href vers les partages natifs (via https://twitter.com/intent/tweet?...) suffit. Zéro JavaScript tiers, zéro iframe, et une expérience qui fonctionne même si le réseau est dégradé. Un compteur de partages, si on y tient vraiment, se charge en idle après l’event load, sans bloquer le moindre pixel.
L’autoplay vidéo qui assassine le LCP
La page d’accueil affichait une vidéo hero en fond, en autoplay, avec un attribut poster défini mais une source pointant sur un fichier .mp4 de 3,2 Mo. Le navigateur a dû télécharger suffisamment de fragments vidéo avant de pouvoir afficher la première frame, ce qui a retardé le Largest Contentful Paint de plusieurs secondes. Pire : la balise <video> n’était pas configurée avec preload="metadata" et laissait le navigateur décider, souvent en téléchargeant agressivement le début du flux.
Dans une situation de pic de trafic, ce genre de choix technique se paie cash. Le LCP mesuré via les données de terrain (CrUX) ce soir-là devait être proche de 8 secondes, et chaque seconde supplémentaire réduisait le taux de conversion sur les pages billetterie et produits dérivés. L’ironie, c’est que la vidéo ne contenait pas d’information critique : un simple fond dégradé animé en CSS aurait donné la même ambiance visuelle pour moins de 2 Ko.
Le correctif est simple, mais encore faut-il l’avoir testé en condition de stress. Utiliser <video> uniquement pour des contenus informatifs, avec preload="none", playsinline, et surtout remplacer l’élément par une image statique (ou un CSS animé) sur mobile en utilisant une media query dans le <picture> parent ou un petit script de détection. Si une vidéo de fond est non négociable, on la sert via un service spécialisé qui stream un fragment minuscule et laisse le LCP se caler sur autre chose.
💡 Conseil : un LCP mesuré sans throttling réseau (Fast 3G ou Slow 4G) ni cache désactivé est un LCP de plaquette commerciale. Le labo ne ment pas quand on lui demande la vérité : une vidéo qui bloque en condition dégradée bloquera aussi un soir d’affluence.
La fausse bonne idée du carousel de gagnants en JS
Au milieu de la page, un carousel des vainqueurs construit en jQuery avec trois plugins et un CSS externe. TTI au-dessus de 10 secondes. Le carousel restait inerte tant que toute la chaîne de dépendances n’était pas résolue, et un visiteur qui scrollait immédiatement tombait sur un trou blanc. Un scroll-snap CSS et des images en lazy aurait fait le job pour zéro JS bloquant.
Ce que l’équipe aurait dû poser : un budget de performance par page
Avant d’écrire une ligne de code, une équipe événementielle devrait définir un budget de performance. Pas un chiffre au doigt mouillé, mais une enveloppe stricte de kilo-octets décomposée par type de ressource. Par exemple : 150 Ko de JavaScript total, dont moins de 50 Ko de tiers, et un LCP fixé sous 2,5 secondes en condition de laboratoire (Slow 4G). Toute fonctionnalité excédant ce budget est soit supprimée, soit différée après le load.
Sur un site comme celui des Latin Grammys, un budget mal tenu explose vite. Une seule intégration vidéo et trois widgets sociaux peuvent dépasser 500 Ko de JS compressé. Sans budget, personne ne dit non. Avec un budget, la discussion change : « Ce widget de live tweet pèse 120 Ko, il nous fait dépasser l’enveloppe. Si on le garde, qu’est-ce qu’on enlève ? » Ce débat n’a jamais eu lieu ce soir de novembre, et ça s’est vu sur la cascade réseau.
Les outils modernes aident à tenir ce budget. Un bundler bien configuré ou un analyseur de build intégré à un environnement comme Cursor ou un assistant Claude Code donne le poids de chaque chunk en regard de la cible, en continu. Sans ce garde-fou, chaque service métier pousse son petit bout de code et personne ne voit la page enfler.
Appliquez ces leçons à vos propres pics de trafic
Que vous gériez un e-commerce pour le Black Friday, une billetterie pour un festival ou un landing produit pour un lancement, les erreurs du site des Latin Grammys 2023 sont universelles. Premier réflexe : auditer chaque dépendance tierce et trancher si elle a quoi que ce soit à faire avant le LCP. Une régie publicitaire qui charge un script de tracking avant le contenu, c’est quelques centaines de millisecondes offertes à un partenaire au prix de votre visibilité organique.
Segmentez ensuite votre cache HTTP. Une page d’accueil événementielle peut être servie entièrement depuis un CDN avec un TTL court, mais les ressources statiques (JS, CSS, images) doivent être versionnées et servies avec max-age long. Cela réduit la pression sur l’origine et évite les goulots d’étranglement côté réseau. Sur le site des Grammys, plusieurs fichiers JS tiers n’étaient pas cache-friendly, probablement pour garder de la fraîcheur sur les widgets. Le trade-off est connu : on accepte un léger différé de mise à jour contre une page qui se charge en moins de 2 secondes.
Reste le test avec throttling réseau et CPU ralenti (6x slowdown dans Chrome DevTools). Le labo standard Lighthouse ne simule pas un téléphone milieu de gamme un soir de pic. Si le LCP dépasse 4 secondes dans ces conditions, les utilisateurs réels passeront la barre des 6 secondes. C’est exactement ce que la cascade des Latin Grammys a montré : un laboratoire acceptable, un terrain désastreux.
Questions fréquentes
Les sites événementiels doivent-ils sacrifier le design pour la performance ? Non. La contrainte de performance oblige à mieux prioriser, pas à s’appauvrir visuellement. On peut obtenir une ambiance forte avec des dégradés CSS, des typographies système et des images optimisées en WebP sans dépasser 200 Ko de poids total. Le design est une question de hiérarchie, pas de mégaoctets.
Est-ce que le lazy-loading des images suffit à sauver le LCP ?
Seulement pour les images sous la ligne de flottaison. Si votre plus grand élément visible (souvent une image hero) est chargé en lazy, vous décalez le LCP encore plus loin. L’image candidate au LCP doit être en eager (valeur par défaut sans loading="lazy") et, si possible, préchargée via un link rel="preload".
Comment tester la charge d’un site avant un pic de trafic sans utilisateurs réels ? Des outils comme k6 ou Siege permettent de simuler des centaines de connexions simultanées sur la page d’accueil, avec un relevé de LCP via Lighthouse en mode throttling. Certains services injectent ces tests dans la CI. Un labo sans stress concurrentiel ne dit rien du comportement sous affluence ; un temps de chargement isolé est une mesure de confort.
