Retour au blog
Technologie

Optimisation images web 2026 : 8 stratégies pour améliorer vos Core Web Vitals

Publié le10 min read
Partager

Les images : le goulot d'étranglement numéro un

Côté technique, les images dominent le poids des pages web actuelles. Selon HTTP Archive (statistiques décembre 2025), la taille médiane d'une page desktop est d'environ 2 312 Ko, dont environ 1 026 Ko pour les images — 44,4 %. Sur mobile, ça monte à 47 %.

Conclusion : si vous ne devez optimiser qu'une chose, choisissez les images.

Plus critique encore, les images impactent directement les Core Web Vitals de Google, surtout le LCP (Largest Contentful Paint). Selon CrUX, plus de 70 % des éléments LCP sont des images ou des blocs avec image de fond. Au-delà de 2,5 s, classé « à améliorer » ; au-delà de 4 s, « mauvais » — impact direct sur le SEO.

On décortique l'optimisation bloc par bloc.

Un cas réel : LCP qui passe de 1,8 s à 6,2 s

Franchement, commençons par la conclusion : l'année dernière, j'ai géré un dossier client où le LCP a explosé du vert (1,8 s) au rouge (6,2 s), uniquement après avoir remplacé une image hero. Au début je pensais que le bundle JS avait dérapé, j'ai débuggé pendant trois jours avant de comprendre — un nouveau designer avait balancé un PNG de 4,5 Mo en 1920×1080 sur la home, pas compressé, sans attribut loading, sans fetchpriority, et pas de CDN. À vrai dire, cette seule image a suffi à flinguer le LCP.

Après avoir fait trois choses, le LCP est retombé à 1,9 s :

  1. Conversion PNG → WebP, compressé à 180 Ko (réduction de 96 %)
  2. Ajout de fetchpriority="high" et de <link rel="preload">
  3. Bascule de l'image sur Cloudflare R2 + Transform Rules avec fallback AVIF automatique

Beaucoup de monde tombe dans ce piège. Pour être honnête, l'image hero de la home, c'est le point névralgique du LCP — si un maillon lâche, tout le rapport Core Web Vitals part au rouge. Chaque section qui suit est tirée de cas comme celui-là, pas recopiée de la doc.

Lazy Loading : charger les images au besoin

Solution HTML native

La plus simple — attribut loading="lazy" :

<img src="photo.webp" loading="lazy" alt="Exemple" width="800" height="600">

Principe : le navigateur déclenche la requête HTTP quand l'image approche du viewport. Chrome le fait à ~1250 px (desktop) ou ~2500 px (connexion lente), garantissant qu'elle est chargée quand l'utilisateur arrive dessus.

Attention : les images above-the-fold ne doivent PAS avoir loading="lazy", sinon vous retardez le LCP. Pour le first screen, utilisez loading="eager" (par défaut) avec fetchpriority="high".

Solution JavaScript : Intersection Observer

Contrôle plus fin avec l'API Intersection Observer :

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, { rootMargin: '200px' });

document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

Avantages : contrôle de la distance de déclenchement (rootMargin), ajout d'animations fade-in, préchargement d'un placeholder basse résolution (LQIP).

Comparatif des deux approches

Critère loading="lazy" natif Intersection Observer
Complexité Très faible (un attribut) Moyenne (JS)
Support navigateur 95 %+ (2026) 97 %+
Contrôle distance Non Oui (rootMargin)
LQIP (placeholder) Non Oui
SEO Oui (natif navigateur) Prévoir <noscript>
Erreur above-fold Possible (à exclure manuellement) Exclusion programmatique

Recommandation : la plupart du temps, le natif suffit. Passez à Intersection Observer seulement si vous avez besoin de LQIP ou contrôle fin.

Images responsives : télécharger la bonne taille

Une image hero de 3000 px sur mobile, absurde. Sans images responsives, les mobinautes téléchargent 4x plus que nécessaire.

srcset + sizes

<img
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="hero-800.webp"
  alt="Bannière page d'accueil"
>

