Préférences utilisateur : le responsive qui ne se voit pas

Depuis quinze ans, le responsive design répond à une seule question : quelle taille fait l’écran ? Chaque requête HTTP transporte pourtant une seconde famille de signaux qui ne décrivent pas l’appareil mais la personne : son thème préféré, sa tolérance au mouvement, son besoin de contraste, son forfait data. Ces signaux sont gratuits, présents dans chaque visite, et massivement ignorés.

Les chiffres du Web Almanac 2024 posent le décalage : environ 50 % des sites mobiles utilisent la media query prefers-reduced-motion, 12 % prefers-color-scheme, et moins de 1 % prefers-contrast. Autrement dit, une déclaration explicite de l’utilisateur reste lettre morte sur l’immense majorité du web, alors que la largeur d’écran, simple contrainte physique, est traitée partout.

Ce guide couvre les cinq préférences que le navigateur expose, leur implémentation CSS moderne, leur détection côté serveur et son coût caché, ainsi que leur impact réel sur les métriques de performance. Une question le traverse de bout en bout : que sait déjà votre site de ses visiteurs, et pourquoi n’en fait-il rien ?

Pourquoi le responsive s’est-il arrêté à la largeur d’écran ?

Le responsive s’est construit sur les media queries de niveau 3, standardisées par le W3C en 2012, qui ne décrivent que les capacités de l’appareil : largeur, résolution, orientation. Les préférences de la personne, elles, arrivent avec Media Queries Level 5, et leur adoption reste très en retard sur celle des breakpoints.

La différence entre les deux familles n’est pas cosmétique. Une largeur d’écran est une contrainte physique que le site subit ; une préférence système est une déclaration explicite que l’utilisateur a formulée dans ses réglages. Ignorer la première dégrade l’affichage, ignorer la seconde revient à ne pas répondre à une demande formulée. La faute n’est pas du même ordre.

L’évolution récente confirme que le retard se comble lentement. D’après le Web Almanac 2025, l’usage de prefers-reduced-motion est passé de 34 % en 2022 à environ 50 %, celui de prefers-color-scheme de 8 % à 12 %, tandis que forced-colors progresse de 5 points pour atteindre 19 % des sites. Le détail le plus révélateur se niche ailleurs : le vieux -ms-high-contrast, propre à Internet Explorer et obsolète, reste présent sur 20 % des sites. Plus de sites déclarent supporter un mode contraste mort que le standard qui l’a remplacé.

Cette inertie ne s’explique pas par la complexité technique, car ces media queries s’écrivent comme n’importe quel breakpoint. Elle s’explique par la méconnaissance de ce que le navigateur expose réellement, et c’est précisément l’inventaire qu’il faut dresser avant d’implémenter quoi que ce soit.

Quelles préférences utilisateur le navigateur expose-t-il vraiment ?

Cinq media features de préférence existent dans Media Queries Level 5 : prefers-color-scheme, prefers-reduced-motion et prefers-contrast sont Baseline et utilisables partout, prefers-reduced-transparency reste limitée à Chrome et Edge depuis leur version 119, et prefers-reduced-data n’est exposée par défaut dans aucun moteur en 2026. Le tableau suivant résume leur statut et leur rôle respectifs.

Media feature	Statut	Ce qu’elle pilote
prefers-color-scheme	Baseline widely available	Thème clair ou sombre
prefers-reduced-motion	Baseline widely available	Animations, transitions, autoplay, parallaxe
prefers-contrast	Baseline widely available (novembre 2024)	Valeurs more, less, custom, no-preference
prefers-reduced-transparency	Chrome et Edge 119 seulement	backdrop-filter, opacités, effets de flou
prefers-reduced-data	Spécifiée, exposée par aucun moteur	Polices, images, ressources tierces

