10 actions concrètes pour améliorer son score EcoIndex (de C à A)

Vous avez audité votre site sur ecoindex.fr et vous obtenez un C. Ou pire, un D. Vous n'êtes pas seul : la page médiane du jeu de référence d'EcoIndex obtient elle aussi un D. Mais la bonne nouvelle, c'est que passer de D à B ne demande ni refonte complète ni budget pharaonique. Une demi-douzaine d'optimisations bien ciblées suffisent dans la plupart des cas.

Cet article est la suite logique de notre guide complet sur EcoIndex. Là où le guide explique le fonctionnement et la méthodologie, celui-ci entre dans le concret : 10 actions techniques détaillées, classées par rapport gain/effort, avec pour chacune le mécanisme expliqué, l'estimation d'impact sur le score, et le code ou la commande à utiliser.

Ce sont les optimisations qu'on applique systématiquement chez Bob le développeur. Avec elles, faire passer un site de D à B est presque mécanique. Aller jusqu'à A demande un peu plus de discipline, mais c'est tout à fait à portée d'une équipe qui sait ce qu'elle fait.

Comprendre ce qu'EcoIndex mesure

Avant de plonger dans les actions, un rappel rapide. EcoIndex évalue trois critères, et tous les leviers d'amélioration agissent sur l'un ou plusieurs d'entre eux :

• Le poids transféré (Ko) : taille totale des données chargées sur la page.
• Le nombre de requêtes HTTP : chaque ressource chargée compte.
• La complexité du DOM : nombre d'éléments HTML rendus.

Une bonne stratégie d'amélioration agit sur les trois en parallèle. Les actions ci-dessous sont classées par impact moyen : celles du haut donnent le plus gros saut de score pour le moins d'effort.

1. Compresser et convertir les images en WebP ou AVIF

Impact estimé : quelques points de score. Le poids ne compte que pour un sixième de la formule : diviser par deux une page de 2,4 Mo rapporte environ 4 points. Les images restent le premier poste de poids, avec environ 1 Mo sur les 2,9 Mo de la page d'accueil médiane sur ordinateur (HTTP Archive, Web Almanac 2025).

Le mécanisme : WebP réduit la taille de 25-35 % par rapport au JPEG à qualité visuelle équivalente. AVIF, format plus récent, va jusqu'à 50 % de réduction. Les deux sont supportés par tous les navigateurs modernes (>95 % de couverture).

Comment l'appliquer :

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

# Conversion AVIF avec sharp-cli (Node.js)
npx sharp-cli -i input.jpg -o output.avif -f avif -q 60

En production, utilisez des outils automatiques :

• Next.js : next/image génère WebP/AVIF à la volée. Activer dans next.config.js : images: { formats: ['image/avif', 'image/webp'] }.
• WordPress : plugins comme ShortPixel, Imagify, ou Optimole.
• CDN : Cloudflare Images, Bunny Optimizer.

Ordre de grandeur calculé avec la formule officielle : à DOM et requêtes inchangés, une page qui passe de 2,4 Mo à 1,1 Mo gagne environ 5 points de score EcoIndex. Pour aller plus loin sur la réduction du poids des pages (images, fonts, JS, CSS), voir notre checklist technique dédiée.

2. Activer le lazy-loading natif

Impact estimé : +3 à +8 points. Réduit le nombre de requêtes initiales en chargeant les images uniquement quand elles entrent dans la viewport.

Comment l'appliquer : ajouter loading="lazy" sur toutes les balises <img> situées sous la ligne de flottaison. Aucune lib JavaScript nécessaire, c'est un attribut HTML natif depuis 2019.

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

À noter :

• Toujours préciser width et height pour éviter les Cumulative Layout Shifts (CLS).
• Ne pas mettre loading="lazy" sur l'image hero (au-dessus de la ligne de flottaison) : au contraire, utiliser fetchpriority="high" pour la prioriser.
• Pour les iframes (vidéos YouTube embarquées), même attribut : <iframe loading="lazy">.

