Aller au contenu
FR / EN
Test GEO
Français English

Guide technique

Performance web : le guide, du serveur au navigateur

Par · Dernière mise à jour : 10 septembre 2026 · Sources Google et web.dev consultées le 8 septembre 2026

La performance web concerne les conditions qui permettent à une page d'arriver vite, de s'afficher sans bouger et de répondre sans délai, sur l'appareil et le réseau réels de chaque visiteur. Ce guide reprend les contrôles de nos optimisations Core Web Vitals, du serveur au navigateur, avec le correctif pour chacun, appliqué sur ce site ou pas encore.

Chaque section sépare ce que Google documente, source à l'appui, de ce que nous recommandons.

Tous les problèmes de performance ne se valent pas

Un rapport d'outil liste trente audits à plat. Nous classons chaque problème sur trois niveaux ; chaque section indique le sien.

  • Bloquant : la page est lente pour la majorité des visiteurs réels. Exemples : un TTFB de plusieurs secondes sur chaque page parce que rien n'est mis en cache ; une image de plusieurs mégaoctets en tête de page, chargée en différé.
  • Important : une métrique de terrain est hors seuil sur un gabarit fréquenté. Exemples : des polices qui font sauter le texte à l'affichage ; un script tiers qui bloque le fil principal pendant chaque interaction.
  • Optimisation : les seuils sont tenus, le confort peut progresser. Exemples : une feuille de style entière chargée pour une page qui en utilise un dixième ; un format d'image plus léger disponible.

Un seul bloquant passe avant vingt optimisations.

1. Mesurer : laboratoire et terrain impact : important

Ce que Google documente. Trois métriques Core Web Vitals : le LCP « dans les 2,5 secondes », l'INP « de 200 millisecondes ou moins », le CLS « de 0,1 ou moins ». Le seuil à viser est « le 75e centile des chargements de page, séparé entre mobile et ordinateur ». Chrome User Experience Report, PageSpeed Insights et Search Console mesurent les trois sur les vrais visiteurs ; « les outils comme Lighthouse, qui chargent les pages dans un environnement simulé sans utilisateur, ne peuvent pas mesurer l'INP » (Web Vitals).

Ce que nous recommandons. Commencer par le terrain : le rapport Core Web Vitals de Search Console dit quels gabarits sont hors seuil chez vos visiteurs. Le laboratoire sert ensuite à trouver la cause. Ce que mesurent LCP, CLS et INP est dans notre guide des Core Web Vitals ; ici, une ligne chacun : le LCP est l'affichage du plus grand élément visible, le CLS la stabilité de la page, l'INP le délai de réponse.

Comment le vérifier

Notre test de vitesse lance une analyse Lighthouse d'une page, mobile ou ordinateur, et rapporte le score, les métriques de laboratoire et les audits prioritaires. Il ne rapporte pas les données de terrain : elles exigent assez de visiteurs Chrome et se lisent dans Search Console. Un bon résultat au test ne garantit pas un rapport Search Console au vert.

Comment le corriger

Une procédure : le terrain d'abord, puis le laboratoire sur le bon gabarit, puis une mesure avant et après chaque correctif.

# 1. terrain : Search Console > Core Web Vitals > URL « médiocres » et « à améliorer », par gabarit
# 2. laboratoire, même page, mobile simulé
npx lighthouse https://votre-site.fr/page-lente --preset=perf --form-factor=mobile --output=json --output-path=./avant.json
# 3. après le correctif, même commande vers ./apres.json, et comparer LCP, CLS, TBT

Ce que nous avons fait sur seoforge.fr

Le test de vitesse gratuit habille l'API PageSpeed Insights : il rapporte les métriques de laboratoire et le dit sur la page de résultats. Nos propres métriques de terrain se lisent dans Search Console.

2. Serveur et TTFB impact : bloquant

Ce que Google documente. Le TTFB « est la somme des phases suivantes de la requête : temps de redirection, démarrage du service worker, résolution DNS, connexion et négociation TLS, requête, jusqu'à l'arrivée du premier octet de la réponse ». « Les bonnes valeurs sont de 0,8 seconde ou moins, les mauvaises au-delà de 1,8 seconde ». Le TTFB « n'est pas une métrique Core Web Vitals », mais comme il précède le FCP et le LCP, « il est recommandé que votre serveur réponde vite aux requêtes de navigation » (Time to First Byte).