Le navigateur choisit selon largeur de viewport et densité de pixels. sizes informe sur la largeur que l'image occupe aux différents breakpoints, pour un choix précis.

<picture> : format et direction artistique

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Bannière page d'accueil">
</picture>

<picture> permet plusieurs formats par navigateur, avec fallback automatique.

Choix du format

Directement lié au poids et à la qualité. Comparatif basé sur une photo 1920×1080 à qualité visuelle équivalente :

Format Poids typique Support navigateur Transparence Animation Usage
JPEG Base 100 % 100 % Non Non Photo (compatibilité max)
WebP ~70 % de JPEG 97 %+ Oui Oui Photo + graphique (défaut)
AVIF ~50 % de JPEG 92 %+ Oui Oui Photo (meilleur ratio)
PNG 300-500 % JPEG 100 % Oui Non Graphique avec transparence
SVG Très faible (vectoriel) 100 % Oui Oui Icônes, logos, graphiques

Stratégie : AVIF → WebP → JPEG en dégradation progressive via <picture>.

CDN et stratégie de cache

Valeur d'un CDN

Une image servie depuis un serveur en France, téléchargée aux USA, parcourt ~12 000 km. Même à la vitesse de la lumière dans la fibre, latence ~40 ms (aller). Avec TCP handshake, TLS, HTTP, le TTFB peut dépasser 200 ms.

Un CDN cache sur des edge mondiaux, l'utilisateur touche le nœud le plus proche. Un bon CDN fait passer le TTFB de 200 ms+ à 20-50 ms.

En-têtes de cache

Cache-Control: public, max-age=31536000, immutable

Les images changent rarement, un cache d'un an + immutable évite la revalidation. Pour forcer la mise à jour : changer le nom de fichier (hash).

Services CDN image

Cloudflare Images, Imgix, Cloudinary, Scaleway Image Processing offrent bien plus que du CDN :

  • Conversion format temps réel (choix AVIF/WebP/JPEG via en-tête Accept)
  • Redimensionnement temps réel (paramètres URL)
  • Optimisation qualité auto (selon vitesse réseau)

Pipeline de compression

Architecture type d'un pipeline complet :

  1. Compression à l'upload : Sharp (Node.js) ou Pillow (Python) côté serveur
  2. Génération multi-tailles : 3-5 variantes par image (400w, 800w, 1200w, 1600w, original)
  3. Conversion multi-formats : AVIF + WebP + JPEG pour chaque taille
  4. Réglage qualité : JPEG 75-85, WebP 75-80, AVIF 60-70
  5. Nettoyage métadonnées : EXIF retirées (poids + vie privée)

Exemple concret : une photo 1920×1080 après pipeline → un mobinaute télécharge un AVIF 400w de ~30 Ko au lieu de 2 Mo original. Réduction de 98,5 % du volume transféré.

Core Web Vitals : impact et cibles

LCP (Largest Contentful Paint)

Temps de rendu du plus gros élément visible. Pour les pages où LCP = image :

  • Bon : ≤ 2,5 s
  • À améliorer : 2,5-4 s
  • Mauvais : > 4 s

Optimiser le first screen :

  1. fetchpriority="high" sur l'image above-fold
  2. <link rel="preload"> pour pré-charger l'image LCP
  3. Pas de lazy loading sur above-fold
  4. Bon taux de cache CDN

CLS (Cumulative Layout Shift)

Images qui chargent sans réservation d'espace = saut de mise en page. Solution simple : toujours spécifier width et height sur <img> pour que le navigateur calcule l'aspect ratio à l'avance.

<img src="photo.webp" width="800" height="600" alt="Exemple">

Checklist d'optimisation

Avant mise en prod :

  • Images above-fold avec fetchpriority="high", autres avec loading="lazy"
  • Tous les <img> ont width et height
  • <picture> pour fallback AVIF/WebP/JPEG
  • srcset + sizes pour multi-tailles
  • Compression appliquée (JPEG 75-85, WebP 75-80)
  • CDN actif, en-têtes cache corrects (max-age=31536000, immutable)
  • EXIF nettoyées
  • Image LCP pré-chargée via <link rel="preload">
  • PageSpeed Insights : LCP ≤ 2,5 s