Ordre de grandeur : sur un blog avec 20 images, le nombre de requêtes initiales tombe de 25 à 6, soit environ 3 points de score pour la seule part des requêtes, plus le poids des images non chargées. L'analyse d'ecoindex.fr fait toutefois défiler la page jusqu'en bas, ce qui peut charger une partie des images différées.

3. Subsetter les fonts custom (ou passer aux fonts système)

Impact estimé : +3 à +6 points. Une font custom non optimisée pèse 200 à 400 Ko par graisse. Avec 3 graisses (regular, semibold, bold) et 2 jeux de caractères (latin + symboles), on arrive vite à 1 Mo de fonts inutiles.

Trois niveaux d'optimisation :

1. Subsetter : ne charger que les caractères utilisés. Pour un site français, le subset "latin" suffit (gain 40-60 %).
2. Format woff2 uniquement : c'est le seul format à utiliser en 2026, supporté partout, plus compressé que woff.
3. Passer aux fonts système (option radicale mais très efficace) : font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;. Zéro requête, zéro Ko, et un rendu natif.

Avec Next.js :

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

const inter = Inter({
  subsets: ['latin'],
  weight: ['400', '600'],
  display: 'swap',
});

Gain réel : page de 2,1 Mo passant à 1,7 Mo après subsetting + format woff2. Et zéro requête bloquante au rendu si on utilise font-display: swap.

4. Supprimer les scripts tiers inutiles

Impact estimé : +5 à +12 points. Les scripts tiers (analytics, chat, marketing automation, A/B testing) s'accumulent au fil des années. Sur un site de 5 ans, on trouve souvent 8 à 15 scripts dont plus personne ne se souvient.

La méthode :

1. Ouvrir DevTools → onglet Network → filtrer sur JS.
2. Lister tous les scripts tiers chargés.
3. Pour chacun, demander : "Quelqu'un consulte-t-il cette donnée ?" Si la réponse est non ou floue, supprimer.
4. Pour ce qui reste, vérifier les alternatives légères : un Plausible (2,5 Ko) à la place de Google Analytics (135 Ko gzippés, selon Plausible), un Crisp ou tout simplement un email à la place d'un chat lib lourde.

Quick wins fréquents :

• Hotjar / Mouseflow → souvent jamais consultés, retirer.
• Lib de cookie consent obsolète → migrer vers une alternative légère type Tarteaucitron ou un composant maison.
• Tag Manager bourré de tags zombies → audit annuel obligatoire.

Gain réel : un client passé de 12 scripts tiers à 4. Poids de page 3,2 Mo → 1,8 Mo. Score EcoIndex : E (38) → B (74).

5. Passer en Static Site Generation (SSG)

Impact estimé : indirect. EcoIndex ne mesure que la taille du DOM, le nombre de requêtes et le poids transféré : le mode de rendu ne change la note que si la page servie devient plus légère. Si votre contenu n'est pas dynamique par utilisateur (blog, landing, vitrine, doc), le SSG est imbattable.

Pourquoi ça marche : un site SSG est servi en HTML statique pré-généré, depuis un CDN. Aucun calcul serveur entre deux builds, requêtes minimales, pas de base de données interrogée à chaque visite.

Stack recommandée :

• Next.js en mode output: 'export' (pour Next.js 13+).
• Astro : encore plus optimisé pour les sites de contenu, JS minimal par défaut.
• Hugo : pur Go, ultra rapide, parfait pour la doc et les blogs.

À éviter : les sites Next.js / Nuxt avec un Server-Side Rendering systématique alors que le contenu est statique 99 % du temps. C'est un gaspillage de ressources serveur, que le score EcoIndex ne voit d'ailleurs pas : il ne mesure que la taille du DOM, le nombre de requêtes et le poids transféré.

Gain réel : refonte d'un blog WordPress (note D) en Astro statique → note A directement, sans autre optimisation.

6. Minifier et compresser (Brotli)

Impact estimé : +2 à +5 points. Compression réseau standard, mais souvent mal configurée.

Deux choses à vérifier :

1. Minification CSS/JS activée en production. La plupart des bundlers (Vite, Webpack, esbuild) le font par défaut, mais à vérifier sur les sites legacy.
2. Compression Brotli au lieu de gzip côté serveur. Brotli compresse 14 à 21 % mieux sur le HTML/CSS/JS textuel.

