Guide d'optimisation des performances

Les performances web ont un impact direct sur l’expérience utilisateur, les taux de conversion et le classement dans les moteurs de recherche. Les pages lentes perdent des visiteurs avant même qu’ils ne voient votre contenu, et chaque seconde d’attente supplémentaire érode la confiance. Voici comment rendre votre site rapide et le garder ainsi.

Ce guide part de la mesure pour aller vers l’extérieur : d’abord définir ce que « rapide » signifie, puis corriger les principaux coupables (images, polices, JavaScript), et enfin pérenniser les gains grâce au cache et à la surveillance.

Les Core Web Vitals

Les Core Web Vitals de Google, à savoir Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS), fournissent des repères mesurables de l’expérience utilisateur. Visez un LCP inférieur à 2,5 secondes, un INP inférieur à 200 millisecondes et un CLS inférieur à 0,1. L’INP a remplacé le First Input Delay (FID) parmi les Core Web Vitals en mars 2024, et c’est un indicateur bien plus exigeant : le FID ne mesurait que le délai avant le traitement de la première interaction, alors que l’INP examine la latence des interactions sur l’ensemble de la visite.

Les seuils sont évalués au 75e percentile des chargements de page, séparément pour le mobile et le desktop. Ce détail compte. Une page rapide sur votre ordinateur de développement, connecté au Wi-Fi du bureau, peut tout de même échouer si un quart de vos vrais visiteurs utilisent des téléphones Android de milieu de gamme sur un réseau saturé.

Ce que chaque indicateur vous dit vraiment

Le LCP mesure le moment où la plus grande image ou le plus grand bloc de texte de la zone visible a fini de s’afficher. Il s’agit généralement d’une image hero, d’un titre ou d’un long paragraphe. Un mauvais LCP s’explique le plus souvent par une réponse serveur lente, du CSS et du JavaScript bloquant le rendu, ou une image hero que le navigateur découvre trop tard.
L’INP mesure la rapidité avec laquelle la page réagit visuellement après un clic, un toucher ou une pression de touche. Un mauvais INP signifie presque toujours que le thread principal est occupé : longues tâches JavaScript, hydratation lourde ou gestionnaires d’événements coûteux.
Le CLS mesure les déplacements inattendus du contenu visible. Les coupables habituels sont les images et contenus intégrés sans dimensions, les polices web qui se substituent avec des métriques différentes, et les bandeaux ou publicités injectés au-dessus du contenu existant.

Données de laboratoire et données de terrain

Les outils de laboratoire comme Lighthouse exécutent un unique chargement synthétique sur un appareil simulé. Ils sont excellents pour le débogage et pour détecter les régressions dans une pull request, mais ils ne peuvent pas mesurer directement l’INP, puisque personne n’interagit avec la page. Ce sont les données de terrain, collectées auprès de vrais visiteurs, qui servent réellement de base à l’évaluation des Core Web Vitals. Utilisez les données de laboratoire pour trouver les problèmes et les données de terrain pour décider lesquels comptent.

Commencer par le serveur

Aucun réglage côté front-end ne peut masquer un premier octet lent. Le Time to First Byte (TTFB) ne fait pas partie des Core Web Vitals, mais il précède directement le LCP : le navigateur ne peut pas commencer le rendu tant que le HTML n’est pas arrivé.

Prérendez tout ce que vous pouvez. La génération statique sert le HTML directement depuis un CDN, sans aller-retour vers l’origine. Pour les pages qui ont réellement besoin de données propres à chaque requête, mettez en cache le rendu en edge avec une courte durée de vie plutôt que de tout recalculer à chaque requête.
Diffusez le HTML en streaming. Lorsque le rendu serveur est inévitable, envoyez tôt l’en-tête du document pour que le navigateur puisse commencer à récupérer le CSS et les polices pendant que le corps est encore en cours de génération.
Évitez les chaînes de redirections. Chaque redirection représente un aller-retour complet avant le chargement du moindre contenu. Pointez directement vers les URL canoniques et gardez des règles cohérentes pour le slash final et le www.
Activez les protocoles et la compression modernes. HTTP/2 ou HTTP/3, ainsi qu’une compression Brotli ou gzip pour les ressources textuelles, sont le minimum attendu de tout hébergeur ou CDN sérieux.

