Poids des pages : budgets de performance web et budgets carbone, comment les fixer



Depuis quelques années, le sujet revient dans presque tous les projets web, mais rarement de façon structurée. Une équipe constate que son site ralentit. Une autre veut améliorer ses Core Web Vitals. Une troisième cherche à réduire l’empreinte environnementale de son dispositif digital. Pourtant, au moment de décider, la même difficulté apparaît : combien une page peut-elle réellement « peser » avant que cela devienne un problème ?

Pour une collectivité ou une destination touristique, la question n’a rien de théorique. Une page trop lourde pénalise l’accès à l’information, dégrade le confort sur mobile, augmente la consommation de données et complique la maintenance. Elle rend aussi beaucoup plus difficiles les arbitrages entre communication, design, performance, accessibilité et écoconception. Dans le même temps, le web continue à grossir : selon le Web Almanac 2025, le poids médian d’une page d’accueil atteint 2,86 Mo sur desktop et 2,56 Mo sur mobile, les images restant le premier poste de poids.

C’est précisément l’intérêt d’un budget. Un budget de performance web permet de fixer des limites avant que le site ne dérive. Un budget carbone, lui, permet de traduire une ambition de sobriété en règles concrètes de conception, de production et de publication. L’enjeu n’est pas de poursuivre un chiffre abstrait. Il s’agit de créer un cadre de pilotage réaliste, compréhensible par les équipes et exploitable dans la durée.

Pourquoi le poids des pages est devenu un vrai sujet de pilotage

Dans une communauté d’agglomération, le site institutionnel accumule au fil des mois des bannières, des modules éditoriaux, des cartes interactives, des vidéos et des scripts tiers. Chaque ajout paraît justifié pris isolément. En revanche, personne ne regarde l’effet cumulé. Le résultat est connu : la page d’accueil devient lente, les fiches pratiques mettent du temps à s’afficher sur mobile et les équipes ne savent plus quels arbitrages faire.

Même logique côté destination touristique. Une fiche séjour, une page agenda ou une page inspiration ont souvent besoin de visuels, parfois de cartes, parfois de widgets externes. Mais sans règle commune, la recherche d’attractivité se transforme vite en inflation technique. Or une page lourde ne pénalise pas seulement la vitesse. Elle pèse aussi sur l’expérience utilisateur, sur la sobriété numérique et, très souvent, sur l’accessibilité.

C’est d’ailleurs tout l’intérêt d’un budget de performance tel que le définit web.dev : un ensemble de limites appliquées à des métriques qui influencent les performances, comme le poids total d’une page, son temps de chargement sur réseau mobile ou le nombre de requêtes HTTP. L’objectif n’est pas seulement technique. Le budget sert de point de référence pour guider les décisions de design, de fonctionnalités et de technologies.

Budget de performance et budget carbone : de quoi parle-t-on exactement ?

Un budget de performance web correspond à une limite fixée à l’avance sur des indicateurs qui ont un effet direct sur la rapidité et la qualité de chargement. Ce budget peut porter sur le poids de la page, sur le volume d’images, sur le poids JavaScript, sur le nombre de requêtes ou encore sur certains indicateurs perçus par l’utilisateur.

Un budget carbone fonctionne différemment, mais il repose souvent sur les mêmes leviers. Il ne s’agit pas d’une vérité physique absolue applicable de la même façon à tous les contextes. En pratique, les équipes utilisent des indicateurs proxy, en premier lieu les données transférées, pour encadrer l’impact potentiel d’une page. Sustainable Web Design rappelle justement que le volume de données transférées est un indicateur imparfait, mais utile, car il est compréhensible, mesurable et fortement corrélé aux dérives de conception. Website Carbon explique de son côté que ses estimations reposent sur les données nécessaires au chargement d’une page et l’énergie associée à ce transfert.

