Écoconception web : budget poids, images et polices (mesurable)

Beaucoup de briefs demandent un site « éco-responsable » sans critère de succès. Le risque est double : vous livrez une page d’intention sans impact technique, ou vous affichez un score marketing impossible à reproduire. L’écoconception web utile commence par une contrainte mesurable : le poids transféré et le travail CPU côté navigateur pour afficher le contenu critique.

Le poids n’est pas l’unique levier (durée de vie du contenu, sobriété fonctionnelle, hébergement, fin de vie des assets comptent aussi). Mais c’est le levier le plus actionnable pour une équipe produit web : design, contenu et développement partagent les mêmes fichiers. Un budget d’octets force les arbitrages avant la MEP, pas après un audit de conscience.

Dans une agence ou une DSI, ce budget devient un contrat interne. Le PO valide le périmètre fonctionnel. Le design limite polices et formats. Le développement refuse les imports opportunistes. La recette vérifie le seuil. Vous évitez ainsi le greenwashing : vous ne promettez pas une planète sauvée, vous livrez une page plus légère et plus prévisible.

Sur Next.js et Vercel, l’écosystème pousse déjà vers le streaming, le découpage de bundles et les images optimisées. Ces aides ne remplacent pas un budget. Sans seuil, chaque nouvelle lib, chaque hero vidéo et chaque fonte variable « au cas où » réintroduit silencieusement des centaines de kilo-octets.

Commencez par nommer les pages types (templates) qui portent 80 % du trafic ou de la valeur métier. Pour une vitrine B2B, ce sont souvent l’accueil, une page expertise, une page mission et le formulaire de contact. Pour un outil métier, ajoutez l’écran de connexion et le tableau de bord initial. Chaque template reçoit un budget distinct.

Un budget poids se décompose. Transfert document (HTML + CSS + JS + polices + images + polices icônes) sur première visite, cache froid. Poids JS exécuté au-dessus de la ligne de flottaison. Nombre de requêtes critiques. Optionnellement, poids des polices et poids des images hero isolés. Cette décomposition évite le débat stérile « la page fait 2 Mo mais c’est l’image marketing » : vous savez exactement quelle ligne dérape.

Fixez des ordres de grandeur réalistes pour votre contexte, pas des dogmes universels. Une page institutionnelle sobre peut viser un transfert initial nettement plus bas qu’un portfolio média. L’important est la cohérence : le budget doit être atteignable avec le design validé, sinon vous organisez l’échec. Documentez la méthode (outil, profil réseau, viewport) dans le dépôt ou le runbook de recette.

Intégrez le budget dans le cycle de livraison. Une mesure manuelle ponctuelle ne tient pas. Préférez un script de CI qui charge les URLs de préproduction, extrait le transfert et échoue au-delà du seuil. Sur Vercel, les Preview Deployments donnent une URL stable par PR : c’est le bon moment pour mesurer avant merge. Le budget devient alors une non-régression, comme un test unitaire.

Les images restent souvent le premier poste de poids. Avant d’optimiser un encodeur, questionnez le besoin : une photo plein écran est-elle indispensable sur mobile ? Un SVG ou une illustration vectorielle suffit-elle ? La sobriété commence au brief, pas au plugin d’optimisation. Chaque asset retiré du chemin critique évite CPU, batterie et bande passante.

Quand l’image est nécessaire, livrez la bonne dimension. Une image 2400 px affichée en 600 px CSS gaspille du transfert. Sur Next.js, le composant d’image (selon votre version et configuration) doit produire des largeurs adaptées et un format moderne (AVIF ou WebP) avec repli. Vérifiez que le CDN ou le loader ne sert pas le fichier source brut par erreur de chemin.

Les bonnes pratiques documentées côté web.dev rappellent d’optimiser les images pour la vitesse perçue et le transfert. En pratique : compressez avec un objectif qualité métier (pas « qualité 100 » par défaut), définissez width/height pour limiter le décalage de mise en page, et réservez le lazy-loading aux images hors viewport. L’image hero au-dessus de la ligne de flottaison doit rester prioritaire (fetchpriority adapté) pour ne pas dégrader l’expérience au nom de la sobriété.

