Diviser par 2 le poids de vos pages web : checklist technique 2026

Le poids moyen d'une page web a doublé en 10 ans. 2,4 Mo en 2024 contre ~1,2 Mo en 2014, selon le rapport HTTP Archive. Et cette tendance n'est pas une fatalité : sur la majorité des sites, on peut diviser ce poids par 2 voire par 3, sans aucune dégradation de l'expérience utilisateur — souvent avec une amélioration nette à la clé.

Cet article est une checklist technique focalisée sur un seul objectif : réduire le poids transféré. C'est l'un des trois critères mesurés par EcoIndex (avec le DOM et les requêtes HTTP), et c'est aussi le levier qui pèse le plus dans les Core Web Vitals (LCP, INP).

Là où notre checklist des 30 bonnes pratiques couvre l'écoconception en largeur, cet article va en profondeur sur le poids et rien que le poids. Avec, pour chaque levier, le gain typique en kilo-octets et un exemple concret.

Avant de commencer : comment mesurer le poids actuel

Sans mesure, pas d'optimisation. Voici comment auditer le poids actuel d'une page :

• Chrome DevTools → Network — recharger la page (Ctrl+F5), regarder le Transferred en bas du panel. C'est le poids compressé transféré sur le réseau.
• PageSpeed Insights — pagespeed.web.dev/, donne le poids total et la répartition (images, JS, CSS, fonts).
• WebPageTest — webpagetest.org, analyse plus poussée avec waterfall détaillé.
• EcoIndex — donne le poids transféré dans son rapport. Voir notre guide complet EcoIndex.

Notez les chiffres avant d'optimiser — ce sont eux qui valideront chaque action.

1. Optimiser les images : 50-70 % du poids potentiel

Les images représentent 60 à 70 % du poids d'une page web moyenne. C'est le premier endroit où regarder, et de très loin.

Convertir en WebP ou AVIF

Gain typique : 30 à 50 % sur le poids des images.

WebP réduit de 25-35 % vs JPEG à qualité équivalente. AVIF, plus récent, va jusqu'à 50 %. Tous deux supportés par les navigateurs modernes (>95 % de couverture).

Outils de conversion :

# WebP (cwebp - Google)
cwebp -q 80 input.jpg -o output.webp

# AVIF (sharp - Node.js)
sharp input.jpg -o output.avif --avif --quality 60

# Batch avec sharp-cli
for f in *.jpg; do sharp "$f" -o "${f%.jpg}.webp" --webp --quality 80; done

En production, automatiser via :

• Next.js : next/image (config images: { formats: ['image/avif', 'image/webp'] }).
• WordPress : plugins ShortPixel, Imagify, Optimole.
• CDN : Cloudflare Image Resizing, Bunny.net Image Engine.

Redimensionner aux dimensions d'affichage

Gain typique : 50-80 % sur les images mal dimensionnées.

Servir une image de 4 000 px de large pour l'afficher en 800 px = 4x trop lourd. Le navigateur télécharge tout et redimensionne à l'arrivée — gaspillage total.

Solution : utiliser srcset et sizes pour servir la bonne taille selon l'écran :

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w,
          /photo-800.webp 800w,
          /photo-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="..."
  loading="lazy"
  width="800"
  height="600"
/>

Sur Next.js, next/image le fait automatiquement. Sur WordPress, les plugins d'optimisation génèrent les variantes au upload.

Compresser plus agressivement

Gain typique : 10-20 % supplémentaire.

La qualité par défaut de la plupart des outils est conservative (90-95). Pour le web, 70-80 est largement suffisant sur du JPEG/WebP, 55-65 sur de l'AVIF. Au-delà, l'œil humain ne perçoit plus la différence.

Tester en A/B avec un échantillon avant de déployer en masse — certaines photos (peau, dégradés subtils) demandent plus de qualité.

Lazy-loading natif

Gain typique : réduit le poids initial de 40-70 % sur les pages avec beaucoup d'images.

Ajouter loading="lazy" sur les <img> sous la ligne de flottaison. Le navigateur ne charge l'image qu'au scroll. Aucune lib JavaScript nécessaire — c'est natif HTML depuis 2019.