Autrement dit, le budget carbone ne remplace pas le budget de performance. Il lui ajoute une intention de sobriété. Dans les faits, les deux se recoupent largement : images trop lourdes, JavaScript excessif, polices inutiles, scripts tiers superflus, vidéos mal intégrées. Les causes sont souvent les mêmes. Les bénéfices aussi.

Pourquoi ces budgets sont particulièrement utiles aux collectivités et aux destinations touristiques

Dans les collectivités, le budget a une vertu simple : il transforme un sujet technique en outil de gouvernance. Il aide à cadrer les prestataires, à objectiver les discussions avec les équipes internes et à éviter que les pages les plus stratégiques deviennent les plus fragiles.

Pour une destination touristique, l’enjeu est proche, mais avec une tension supplémentaire. Le site doit donner envie, tout en restant rapide, lisible et sobre. Une logique de budget permet justement d’éviter l’opposition stérile entre attractivité et performance. Une page peut rester éditorialement riche à condition que ses composants soient choisis, dimensionnés et priorisés intelligemment.

Quels indicateurs faut-il surveiller en priorité ?

Le premier indicateur reste le plus simple : le poids total transféré au chargement initial. C’est celui que les équipes comprennent le plus facilement et celui qui permet souvent de repérer les dérives les plus évidentes. Il doit cependant être lu avec nuance. Une page d’accueil, une page article, une fiche événement, une page agenda ou une fiche hébergement n’ont pas les mêmes besoins ni les mêmes usages.

Le deuxième indicateur à suivre est la répartition du poids. Sur la plupart des sites, les images représentent la part la plus importante. Le Web Almanac 2025 confirme qu’elles constituent le principal poste de poids sur mobile comme sur desktop. Cela veut dire qu’un budget crédible ne doit pas se limiter à un chiffre global. Il doit aussi distinguer les médias, le JavaScript, les polices et éventuellement les scripts tiers.

Le troisième indicateur concerne justement le JavaScript. En 2024, le Web Almanac relève un poids médian JavaScript de 558 Ko sur mobile et 613 Ko sur desktop, en hausse de 14 % sur un an. C’est un signal important, car les scripts ne ralentissent pas seulement le téléchargement. Ils pèsent aussi sur le rendu, l’interactivité et les appareils modestes.

Enfin, il est utile d’associer le budget à quelques métriques d’expérience utilisateur. Les Core Web Vitals restent ici un cadre pratique : un bon LCP se situe à 2,5 secondes ou moins, un bon INP à 200 ms ou moins, et un bon CLS à 0,1 ou moins, en visant le 75e percentile des visites. Le budget de poids ne remplace pas ces indicateurs, mais il aide à éviter certaines causes structurelles de dégradation.

Comment fixer un budget sur un site existant

La première erreur consiste à définir un seuil sans mesurer l’existant. Sur un site déjà en ligne, il faut commencer par observer un échantillon de pages réellement représentatif. Pour une collectivité, cela peut inclure la page d’accueil, une page service, une actualité, une page démarche, un agenda et une page contact. Pour un OGD, on ajoutera volontiers une fiche hébergement, une fiche activité, une page inspiration, une page événement et une page pratique.

Cette phase sert à établir une ligne de base. Il ne s’agit pas encore de décider ce qui est « bon » ou « mauvais », mais de comprendre où se situe le site aujourd’hui. L’objectif est ensuite d’identifier les écarts les plus coûteux. Dans la majorité des cas, les dérives viennent de quatre familles : des images mal dimensionnées ou mal compressées, des scripts tiers nombreux, des composants lourds sur la page d’accueil et des choix de design qui multiplient les ressources chargées.

À partir de là, il devient possible de fixer des seuils par type de page. C’est un point essentiel. Il est rarement pertinent d’imposer exactement le même plafond à tous les gabarits. Une page article de fond, une fiche pratique et une page d’accueil n’ont ni la même fonction ni la même densité attendue. En revanche, chacune peut disposer d’un cadre clair, avec un objectif cible, un seuil d’alerte et un seuil bloquant.

