How we score

We actually load your page in Chromium — twice, once on a throttled mobile profile and once on a desktop profile — then record the same metrics as Lighthouse and score them with its official curves. In parallel, the HTTP headers go through the Mozilla Observatory scale, and accessibility is analysed by axe-core, the engine Lighthouse itself uses.

Each category yields a score out of 100. The overall score is their weighted average.

Measurement conditions. Mobile profile: 412 × 823 viewport, network capped at 1.6 Mb/s with 150 ms latency — Lighthouse’s “Slow 4G” preset — and the CPU slowed by a factor of 4. Desktop profile: 1350 × 940, unthrottled. The report’s overall score uses the mobile profile, as Google does.

How long we watch. We wait for network silence, up to ten seconds. That ceiling was three seconds until 14 August 2026, and it truncated slow pages: on gouvernement.fr we recorded a largest contentful paint at 1.6 s where Lighthouse measures 25.6 s — we had simply closed our eyes too early. Widening it costs about two seconds of audit on slow pages, and nothing on the others, which fall silent well before the ceiling.

Speed Index is not measured, because it requires analysing a video recording of the load frame by frame. Rather than invent a value, we exclude its 10 % of weight and renormalise the score over the remaining 90 %. Every report states that coverage.

Claiming compatibility without putting numbers on it is worthless. So we set our scores against Lighthouse’s — in its default setting, the one PageSpeed Insights uses — on a sample of public sites. Reading of 11 August 2026, mobile profile:

On light to medium pages the gap runs from 0 to 5 points. On pages that execute a lot of JavaScript it reached 12–24 points before 14 August 2026; two defects in our own instrument were responsible, and both have been fixed.

Our own security guard was skewing the measurement. To stop a site making us query an internal address through a redirect, we paused every document request for the duration of a check. That check takes 9 ms — but pausing a navigation stops Chromium launching its preload scanner. Measured on gouvernement.fr: first paint at 15.0 s instead of 1.6 s. It was the instrument producing the bad score, not the site. The protection now works by observation, pausing nothing.

Applied throttling versus simulated throttling. We genuinely slow the CPU and the network, then watch what happens. Lighthouse, by default, loads the page unthrottled and then simulates degraded conditions arithmetically. Both methods are legitimate, but they do not measure the same quantity, and the gap widens precisely where there is a lot of code to run.

Lighthouse itself varies a great deal. On one heavy page, three consecutive Lighthouse runs under identical conditions gave us 47, then 65, then 66. On such pages, aiming for a gap under five points would be chasing noise. It is the detailed metrics and the orders of magnitude that must agree, not the decimal.

A large gap with PageSpeed Insights on a light page, however, would most likely be a defect on our side. Tell us about it: that is how we found a measurement defect that cost flawless pages up to 27 points.

The score starts at 100 points, then each test adds or removes points according to Mozilla’s public scale: no Content-Security-Policy −25, no clickjacking protection −20, missing HSTS −20, a session cookie without the Secure flag −40, a third-party script loaded over HTTP −50; conversely a CSP with default-src 'none' earns +10, and a protective Referrer-Policy +5. The total is then converted into a letter, from A+ to F.

Three Observatory tests are out of our reach and are flagged as such in every report rather than counted as passed: cross-origin resource sharing (CORS), actual membership of the HSTS preload list, and validity of the TLS certificate chain.

Read directly from public DNS and through a TLS handshake: addresses, name servers, MX and CAA records, certificate expiry date and issuer, negotiated TLS version, then SPF, DMARC and DKIM. Nothing is sent to the site, nothing is modified.

These checks do not depend on the page audited but on the domain: a certificate expiring in eight days, or a domain without DMARC, costs far more in practice than a few points of performance.

Two limits we own up to. SPF and DMARC are only required if the domain publishes mail servers (MX): demanding them on a domain that receives no e-mail would be a false positive. And DNS offers no way to list DKIM selectors: we test the most common ones, so finding none is not proof that DKIM is absent — the report says so explicitly rather than concluding wrongly.

The analysis runs on the rendered page, after JavaScript has executed: contrasts are actually computed and ARIA roles resolved, which reading the HTML source cannot do. The rules kept are those of WCAG 2.0 and 2.1, levels A and AA.

The score is a share of rules passed, not a subtraction: the number of rules passed, divided by that same number plus the weight of the failing rules (2 for a critical violation, 1 for a serious one, 0.5 for a moderate one, 0.25 for a minor one).

Why this changed, and what it fixes: the previous scale deducted a flat amount per violation. On a reasonably rich site the sum exceeded 100 and the score fell to zero — lemonde.fr came out at 0/100 while 26 of its 36 evaluated rules passed. Readings of 13 August 2026 against real Lighthouse (mobile): lemonde.fr 68 there, 0 on the old scale, 67 on the new one; ovhcloud.com 72 / 15 / 77; our deliberately degraded demo page 89 / 75 / 88; fr.wikipedia.org 96 / 85 / 94. The mean gap falls from 37.5 points to 2.3.

The gap that remains, and we say so: Lighthouse weights each rule individually, with a table of roughly a hundred entries that changes with every version; we rely on the impact level axe publishes. The engine is the same, the weighting stays coarser.

