Vitesse de chargement : optimiser son site en 2026 YperLine

TTFB, LCP, INP, CLS : les 8 causes de lenteur, optimisation des images, du JS/CSS et du serveur. Checklist 14 points.


Vitesse de chargement : optimiser son site en 2026

Pourquoi la vitesse est un facteur de classement

La vitesse de chargement est un facteur de classement direct depuis 2010 (Mobile Speed Update) et un composant des Core Web Vitals depuis 2021. Un site lent perd à la fois en classement, en conversion et en expérience utilisateur.

Les chiffres clés :

  • Au-delà de 3 secondes de chargement, 53 % des utilisateurs mobiles abandonnent la page (Google, 2016).
  • Chaque seconde de délai supplémentaire réduit les conversions de 7 % sur mobile (Akamai, 2024).
  • Un LCP > 4 s est classé « médiocre » par Google → signal négatif dans l'algorithme.

→ Guide détaillé des métriques : Core Web Vitals : LCP, INP, CLS

Les métriques qui comptent (TTFB, LCP, INP, CLS)

4 métriques à surveiller, de la plus impactante à la moins visible :

MétriqueCe que ça mesureCibleSeuil médiocre
TTFB (Time To First Byte)Temps entre la requête HTTP et le premier octet de la réponse serveur< 800 ms> 1 800 ms
LCP (Largest Contentful Paint)Temps d'affichage du plus grand élément (image hero, titre)≤ 2,5 s≥ 4,0 s
INP (Interaction to Next Paint)Latence perçue lors d'une interaction (clic, tap)≤ 200 ms≥ 500 ms
CLS (Cumulative Layout Shift)Stabilité visuelle (décalages de mise en page)≤ 0,1≥ 0,25

Le TTFB n'est pas un Core Web Vital à part entière, mais il est un composant du LCP. Un TTFB élevé pénalise directement le LCP, qui lui est un CWV officiel.

Les 8 causes principales de lenteur

#CauseImpact typiqueMétrique affectée
1Images non optimisées (PNG/JPEG lourds, taille excessive)+1 à 5 sLCP
2TTFB élevé (serveur lent, pas de cache)+0,5 à 3 sLCP, TTFB
3Scripts JS bloquants (chargement synchrone)+0,5 à 2 sLCP, INP
4CSS bloquant le rendu (render-blocking)+0,3 à 1,5 sLCP
5Redirections en chaîne (http→https→www→page)+0,3 à 1 sTTFB, LCP
6Polices web chargées tardivement+0,5 à 1,5 sLCP, CLS
7Librairies tierces lourdes (analytics, chat, A/B test)+0,5 à 2 sINP, LCP
8Éléments sans dimensions (images, iframes) → layout shiftCLS 0,1 à 0,5CLS

Optimiser les images (impact n°1)

Les images représentent en moyenne 50 à 70 % du poids total d'une page. C'est le levier le plus rapide et le plus impactant.

Actions à fort impact

  1. Format moderne : convertir en WebP (réduction de 25-35 % vs JPEG) ou AVIF (réduction de 50-80 % vs JPEG). Fallback JPEG pour les anciens navigateurs.
  2. Taille adaptée : ne pas servir une image de 2000 px sur un conteneur de 800 px. Utiliser srcset et sizes pour servir la bonne résolution.
  3. Lazy loading : loading="lazy" sur toutes les images hors viewport. Ne PAS mettre lazy loading sur l'image LCP (hero) — elle doit charger en priorité.
  4. Préchargement de l'image LCP : <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> dans le <head>.
  5. Dimensions explicites : width et height sur chaque <img> → évite le CLS.

Outils de compression

OutilUsageFormat
Squoosh (squoosh.app)Compression en ligne, preview qualité/poidsWebP, AVIF, JPEG, PNG
ImageOptim (macOS)Compression locale par lotWebP, AVIF, JPEG, PNG
ShortPixel / CloudinaryCompression automatique via plugin/CMSWebP, AVIF
cwebp / avifenc (CLI)Conversion en ligne de commande (CI/CD)WebP, AVIF

Optimiser le JavaScript et le CSS

JavaScript

  1. Defer / async : <script defer src="…"> sur tous les scripts non critiques. Le HTML est parsé avant l'exécution du JS.
  2. Code splitting : ne charger que le JS nécessaire à la page courante (tree shaking, lazy loading des routes).
  3. Minification : supprimer les espaces, commentaires et variables longues (UglifyJS, Terser).
  4. Éliminer les long tasks : aucune tâche JS ne doit bloquer le main thread plus de 50 ms. Utiliser requestIdleCallback pour les tâches non urgentes.
  5. Limiter les librairies tierces : chaque script de tracking, chat ou A/B test ajoute de la latence. Max 2-3 scripts tierces.