Comment fixer un budget dans une refonte ou un nouveau site

Dans un projet neuf, le meilleur moment pour définir un budget n’est pas la recette finale. C’est le cadrage. Trop de projets parlent de sobriété ou de performance en intention, puis repoussent les vraies décisions à la fin. À ce stade, il est généralement trop tard : les choix de maquette, de CMS, de composants, de médias et de trackers sont déjà ancrés.

Un budget utile doit donc figurer dès le cahier des charges et les ateliers de conception. Cela ne veut pas dire figer chaque détail en amont. Cela signifie poser des règles du jeu. Par exemple, quels types de pages doivent rester particulièrement légers ? Quels composants riches sont réellement nécessaires ? Quels scripts tiers sont considérés comme indispensables ? À quelles conditions une vidéo peut-elle être intégrée ? Quel niveau de contrôle est attendu avant mise en ligne ?

Dans cette logique, le budget sert autant à cadrer la conception qu’à encadrer la production. Il oblige chaque choix à être justifié. Une carte interactive, un carrousel, une police externe ou un widget social ne sont plus des ajouts neutres. Ils deviennent des décisions avec un coût.

Une méthode simple pour définir des seuils réalistes

La méthode la plus robuste reste aussi la plus pragmatique.

La première étape consiste à classer les pages par rôle. Certaines pages doivent être consultables très vite, même avec un réseau moyen : accueil, pages d’accès rapide, horaires, contact, démarches, informations pratiques, agenda, pages « venir », « réserver », « se déplacer ». Ce sont les meilleures candidates pour des budgets serrés.

La deuxième étape consiste à distinguer ce qui relève du socle et ce qui relève de l’exception. Une page éditoriale standard ne doit pas être conçue comme une page de campagne ou une page événementielle enrichie. En revanche, même une page plus riche doit rester encadrée. Le but n’est pas de tout uniformiser, mais d’éviter l’absence totale de limite.

La troisième étape consiste à documenter le budget dans un tableau de pilotage simple, avec pour chaque gabarit le poids cible, le plafond à ne pas dépasser, les postes les plus sensibles et les validations nécessaires en cas de dépassement. Ce document n’a pas besoin d’être sophistiqué. Il doit surtout être compris par l’AMO, les chefs de projet, les équipes éditoriales et les prestataires.

La quatrième étape consiste à intégrer le contrôle dans la vie du site. web.dev recommande d’ailleurs d’incorporer les budgets dans les outils de build ou les processus de vérification afin de détecter les écarts avant qu’ils n’atteignent la production. Même sans chaîne très industrialisée, un contrôle régulier sur les gabarits stratégiques suffit déjà à éviter beaucoup de dérives.

Les arbitrages les plus fréquents

Le premier arbitrage concerne presque toujours les images. Sur un site public ou touristique, elles jouent un rôle éditorial fort. Mais elles doivent être dimensionnées selon leur usage réel. Une image plein écran sur desktop n’a pas à être servie de la même façon à un mobile. Ici, le budget n’interdit pas le visuel. Il oblige à choisir le bon format, la bonne taille et le bon niveau de compression.

Le deuxième arbitrage porte sur les scripts tiers. Outils de mesure, cartes, vidéos, widgets externes, modules de personnalisation ou d’avis clients ont un coût souvent sous-estimé. Ils dégradent non seulement le poids, mais aussi l’interactivité. Quand l’INP se dégrade, la cause n’est pas toujours visible à l’œil nu. Elle se niche fréquemment dans des scripts chargés par défaut.

Le troisième arbitrage touche au design. Certains effets sont séduisants en maquette, mais coûteux en production. Là encore, le budget permet une discussion plus saine. Il ne s’agit pas d’appauvrir le site. Il s’agit de vérifier que la richesse perçue apporte une vraie valeur d’usage.