<!-- Image hero (au-dessus de la ligne de flottaison) -->
<img src="/hero.webp" alt="..." fetchpriority="high" />

<!-- Images sous la ligne de flottaison -->
<img src="/photo-1.webp" alt="..." loading="lazy" width="800" height="600" />
<img src="/photo-2.webp" alt="..." loading="lazy" width="800" height="600" />

Toujours préciser width et height pour éviter les Cumulative Layout Shifts (CLS).

Pour les icônes : SVG inline

Gain typique : élimine 100-200 Ko de lib d'icônes type Font Awesome.

Pour les petites icônes, préférer du SVG inline plutôt qu'une lib d'icônes complète. Une icône SVG pèse 1-2 Ko, peut être stylée en CSS, et évite une requête HTTP supplémentaire.

<svg width="24" height="24" viewBox="0 0 24 24" fill="currentColor">
  <path d="M12 2L2 7v10l10 5 10-5V7l-10-5z"/>
</svg>

2. Alléger les fonts : 100-500 Ko à gagner

Une font custom non optimisée pèse 200-400 Ko par graisse. Avec 3 graisses + jeux de caractères étendus, on dépasse facilement 1 Mo de fonts inutiles.

Subsetter aux caractères utilisés

Gain typique : 40-60 % par font.

Pour un site français, le subset "latin" suffit (pas besoin du cyrillique, du chinois, des symboles mathématiques). Les fonts Google fonts permettent de spécifier le subset directement dans l'URL :

<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap&subset=latin" rel="stylesheet">

Pour les fonts hébergées en local, utiliser glyphhanger ou pyftsubset pour générer les sous-ensembles.

Format woff2 uniquement

Gain typique : 30 % vs woff, 50 % vs ttf.

En 2026, plus aucune raison d'utiliser woff, ttf ou eot. Le woff2 est supporté par tous les navigateurs modernes (97 % de couverture mondiale) et compresse beaucoup mieux.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}

Limiter les graisses

Gain typique : 200-400 Ko en supprimant les graisses inutilisées.

Audit simple : ouvrir DevTools, regarder quelles graisses sont effectivement appliquées dans le CSS. Souvent on trouve font-weight: 100, 200, 300, 400, 500, 600, 700, 800, 900 déclarées alors que le design en utilise seulement 2-3.

Sur Next.js avec next/font :

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  weight: ['400', '600'], // Seulement les graisses utilisées
  display: 'swap',
});

Option radicale : fonts système

Gain : zéro requête, zéro Ko.

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Inter, sans-serif; charge la font native du système d'exploitation. Plus rapide qu'une font custom, jamais de FOUT (Flash of Unstyled Text), zéro impact réseau.

Solution radicale, mais parfaitement valable pour beaucoup de sites — surtout les sites institutionnels où la typo personnalisée n'apporte rien de différenciant.

3. Réduire le JavaScript : 200 Ko à 1 Mo à gagner

Le JavaScript est le deuxième poste après les images sur la plupart des sites modernes. Et c'est aussi le plus coûteux : 1 Mo de JS coûte ~5x plus en CPU client que 1 Mo d'image.

Tree-shaking

Gain typique : 30-50 % sur le bundle final.

Activé par défaut sur Webpack, Vite et esbuild en mode production. Vérifier :

# Avec Webpack Bundle Analyzer
npm install --save-dev webpack-bundle-analyzer
# Puis ajouter au webpack.config.js

# Avec Vite
npm install --save-dev rollup-plugin-visualizer

Le rapport montre quelles libs prennent le plus de place. C'est souvent l'occasion de découvrir qu'on importe lodash (70 Ko) pour utiliser une seule fonction qu'on aurait pu écrire en 5 lignes.

Code splitting

Gain typique : −60-80 % sur le bundle initial.

Charger uniquement le code nécessaire à la page courante, pas l'application entière.

// Next.js / React
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <Spinner />,
});

// Astro
const islands = await Astro.glob('./components/*.astro');