Optimisation des images

Les images restent le premier contributeur au poids des pages sur la plupart des sites. Utilisez des formats modernes comme WebP et AVIF avec des solutions de repli adaptées. Implémentez des images responsives avec srcset pour servir des images de taille appropriée à chaque appareil. Chargez en différé les images situées sous la ligne de flottaison grâce à l’attribut natif loading="lazy".

Une image responsive bien construite ressemble à ceci :

<img
  src="/images/dashboard-800.webp"
  srcset="/images/dashboard-400.webp 400w,
          /images/dashboard-800.webp 800w,
          /images/dashboard-1600.webp 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  width="1600"
  height="900"
  alt="Revenue dashboard showing monthly trends"
  loading="lazy"
  decoding="async"
/>

Les attributs width et height permettent au navigateur de réserver le bon ratio d’aspect avant le téléchargement du fichier, ce qui élimine une source courante de décalage de mise en page. L’attribut sizes indique au navigateur la largeur d’affichage de l’image, pour qu’il choisisse le plus petit candidat adapté dans srcset.

Traiter l’image LCP à part

Le chargement différé est un mauvais choix pour l’image la plus susceptible d’être votre élément LCP. Une image hero en lazy loading attend la mise en page avant de commencer à se télécharger, ce qui retarde directement le LCP. Pour l’image hero :

Retirez loading="lazy".
Ajoutez fetchpriority="high" pour que le navigateur la récupère avant les autres images.
Assurez-vous qu’elle est découvrable dans le HTML initial, et non définie comme arrière-plan CSS ou injectée par JavaScript.
Si elle doit provenir du CSS ou d’un composant chargé tardivement, ajoutez un <link rel="preload" as="image"> dans l’en-tête du document.

Si vous utilisez Astro, les composants intégrés <Image /> et <Picture /> génèrent au moment du build les formats optimisés, les dimensions et les valeurs de srcset, ce qui supprime l’essentiel du travail manuel.

Des polices sans flash

Les polices web affectent surtout le LCP et le CLS. Une police qui bloque le rendu du texte retarde le LCP lorsque l’élément LCP est du texte, et une police de repli remplacée par une police web aux métriques différentes provoque un décalage de mise en page.

Auto-hébergez vos polices pour qu’elles proviennent de la même origine et de la même connexion que votre page, ce qui évite une résolution DNS et une négociation TLS supplémentaires.
Créez des sous-ensembles limités aux jeux de caractères que vous utilisez réellement. Un sous-ensemble latin ne pèse qu’une fraction d’un fichier multilingue complet.
Utilisez exclusivement WOFF2 ; tous les navigateurs modernes le prennent en charge.
Préchargez uniquement le ou les deux fichiers de police utilisés au-dessus de la ligne de flottaison.
Alignez les métriques de la police de repli avec les descripteurs size-adjust, ascent-override et descent-override, pour que la substitution soit quasiment invisible.

@font-face {
  font-family: "Inter Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
}

body {
  font-family: "Inter", "Inter Fallback", system-ui, sans-serif;
}

Les valeurs exactes dépendent du couple de polices ; plusieurs outils open source peuvent les calculer pour vous.

Le code splitting

N’envoyez que le JavaScript dont une page a réellement besoin. Des frameworks comme Astro s’en chargent automatiquement grâce à l’architecture en îlots, mais pour les applications fortement orientées client, les imports dynamiques et le découpage par route réduisent considérablement la taille des bundles initiaux.

Les octets ne représentent que la moitié du coût. Le JavaScript doit aussi être analysé, compilé et exécuté sur le thread principal, et sur un téléphone de milieu de gamme ce travail peut prendre plusieurs fois plus de temps que sur une machine de développeur. C’est pourquoi les gros bundles se traduisent par un mauvais INP, et pas seulement par des chargements lents.

