Expertise technique
Optimiser les performances d'un site web, c'est aussi réduire son empreinte carbone. SSG, images, serverless — comment performance et sobriété se rejoignent.
Le numérique représente environ 4 % des émissions mondiales de gaz à effet de serre — un chiffre qui devrait doubler d'ici 2030 selon certaines projections. Dans ce contexte, le "green web" est devenu un sujet pris au sérieux, parfois pour de bonnes raisons, parfois pour des raisons de communication. Ce qui est peu dit, c'est que la majorité des pratiques qui réduisent l'empreinte carbone d'un site web sont exactement les mêmes que celles qui améliorent ses performances. Ce n'est pas une coïncidence : c'est une convergence structurelle.
La consommation d'énergie d'un site web se répartit sur trois niveaux :
Chaque octet transféré a un coût énergétique. Chaque calcul effectué côté serveur consomme des ressources. Chaque requête vers un service tiers (analytics, publicité, fonts, CDN externe) multiplie les allers-retours réseau.
Selon le Website Carbon Calculator, un site web moyen émet environ 0,5 g de CO₂ par page vue. Un site bien optimisé descend en dessous de 0,1 g. Sur un site recevant 10 000 visites par mois, l'écart représente 48 kg de CO₂ économisés par an — soit l'équivalent de plusieurs centaines de kilomètres en voiture.
Ces chiffres semblent modestes à l'échelle individuelle. Ils deviennent significatifs à l'échelle d'une entreprise avec plusieurs sites, d'un éditeur avec des millions de pages vues, ou d'une agence qui construit des dizaines de projets.
Ce qui est remarquable, c'est que les meilleures pratiques de performance web et les meilleures pratiques éco-responsables sont quasiment identiques. Améliorer l'une améliore l'autre automatiquement.
Un site généré statiquement — où les pages HTML sont pré-compilées et stockées sur un CDN — consomme une fraction de l'énergie d'un site dynamique qui génère chaque page à la demande via un serveur applicatif et une requête base de données.
Comparaison factuelle sur une page vitrine classique :
| Architecture | Requêtes serveur | Calcul serveur | Transfert moyen |
|---|---|---|---|
| WordPress dynamique | 1 requête PHP + 3-8 requêtes BDD | 50-200 ms CPU | 800 KB - 3 MB |
| WordPress + cache | 1 requête fichier | < 5 ms CPU | 600 KB - 2 MB |
| Next.js SSG sur CDN | Fichier statique (edge) | 0 ms CPU serveur | 80 - 300 KB |
Le site Next.js statique ne sollicite aucun serveur d'application, aucune base de données, et son poids est structurellement inférieur parce que le framework encourage les bonnes pratiques dès la conception.
Les images représentent en moyenne 50 à 70 % du poids d'une page web. C'est le premier levier pour réduire simultanément la consommation de bande passante et le temps de chargement.
Les formats modernes font une différence mesurable :
loading="lazy") évite de télécharger des images que l'utilisateur ne verra peut-être jamaisChaque script tiers — Google Analytics, Facebook Pixel, Hotjar, Intercom, boutons de partage sociaux — ajoute des requêtes réseau, du JavaScript à exécuter, et des connexions vers des serveurs externes. Ces connexions ont un coût énergétique sur les appareils des utilisateurs.
L'alternative : utiliser des outils d'analytics respectueux de la vie privée et légers comme Plausible ou Fathom (script < 1 KB contre 45 KB pour Google Analytics 4), et évaluer si chaque script tiers apporte une valeur proportionnelle à son coût.
Les fonctions serverless (Vercel Edge Functions, Cloudflare Workers) ne consomment des ressources que lorsqu'elles sont invoquées. Un serveur classique consomme de l'énergie 24h/24 même à 0 % de charge utile. Le serverless réduit structurellement la consommation d'énergie par requête servie.
Vercel, Netlify et Cloudflare — nos hébergeurs principaux — s'approvisionnent en énergie renouvelable à des degrés variables. The Green Web Foundation maintient une base de données des hébergeurs verts vérifiés, un critère que nous intégrons dans le choix d'infrastructure pour nos clients sensibles à cet enjeu.
Nous n'avons pas de "label vert" à vendre. Ce que nous faisons, c'est appliquer systématiquement les bonnes pratiques de performance — et la réduction d'empreinte carbone en est un bénéfice naturel.
Concrètement, sur chaque projet :
<Image> de Next.js (WebP/AVIF, lazy loading, dimensionnement correct)Ces pratiques sont détaillées dans notre article sur l'impact du score Lighthouse pour votre business — les métriques se recoupent complètement.
Mesures types sur nos projets récents :
Le web éco-responsable n'est pas une niche militante réservée aux organisations engagées. C'est une conséquence directe des bonnes pratiques de développement web. Un site performant est presque automatiquement un site sobre : moins de données transférées, moins de calculs serveur, moins de JavaScript inutile.
L'inverse est tout aussi vrai : un site lent est un site gourmand. Chaque méga-octet superflu transféré a un coût énergétique. Chaque requête vers un script tiers mobilise des serveurs quelque part dans le monde.
La sobriété numérique n'est pas un sacrifice — c'est une meilleure ingénierie. Et une meilleure ingénierie, c'est aussi un avantage compétitif : meilleur SEO, meilleure conversion, meilleure expérience utilisateur sur les réseaux dégradés et les appareils modestes.
Pour aller plus loin sur l'aspect technique de la performance, notre comparatif Next.js vs WordPress illustre concrètement les différences d'architecture et leurs conséquences sur les performances réelles.
Votre site est lourd et lent ? Contactez-nous pour un audit — nous identifions rapidement les gains les plus impactants, pour vos utilisateurs et pour l'environnement.
Ce sujet vous parle ?
Pas de modèle tout prêt : on part de votre métier, de vos clients et de vos couleurs pour construire le site qui vous ressemble.