An automated audit covers only part of real accessibility in any case — around a third of the RGAA criteria. Keyboard navigation, the relevance of alternative text, or reading order all need a human test.

RGAA 4.1 criterion. Every violation is mapped to its criterion, with the official number and wording taken verbatim from the standard published by the French DINUM. The WCAG level (A, AA) and the matching WCAG criterion number are shown beside it. Outside French, the wording is a courtesy translation and the interface says so: the binding text remains the French one, and it is the number that serves as the reference.

A rule we impose on ourselves: a rule whose mapping depends on context gets no number at all. A button without an accessible name falls under criterion 7.1 if it drives a component and under 11.1 if it submits a form; picking one at random would distort an accessibility statement, which is a public document binding on whoever publishes it. Those findings keep their theme and nothing more.

A separate rate is displayed: the share of criteria met among those a machine can settle, roughly twenty-five out of one hundred and six. It is not an RGAA conformance rate, and that is written next to the figure, in the PDF too — a percentage copied on its own into a tender would become a lie.

Criteria that cannot be automated are listed with instructions for running them, and moved to the top when the measurement gives a reason to worry: a positive tabindex attribute makes the tab order suspect, fields without labels make the relevance of the existing labels doubtful.

Finally, a draft accessibility statement is produced in the DINUM format: commitment, results, inaccessible content, remedies. The conformance status is left to be filled in, never filled in for you — asserting it on the strength of automated tests would make the statement inaccurate.

Every accessibility finding carries the CSS selector of each offending element, its markup, and the line in the served document when it could be found. The search runs on the document the browser actually received, not the one our crawler fetches: many servers answer differently depending on the user agent, and the line would then be looked up in the wrong text.

Three possible answers, and never false precision: an exact line, an approximate line (the element was found via a landmark, the attribute order having changed at render time), or no line at all — either because the served HTML is minified onto a single line, or because the element is produced by JavaScript. In the last two cases the report says which.

A before / after fix accompanies the common defects. It is marked “ready to paste” only when the transformation is mechanical and complete; as soon as an attribute value had to be shortened for display, it goes back to being a template — pasting truncated code would break the page.

Priority crosses severity, the number of elements affected and an estimated effort: adding an attribute takes a minute, revisiting a colour palette involves a designer. The exportable remediation plan lists everything in that order, with the location, the code and the verification test for each entry.

This pillar no longer reads the source code: it observes. The page is loaded in a real browser and nothing is clicked — no banner accepted, no dialog closed. Everything the report then lists was therefore obtained without consent: that is what makes the finding evidential rather than probable.

Recorded are the domains actually contacted, the cookies actually set with their lifetime, the keys written to local storage, and whether a consent dialog appears — searched for inside iframes and shadow DOM too, where most market platforms put it. Cookies are classified in three natures: recognised tracker, strictly necessary (session, cart, anti-CSRF, anti-bot, consent memory — the exemptions the French regulator accepts), or undetermined. An unknown third-party cookie is never filed as necessary.

Transfers outside the EU: we identify the organisation operating each domain contacted and the law it falls under. So we observe the recipient, not the physical location of its servers — the nuance is written into the report, because it changes what can be concluded from it.

Legal notice: the link to the legal notice is followed from the home page, and twelve items required by the French LCEN and commercial code are looked for one by one — company name, share capital, registered office, registration number, VAT, contact, publication director, hosting provider and its details, personal data, cookies, intellectual property. The check is textual: it spots an absence, it does not judge whether what is written is accurate. It only runs for sites that plausibly fall under French law.

If the browser could not run, the pillar falls back to reading the HTML, which is far coarser — and the report says so instead of letting you believe in a real observation. Calling a site “GDPR compliant” would require examining its processing activities, which no automated tool does.

The score uses the public calculation of the Green IT collective, the one ecoindex.fr uses: only three quantities — number of document nodes, number of requests, transferred weight — converted into a rank within a reference population, then weighted. The document counts for half the score, requests for a third, weight for a sixth. The quantiles and the formula are taken as-is from the reference implementation, so that our score is comparable to theirs.

Those three quantities come from the load already performed for performance: the eco-score adds neither a request nor a second to the audit. The emissions displayed (grams of CO₂ equivalent and centilitres of water per visit) are the score’s official functions, not an in-house estimate.

What this score does not say: it rates the frugality of the page and nothing else. It ignores your hosting provider, your servers’ electricity mix and the site’s actual traffic. It is a design indicator, not to be confused with a carbon footprint.

These three categories rest on checks of the served document: presence and length of the title and meta description, Open Graph tags, heading hierarchy, robots.txt and sitemap, canonical URL, declared language, viewport meta, doctype, inline styles and event handlers.

The score starts at 100 and each finding removes points according to its severity: 22 for a critical defect, 14 for a high one, 8 for a medium one, 4 for a low one, 1 for a simple remark. This is an in-house scale, unlike the three categories above. The GDPR pillar follows the same scale with one exception: simple remarks cost nothing there, so that a site with no tracker at all does score 100.