Les frameworks modernes (Next.js, Astro, SvelteKit) le font automatiquement par route. Vérifier dans le DevTools → Network que seul le bundle de la page actuelle est chargé.

Auditer et supprimer les libs tierces

Gain typique : 100-500 Ko en moyenne.

Sur un site de 3-5 ans, on trouve facilement 5 à 10 scripts tiers qui ne servent plus à rien : ancien chat, ancien analytics, lib de cookie consent obsolète, A/B testing arrêté, etc.

Méthode :

1. DevTools → Network → filtrer sur JS.
2. Lister tous les scripts tiers (ceux qui ne viennent pas de votre domaine).
3. Pour chacun : "Quelqu'un consulte cette donnée ? Cette feature est-elle utilisée ?"
4. Si non, retirer. Si oui, vérifier s'il existe une alternative légère.

Alternatives légères courantes :

Lib lourde	Poids	Alternative légère	Poids
Google Analytics	~45 Ko	Plausible / Umami	~1 Ko
Intercom / Drift	~150 Ko	Crisp (basique)	~30 Ko
Moment.js	~70 Ko	date-fns ou Day.js	~6-10 Ko
Lodash (full)	~70 Ko	Imports ciblés (lodash/get)	~2 Ko
jQuery	~30 Ko	Vanilla JS	0 Ko

Minification et compression

Gain typique : 60-70 % sur le poids réseau du JS.

• Minification activée par défaut sur tous les bundlers modernes en production.
• Compression Brotli côté serveur — meilleure que gzip de 15-25 %.

Vérifier dans DevTools → Network → cliquer sur un fichier JS → onglet Headers → content-encoding: br (Brotli) ou gzip. Si rien, optimiser la config serveur.

4. Optimiser le CSS : 50-200 Ko à gagner

Purge CSS

Gain typique : 70-90 % sur le CSS final.

Tailwind, Bootstrap, ou n'importe quel framework CSS contient des milliers de classes — dont vous utilisez 5 à 10 %. La purge supprime les inutilisées.

• Tailwind v3+ : purge native via le scan des templates (configuration content dans tailwind.config.js).
• Frameworks classiques : PurgeCSS en post-traitement.

Gain typique : un CSS Tailwind purgé pèse 10-20 Ko en production, contre 3-4 Mo non purgé.

Critical CSS inline

Gain typique : améliore LCP de 200-500 ms.

Le CSS bloquant le rendu retarde l'affichage. Inline le CSS critique (above-the-fold) dans le HTML, et différer le reste :

<head>
  <style>
    /* Critical CSS minifié, ~5-10 Ko max */
    body { font-family: ... }
    .hero { ... }
  </style>
  <link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">
</head>

Frameworks modernes (Next.js, Astro, SvelteKit) le font automatiquement. Sur sites legacy, outils comme critical (npm) automatisent l'extraction.

5. Compression réseau : 60-80 % gratuit

C'est le levier le plus mécanique de tous : activer la compression côté serveur réduit instantanément le poids transféré sans modifier une ligne de code.

Brotli > gzip

Gain typique : 15-25 % de mieux que gzip sur HTML/CSS/JS.

• Activé par défaut sur Vercel, Netlify, Cloudflare, AWS CloudFront.
• À configurer sur nginx, Apache, Caddy si serveur custom.

Configuration nginx :

brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;
brotli_comp_level 6;

Vérification : DevTools → Network → fichier HTML/CSS/JS → onglet Headers → content-encoding: br.

Cache headers

Gain : aucun téléchargement pour les visites récurrentes.

Sur les assets statiques avec hash dans le nom (main-abc123.js) :

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

Le navigateur ne re-télécharge plus jamais ces fichiers tant que leur hash ne change pas. Sur les pages HTML, cache plus court (5 min à 1 heure) selon fréquence de mise à jour.

Récapitulatif : à quoi s'attendre

Voici les gains cumulés observés sur un site type vitrine de 2,4 Mo non optimisé :