Charger le code interactif au moment où il est nécessaire

Différez tout ce qui n’est pas requis pour la première interaction. Une bibliothèque de graphiques utilisée dans une modale n’a pas sa place dans le bundle initial :

const openReport = async () => {
  const { renderChart } = await import("./charts/revenue-chart");
  renderChart(document.querySelector("#report")!);
};

button.addEventListener("click", openReport);

Dans Astro, choisissez délibérément la directive d’hydratation. client:load hydrate immédiatement, client:idle attend que le navigateur soit inactif et client:visible attend que le composant entre dans la zone visible. Un widget de commentaires en bas d’un article n’a presque jamais besoin de client:load.

Auditer vos dépendances

Lancez un analyseur de bundle sur chaque build de production et cherchez les suspects habituels : une bibliothèque utilitaire complète importée pour une seule fonction, des bibliothèques de dates qui embarquent toutes les locales, plusieurs copies du même paquet dans des versions différentes, et des polyfills pour des navigateurs que vous ne prenez plus en charge. Remplacer une seule dépendance lourde fait souvent gagner davantage que des semaines de micro-optimisation.

Libérer le thread principal

Les problèmes d’INP sont des problèmes de thread principal. Toute tâche qui dure plus de 50 millisecondes est une tâche longue, et pendant son exécution le navigateur ne peut pas réagir aux saisies.

Découpez les tâches longues. Fractionnez les grandes boucles et les routines d’initialisation en morceaux, et rendez la main au navigateur entre chacun. scheduler.yield() est disponible dans les navigateurs basés sur Chromium et dans Firefox ; détectez sa prise en charge et rabattez-vous sur setTimeout ailleurs.
Faites moins de choses dans les gestionnaires d’événements. Mettez à jour l’interface immédiatement, puis différez les appels d’analytics, la persistance et le travail non visible.
Évitez le layout thrashing. Lire des propriétés de mise en page comme offsetHeight après avoir modifié des styles force un calcul de mise en page synchrone. Regroupez les lectures avant les écritures.
Sortez les calculs lourds du thread principal. L’analyse de gros volumes JSON, le filtrage de grands jeux de données ou le traitement d’images peuvent s’exécuter dans un Web Worker.
Surveillez les scripts tiers. Les gestionnaires de balises, les widgets de chat et les outils d’A/B testing sont souvent à l’origine des pires tâches longues d’une page. Chargez-les une fois la page interactive, et demandez-vous si chacun justifie encore son coût.