Contexte français : que dit la RGAA et la sobriété numérique ?

RGAA (Référentiel général d'amélioration de l'accessibilité) : obligatoire pour les sites publics français. Oblige l'attribut alt pour chaque image informative, et la description longue pour les images complexes. Au-delà du SEO, l'accessibilité est une exigence légale pour le service public.

Sobriété numérique : mouvement soutenu par l'ADEME et l'ARCEP. Réduire le poids des images = réduire l'empreinte carbone du web. Une page optimisée consomme 5-10x moins d'énergie qu'une page alourdie. Des frameworks comme EcoIndex (développé par GreenIT) mesurent cet impact et sont de plus en plus utilisés par les agences web françaises.

Référence : le label « Numérique Responsable » de l'INR (Institut du Numérique Responsable) intègre directement les critères d'optimisation d'image dans son référentiel.

Rôle d'un hébergeur d'images

Si vous ne voulez pas construire un pipeline complet ni gérer l'infra CDN, un hébergeur pro reste pragmatique.

lpic.cc, par exemple, offre upload sans inscription, distribution CDN globale, protection par mot de passe. Pour un blog ou un petit site, vous économisez l'effort infra. Mais notez : lpic.cc ne propose pas d'API d'intégration ni de redimensionnement temps réel. Pour du batch programmatique ou de la transformation dynamique, associez avec Cloudinary, Imgix, ou en souveraineté française avec Scaleway Image Processing.

FAQ

Q1 : Lazy loading = mauvais pour le SEO ?

Non. Googlebot exécute le JS et simule le scroll, les images en loading="lazy" sont bien indexées. Mais si vous utilisez un lazy loading JS custom, prévoyez un <noscript> fallback pour que les crawlers récupèrent l'URL image.

Q2 : WebP ou AVIF en priorité ?

AVIF gagne en ratio (~50 % plus petit que JPEG), mais encodage lent, peu adapté au temps réel. Stratégie : <picture> avec les deux, choix auto par le navigateur. Si vous devez en choisir un, WebP supporte 97 % vs 92 % pour AVIF — plus prudent.

Q3 : CDN image payant, ça vaut la peine ?

Ça dépend du volume. Moins de 100 k PV/mois, Cloudflare gratuit suffit généralement. Au-dessus, un CDN pro (Imgix, Cloudinary, Scaleway Image Processing) avec conversion et redimensionnement dynamiques devient rentable — économies bande passante > coût abonnement.

Q4 : Compresser impacte-t-il vraiment la qualité ?

Avec perte, toujours un peu, mais dans les paramètres usuels (JPEG 75-85, WebP 75-80), œil humain quasi incapable de voir. Évaluez avec SSIM (Structural Similarity Index) : SSIM > 0,95 = perception identique à l'original dans la majorité des cas.

Q5 : J'ai un CDN, encore besoin d'optimiser les images ?

Oui. CDN résout la distance, pas le volume. Une image 5 Mo non optimisée, même servie depuis le bord réseau, reste 5 Mo à télécharger. Conversion de format, multi-tailles et compression réduisent le volume de 80-95 % — effet bien plus fort qu'un CDN seul.

Q6 : Quelles alternatives européennes à Cloudinary pour transformation d'images ?

Scaleway Image Processing (France) : redimensionnement et conversion WebP/AVIF, facturation à l'appel, données en France. Imgproxy (open source, auto-hébergeable) : déployable sur OVH ou Scaleway Elements pour un setup 100 % souverain. Cloudflare Images : US-based mais edge européen correct, bon compromis.

Références

#performance web#optimisation image#lazy loading#images responsives#CDN#Core Web Vitals
H

Rédigé par

Harvey Zhang

Co-fondateur & CTO

Ingénieur backend devenu architecte, il offre une analyse technique approfondie des infrastructures d'hébergement d'images.