Comment vérifier : DevTools → Network → cliquer sur une ressource → onglet Headers → chercher content-encoding: br (Brotli activé) ou gzip. Si c'est gzip ou rien, optimiser.

Configuration nginx (directives du module ngx_brotli, à ajouter à nginx à la compilation) :

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

Sur Vercel, Netlify, Cloudflare : Brotli est activé par défaut. Sur OVH mutualisé ou un VPS bricolé : à vérifier.

7. Réduire la profondeur du DOM

Impact estimé : le plus fort de la formule, qui pondère le DOM par 3. Une page avec 1500 nœuds DOM est lente à parser et pénalisée par EcoIndex. La même refactorisée à 600 nœuds gagne environ 18 points de score, à requêtes et poids inchangés.

D'où vient la lourdeur :

• Wrappers inutiles : <div><div><span><span>... sans raison structurelle. Souvent généré par des outils no-code ou des frameworks CSS comme Bootstrap mal utilisés.
• Listes excessives : afficher 200 articles sur la home alors que 12 suffisent.
• HTML générique non sémantique : <div> partout au lieu de <article>, <section>, <nav>.

Comment auditer : DevTools → console → document.querySelectorAll('*').length. Si > 1000, il y a du gras.

Bénéfice annexe : un DOM léger améliore aussi l'accessibilité (lecture d'écran), le SEO, et la vitesse de rendu.

8. Choisir un hébergeur à mix énergétique faible

Impact sur le score et sur les estimations d'EcoIndex : aucun. EcoIndex n'évalue pas l'hébergeur, et ses estimations de gCO2 et d'eau se déduisent du seul score. Le choix de l'hébergeur joue sur l'empreinte réelle du site, pas sur la note.

Hébergeurs recommandés en France :

• Scaleway : refroidissement adiabatique sur le datacenter DC5 (Paris), électricité éolienne ou hydraulique sous garanties d'origine, PUE moyen de 1,37 en 2024.
• Infomaniak (Suisse, data centers en Suisse) : électricité 100 % renouvelable certifiée.
• PlanetHoster : 100 % d'énergie renouvelable annoncée sur ses centres de données (Canada, France, Suisse), mutualisé adapté aux sites vitrines.