async function processInChunks<T>(items: T[], work: (item: T) => void) {
  for (let i = 0; i < items.length; i++) {
    work(items[i]!);
    if (i % 100 === 0) {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

CSS et rendu

Les feuilles de style placées dans l’en-tête du document bloquent le rendu par conception. C’est généralement le bon comportement, car vous ne voulez pas d’un flash de contenu non stylé, mais cela signifie que la taille du CSS affecte directement le LCP.

Gardez un CSS critique léger. Les frameworks utility-first qui ne génèrent que les classes utilisées sont utiles ici.
Évitez @import dans les fichiers CSS, qui crée des chaînes de requêtes séquentielles.
Utilisez content-visibility: auto sur les longues sections situées sous la ligne de flottaison, pour que le navigateur puisse différer leur rendu jusqu’à ce qu’elles approchent de la zone visible. Associez-le à contain-intrinsic-size pour éviter les sauts de barre de défilement.
Animez transform et opacity plutôt que des propriétés comme top, width ou height, qui déclenchent un recalcul de mise en page à chaque image.

Stratégies de cache

Mettez en place une approche de cache en couches : cache navigateur pour les ressources statiques avec des en-têtes max-age longs, cache CDN en edge pour le contenu distribué géographiquement, et cache applicatif pour les données calculées ou issues de la base de données. Utilisez le cache-busting avec des empreintes de contenu pour les ressources immuables.

Un ensemble d’en-têtes pragmatique couvre la plupart des sites :

# Ressources de build avec empreinte : ne changent jamais, cache permanent
Cache-Control: public, max-age=31536000, immutable

# HTML : toujours revalider pour que les déploiements soient visibles immédiatement
Cache-Control: public, max-age=0, must-revalidate

# Réponses d'API semi-dynamiques : servir la version périmée pendant le rafraîchissement
Cache-Control: public, max-age=60, stale-while-revalidate=300

La règle essentielle : seuls les fichiers dont le nom contient une empreinte de contenu reçoivent une longue durée de vie. Si un nom de fichier peut être réutilisé pour un contenu différent, un max-age long bloquera les utilisateurs sur d’anciennes versions après un déploiement.

Cache en edge et cache applicatif

Au niveau du CDN, mettez en cache le HTML pour les visiteurs anonymes chaque fois que le contenu le permet, et utilisez des surrogate keys ou une purge par tags si votre fournisseur le propose, pour qu’une mise à jour de contenu invalide exactement les pages concernées. Au niveau applicatif, mettez en cache les requêtes coûteuses et les fragments calculés, et soyez explicite sur l’invalidation. Un cache sans stratégie d’invalidation claire finit par servir des données erronées, ce qui est pire que de servir des données lentement.

Accélérer la page suivante

Une fois la page courante rapide, faites en sorte que la navigation paraisse instantanée. Préchargez les pages suivantes probables au survol ou lorsque les liens entrent dans la zone visible ; Astro inclut une fonctionnalité de prefetch configurable précisément pour cela. Assurez-vous que vos pages sont éligibles au back/forward cache du navigateur en évitant les gestionnaires unload et l’en-tête Cache-Control: no-store sur le HTML qui n’en a pas besoin.

Définir un budget de performance

Sans garde-fous, les corrections régressent. Un budget de performance transforme « garder le site rapide » en chiffres sur lesquels un build peut échouer :

Volume maximal de JavaScript envoyé par route, compressé.
Poids total maximal des images sur les pages d’atterrissage clés.
Score de performance Lighthouse minimal sur des pages représentatives.
Objectifs de terrain : LCP, INP et CLS au 75e percentile dans les seuils « bons ».

Vérifiez les budgets basés sur les données de laboratoire à chaque modification, dans votre contrôle local ou en CI, et examinez les objectifs de terrain à intervalles réguliers. Lorsqu’un budget est dépassé, traitez-le comme un test en échec : corrigez la régression, ou prenez la décision explicite et documentée de relever la limite.

Surveillance

L’optimisation des performances n’est pas une tâche ponctuelle. Mettez en place une surveillance des utilisateurs réels (RUM) pour suivre les indicateurs de performance issus de vraies sessions. Les services RUM commerciaux ou la bibliothèque JavaScript open source web-vitals offrent une visibilité continue sur la façon dont les vrais utilisateurs vivent votre site.

Collecter vous-même des données de terrain ne demande que quelques lignes :

import { onCLS, onINP, onLCP } from "web-vitals";

function send(metric: { name: string; value: number; id: string }) {
  navigator.sendBeacon("/api/vitals", JSON.stringify(metric));
}

onCLS(send);
onINP(send);
onLCP(send);

Segmentez les données par template de page, type d’appareil et type de connexion lorsque c’est possible. Une moyenne sur l’ensemble du site masque le template qui échoue pour la majorité de ses visiteurs. La version « attribution » de la bibliothèque peut aussi indiquer quel élément était le candidat LCP et quelle interaction a causé un INP lent, ce qui transforme un vague « le site est lent » en une correction précise.

Pour conclure

Les sites rapides sont rarement le fruit d’une seule astuce ingénieuse. Ils découlent d’une courte liste d’habitudes appliquées avec constance : mesurer avec des données d’utilisateurs réels, servir le HTML rapidement, prioriser la ressource LCP, envoyer moins de JavaScript, libérer le thread principal, mettre en cache de façon réfléchie et protéger les résultats par un budget. Commencez par l’indicateur le plus éloigné de son seuil sur vos pages les plus importantes, corrigez la cause principale, mesurez à nouveau, et recommencez.