Les erreurs à éviter

La première erreur consiste à fixer un chiffre universel pour tout le site. Cette approche paraît simple, mais elle fonctionne mal. Elle ne tient ni compte des usages ni de la diversité des gabarits.

La deuxième erreur est de copier un seuil vu ailleurs sans rapport avec son contexte. Un budget doit être ambitieux, mais atteignable. S’il est irréaliste, il sera contourné. S’il est trop permissif, il ne servira à rien.

La troisième erreur consiste à traiter le budget comme un sujet purement technique. Dans la réalité, les dérives viennent souvent autant des contenus, du design et de la gouvernance que du développement.

La quatrième erreur est de ne contrôler que le poids global. Une page peut afficher un total acceptable tout en embarquant trop de scripts, trop de polices ou trop de requêtes. Le suivi doit rester un minimum granulaire.

Ce qu’il faut retenir

Le poids des pages n’est pas seulement un indicateur de performance. C’est un outil d’arbitrage. Bien utilisé, il aide à concilier expérience utilisateur, accessibilité, sobriété et qualité éditoriale.

Pour une collectivité ou une destination touristique, la bonne approche n’est pas de chercher un chiffre miracle. Elle consiste à définir des budgets par type de page, à distinguer seuil cible, seuil d’alerte et seuil bloquant, puis à intégrer ce cadre dans la gouvernance du site.

Autrement dit, un bon budget n’est pas celui qui impressionne sur le papier. C’est celui qui aide réellement les équipes à décider.


FAQ

Qu’est-ce qu’un budget de performance web ?

Un budget de performance est un ensemble de limites fixées à l’avance sur des métriques qui influencent la rapidité et la qualité de chargement d’un site, comme le poids d’une page, le nombre de requêtes ou certains temps de chargement. web.dev le présente comme un outil d’aide à la décision pour le design, les fonctionnalités et la technique.

Quelle différence entre budget de performance et budget carbone ?

Le budget de performance vise d’abord la rapidité et la qualité d’usage. Le budget carbone cherche à encadrer l’impact environnemental potentiel. Dans la pratique, ils utilisent souvent les mêmes leviers, notamment le volume de données transférées, les médias et les scripts.

Faut-il le même budget pour toutes les pages ?

Non. Une page d’accueil, une fiche pratique, une actualité ou une fiche touristique n’ont pas les mêmes besoins. Il est généralement plus pertinent de définir des budgets par gabarit ou par famille de pages.

Le poids d’une page suffit-il à mesurer sa qualité ?

Non. C’est un indicateur utile, mais insuffisant à lui seul. Il faut aussi observer la répartition du poids, le nombre de requêtes, le JavaScript chargé et les métriques d’expérience comme le LCP, l’INP et le CLS.

Quels éléments font le plus souvent dériver les budgets ?

Les images surdimensionnées arrivent très souvent en tête, suivies par le JavaScript, les scripts tiers, les polices web et certains composants riches comme les cartes, vidéos ou carrousels. Le Web Almanac confirme que les images restent le principal poste de poids des pages web.

À quel moment faut-il définir ces budgets ?

Le plus tôt possible. Dans une refonte, le bon moment est le cadrage. Sur un site existant, il faut commencer par mesurer l’existant sur un panel de pages représentatives avant de fixer les seuils.

Comment suivre un budget dans le temps ?

Le plus simple est d’identifier quelques gabarits stratégiques, de les mesurer régulièrement et d’intégrer un contrôle avant publication ou mise en ligne. Quand c’est possible, le suivi peut aussi être automatisé dans les outils de build.

Peut-on concilier attractivité, performance et sobriété ?

Oui, à condition de raisonner en arbitrages et non en oppositions. Un site peut être visuellement riche sans devenir excessivement lourd, dès lors que les médias, les scripts et les composants sont réellement maîtrisés.


Sur le même sujet