RGESN for developers, the front-end criteria to apply (v2)

Key points

• The 2024 RGESN has 78 criteria in nine themes, and only part of them is decided in the code.
• It is not mandatory for a private company, but a site that claims to follow it must be able to prove it.
• On the front end, the criteria are mostly about media, images, fonts, caching and compression.
• Part of it can be checked on every deployment in CI, the rest needs a declaration.

If you build websites or applications for French clients, you have probably met the acronym RGESN in a brief, a tender or an article about eco-design. This guide is written for the people who write the code. We explain where the framework comes from, what it requires (which is less than people sometimes say), and then, criterion by criterion, what the front-end ones ask for in a web project. The framework itself is published in French, so the official links below lead to French pages, and we translate the criteria where we quote them.

What the RGESN is and who published it

RGESN stands for Référentiel général d’écoconception de services numériques, the general eco-design framework for digital services. The 2024 version was published on 17 May 2024 by Arcep and Arcom (the French regulators for telecoms and for audiovisual media), together with ADEME, DINUM and the CNIL, according to the Arcep press release. The government’s ecoresponsable.numerique.gouv.fr portal gives 28 May 2024 instead, and we keep the press release date since it is the most direct source. The lists of partners also differ a little from one page to another, so we do not name them all.

Its legal basis is article 25 of the law of 15 November 2021, known as the REEN law. The 2024 version is the second one, the first dating from 2022 according to a secondary source, and it is the one people sometimes call “RGESN v2”. The official PDF is the reference if you want to read the whole thing.

How it is organised

The 2024 version has 78 criteria split into nine themes, according to Arcep. These are strategy, specifications, architecture, UX/UI, content, front-end, back-end, hosting and algorithms. Each criterion is written as a question, such as “does the digital service only contain animations, videos and sounds whose autoplay is disabled?”.

This split matters to a developer, because only part of the framework is played out in code. The first themes (strategy, specifications, architecture) are rather about how a project is run, and hosting or algorithms often depend on choices that are not the developer’s to make. In practice, most of what you can do from a code editor sits in UX/UI, content and what the framework calls front-end. For the first four themes, the portal counts 10 criteria for strategy, 10 for specifications, 7 for architecture and 15 for UX/UI.

Who it applies to

The answer needs some nuance. The RGESN itself is a non-binding document, as the portal says on its regulation page. No text tells a private company “you must apply the RGESN or pay a fine”, so anyone searching for “RGESN mandatory” will find a framework that you adopt by choice, or because a client, a local authority or a tender asks for it.

Two things are still worth keeping in mind. The first is that some public bodies, local authorities in particular, seem to have obligations of their own (a responsible digital strategy, for example), whose details and thresholds are not confirmed by an official page (a population threshold circulates in secondary sources, without confirmation). If you work for a local authority, check what applies to it.

The second is that an eco-design declaration is optional, but any public communication that refers to the RGESN is open to being checked. Saying “our site complies with the RGESN” is therefore a claim you need to be able to back up, which ties in with our guide on the 2024/825 directive and websites.

The criteria that touch the front-end

Here we go through the criteria whose wording is about things you control in code or in how resources are served. Each one links to the official criterion, and the numbers follow the pattern 4.8, 6.3 and so on.

Media, animations and fonts

Criterion 4.1 asks that animations, videos and sounds do not autoplay. In code, that means no autoplay attribute on a <video> or <audio>, and playback that starts from an action of the person visiting the page.

<video controls preload="none" poster="/img/demo.webp" src="/media/demo.mp4"></video>

In the same area, 4.2 targets infinite scroll (pagination or a “show more” button does the job), 4.6 only accepts videos, sounds and animations that carry information, and 4.7 asks you to choose the most frugal option between text, image, audio or video, depending on the need. An SVG diagram or a sentence is often enough where a decorative video would have gone.

Criterion 4.8 limits the number of fonts that are downloaded. In practice, you keep one family for headings and one for body text, with only the weights you use, and you serve them from your own domain instead of a third-party service.

Requests, third-party scripts and components