Attention aux carrousels et aux galeries. Cinq slides préchargées multiplient le poids même si une seule est visible. Chargez la slide active, différéz les suivantes, et évitez les autoplays vidéo en fond de hero sauf décision produit assumée et budgétée. Une vidéo « atmosphère » non mesurée fait exploser le budget plus vite qu’une librairie JS moyenne.

Documentez une convention d’assets dans le dépôt : dossiers, suffixes de taille, formats acceptés, poids max par type (icône, illustration, photo hero). Les contributeurs contenus et design respectent alors la même règle que les développeurs. Sans convention, chaque nouvelle campagne marketing réintroduit des PNG non compressés.

Les polices web sont un poste sous-estimé. Deux familles avec plusieurs graisses et italiques peuvent dépasser 300 Ko facilement. Commencez par limiter le design system : une famille titre, une famille texte, le minimum de graisses réellement utilisées. Si une graisse n’apparaît que sur un badge rare, fusionnez-la avec la graisse voisine.

Préférez l’auto-hébergement maîtrisé (fichiers dans votre CDN / static) plutôt qu’un appel tiers non maîtrisé. Sur Next.js, l’approche locale ou via le module de polices du framework permet de contrôler le chargement, le sous-ensemble de glyphes et le swap. Un sous-ensemble latin (et symboles utiles) réduit fortement le fichier si vous n’avez pas besoin de tous les alphabets.

Utilisez `font-display: swap` (ou l’équivalent fourni par votre helper) pour éviter le texte invisible prolongé, tout en acceptant un bref FOIT/FOUT maîtrisé. Testez le rendu sur les pages longues : un swap trop agressif avec une métrique très différente peut créer un saut de mise en page. Ajustez les métriques de fallback si votre stack le permet.

Les icônes-font sont souvent un reliquat coûteux. Si vous n’utilisez que dix glyphes, une police d’icônes complète est disproportionnée. Préférez des SVG inline ou un sprite limité, surtout sur les parcours critiques. Même logique pour les emoji custom et les webfonts décoratives chargées « parce que la charte PDF les utilise ».

Mesurez le poids polices isolément dans le budget. Une régression de design (nouvelle graisse) doit apparaître dans le rapport CI comme une ligne dédiée. Ainsi le débat porte sur le bénéfice UX réel, pas sur une impression de « légèreté globale ».

Le JS coûte deux fois : transfert et exécution. Une page sobre en images peut rester lourde si elle hydrate trop de composants inutiles au premier paint. Sur Next.js, séparez clairement le contenu serveur du besoin d’interactivité client. Tout ce qui n’a pas d’état ni d’écouteur peut rester hors du bundle client.

Auditez les imports. Une lib « utile un jour » importée au niveau layout contamine toutes les routes. Préférez l’import dynamique pour les modules lourds (éditeurs, cartes, visualisations) déclenchés par action utilisateur. Vérifiez aussi les polyfills et les helpers date/i18n : ils grossissent vite si mal tree-shakés.

Les animations méritent un arbitrage. Une motion bien conçue peut rester légère (transformations CSS / compositing). Une pile d’effets sur chaque section, sans respect de `prefers-reduced-motion`, alourdit le runtime et l’accessibilité. Budgettez les librairies motion comme n’importe quel média : entrée au catalogue uniquement si le bénéfice produit est clair.

Côté analytics et tags marketing, appliquez le consentement et la charge différée. Un tag manager qui tire six pixels avant interaction ruine le budget initial. Chargez le strict nécessaire au premier écran, puis le reste après consentement ou idle. Documentez la liste des scripts autorisés : sans liste blanche, le marketing réintroduit la dette à chaque campagne.

Enfin, refusez le pattern « on ajoute une dépendance pour trois lignes ». La dette JS est cumulative. Un revue de bundle (analyseur de chunks) avant chaque release majeure coûte moins cher qu’une refonte performance improvisée six mois plus tard.

L’hébergement influence la sobriété, mais pas comme on le raconte parfois. Un CDN proche de l’utilisateur réduit la latence et peut diminuer les retransferts grâce au cache. En revanche, afficher un hébergeur « vert » sans maîtriser le poids des pages ne change pas l’essentiel : des Mo inutiles restent des Mo inutiles, quelque soit le mix électrique annoncé.

