---
title: "Optimisation de la vitesse de site web à Nantes"
description: "Optimisation de la vitesse de votre site web à Nantes : audit des Core Web Vitals dès 990 € HT, plan d’action chiffré et correctifs WordPress, Shopify ou Nuxt."
canonical_url: "https://studiofogg.fr/services/optimisation-vitesse-site-web-nantes"
---

> Index of every page on this site: [llms.txt](https://studiofogg.fr/llms.txt)

L’optimisation de la vitesse d’un site web consiste à mesurer ce qui ralentit vos pages chez vos vrais visiteurs, puis à en corriger les causes — images, polices, scripts tiers, cache, hébergement — pour atteindre les seuils des Core Web Vitals de Google. Chez FOGG Studio, à Nantes, l’audit et le plan d’action prennent 1 à 2 semaines, à partir de 990 € HT. Les correctifs, chiffrés ligne par ligne dans ce plan, sont ensuite réalisés sur WordPress, WooCommerce, PrestaShop, Shopify ou Nuxt, puis vérifiés sur les données réelles 28 jours plus tard. [Nos tarifs d’optimisation de la vitesse](https://studiofogg.fr/tarifs#optimisation-vitesse-site-web-nantes) détaillent ce que comprend l’audit.

## Les seuils que vos pages doivent atteindre

Les Core Web Vitals sont les trois indicateurs que Google retient pour juger l’expérience vécue sur une page : la vitesse d’affichage du contenu principal, la réactivité aux interactions et la stabilité de la mise en page. Chacun est jugé bon quand au moins 75 % des visites respectent son seuil, et une page ne réussit l’évaluation que si les trois sont bons. Mobile et ordinateur sont évalués séparément, avec les mêmes seuils.

<table>
<thead>
  <tr>
    <th>
      Indicateur
    </th>
    
    <th>
      Ce qu’il mesure
    </th>
    
    <th>
      Bon
    </th>
    
    <th>
      Amélioration nécessaire
    </th>
    
    <th>
      Médiocre
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      LCP (Largest Contentful Paint)
    </td>
    
    <td>
      Le temps d’affichage du plus grand élément visible, souvent une photo ou un bloc de texte
    </td>
    
    <td>
      2,5 s ou moins
    </td>
    
    <td>
      De 2,5 à 4 s
    </td>
    
    <td>
      Plus de 4 s
    </td>
  </tr>
  
  <tr>
    <td>
      INP (Interaction to Next Paint)
    </td>
    
    <td>
      Le délai entre un clic, un toucher ou une frappe au clavier et l’affichage de la réponse
    </td>
    
    <td>
      200 ms ou moins
    </td>
    
    <td>
      De 200 à 500 ms
    </td>
    
    <td>
      Plus de 500 ms
    </td>
  </tr>
  
  <tr>
    <td>
      CLS (Cumulative Layout Shift)
    </td>
    
    <td>
      Les décalages inattendus du contenu pendant la consultation
    </td>
    
    <td>
      0,1 ou moins
    </td>
    
    <td>
      De 0,1 à 0,25
    </td>
    
    <td>
      Plus de 0,25
    </td>
  </tr>
</tbody>
</table>

Ces seuils sont [publiés par l’équipe Chrome sur web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds) et repris tels quels par la Search Console. Le seuil le plus souvent manqué est celui du LCP : dans [le bilan de septembre 2026 du rapport CrUX](https://developer.chrome.com/docs/crux/release-notes/), publié le 13 octobre 2026, 68,3 % des 18,4 millions d’origines suivies — en pratique, des sites — avaient un bon LCP, contre 81,7 % pour le CLS et 85,4 % pour l’INP. Au total, 55,9 % seulement avaient de bons Core Web Vitals. Le détail de chaque indicateur fait l’objet de [notre guide des Core Web Vitals : LCP, INP et CLS](https://studiofogg.fr/journal/core-web-vitals-lcp-inp-cls) ; l’optimisation des Core Web Vitals de votre site, elle, commence par la mesure.

## Ce qu’un site plus rapide vous apporte

Gagner en vitesse peut se traduire en ventes. Vodafone a comparé deux versions d’une même page d’atterrissage, identiques en apparence comme en fonctionnement, en partageant son trafic publicitaire moitié-moitié : [la version au LCP amélioré de 31 % a généré 8 % de ventes en plus](https://web.dev/case-studies/vodafone) (étude publiée sur web.dev en mars 2021). HTML essentiel rendu côté serveur, moins de JavaScript bloquant, image principale redimensionnée : mesuré sur les visites réelles, le LCP de la page optimisée était de 5,7 secondes contre 8,3 pour l’autre, un résultat encore loin des 2,5 secondes recommandées. Un test mené par un grand groupe, sur une seule page, ne promet rien pour votre site ; il montre en revanche qu’un progrès compte avant même d’atteindre les seuils, et que l’effet se mesure : c’est ce que nous faisons, avant et après.

Côté référencement, [Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement](https://developers.google.com/search/docs/appearance/page-experience?hl=fr), sans qu’une bonne note suffise à passer devant un contenu plus pertinent. La vitesse est une fondation ; les contenus, le maillage et la visibilité locale relèvent du [travail de notre agence SEO à Nantes](https://studiofogg.fr/services/referencement-naturel-seo-nantes), qui s’appuie sur les mêmes données de la Search Console.

Un site plus rapide est souvent un site plus léger : moins de fichiers à télécharger, moins de travail pour le téléphone de vos visiteurs, y compris les modèles anciens. Si vous voulez aller plus loin dans cette logique de sobriété, [notre service d’éco-conception web](https://studiofogg.fr/services/eco-conception-web-nantes) prolonge ce travail avec un audit selon le référentiel RGESN.

## Mesurer d’abord : vos visiteurs réels, puis le laboratoire

Deux familles de mesures se complètent. Les données réelles, dites « de terrain », proviennent des visites d’internautes qui utilisent Chrome : elles alimentent le rapport CrUX, le rapport Core Web Vitals de la Search Console et la première partie du rapport PageSpeed Insights. Les tests « en laboratoire », menés avec Lighthouse ou PageSpeed Insights, chargent une page dans des conditions contrôlées. Comme le rappelle [la documentation de PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about?hl=fr), les tests servent à diagnostiquer une lenteur, les données réelles à savoir ce que vivent vraiment vos visiteurs.

<table>
<thead>
  <tr>
    <th>
      Critère
    </th>
    
    <th>
      Données réelles (terrain)
    </th>
    
    <th>
      Tests en laboratoire
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Outils
    </td>
    
    <td>
      Search Console, rapport CrUX, PageSpeed Insights
    </td>
    
    <td>
      Lighthouse, PageSpeed Insights, outils de développement du navigateur
    </td>
  </tr>
  
  <tr>
    <td>
      Ce qu’on y lit
    </td>
    
    <td>
      L’expérience de vos visiteurs sur les 28 derniers jours
    </td>
    
    <td>
      Les causes d’une lenteur, sur un chargement donné
    </td>
  </tr>
  
  <tr>
    <td>
      Limites
    </td>
    
    <td>
      Il faut assez de visites, et un progrès met des semaines à apparaître
    </td>
    
    <td>
      Un appareil et une connexion simulés ; sans visiteur pour cliquer, Lighthouse ne mesure pas l’INP
    </td>
  </tr>
  
  <tr>
    <td>
      Notre usage
    </td>
    
    <td>
      Fixer les priorités, puis valider les résultats
    </td>
    
    <td>
      Trouver les causes et tester chaque correctif avant sa mise en ligne
    </td>
  </tr>
</tbody>
</table>

Ces données réelles ont leurs angles morts. [CrUX ne retient que des utilisateurs de Chrome sur ordinateur et sur Android](https://developer.chrome.com/docs/crux/methodology) : vos visiteurs sur iPhone n’y figurent pas, et un site trop peu visité n’y apparaît pas du tout — la Search Console affiche alors « Aucune donnée disponible ». Dans ce cas, nous nous appuyons sur les tests en laboratoire des pages clés et, si vous le souhaitez, sur une mesure des visites réelles ajoutée à votre site avec [la bibliothèque web-vitals de l’équipe Chrome](https://github.com/GoogleChrome/web-vitals), qui relève aussi le LCP et l’INP sur les versions récentes de Safari, iPhone compris.

Mesurer sur le terrain compte, parce que vos visiteurs ne naviguent pas dans les mêmes conditions : un client qui ouvre votre site en 4G depuis un chantier de Rezé n’a ni le téléphone ni la connexion d’un acheteur installé sur la fibre, dans un bureau de l’Île de Nantes. C’est pourquoi nous analysons le mobile et l’ordinateur séparément, comme la Search Console.

Une évolution concerne les sites conçus comme des applications, où l’on change de page sans rechargement complet — c’est le fonctionnement d’un site Nuxt une fois la première page chargée. CrUX n’enregistrait jusqu’ici que ce premier chargement, auquel il rattachait les clics et décalages de toute la visite. Depuis le 13 octobre 2026, il publie [des versions expérimentales des trois indicateurs qui tiennent compte de ces navigations](https://web.dev/blog/crux-experimental-soft-navs) : selon Google, les résultats de ces sites s’y maintiennent ou s’améliorent. Les scores officiels et la Search Console restent inchangés tant qu’elles n’ont pas été validées, ce que Google vise pour mai 2027, sous réserve des retours.

## Ce que l’audit de performance passe en revue

Un site internet lent l’est rarement pour une seule raison. L’audit examine chaque maillon, du serveur au dernier script ajouté :

- **Les images** : poids, format (WebP, AVIF), taille adaptée à chaque écran, dimensions déclarées pour réserver leur place. L’image principale doit figurer dans le HTML, être chargée en priorité et [jamais en différé](https://web.dev/articles/optimize-lcp), contrairement aux images situées plus bas dans la page.
- **Les polices** : nombre de familles et de graisses, hébergement sur votre propre domaine, préchargement de la police principale et police de secours aux proportions voisines, pour que le texte ne bouge pas quand la police définitive arrive.
- **Les scripts tiers** : mesure d’audience, gestionnaire de balises, chat, vidéos intégrées, cartes, widgets d’avis, publicité. Chacun est inventorié avec son coût, puis supprimé s’il ne sert plus, chargé plus tard ou remplacé par une « façade », un aperçu statique qui ne charge le vrai service qu’au clic.
- **Le JavaScript et les animations** : toute tâche de plus de 50 millisecondes est une « tâche longue », qui occupe le navigateur ; un clic qui survient pendant ce temps attend, et l’INP s’en ressent. Les animations ont aussi un coût ; [notre article sur les animations utiles ou nuisibles](https://studiofogg.fr/journal/animations-site-web-utiles-ou-nuisibles) aide à garder celles qui servent vraiment le visiteur.
- **Le cache** : en-têtes de cache des fichiers, cache des pages côté serveur, compression et, quand votre audience le justifie, un [réseau de diffusion de contenu (CDN)](https://studiofogg.fr/glossaire#cdn).
- **L’hébergement** : le délai avant l’arrivée du premier octet de la page, ou TTFB, n’est pas un Core Web Vital, mais il retarde tout l’affichage ; [web.dev en fixe le repère indicatif à 0,8 seconde au plus](https://web.dev/articles/ttfb). Il inclut le temps des redirections et de la connexion, pas seulement le travail du serveur : nous repérons donc les renvois en chaîne (de http vers https, puis vers www, par exemple) et vérifions la version de PHP ou de Node.js ainsi que les ressources réellement disponibles aux heures de pointe.
- **La base de données** : requêtes lentes, tables gonflées par d’anciennes extensions, réglages chargés à chaque affichage de page. Depuis sa version 6.6, WordPress signale d’ailleurs, dans son outil Santé du site, quand le volume de ces réglages chargés automatiquement dépasse 800 Ko.

## Un plan d’action chiffré, classé par gain attendu

Chaque constat devient une ligne du plan : l’indicateur concerné, les pages touchées, le gain attendu, l’effort et le prix. Les lignes sont classées par gain attendu : une correction qui profite à toutes les pages passe avant le réglage fin d’une page peu visitée. Quand un gain est incertain, nous le testons d’abord en laboratoire, sur une copie du site.

Voici le type de lignes que l’on retrouve souvent dans un plan d’action. Ce sont des cas types, pas ceux d’un client :

<table>
<thead>
  <tr>
    <th>
      Constat
    </th>
    
    <th>
      Indicateur
    </th>
    
    <th>
      Correctif
    </th>
    
    <th>
      Effort
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Photo d’accueil de plusieurs mégaoctets, chargée en différé
    </td>
    
    <td>
      LCP
    </td>
    
    <td>
      Format récent, taille adaptée à l’écran, chargement prioritaire
    </td>
    
    <td>
      Faible
    </td>
  </tr>
  
  <tr>
    <td>
      Chat chargé dès l’arrivée, sur toutes les pages
    </td>
    
    <td>
      INP
    </td>
    
    <td>
      Façade : le chat ne se charge qu’au clic sur son bouton
    </td>
    
    <td>
      Faible
    </td>
  </tr>
  
  <tr>
    <td>
      Bandeau inséré en haut de page après l’affichage
    </td>
    
    <td>
      CLS
    </td>
    
    <td>
      Place réservée dès le chargement, ou bandeau en surimpression
    </td>
    
    <td>
      Faible
    </td>
  </tr>
  
  <tr>
    <td>
      Serveur lent à répondre, aucune page en cache
    </td>
    
    <td>
      LCP
    </td>
    
    <td>
      Cache de pages, CDN, hébergement adapté
    </td>
    
    <td>
      Moyen
    </td>
  </tr>
  
  <tr>
    <td>
      Constructeur de pages qui produit des pages très lourdes
    </td>
    
    <td>
      LCP, INP
    </td>
    
    <td>
      Allègement des modèles, voire changement de thème
    </td>
    
    <td>
      Élevé
    </td>
  </tr>
</tbody>
</table>

Le plan est rédigé pour qu’un autre développeur que nous puisse l’exécuter : vous pouvez nous confier les correctifs, les répartir avec votre prestataire actuel ou en garder une partie en interne. Ceux que vous nous confiez font l’objet d’un devis séparé, établi à partir du plan validé.

## Des correctifs adaptés à votre technologie

Les causes d’une lenteur dépendent beaucoup de l’outil sur lequel votre site est construit. Chaque technologie a ses points faibles et ses leviers d’accélération :

<table>
<thead>
  <tr>
    <th>
      Technologie
    </th>
    
    <th>
      Ce qui ralentit le plus souvent
    </th>
    
    <th>
      Nos leviers
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      WordPress
    </td>
    
    <td>
      Extensions accumulées, constructeur de pages, absence de cache, version de PHP ancienne
    </td>
    
    <td>
      Tri des extensions, cache de pages, PHP à jour, images, contrôle de l’image principale
    </td>
  </tr>
  
  <tr>
    <td>
      WooCommerce
    </td>
    
    <td>
      Les mêmes causes, plus un panier et une commande qui échappent au cache
    </td>
    
    <td>
      Serveur et base de données dimensionnés pour ces pages, scripts limités aux pages qui en ont besoin
    </td>
  </tr>
  
  <tr>
    <td>
      PrestaShop
    </td>
    
    <td>
      Modules superflus, cache désactivé, fichiers CSS et JavaScript non regroupés
    </td>
    
    <td>
      Cache et regroupement des fichiers activés puis testés dans les réglages de performance du back-office, tri des modules, images
    </td>
  </tr>
  
  <tr>
    <td>
      Shopify
    </td>
    
    <td>
      Applications installées au fil du temps, code laissé par d’anciennes applications
    </td>
    
    <td>
      Tri des applications, nettoyage du thème, revue des pixels et balises marketing
    </td>
  </tr>
  
  <tr>
    <td>
      Nuxt
    </td>
    
    <td>
      Pages souvent générées à l’avance, donc rapides à servir ; restent les images, les polices, les scripts tiers et le poids du JavaScript
    </td>
    
    <td>
      Nuxt Image, Nuxt Fonts, Nuxt Scripts, budget de performance vérifié à chaque mise en ligne
    </td>
  </tr>
</tbody>
</table>

Quelques exemples montrent pourquoi nous vérifions au lieu de supposer. Depuis sa version 6.3, sortie en août 2023, WordPress ajoute de lui-même l’attribut `fetchpriority="high"` à l’image qu’il estime principale ; mais une analyse publiée en septembre 2023 sur le blog des développeurs de WordPress a montré que cette version [ne visait la bonne image qu’environ une fois sur deux](https://make.wordpress.org/core/2023/09/19/analyzing-the-core-web-vitals-performance-impact-of-wordpress-6-3-in-the-field/). Sur Shopify, [désinstaller une application ne retire pas automatiquement son code du thème](https://help.shopify.com/fr/manual/online-store/web-performance/improving-web-performance) : des scripts peuvent continuer à se charger pour un service que vous n’utilisez plus.

Sur une boutique WooCommerce, enfin, [le panier, le compte client et la page de commande doivent rester hors du cache](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins), puisqu’ils affichent les informations propres à chaque client. C’est sur ces pages que la puissance du serveur et la santé de la base de données se ressentent le plus.

## Vérifier sur 28 jours, puis tenir dans la durée

Phileas Fogg s’était donné 80 jours pour boucler son tour du monde ; il en faut 28 pour juger un correctif. Les données réelles couvrent en effet les 28 derniers jours, et le bouton « Démarrer le suivi » du [rapport Core Web Vitals de la Search Console](https://support.google.com/webmasters/answer/9205520?hl=fr) lance une période de surveillance de la même durée. Nous refaisons donc la mesure 28 jours après la mise en ligne des derniers correctifs et vous remettons la comparaison avant/après, indicateur par indicateur.

Reste à garder le terrain gagné. Une vidéo ajoutée sur l’accueil, une nouvelle balise marketing ou une extension de plus peuvent suffire à faire rechuter un site. Nous fixons donc un budget de performance par modèle de page — poids, nombre de scripts tiers, LCP, CLS et temps de blocage du navigateur, qui annonce les problèmes d’INP — et des alertes qui signalent un dépassement avant qu’il ne s’installe dans les données réelles. La surveillance peut ensuite se poursuivre avec [notre contrat de maintenance de site internet](https://studiofogg.fr/services/maintenance-site-internet-nantes), qui comprend des contrôles réguliers de performance et de référencement.

<callout type="conseil">

Ouvrez votre gestionnaire de balises — Google Tag Manager, par exemple — et dressez la liste des scripts qu’il charge, en notant pour chacun qui en exploite encore les données. Ceux qui n’ont plus de lecteur peuvent souvent être retirés tout de suite : c’est l’un des gains les plus simples à obtenir.

</callout>

## Optimiser ou refaire le site ?

L’optimisation a ses limites, et nous préférons vous le dire tôt. Quand un thème ou un constructeur de pages produit des pages trop lourdes, que la technologie n’est plus maintenue ou que chaque correctif en casse un autre, le plan d’action le signale et chiffre les deux options côte à côte. Si les mêmes correctifs reviennent à chaque mise à jour, [une refonte sur une base plus légère](https://studiofogg.fr/services/refonte-site-internet-nantes) — un site statique pour une vitrine, par exemple — peut coûter moins cher sur quelques années que de continuer à rapiécer l’existant.

Pour savoir où en est votre site, le premier rendez-vous de 30 minutes est gratuit, à notre studio à Nantes ou en visio, et chaque demande reçoit une réponse sous 48 h ouvrées. Préparez l’adresse des pages qui comptent le plus pour votre activité : ce sont elles que nous regarderons en premier.

## Sitemap

See the full [sitemap](https://studiofogg.fr/sitemap.md) for all pages.