4.4 asks that the user decides whether a third-party service is activated (a map, an embedded video, a social widget). You then load the element only after a click, with a placeholder image until then. 4.9, which we paraphrase, aims at avoiding needless client-server requests, such as an autocomplete that queries the server on every keystroke, or third-party scripts and fonts loaded for no good reason. A debounce of a few hundred milliseconds on a search field already solves a good part of it.

6.6, also paraphrased, asks to warn the user and get consent before a device sensor such as geolocation is activated.

Images

Three criteria are about images. 5.1 asks for a format suited to the content and context of each image (WebP or AVIF for a photo, SVG for a logo). 5.2 is about a suitable compression level for raster images, and 6.4 wants the original dimensions to match those of the display. The typical case is a 3000-pixel-wide image shown in a 400-pixel column, and srcset with sizes lets the browser pick the right size.

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

5.3 does the same job for video definition.

Weight, cache, compression and loading

Criterion 6.1 asks you to keep to a maximum weight and a request limit per screen. It is a budget, which you set as a team and follow over time. 6.2 is about caching the transferred content you control, and you answer it with a long-lived Cache-Control header on files whose name changes when their content changes. 6.3 asks for compression of resources, which means Brotli or gzip turned on at the server for HTML, CSS and JavaScript.

6.5 asks you to avoid loading unused resources for each feature, which goes through loading="lazy" on images below the fold, JavaScript split per page, and dropping libraries of which you use a single function. Finally 6.7 wants the static resources you emit to be hosted on one domain.

What Grammage checks, and which criterion it relates to

Grammage opens a page in a real browser and checks fifteen good-practice rules, nine of which cite in their references column one of the eight RGESN 2024 criteria (the full list is on the code analysis and method pages). Where the link is clear, this is how it reads.

Rule checked by Grammage	RGESN criterion	What it means
text-compression	6.3	At least 95% of text bytes over 1 KB arrive compressed in Brotli, gzip or zstd.
static-cache	6.2	Every image, font, stylesheet, script or media file has a cache duration.
image-resized	6.4	No raster image is more than twice as wide as its display.
image-lazy	6.5	Every raster image outside the first screen has loading="lazy".
font-families	4.8	At most two font families are downloaded.
no-autoplay	4.1	No video or sound starts on its own.

Three other rules only cover part of the criterion. image-formats (more than three raster images out of four in WebP or AVIF) relates to 5.1, which asks for a format suited to each image and not only those two. domains (at most five domains) relates to 6.7, which is stricter since it aims at a single domain for the static files you emit. As for no-infinite-animation, it relates to 4.1, but that criterion is about autoplay, not about loops as such. The other Grammage rules (http2, redirects, http-errors, font-woff2, meta-description) have no clear link with a criterion, and we do not invent one.

What Grammage does not check

Grammage measures technical signals on a page, it does not fill in a framework for you. Within the front-end scope, it therefore checks neither infinite scroll (4.2), nor third-party services being activated on demand (4.4), nor how frugal the choice between text, image, audio and video is (4.6 and 4.7), nor the compression level of images (5.2), nor video definition (5.3), nor consent before a sensor is used (6.6). Criterion 4.9 is only partly covered, by the no-polling rule, which Grammage does not formally tie to that criterion. For 6.1, it does measure weight and number of requests, but it compares them with reference points and does not apply a ceiling you would have set.

The themes of strategy, specifications, architecture, back-end, hosting and algorithms are outside what a page measurement can say. A Grammage score is therefore not a declaration of compliance with the RGESN, and it does not replace the eco-design declaration, which covers the whole service. It does give you measured facts to attach to your own work on the criteria.

Bringing it into CI

The point of a framework like this is that it does not get lost between two releases. If you check it once a year, one forgotten image or one script added in a hurry is enough to undo what had been gained. So it makes more sense to hook it to the deployment, the way you would a test or a linter.

With the CI/CD integration, Grammage audits the live site and analyses its source code on every deployment, then validates the eco-design scores against the criteria that were set, which lets you see right away when a rule gets worse. The --format rgesn output lists the RGESN criteria that the rules touch, as an aid for the declaration. To know where you stand before wiring anything, the audit goes through the site page by page and shows what to fix first. And if you want to show the result to your clients, the attestation gives a result signed by Grammage, which remains an attested measurement and not a certification, since Grammage is not an accredited body.