CSS

  1. CSS critique inline : extraire le CSS nécessaire au premier écran (above the fold) et l'injecter inline dans le <head>. Le reste en <link> avec media="print" onload="this.media='all'">.
  2. Minification : purger les CSS inutilisés (PurgeCSS, UnCSS).
  3. Éviter les @import : chaque @import dans le CSS ajoute une requête bloquante. Utiliser des <link> séparés.

Optimiser le serveur (TTFB)

Le TTFB (Time To First Byte) est le temps que met le serveur pour envoyer le premier octet de la réponse. C'est le premier maillon de la chaîne de chargement : si le TTFB est lent, tout le reste l'est aussi.

Actions à fort impact

  1. CDN (Cloudflare, Bunny CDN, CloudFront) : servir le contenu depuis le datacenter le plus proche de l'utilisateur. Réduit le TTFB de 30-60 %.
  2. Cache page : Varnish, LiteSpeed Cache, ou cache PHP (OPcache). Servir une page statique au lieu de re-générer en PHP à chaque requête.
  3. OPcache PHP : compiler le code PHP une fois et le servir en mémoire. Réduit le TTFB de 20-40 % sur les sites PHP.
  4. HTTP/2 ou HTTP/3 : multiplexage des requêtes (pas de limitation à 6 connexions TCP). Réduit le temps de chargement des pages avec beaucoup d'assets.
  5. Hébergement : un shared hosting bas de gamme a un TTFB de 1-3 s. Un VPS ou un PaaS (Render, Railway, OVH) le ramène à 200-500 ms.

Vérification rapide

# Mesurer le TTFB depuis le terminal
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yperline.net

Objectif : < 800 ms. Si > 1 500 ms, le problème est côté serveur (hébergement, base de données, code PHP lent).

Spécificités mobile

60 % du trafic web est généré sur mobile. Les Core Web Vitals sont mesurés en priorité sur mobile (percentile 75 mobile + desktop). Les spécificités :

  • Connexion plus lente : 4G/5G vs fibre fixe. Le TTFB est 2 à 3× plus élevé sur mobile. Le CDN est encore plus critique.
  • Écran plus petit : l'image LCP est souvent plus petite (hero mobile vs desktop) → le poids de l'image LCP mobile est le premier levier.
  • Processing power limité : le JS est exécuté plus lentement sur un smartphone milieu de gamme. Les long tasks ont un impact INP 2 à 3× plus fort.
  • Viewport réduit : moins d'éléments au-dessus du fold → le CLS est moins critique, mais le LCP l'est plus (moins d'éléments concurrents).

→ Guide : Mobile-first indexing : guide complet

Outils de mesure

OutilTypeUsagePrix
PageSpeed Insights (pagespeed.web.dev)Labo + TerrainScore 0-100, éléments LCP/CLS identifiés, suggestionsGratuit
Google Search Console → CWVTerrainVue d'ensemble par page, tendance 28 jGratuit
Chrome DevTools → PerformanceLabo (local)Long tasks, waterfall, TTFB, layout shiftsGratuit
WebPageTest (webpagetest.org)Labo (multi-geo)Test depuis Paris, New York, Tokyo. Vidéo du chargementGratuit
CrUX DashboardTerrainDonnées brutes Chrome User Experience ReportsGratuit
Lighthouse (DevTools)LaboScore global, audit accessibilité + SEO + PWAGratuit

Workflow recommandé : GSC pour identifier les pages à problème → PageSpeed Insights pour le diagnostic → Chrome DevTools pour l'investigation fine → re-tester dans GSC après correction (attendre 28 jours pour le terrain).

Checklist vitesse de chargement

#Point de contrôleStatut
1TTFB < 800 ms (mesuré via curl ou GSC)☐
2LCP ≤ 2,5 s sur mobile (GSC, percentile 75)☐
3INP ≤ 200 ms sur mobile☐
4CLS ≤ 0,1 sur mobile☐
5Image hero en WebP/AVIF avec preload + fetchpriority="high"☐
6Toutes les images ont width/height (ou aspect-ratio)☐
7Lazy loading sur les images hors viewport (pas sur le LCP)☐
8Scripts JS en defer, pas de long task > 50 ms☐
9CSS critique inline, le reste en media="print" onload☐
10CDN actif + cache page (OPcache ou Varnish)☐
11Pas de redirection en chaîne (1 hop max)☐
12Polices : font-display: swap + preload☐
13Max 2-3 scripts tierces, chargés en defer☐
14HTTP/2 ou HTTP/3 actif☐

Pour le détail des métriques, voir Core Web Vitals : guide complet. Pour le contexte plus large, voir SEO fondamental. Pour la vue d'ensemble, voir le guide complet du SEO.

Débloquez vos temps de chargement

Audit SEO : nous analysons votre TTFB, LCP, INP et CLS sur les 5 pages clés et vous livrons un plan d'optimisation priorisé avec les corrections à fort impact.

Demander un audit