Ce que nous recommandons. Un TTFB élevé se corrige presque toujours avant le code : une seule redirection avant la page finale, un cache de pages pour les visiteurs anonymes, un hébergement proche des visiteurs. Le TTFB est le plancher du LCP.

Comment le vérifier

En ligne de commande, curl -o /dev/null -s -w "%{time_starttransfer}\n" https://votre-site.fr/ donne le TTFB d'une requête ; répétez sur trois pages. Notre test de vitesse rapporte le temps de réponse serveur parmi ses audits.

Comment le corriger

Un cache de pages devant l'application, et une redirection directe.

# réponse d'une page anonyme : cachable par un cache partagé ou un CDN pendant cinq minutes
Cache-Control: public, s-maxage=300, stale-while-revalidate=60

# une seule redirection, directement vers la forme finale
http://votre-site.fr/  ->  https://votre-site.fr/fr  (301)

Ce que nous avons fait sur seoforge.fr

Les pages publiques sont servies par le cache HTTP applicatif de Symfony, cinq minutes avec revalidation ; le sitemap et le fichier llms.txt sont cachés une heure. La racine fait une seule redirection vers la langue par défaut.

3. Cache HTTP impact : important

Ce que Google documente. Pour les ressources dont l'URL est versionnée, par exemple style.x234dff.css, un Cache-Control: max-age=31536000, parce qu'un changement de contenu change l'URL et invalide de lui-même l'ancienne version ; immutable « comme optimisation supplémentaire ». Pour les URL non versionnées, no-cache impose une revalidation à chaque usage, alors que no-store interdit tout stockage ; ETag et Last-Modified « servent le même objectif : déterminer si le navigateur doit retélécharger un fichier en cache », avec une réponse 304 quand il est inchangé (le cache HTTP).

Ce que nous recommandons. Deux régimes : un an et immutable pour tout fichier dont le nom porte une empreinte de contenu, une durée courte avec revalidation pour le HTML.

Comment le vérifier

curl -sI https://votre-site.fr/assets/css/site-abc123.css | grep -i cache-control, puis la même commande sur une page HTML.

Comment le corriger

Les en-têtes se posent au niveau du serveur web ou de l'application, par famille d'URL.

# nginx : fichiers versionnés, un an, immutables
location ~* ^/assets/.+\.(css|js|woff2|webp|avif|svg)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}
# HTML : court, revalidé
location / {
    add_header Cache-Control "public, max-age=300, must-revalidate";
}

Ce que nous avons fait sur seoforge.fr

Les feuilles de style, scripts, polices et images sont servis sous un nom qui porte l'empreinte de leur contenu, avec public, max-age=31536000, immutable ; le HTML reçoit public, max-age=300, must-revalidate. Les réponses de l'API sont exclues de tout cache partagé.

4. Images impact : bloquant

Ce que Google documente. Le LCP se décompose en TTFB, délai avant chargement de la ressource, durée de chargement et délai de rendu. Pour l'image principale, « ne chargez jamais votre image LCP en différé, cela entraîne toujours un délai de chargement inutile », indiquez sa priorité avec fetchpriority="high", préchargez-la avec link rel="preload" quand elle vient du CSS, servez « la taille d'image optimale » et « un format plus efficace, comme AVIF ou WebP » (optimiser le LCP).

Ce que nous recommandons. Trois largeurs en srcset, un format moderne, width et height partout, le chargement différé sous la ligne de flottaison et jamais sur l'image de tête.

Comment le vérifier

Le test de vitesse liste les audits « Diffusez des images de taille appropriée » et « Diffusez des images aux formats nouvelle génération » avec le gain estimé. Le panneau Performance nomme l'élément LCP ; si sa ressource a loading="lazy", c'est la première correction.

Comment le corriger

Une balise complète pour l'image de tête, une balise différée pour les autres.

<!-- image de tête : prioritaire, jamais différée, dimensions déclarées -->
<img src="/img/hero-1200.webp"
     srcset="/img/hero-480.webp 480w, /img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
     sizes="(max-width: 700px) 100vw, 560px"
     width="1200" height="630" alt="…" fetchpriority="high">