Deux subtilités méritent d’être relevées. La valeur custom de prefers-contrast signale qu’une palette personnalisée est configurée, sans jamais dire laquelle : la media query ne permet pas de lire les couleurs choisies par l’utilisateur. Quant à prefers-reduced-transparency, Firefox et Safari ne l’ont pas implémentée, Safari invoquant des réserves de confidentialité, pour un usage mesuré autour de 3,3 % des chargements de pages côté Chrome.

Quatre media queries de préférence, quatre rendus du même composant, sans changer une ligne de HTML.

Le cas de prefers-reduced-data illustre le décalage entre spécification et réalité. La feature est documentée, testable derrière un drapeau dans Chromium, mais aucun navigateur ne l’expose en production selon caniuse. Le repli pratique existe pourtant depuis 2018 : l’en-tête HTTP Save-Data et la propriété navigator.connection.saveData, disponibles dans Chromium, sont le seul canal fiable pour l’économie de données, Firefox ayant retiré la Network Information API.

Les media features voisines à connaître

Au-delà des cinq préférences déclarées, le navigateur expose une seconde famille de signaux contextuels, entre capacité et préférence. Leur liste donne la mesure de tout ce qu’un site peut savoir sans le moindre script.

Media feature	Ce qu’elle détecte
forced-colors	Palette système imposée, type contraste élevé Windows
inverted-colors	Inversion des couleurs au niveau de l’OS
scripting	JavaScript actif, restreint ou absent
update	Fréquence de rafraîchissement de la surface d’affichage
pointer, hover et variantes any-	Précision du pointeur et capacité de survol
dynamic-range	Capacité HDR de l’écran
device-posture et display-mode	Écran plié, application installée en PWA

Chacune de ces features mériterait son propre développement, et forced-colors sera traitée plus loin tant elle piège de composants. Avant cela, le chantier le plus courant reste le thème clair et sombre, dont l’implémentation moderne tient en trois mécanismes complémentaires et beaucoup moins de CSS qu’on ne l’imagine.

Comment implémenter un thème clair et sombre sans dupliquer tout son CSS ?

Trois mécanismes se superposent : la balise meta color-scheme dans le head, la propriété CSS color-scheme sur la racine, et la fonction light-dark() disponible dans tous les navigateurs depuis mai 2024. Ensemble, ils remplacent la duplication de blocs @media par une déclaration unique par couleur, sans une ligne de JavaScript.

Le premier réflexe se joue dans le head, avant toute information de style. La balise meta informe le navigateur des schémas supportés au plus tôt du parsing, ce qui évite les flashs d’écran pendant le chargement, et pilote l’interface native : barres de défilement, contrôles de formulaire, fond par défaut du canvas. Son pendant CSS, la propriété color-scheme, est widely available depuis 2022 et active le rendu natif des deux thèmes au niveau de la racine.

<meta name="color-scheme" content="light dark">

:root {
  color-scheme: light dark;
}

La fonction light-dark() supprime ensuite la duplication : là où il fallait redéclarer chaque custom property dans un bloc @media, une seule déclaration porte les deux valeurs. Elle est Baseline newly available depuis mai 2024, avec un passage en widely available attendu autour de novembre 2026, ce qui justifie encore un repli @supports sur les audiences à parc ancien.