Sur Vercel, profitez du cache edge et des headers de cache corrects pour les assets versionnés. Un hash dans le nom de fichier autorise un cache long. Les HTML dynamiques demandent une stratégie plus fine (ISR, revalidation, ou rendu à la demande selon le cas). L’objectif n’est pas de tout mettre en edge par principe, mais d’éviter de régénérer et retransférer ce qui est stable.

La géographie des utilisateurs compte. Si votre audience est surtout française, optimiser pour un public mondial au prix de complexités inutiles n’est pas de la sobriété. Alignez régions de déploiement, besoins légaux et réalité trafic. Moins de hops, moins de copies chaudes inutiles, moins de surprises de facturation.

Surveillez aussi les images et fichiers servis hors de votre pipeline (liens directs vers des drives, CDN tiers non contractés, pixels). Chaque origine supplémentaire ajoute DNS, TLS et souvent du JS. Consolidez quand c’est possible. L’écoconception opérationnelle ressemble beaucoup à une bonne hygiène d’architecture front.

Une mesure unique avant MEP ne suffit pas. Le contenu évolue, les campagnes ajoutent des bannières, une nouvelle section GSAP arrive « juste pour la home ». Planifiez une mesure périodique sur les templates budgétés, idéalement automatisée. Conservez un historique simple (CSV ou tableau) pour voir la tendance, pas seulement le dernier chiffre.

Choisissez des indicateurs compréhensibles par le PO. « Transfert document cache froid » et « JS initial » parlent mieux qu’un score composite opaque. Vous pouvez corréler avec les Core Web Vitals, mais ne confondez pas performance UX et écoconception : elles se renforcent souvent, sans être identiques. Un LCP correct avec 4 Mo d’images hors viewport reste un échec de budget poids.

Quand le budget casse, traitez la cause racine. Remplacer une image par une version compressée est un correctif. Revoir le composant qui importe une lib entière est un vrai gain. Priorisez les postes les plus lourds d’abord (souvent médias, puis JS, puis polices). Documentez la décision si vous relevez exceptionnellement le budget pour un besoin métier assumé.

Formez les contributeurs. Un rédacteur qui uploade un PNG 8 Mo dans le CMS annulera votre travail. Donnez une checklist courte : format, largeur max, poids cible, pas de vidéo autoplay sans validation. L’écoconception tient dans les rituels d’équipe autant que dans le code.

Enfin, communiquez sans surpromesse. Vous pouvez dire : « nous plafonnons le transfert initial de l’accueil à X et nous le vérifions en CI ». C’est vérifiable. Évitez « site neutre en carbone » ou « divisé par trois l’empreinte » sans méthode ADEME / GreenIT explicitement appliquée et auditée.

Erreur classique : optimiser uniquement Lighthouse en lab tout en servant des assets non compressés aux utilisateurs réels (mauvais cache, mauvais loader, images CMS hors pipeline). Mesurez la production ou une preview fidèle.

Autre piège : multiplier les widgets de « compensation carbone » ou badges verts tout en chargeant des scripts tiers lourds. Le badge ne réduit pas le transfert. Il ajoute souvent une requête.

Confusion fréquente entre dark mode et écoconception. Un thème sombre n’est pas une stratégie de sobriété. Traitez-le comme un sujet UX / accessibilité, pas comme un argument environnemental.

Absence de propriétaire. Sans responsable nommé (tech lead + PO), le budget dérive. Assignez la revue poids comme une case de definition of done sur les pages critiques.

Sur-promesse commerciale. Si le discours marketing dépasse ce que la technique mesure, vous créez un risque réputationnel. Alignez fiche offre, site et runbook technique sur les mêmes formulations prudentes.

L’écoconception web crédible repose sur un budget poids par template, pas sur un slogan. Images, polices et JavaScript sont les trois leviers quotidiens ; l’hébergement et le cache amplifient ou gaspillent ces choix.

Mesurez en conditions reproductibles, automatisez le seuil en CI sur les Preview Vercel, et traitez les dépassements comme des régressions bloquantes.

Refusez les chiffres carbone improvisés. Préférez des indicateurs auditable (Ko transférés, JS initial) et des sources sérieuses quand vous évoquez l’impact environnemental du numérique.

Faites vivre la règle côté contenu et design : sans convention d’assets et sans liste blanche de scripts, le budget ne survit pas à la première campagne.