Hébergeurs à éviter pour des sites européens : datacenters US ou Asie au mix carboné élevé, sauf si nécessité métier (latence proche d'utilisateurs spécifiques).

Pour un comparatif détaillé, voir notre article Top 5 hébergeurs web verts en France.

9. Mettre en cache de manière agressive

Impact sur le score : aucun. EcoIndex ouvre la page sans données locales (cache, cookies). Le gain est ailleurs : chez un visiteur récurrent, une ressource en cache n'est pas retéléchargée.

Trois niveaux :

1. Headers HTTP : Cache-Control: public, max-age=31536000, immutable sur les assets statiques (avec hash dans le nom de fichier pour le cache busting).
2. CDN : Cloudflare, Bunny.net, Fastly. La majorité offrent un free tier généreux.
3. Service worker : pour pré-cacher les ressources critiques côté client. Voir l'API CacheStorage et Workbox pour la mise en œuvre.

Configuration Next.js : les fichiers dans /public ne reçoivent pas de cache long par défaut : Next.js les sert avec Cache-Control: public, max-age=0, car ils peuvent changer. Pour les pages, configurer via headers() dans next.config.js.

10. Auditer en continu (CI/CD)

Impact estimé : protège les gains acquis. Un site noté A aujourd'hui peut dériver vers C en 2 ans par accumulation de scripts ajoutés sans contrôle.

La méthode :

1. Intégrer un check EcoIndex API dans la CI (GitHub Actions, GitLab CI). L'API publique est limitée à 10 analyses par jour pour un même nom de domaine : au-delà, déployer sa propre instance ou utiliser l'outil en ligne de commande du collectif.
2. Définir un seuil de score minimal par page critique (ex : score ≥ 75).
3. Faire échouer le build si la PR dégrade le score au-delà du seuil.
4. Compléter avec Lighthouse CI pour les Core Web Vitals.

Exemple GitHub Action :

- name: EcoIndex check
  run: |
    TASK=$(curl -s -X POST https://bff.ecoindex.fr/api/tasks \
      -H 'Content-Type: application/json' \
      -d '{"web_page": {"url": "https://staging.example.com"}}' | jq -r '.')
    for i in $(seq 1 30); do
      RESULT=$(curl -s "https://bff.ecoindex.fr/api/tasks/$TASK")
      [ "$(echo "$RESULT" | jq -r '.status')" = "SUCCESS" ] && break
      sleep 10
    done
    echo "$RESULT" | jq -e '.ecoindex_result.detail.score >= 75'

Cette discipline est ce qui sépare les sites éco-conçus dans le temps des sites éco-conçus au moment de la livraison. La différence est énorme à 3 ans d'horizon.

Combien de points pouvez-vous espérer gagner ?

Tableau récapitulatif des impacts cumulés selon les optimisations appliquées :

Profil de chantier	Actions	Gain de score moyen
Quick wins (1 jour)	#1, #2, #4 partiel	+8 à +15 points
Refonte technique (1 semaine)	#1, #2, #3, #4, #6	+15 à +25 points
Refonte complète (1 mois+)	Tout, dont #5 et #10	+25 à +40 points

Concrètement : un site noté D (45) peut atteindre B (72) en une semaine de travail bien ciblé. Passer à A demande généralement une refonte de stack (action #5, SSG) et une discipline d'audit continu (action #10).

Questions fréquentes

Quelle action a le plus d'impact ?

Sur la majorité des sites, la combinaison #1 (compression images) et #4 (nettoyage scripts tiers) est la plus rapide à mettre en place. Si vous ne deviez en faire que deux, ce sont celles-ci.

Combien de temps pour passer de D à A ?

Pour un site standard : entre 1 semaine et 1 mois de travail technique, selon l'état initial et la stack. Le passage de D à B est rapide et mécanique. Le passage de B à A demande une refonte plus profonde (souvent SSG).

Faut-il refaire le site pour atteindre A ?

Non, pas systématiquement. Beaucoup de sites peuvent passer à B ou A par optimisation incrémentale, sans refonte. La refonte devient nécessaire si la stack initiale est intrinsèquement lourde (CMS surchargé de plugins, framework JS mal exploité).

Ces actions valent-elles aussi pour le SEO ?

Oui, intégralement. Un site qui passe de D à A sur EcoIndex améliore aussi ses Core Web Vitals (LCP, CLS, INP) et donc son ranking Google. C'est le double bénéfice de l'écoconception : moins de CO2 et meilleur SEO.

Comment savoir laquelle de ces actions appliquer en priorité ?

Faites d'abord un audit EcoIndex sur 5 à 10 pages représentatives de votre site. Le rapport détaille les 3 critères (DOM, poids, requêtes) et indique lequel pèse le plus. Vous saurez alors si votre problème principal est les images, les scripts, ou la structure HTML.

En résumé

• Les 3 leviers les plus puissants : compression images (#1), suppression scripts tiers (#4), passage en SSG (#5).
• Un site type peut gagner +15 à +25 points en une semaine de travail ciblé.
• Le passage de D à B est rapide et mécanique. De B à A demande discipline et SSG.
• L'audit continu en CI/CD (#10) est ce qui maintient les gains dans la durée.
• Les optimisations EcoIndex servent aussi votre SEO (Core Web Vitals).

Si vous voulez auditer votre site et structurer un plan d'action concret, parlons-en. On fait un diagnostic gratuit (score EcoIndex + 3 actions prioritaires identifiées) avant toute estimation. Voir aussi notre guide complet EcoIndex, notre guide RGESN (l'audit qualitatif complémentaire), notre checklist des 30 bonnes pratiques d'écoconception web pour la version exhaustive, notre méthode en 7 étapes pour éco-concevoir un site (cadre projet complet), notre checklist technique pour diviser par 2 le poids des pages et notre guide sur la sobriété numérique en entreprise, sans oublier notre démarche écoconception web, ainsi que notre annonce Bob le développeur, signataire de Planet Tech'Care.