Action	Gain	Poids après
Point de départ	—	2,4 Mo
Images en WebP	−500 Ko	1,9 Mo
Redimensionnement images	−400 Ko	1,5 Mo
Lazy-loading	(réduit le poids initial uniquement)	1,1 Mo (initial)
Fonts subsettées + woff2	−200 Ko	0,9 Mo
Tree-shaking + purge	−150 Ko	0,75 Mo
Suppression scripts tiers	−200 Ko	0,55 Mo
Compression Brotli	(sur poids transféré)	~0,4 Mo transféré

Résultat typique : un site qui pesait 2,4 Mo non optimisé tombe à 400-550 Ko transférés, soit une réduction de 75-80 %. Et le score EcoIndex passe généralement de D (45) à A (85) dans la foulée.

Questions fréquentes

Quel est le poids cible idéal pour une page web ?

L'objectif raisonnable en 2026 : moins de 500 Ko transférés sur la page d'accueil, moins de 1 Mo sur les pages de contenu (articles, fiches produit). En dessous de 300 Ko, on est en territoire excellent (sites éco-conçus de référence). Au-dessus de 2 Mo, c'est un signal d'alerte — la médiane web mondial, mais pas un objectif souhaitable.

Le poids influe-t-il vraiment sur le SEO ?

Oui, directement via les Core Web Vitals (LCP, INP, CLS) qui sont des facteurs de ranking Google depuis 2021. Et indirectement : un site lourd a un taux de rebond plus élevé, ce qui dégrade les signaux d'engagement vus par Google. Réduire le poids améliore mécaniquement le SEO.

Combien de temps pour diviser le poids par 2 ?

Sur un site existant, 1 à 3 jours de dev suffisent pour appliquer les leviers les plus mécaniques (images, fonts, compression). Aller plus loin (audit scripts tiers, code splitting, purge CSS) demande 1 à 2 semaines selon la taille du site. Diviser par 3 ou 4 nécessite parfois une refonte plus profonde.

Les utilisateurs voient-ils vraiment la différence ?

Oui, surtout en mobile et en 4G dégradée. Une page qui passe de 2 Mo à 500 Ko se charge typiquement en 1-2 secondes au lieu de 4-6 secondes — différence très perceptible. Sur fibre, l'écart est moindre, mais le temps de rendu côté navigateur (parsing, mise en page) s'améliore aussi.

Comment maintenir le poids bas dans la durée ?

Trois pratiques : (1) monitoring du poids sur les pages clés dans la CI/CD (échec du build au-delà d'un seuil), (2) audit trimestriel des scripts tiers et des libs, (3) discipline d'équipe — chaque PR qui ajoute une dépendance doit justifier son impact poids. Voir notre guide écoconception en 7 étapes (étape 7).

Faut-il sacrifier le design pour gagner en poids ?

Non. Beaucoup des plus beaux sites du web sont aussi parmi les plus légers. La contrainte stimule la créativité : préférer une animation CSS à une vidéo, optimiser une image plutôt que la supprimer, utiliser une typo bien chargée plutôt que trois fonts différentes. La sobriété peut être très esthétique.

En résumé

• Les images représentent 60-70 % du poids d'une page moyenne — c'est le premier levier.
• Le JavaScript est le deuxième poste, et le plus coûteux côté client (CPU).
• Un site type peut être divisé par 3-4 en poids par l'application méthodique des leviers de cet article.
• Le gain SEO est automatique — Core Web Vitals améliorés, taux de rebond réduit.
• L'objectif raisonnable en 2026 : < 500 Ko sur la home, < 1 Mo sur les pages contenu.

Pour aller plus loin : nos 10 actions concrètes pour améliorer son score EcoIndex, notre checklist 30 bonnes pratiques, notre guide complet EcoIndex, notre méthode en 7 étapes, notre guide RGESN, notre comparatif des hébergeurs verts et notre guide sur la sobriété numérique en entreprise.

Si vous voulez auditer le poids actuel de votre site et structurer un plan d'allègement, parlons-en — on fait un diagnostic gratuit avec poids actuel, poids cible et liste des 5 actions prioritaires pour votre contexte. Voir aussi notre démarche écoconception web.