<!-- sous la ligne de flottaison : différée -->
<img src="/img/photo-800.webp" width="800" height="600" alt="…" loading="lazy">

Ce que nous avons fait sur seoforge.fr

Les images d'articles sont servies en WebP en trois largeurs avec srcset et sizes, dimensions déclarées, fetchpriority="high" sur l'image de tête et chargement différé sur les autres. La recommandation AVIF n'est pas encore appliquée sur ce site : nos images restent en WebP.

5. Polices impact : important

Ce que Google documente. « N'utilisez que le WOFF2 et oubliez tout le reste » : il compresse environ 30 % mieux que le WOFF. « Retirer les glyphes inutilisés peut réduire nettement la taille d'un fichier de police ». Le préchargement « doit être utilisé avec précaution », mais il est efficace quand la police est déclarée dans une feuille de style externe, découverte tard. font-display: optional évite les sauts de mise en page, swap affiche le texte tout de suite au prix d'un basculement visible (bonnes pratiques pour les polices).

Ce que nous recommandons. Deux fichiers au plus, variables, en WOFF2, hébergés sur votre domaine, préchargés, limités aux glyphes latins. Avec swap, la police de repli doit être calibrée sur la police finale, sinon le texte saute au basculement.

Comment le vérifier

Dans le panneau Réseau, filtrez sur « font » : nombre, format et poids se lisent en une ligne. Un CLS de terrain sans image en cause est souvent une police.

Comment le corriger

Une déclaration avec sous-ensemble et une police de repli calibrée.

<link rel="preload" href="/fonts/sora-var.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: 'Sora'; font-weight: 600 700; font-display: swap;
  src: url('/fonts/sora-var.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0152-0153, U+2000-206F, U+20AC;
}
@font-face {
  font-family: 'Sora Fallback'; src: local('Arial');
  size-adjust: 112%; ascent-override: 92%; descent-override: 24%; line-gap-override: 0%;
}
h1 { font-family: 'Sora', 'Sora Fallback', system-ui, sans-serif; }

Ce que nous avons fait sur seoforge.fr

Deux polices variables en WOFF2, hébergées sur le site, préchargées depuis l'en-tête HTML, limitées aux glyphes latins par unicode-range, en font-display: swap avec une police de repli calibrée par size-adjust et les métriques verticales, pour que le basculement ne déplace pas le texte.

6. JavaScript et scripts tiers impact : important

Ce que Google documente. Pour l'INP, « les sites doivent viser 200 millisecondes ou moins ». Faire le minimum dans les gestionnaires d'événements, découper la logique longue en tâches séparées, céder la main : « setTimeout est une façon de découper les tâches, parce que sa fonction de rappel s'exécute dans une nouvelle tâche ». (optimiser l'INP).

Ce que nous recommandons. Le premier levier n'est pas d'optimiser un script, c'est d'en retirer. Chaque script tiers se justifie ou disparaît ; ceux qui restent sont chargés en defer ou après une action du visiteur, et les outils de mesure attendent le consentement.

Comment le vérifier

Le test de vitesse liste « Réduisez l'impact du code tiers ». Dans le panneau Performance, les tâches de plus de 50 millisecondes sont marquées en rouge, avec le script responsable.

Comment le corriger

Chargement différé et conditionnel.

<!-- script du site : différé, exécuté après l'analyse du HTML -->
<script src="/assets/js/site-abc123.js" defer></script>

<!-- mesure d'audience : seulement après consentement -->
<script>
  window.addEventListener('sf:consent-granted', function () {
    var s = document.createElement('script'); s.async = true;
    s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXX';
    document.head.appendChild(s);
  });
</script>

Ce que nous avons fait sur seoforge.fr

Un seul script de site, chargé en defer, servi par AssetMapper sans étape de compilation : modules déclarés dans une carte d'import, servis sous un nom versionné. Le seul script tiers, Google Tag Manager, n'est injecté qu'après consentement explicite.

7. CSS et rendu impact : optimisation