/* Avant : duplication */
:root { --surface: #ffffff; }
@media (prefers-color-scheme: dark) {
  :root { --surface: #092652; }
}

/* Après : une seule déclaration */
@supports (color: light-dark(#fff, #000)) {
  :root { --surface: light-dark(#ffffff, #092652); }
}

Deux pièges guettent cette fonction. Elle n’accepte que des couleurs, jamais d’autres types de valeurs, et surtout elle résout selon la propriété color-scheme, pas directement selon la media query : sans color-scheme light dark sur la racine, elle renvoie toujours la branche claire, silencieusement. C’est l’erreur numéro un constatée en audit, et la première chose à vérifier quand un thème sombre ne s’applique pas.

contrast-color(), la nouveauté 2026

La fonction contrast-color() renvoie noir ou blanc selon le meilleur contraste sur une couleur donnée. Elle est Baseline newly available depuis avril 2026, avec Chrome 147, Firefox 146 et Safari 26, et supprime le besoin d’une fonction Sass ou d’un calcul JavaScript à chaque changement de couleur de marque.

.btn {
  background: var(--brand, #2E69E8);
  color: #ffffff; /* repli */
}
@supports (color: contrast-color(red)) {
  .btn { color: contrast-color(var(--brand, #2E69E8)); }
}

Ses limites ne doivent pas être escamotées : elle ne rend que du noir ou du blanc, échoue sur les dégradés et les images, garantit une conformité mathématique WCAG et non une lisibilité perçue, et elle est ignorée quand le mode contraste forcé est actif. Le contexte chiffré invite d’ailleurs à l’humilité : Smashing Magazine, citant le WebAIM Million, relève 83,9 % de pages d’accueil signalées pour contraste insuffisant en 2026, contre 79,1 % en 2025. Le problème empire malgré l’outillage, et le mode contraste forcé, justement, mérite un examen à part.

Qu’est-ce que le mode contraste forcé et pourquoi casse-t-il vos composants ?

Le mode contraste forcé, détectable via la media query forced-colors, Baseline depuis septembre 2022, remplace toutes les couleurs d’auteur par une palette système limitée, typiquement celle du mode contraste élevé de Windows. Le navigateur substitue des couleurs comme Canvas, CanvasText ou ButtonText, et neutralise certains styles au passage, dont les ombres portées.

Le mécanisme, documenté sur MDN, va plus loin qu’un simple remplacement de palette : le navigateur déclenche aussi la valeur de prefers-color-scheme correspondant à la luminosité de la couleur Canvas, si bien qu’un thème système sombre à contraste élevé active à la fois forced-colors et le thème sombre du site. Le piège le plus fréquent tient en une propriété : en contraste forcé, box-shadow est forcé à none. Tout composant dont la délimitation ne repose que sur une ombre disparaît purement et simplement, un bouton fantôme au premier chef.

/* Bouton délimité par une ombre : invisible en contraste forcé */
.btn { box-shadow: 0 1px 4px rgba(9, 38, 82, .3); }

/* Correctif : bordure conditionnelle */
@media (forced-colors: active) {
  .btn { border: 1px solid ButtonText; }
}

L’échappatoire inverse existe et se manie avec parcimonie : forced-color-adjust none désactive l’adaptation automatique d’un élément, au risque de casser le contraste que l’utilisateur a explicitement demandé. Son usage légitime se limite à de rares cas scopés et justifiés, un logo dont les couleurs portent l’identité, une dataviz dont les teintes encodent l’information.

Côté conformité, le mode contraste forcé n’est pas un critère nommé du référentiel français, mais il agit comme un révélateur : les défauts qu’il expose recoupent les critères 3.1, 10.5 et 10.9 détaillés dans notre guide des obligations d’accessibilité numérique. Tester ce mode fait ressortir des manquements déjà sanctionnables par ailleurs, et la question suivante est de savoir si l’on peut anticiper ces préférences avant même le premier rendu.

Peut-on connaître la préférence de l’utilisateur avant d’envoyer le HTML ?

Oui, via les client hints de préférence, cinq en-têtes HTTP supportés par Chromium uniquement : Sec-CH-Prefers-Color-Scheme, Sec-CH-Prefers-Reduced-Motion, Sec-CH-Prefers-Reduced-Transparency, Sec-CH-Prefers-Contrast et Sec-CH-Prefers-Reduced-Data. Le serveur peut ainsi servir directement le bon thème, sans flash ni script correctif côté client.

Le mécanisme, décrit par web.dev et spécifié par le WICG, se joue en trois temps : le serveur annonce dans Accept-CH les en-têtes qu’il accepte, le navigateur les renvoie aux requêtes suivantes, et le serveur inscrit chaque en-tête utilisé dans Vary pour que les caches stockent la bonne variante. Un troisième en-tête, Critical-CH, déclare un hint assez essentiel pour que le navigateur relance sa requête initiale quand il manque, et tout en-tête listé dans Critical-CH doit aussi figurer dans Accept-CH et dans Vary.

Accept-CH: Sec-CH-Prefers-Color-Scheme
Vary: Sec-CH-Prefers-Color-Scheme
Critical-CH: Sec-CH-Prefers-Color-Scheme

Sur un hébergement Apache, ces trois lignes se posent en quelques directives Header, selon la même mécanique que celle détaillée dans notre guide du fichier de configuration Apache. Côté WordPress, un simple header() en PHP avant l’envoi du HTML suffit, et la lecture de l’en-tête reçu tient en une ligne : la valeur de $_SERVER[‘HTTP_SEC_CH_PREFERS_COLOR_SCHEME’] vaut dark ou light, ce qui permet de poser la classe de thème dès le rendu serveur.

Le support reste circonscrit à Chromium, ce qui n’est pas rédhibitoire puisque le CSS continue de faire foi ailleurs : les client hints sont une optimisation progressive, pas un prérequis. La vraie question n’est pas la couverture navigateur, mais le prix que cette détection fait payer à l’infrastructure de diffusion.

Votre site est-il aussi rapide que vos visiteurs l’espèrent ?

Découvrez comment nous pouvons vous accompagner

Combien coûte la détection côté serveur ?

La détection serveur a trois coûts documentés : un aller-retour réseau supplémentaire à la première visite via Critical-CH, une multiplication des variantes en cache par chaque en-tête ajouté à Vary, et une surface de fingerprinting accrue. Le remède au flash de thème n’est jamais gratuit pour l’infrastructure, et se chiffre avant de se déployer.

Le premier coût frappe la première visite, la plus sensible pour les Core Web Vitals. Quand Critical-CH exige un en-tête absent de la requête initiale, le navigateur relance cette requête, soit un aller-retour complet ajouté avant le premier octet utile. Les protocoles récents en effacent une partie : la trame ACCEPT_CH de HTTP/2 et HTTP/3, délivrée pendant le handshake TLS, communique les préférences au niveau de la connexion, un mécanisme cousin de ceux détaillés dans notre article sur les protocoles HTTP successifs. Sans elle, le surcoût se paie précisément là où le TTFB se joue.

Le deuxième coût touche la diffusion. Chaque en-tête ajouté au Vary multiplie le nombre d’objets stockés par les caches intermédiaires : un Vary sur le schéma de couleurs double le nombre de variantes, empiler schéma et contraste le quadruple. Sur un site servi depuis un réseau de diffusion de contenu, cette fragmentation dégrade le taux de hit exactement comme les mauvais réglages décrits dans notre guide du cache web : chaque variante supplémentaire dilue la mémoire partagée entre visiteurs.

Le troisième coût est plus discret. La documentation de Sec-CH-Prefers-Color-Scheme le classe parmi les hints à forte entropie, que le navigateur peut délibérément omettre : une préférence stable est une donnée de fingerprinting. Le paramètre Resist Fingerprinting de Firefox fait d’ailleurs mentir de nombreuses media queries en renvoyant des valeurs par défaut, et ces mêmes réserves de confidentialité expliquent le blocage de Safari et Firefox sur prefers-reduced-transparency.

L’arbitrage se formule alors nettement : la détection serveur ne se justifie que si le flash de thème est un problème mesuré sur le site, et sur des pages où la fragmentation du cache reste supportable. Sur un site éditorial à fort trafic mis en cache en périphérie, le remède peut coûter plus cher que le mal, et il reste heureusement tout un versant où respecter les préférences rapporte au lieu de coûter.

En quoi respecter ces préférences améliore-t-il la performance ?

Respecter une préférence revient presque toujours à charger moins, peindre moins ou calculer moins : CSS du thème inactif sorti du chemin critique, polices non préchargées sous Save-Data, backdrop-filter retiré, animations JavaScript coupées. Chacun de ces leviers agit sur une métrique mesurable, du LCP à l’INP.

Le premier gisement est le script anti-flash de thème. Le pattern dominant est un script inline bloquant dans le head, qui lit localStorage avant le premier paint pour poser la classe du thème : il bloque le parsing, échappe à toute mutualisation en cache et complique le CSS critique. Les trois sorties propres sont la meta color-scheme, la fonction light-dark() qui supprime la duplication de custom properties, et le rendu serveur via client hint : dans les trois cas, le thème arrive sans JavaScript bloquant.

Le deuxième levier sort le CSS du thème inactif du chemin critique. La recommandation de web.dev est de porter la media query sur l’attribut media du link, afin que seule la feuille du schéma actif participe au rendu initial. La nuance compte : le navigateur télécharge quand même la feuille inactive, mais en priorité basse et sans bloquer le rendu, selon la hiérarchie détaillée dans notre article sur l’ordre de chargement des ressources. Le gain porte sur le blocage du rendu, pas sur les octets.

<link rel="stylesheet" href="theme-light.css"
      media="(prefers-color-scheme: light)">
<link rel="stylesheet" href="theme-dark.css"
      media="(prefers-color-scheme: dark)">

Le même attribut media conditionne le préchargement des polices. MDN documente l’exemple exact : un preload de fichier woff2 assorti de media prefers-reduced-data no-preference, si bien que la police n’est ni préchargée ni téléchargée quand l’utilisateur demande moins de données, avec repli sur la pile système. Combiné aux stratégies de notre guide des polices d’écriture, ce conditionnement économise des dizaines de kilooctets sur le chemin critique pour les visiteurs qui l’ont demandé.

<link rel="preload" as="font" type="font/woff2" crossorigin
      href="/fonts/manrope.woff2"
      media="(prefers-reduced-data: no-preference)">

Deux préférences agissent directement sur le pipeline de rendu. Retirer backdrop-filter sous prefers-reduced-transparency supprime une passe de compositing coûteuse, et la préférence d’accessibilité produit ici un gain de paint mesurable. Quant à prefers-reduced-motion, elle ne s’arrête pas au CSS : les animations JavaScript et les librairies tierces continuent de charger le thread principal même quand les keyframes sont neutralisées, un mécanisme au cœur de notre article sur la métrique INP et illustré par les carrousels analysés dans notre banc d’essai des sliders. Couper l’animation à la source, via l’API matchMedia, libère du temps de thread principal, pas seulement des pixels.

Reste le signal Save-Data, dont la lecture tient en deux lignes, côté serveur comme côté client. Les adaptations concrètes qu’il autorise forment une liste courte et à fort rendement :

ne pas charger de polices personnalisées ;
différer le téléchargement des vidéos et des iframes ;
ne pas ouvrir d’emblée l’image la plus lourde d’une galerie ;
réduire le nombre de scripts tiers ;
désactiver l’autoplay vidéo.

// PHP
$saveData = isset($_SERVER['HTTP_SAVE_DATA'])
  && strtolower($_SERVER['HTTP_SAVE_DATA']) === 'on';

// JavaScript
const saveData = navigator.connection?.saveData === true;

Chaque point de cette liste retire des octets ou des requêtes du chemin de chargement, au bénéfice direct du LCP. Un argument revient pourtant sans cesse pour justifier le thème sombre seul, celui de la batterie, et il mérite une vérification chiffrée plutôt qu’une conviction.

Le mode sombre économise-t-il vraiment de la batterie ?

Marginalement dans l’usage courant. L’étude de l’université Purdue présentée à MobiSys 2021 mesure qu’à 30 à 50 % de luminosité, la plage typique en intérieur, passer du clair au sombre n’économise que 3 à 9 % de la puissance consommée sur plusieurs smartphones OLED. L’économie substantielle n’apparaît qu’à luminosité maximale.

Les mesures publiées par Dash et Hu précisent les deux régimes : à 100 % de luminosité, l’économie du mode sombre grimpe à 39 voire 47 %, un cas réel en plein soleil mais minoritaire. Le facteur dominant n’est pas le thème mais la luminosité elle-même, puisque la ramener de 100 à 50 % divise la consommation de la dalle OLED par environ 10, indépendamment du contenu affiché. Autrement dit, le réglage de luminosité écrase l’effet du thème d’un ordre de grandeur.

La conclusion s’assume : le mode sombre est un choix de confort visuel légitime, pas un levier d’écoconception significatif, et le présenter comme tel relèverait du greenwashing. Les leviers qui pèsent réellement sur l’empreinte d’un site sont ceux de notre approche responsable : octets transférés, requêtes évitées, durée de vie des terminaux. Cette honnêteté sur les chiffres évite aussi les erreurs d’implémentation les plus répandues, qui font l’objet de la section suivante.

Quelles sont les erreurs les plus fréquentes ?

Six erreurs reviennent dans la quasi-totalité des audits : thème sombre jamais audité en contraste, noir pur fatigant, sélecteur à trois états, mouvement supprimé en bloc, contrast-color() supposée active partout, et mode contraste forcé jamais testé. Chacune a un correctif court et vérifiable.

La première erreur consiste à croire que le mode sombre est un acquis d’accessibilité. Le minimum WCAG de 4,5:1 pour le texte courant s’applique indépendamment à chaque thème, les ratios ne s’arrondissent pas, un 4,47:1 échoue, et proposer un bouton de bascule ne satisfait aucune exigence en soi : les deux palettes s’auditent séparément, avec les mêmes outils.

La deuxième tient au noir pur. Un fond #000000 sous un texte blanc accentue la fatigue oculaire et l’effet de halation, particulièrement sur OLED : la pratique éprouvée est un gris très foncé, entre #121212 et #1e1e1e, sous un blanc cassé.

La troisième erreur est le sélecteur de thème à trois états posé dans l’en-tête du site. L’argument de Lea Verou, publié le 6 août 2026 dans Dark mode toggles: two states are enough, renverse la logique dominante : le modèle sous-jacent doit bien porter trois états, mais l’un d’eux est toujours hors sujet pour la personne qui clique, puisqu’on ne cherche un bouton de bascule que lorsque la page gêne.

Les utilisateurs ne cherchent pas de solutions à des problèmes qu’ils n’ont pas au moment présent.
Lea Verou, dans son article Dark mode toggles: two states are enough, publié le 6 août 2026

Un bon toggle à deux états exprime pourtant les trois états du modèle : il affiche la valeur résolue quand rien n’est stocké et son inverse quand un override existe, le premier clic stocke l’override, et le clic qui ramène vers la valeur système supprime le stockage pour rendre la main à l’OS. Le sélecteur tri-state garde sa place dans un vrai panneau de préférences, où l’utilisateur est en mode réglage.

La quatrième erreur neutralise tout le mouvement d’un animation none !important global. L’animation n’est pas systématiquement superflue : une interface transitionnelle, comme une liste qui ménage une place pour un nouvel élément, aide à la compréhension. La bonne réponse est souvent moins de mouvement, plus lent, ou un fondu, plutôt qu’une suppression sèche.

Les deux dernières erreurs se rejoignent sur le contraste forcé : oublier que contrast-color() y est ignorée, et ne jamais tester le mode lui-même. Quatre points se vérifient en quelques minutes, les icônes restent visibles, le focus reste perceptible au clavier, les états restent distinguables sans la couleur, et aucune information critique ne vit uniquement dans une background-image. Encore faut-il savoir déclencher ces modes sans toucher à son système, ce qui est plus simple qu’il n’y paraît.

Comment tester ces préférences sans changer ses réglages système ?

Dans Chrome et Edge, le panneau Rendering des DevTools émule prefers-color-scheme, prefers-reduced-motion, prefers-contrast et forced-colors active en un clic, sans toucher à l’OS. Firefox passe par about:config, avec la préférence numérique ui.prefersReducedMotion, 0 pour l’animation complète, 1 pour le mouvement réduit, prise en compte immédiatement.

Ces émulations couvrent le quotidien du développement, mais elles simulent la media query, pas l’environnement complet : un vrai poste Windows en mode contraste élevé applique sa palette, ses réglages utilisateur et ses interactions clavier réels. Un test final sur machine réelle reste le seul verdict fiable pour forced-colors, au moins avant chaque mise en production majeure.

L’outillage de test progresse d’ailleurs moins vite que la plateforme elle-même, car le prochain chapitre de ces préférences n’est plus dans les media queries mais dans une API JavaScript dédiée, qui promet de changer la manière même de construire un toggle.

Qu’est-ce qui va changer avec la User Preferences API ?

La User Preferences API expose navigator.preferences, un PreferenceManager portant cinq objets, colorScheme, contrast, reducedMotion, reducedTransparency et reducedData. Chacun offre les propriétés value, override et validValues, les méthodes requestOverride() et clearOverride(), et un événement change. Elle reste expérimentale, derrière un drapeau Chrome en 2026.

Ce qu’elle résout d’un coup mérite l’attention : plus de script inline bloquant pour restaurer un choix, plus de duplication de custom properties, et surtout un override qui met réellement à jour la media query CSS au lieu de la court-circuiter par une classe sur l’élément html. Le toggle minimal tient en quelques lignes, protégées par un simple test de présence.

if (navigator.preferences) {
  const cs = navigator.preferences.colorScheme;
  btn.addEventListener('click', () => {
    const target = cs.value === 'dark' ? 'light' : 'dark';
    cs.requestOverride(target).catch(() => cs.clearOverride());
  });
  cs.addEventListener('change', () => render(cs.value));
}

Le statut se vérifie avant tout usage : la spécification vit dans le dépôt WICG porté par Luke Warlow, rattachée à Media Queries Level 5, et s’active dans Chrome via le drapeau Experimental Web Platform Features. Le contexte plaide pour elle : la demande d’un réglage de thème natif dans l’interface du navigateur est ancienne, portée notamment par Bramus Van Damme dans Dark Mode Toggles Should be a Browser Feature, et cette API en est la brique technique manquante.

CSS pur ou client hints : à quel étage traiter les préférences ?

Ces signaux ne coûtent rien à lire, ils sont déjà dans chaque requête, et les ignorer revient à laisser sans réponse une demande que l’utilisateur a explicitement formulée. Le vrai arbitrage technique n’est plus faut-il les respecter, mais à quel étage les traiter : CSS pur quand le flash est tolérable, client hints quand il ne l’est pas et que le cache le supporte.

Cet arbitrage rejoint celui du responsive dimensionnel, dont notre guide du responsive design couvre le versant complémentaire : le responsive répond à la question de la taille, les préférences à celle de la personne. Un site qui maîtrise les deux familles de signaux sert à chaque visiteur la version qu’il a déjà demandée, sans qu’aucun réglage ne soit visible.

Mesurer ce que coûtent réellement un flash de thème, un Vary mal calibré ou une animation qui tourne à vide suppose un diagnostic instrumenté, du terrain au laboratoire. C’est exactement le périmètre d’un audit de performance web, et le déploiement de ces correctifs celui d’une optimisation de performance menée règle par règle : les préférences utilisateur y sont désormais un chapitre à part entière du diagnostic, au même titre que les images ou les polices.