Ce que Google documente. Pour le CLS, « les sites doivent viser 0,1 ou moins pour au moins 75 % des visites ». « Incluez toujours les attributs width et height sur vos images et vidéos », ou réservez l'espace avec aspect-ratio ; « évitez d'insérer du nouveau contenu sans interaction de l'utilisateur » ; « les animations composées avec translate ne peuvent pas affecter les autres éléments et ne comptent donc pas dans le CLS » (optimiser le CLS).

Ce que nous recommandons. Une seule feuille de style, servie avec une empreinte et un an de cache, vaut mieux que du CSS critique en ligne mal entretenu. Les animations passent par transform et opacity, jamais par les propriétés qui relancent la mise en page.

Comment le vérifier

Dans le panneau Performance, la piste « Layout shifts » date chaque saut et nomme l'élément déplacé.

Comment le corriger

De l'espace réservé avant que le contenu arrive, et des animations composées.

/* espace réservé pour un bloc chargé tard */
.reviews { min-height: 320px; }
.embed  { aspect-ratio: 16 / 9; }

/* animation composée : ne déplace pas le reste de la page */
.card { transition: transform .2s ease, opacity .2s ease; }
.card:hover { transform: translateY(-2px); }

Ce que nous avons fait sur seoforge.fr

Une seule feuille de style d'environ 100 kilooctets avant compression, servie sous un nom versionné avec un an de cache ; aucun CSS critique en ligne, et c'est un choix. Les blocs révélés au défilement n'animent que transform et opacity.

8. Spécificités CMS : WordPress et Shopify impact : important

Ce que Google documente. « Les scripts synchrones retardent la construction du DOM et le rendu » : « chargez toujours les scripts tiers de façon asynchrone, sauf si le script doit s'exécuter avant que la page puisse être rendue », async quand il doit tourner tôt, defer pour le reste. Et la première question reste : « retirez-le s'il n'apporte pas de valeur claire à votre site » (charger efficacement le JavaScript tiers).

Ce que nous recommandons. Sur WordPress, la lenteur vient rarement du cœur : elle vient de l'hébergement, du thème et du nombre d'extensions, chacune ajoutant ses scripts à chaque page. Cache de pages, thème léger, extensions comptées ; le détail est dans notre article sur la vitesse d'un site WordPress. Sur Shopify, hébergement et cache sont imposés : le levier est le thème et les applications, dont chacune injecte son script.

Comment le vérifier

Comptez les fichiers CSS et JavaScript chargés sur la page d'accueil, dans le panneau Réseau. Au-delà d'une vingtaine, la page charge des fichiers qu'elle n'utilise pas.

Comment le corriger

Retirer avant d'optimiser, puis ne charger un script que là où il sert.

// WordPress, functions.php : le script d'une extension seulement sur la page qui l'utilise
add_action('wp_enqueue_scripts', function () {
    if (!is_page('contact')) {
        wp_dequeue_script('contact-form-widget');
        wp_dequeue_style('contact-form-widget');
    }
}, 100);

Ce que nous avons fait sur seoforge.fr

Ce site n'est pas un CMS : c'est une application Symfony rendue côté serveur, sans extension ni thème. Les recommandations de cette section viennent de nos interventions chez des clients WordPress.

Ce qu'une optimisation Core Web Vitals livre chez nous

  1. Le diagnostic par gabarit : LCP, CLS, INP avec la cause de chaque dégradation.
  2. La mesure de terrain et de laboratoire, avant intervention.
  3. La liste des correctifs classés par gain attendu et effort, du serveur au navigateur.
  4. Les correctifs implémentés dans votre code, ou spécifiés pour votre équipe.
  5. Les mesures après, et les règles pour garder les métriques au vert.

Sur devis, selon le nombre de gabarits et votre technologie ; premier diagnostic gratuit sous 24 h ouvrées. L'optimisation ne s'arrête pas au rapport : les correctifs sont implémentés, pas seulement listés.

Par où commencer

Lancez le test de vitesse sur votre page la plus visitée, en mobile. Pour aller plus loin, l'Optimisation des Core Web Vitals reprend les huit sections de ce guide sur vos gabarits, seule ou dans l'Audit Croissance. Pour le crawl, les redirections et le rendu, le guide du SEO technique prend le relais.

Pour aller plus loin

Appeler Réserver 20 min