Responsive design : le guide complet, du viewport au site faussement responsive

Les Core Web Vitals mobiles sont systématiquement moins bons que leurs équivalents desktop, sur à peu près tous les sites que l’on peut auditer. Le réseau plus lent et les processeurs plus modestes n’expliquent qu’une partie de l’écart : le reste vient de sites dits responsive qui envoient au téléphone l’intégralité du site desktop, simplement masquée par le CSS.

Le responsive design est pourtant la bonne approche, et la seule raisonnable depuis quinze ans : une même page, un même HTML, une mise en page qui s’adapte à toutes les tailles d’écran. Le problème n’est pas le principe, c’est son implémentation courante, qui confond adapter l’affichage et adapter ce qui est envoyé : deux choses très différentes du point de vue du navigateur.

Ce guide reprend les fondations, viewport et media queries, code à l’appui, puis démonte une à une les quatre erreurs qui font qu’un site parfaitement adapté visuellement reste lent sur mobile. Une question le traverse de bout en bout : votre site est-il responsive, ou seulement déguisé en site responsive ?

Qu’est-ce que le responsive design ?

Le responsive design est une approche de conception et d’intégration où une même page s’adapte à toutes les tailles d’écran à partir d’un HTML unique, par le seul CSS. Le terme a été posé par Ethan Marcotte le 25 mai 2010 dans A List Apart, et l’équivalent français est site web adaptatif, ou site réactif.

Trois piliers historiques le définissent : des grilles fluides dimensionnées en proportions plutôt qu’en pixels, des médias flexibles qui se plient à leur conteneur, et des media queries qui ajustent la mise en page par paliers. Le volet images, du srcset à la direction artistique, dispose de son propre guide pour optimiser les images pour le web : cet article n’y reviendra pas, et c’est un choix de périmètre assumé. Le texte fondateur, lui, mérite d’être relu dans sa version originale, car il contient une idée que quinze ans ont diluée.

Plutôt que de tailler des conceptions déconnectées pour chacun d’un nombre toujours croissant d’appareils, nous pouvons les traiter comme les facettes d’une même expérience.
Ethan Marcotte, designer et intégrateur indépendant, dans son article fondateur « Responsive Web Design » publié dans A List Apart le 25 mai 2010

Quelle différence entre responsive et adaptatif ?

Le responsive est fluide et continu : la mise en page se recompose à toute largeur, sans rupture. L’adaptive design repose sur des gabarits fixes servis par palier : trois ou quatre mises en page figées, activées selon la largeur détectée. La distinction date de 2011 et penche aujourd’hui nettement en faveur du responsive fluide, plus robuste face à la diversité des écrans.

Une troisième variante, l’adaptatif côté serveur qui envoie un HTML différent selon l’appareil, sera traitée plus loin avec le legacy, car elle pose des problèmes spécifiques de cache et de maintenance. Avant d’y arriver, un point capital : responsive ne signifie pas léger. Un site peut s’afficher parfaitement sur un téléphone et lui envoyer trois fois ce dont il a besoin, et c’est tout l’objet de la suite.

Comment rendre un site responsive ?

Quatre chantiers suffisent, dans cet ordre : poser la balise meta viewport, construire la mise en page en grilles fluides avec des unités relatives, ajuster les paliers par media queries, et rendre les médias flexibles. Sur un CMS moderne, les thèmes récents livrent ce socle, et le travail réel porte sur ce qu’on y ajoute : menus, sliders et blocs dupliqués.

La question voisine des images mérite sa réponse courte : une image devient responsive avec une largeur fluide et une hauteur automatique en CSS, puis des variantes servies selon l’écran via srcset. Le détail de ces mécanismes, formats modernes compris, appartient au guide des images cité plus haut, ce qui laisse ce guide se concentrer sur la partie que personne ne traite, le coût. Tout commence par une balise d’une seule ligne.

À quoi sert la balise meta viewport ?

La balise meta viewport indique au navigateur mobile de caler la largeur de rendu sur la largeur réelle de l’écran, avec une échelle initiale de 1. Sans elle, les navigateurs mobiles rendent la page dans une fenêtre virtuelle d’environ 980 pixels puis la réduisent, un mode de compatibilité hérité de l’ère pré-mobile.

<meta name="viewport" content="width=device-width, initial-scale=1">

Cette valeur canonique, documentée sur la référence MDN du meta viewport, suffit dans la quasi-totalité des cas. Les ajouts que l’on croise encore, user-scalable=no ou maximum-scale=1, sont à proscrire : ils bloquent le zoom, ce qui constitue un défaut d’accessibilité caractérisé pour toute personne malvoyante, sans aucun bénéfice de performance en contrepartie. Aucune media query ne fonctionne correctement sans cette balise, puisque la largeur évaluée serait la fenêtre virtuelle, pas l’écran.

Pourquoi 100vh pose-t-il problème sur mobile ?

L’unité vh mesure la hauteur du viewport, mais les barres d’interface des navigateurs mobiles apparaissent et disparaissent au défilement : 100vh correspond à la fenêtre la plus grande, donc un élément calé dessus déborde de l’écran quand les barres sont visibles. Les unités dvh, svh et lvh, standardisées pour régler ce cas, sont disponibles dans tous les navigateurs majeurs depuis fin 2022.

.panneau {
  height: 100vh;  /* repli : hauteur figée sur la plus grande fenêtre */
  height: 100dvh; /* hauteur dynamique : suit les barres du navigateur */
}

Les deux déclarations successives forment un repli propre : un navigateur ancien ignore la seconde ligne, un navigateur moderne l’applique. L’état de support exact se vérifie sur la table des variantes d’unités viewport, et le choix se fait selon l’usage : svh pour garantir qu’un élément tient toujours à l’écran, dvh pour suivre la barre en temps réel, en gardant à l’esprit que dvh change de valeur au défilement et peut provoquer des recalculs de mise en page en continu. Ces unités s’évaluent dans les media queries, qu’il est temps de poser proprement.

Comment fonctionnent les media queries ?

Une media query est une condition CSS qui applique un bloc de styles quand l’environnement la satisfait : largeur de fenêtre, orientation, préférences utilisateur. La notation de plages, du type width >= 48rem, est supportée par tous les navigateurs majeurs depuis 2023 et rend les bornes enfin lisibles.

/* Syntaxe classique */
@media (min-width: 48rem) {
  .grille { display: grid; }
}

/* Notation de plages, equivalente et plus lisible */
@media (width >= 48rem) {
  .grille { display: grid; }
}

/* Un intervalle sans chevauchement possible */
@media (48rem <= width < 64rem) {
  .grille { grid-template-columns: 1fr 1fr; }
}

L’écriture des bornes en rem plutôt qu’en pixels suit le réglage de taille de texte de l’utilisateur, ce qui adapte la mise en page aux personnes qui agrandissent leur police. La largeur n’est d’ailleurs pas la seule condition utile : orientation, hover et pointer détectent le type d’interaction, et prefers-reduced-motion permet de couper les animations pour qui les demande réduites, une attention d’accessibilité qui évite aussi des animations coûteuses sur les appareils modestes. L’état de support de la notation de plages se vérifie sur sa table caniuse.

Combien de points de rupture faut-il prévoir ?

Aussi peu que possible, placés là où le contenu casse, jamais sur des tailles d’appareils. La liste des « breakpoints iPhone » à maintenir est un anti-pattern : les tailles d’écran du marché se comptent par centaines, et un point de rupture se découvre en étirant la fenêtre jusqu’à ce que la mise en page se dégrade.

Deux ou trois points de rupture majeurs suffisent à la plupart des sites, complétés de quelques ajustements locaux par composant. Le sens des bornes, min-width ou max-width, engage quant à lui toute l’architecture du CSS : c’est la porte d’entrée de la distinction mobile-first, traitée plus loin. Un dernier fait mérite d’être posé avant le cœur du sujet, car presque personne ne le connaît : une feuille de style liée avec un attribut media non correspondant est tout de même téléchargée, mais sans bloquer le rendu, en priorité basse, comme le documente le guide web.dev sur le CSS non critique. Ce mécanisme fonde l’une des corrections majeures qui suivent.

Les quatre symptômes du site faussement responsive

Un site faussement responsive est un site qui s’affiche correctement à toutes les tailles d’écran, mais qui fait payer à chaque appareil les interfaces des autres. Le diagnostic tient en quatre symptômes récurrents, observés en audit sur toutes les plateformes : DOM dupliqué, CSS non conditionnel, ressources masquées mais téléchargées, et JavaScript unique initialisant deux interfaces.

Chaque symptôme suit ici la même grille de lecture : ce qu’on observe, ce que ça coûte et sur quelle métrique, comment le détecter, comment le corriger. Les quatre se cumulent sur les mêmes pages, et c’est leur addition qui explique l’écart systématique entre mobile et desktop constaté dans les données terrain.

Le DOM dupliqué et masqué

Le symptôme cardinal s’observe en deux minutes dans l’inspecteur : deux en-têtes complets dans le HTML, une barre de navigation desktop avec son mega-menu et un tiroir mobile qui recopie le même menu, chacun masqué en display:none à l’autre point de rupture. Le motif se répète sur les colonnes déclinées « version mobile / version desktop », les tableaux doublés d’une version cartes et les sliders dupliqués par appareil, un travers que nous avons déjà documenté sur le composant le plus dupliqué du web, le slider et ses variantes.

La mécanique du coût tient en une phrase : display:none retire du rendu, pas du document. Le HTML est transféré et parsé, les nœuds construits, les règles CSS confrontées à chaque nœud, et chaque interaction paie ensuite le recalcul de style sur l’ensemble de l’arbre, comme l’explique l’article web.dev sur la taille du DOM et l’interactivité. La métrique qui encaisse est l’INP, dont l’optimisation fait l’objet d’un guide dédié : l’audit Lighthouse correspondant émet un avertissement au-delà de 800 nœuds et une alerte au-delà de 1 400, seuils documentés par l’équipe Chrome.

display:none retire du rendu, pas du document : les deux interfaces sont payées par tous les appareils.

Le volet référencement aggrave le dossier depuis que Google a achevé sa bascule vers l’indexation mobile-first, annoncée close le 31 octobre 2023 : le HTML mobile est la version indexée. Les conséquences sont symétriques : un contenu retiré de la version mobile disparaît de l’index, et un DOM dupliqué envoie à Google un document artificiellement gonflé où le contenu utile se dilue.

Les page builders sont le cas le plus documenté de ce travers, avec leurs options « masquer sur mobile » qui ne font qu’ajouter du display:none et leurs colonnes déclinées par appareil. Le problème dépasse largement WordPress : thèmes PrestaShop doublant leurs blocs, intégrations sur mesure pressées par les délais, gabarits d’e-mailing recyclés en pages. L’option de masquage n’est pas en cause en soi : c’est son usage comme outil de conception d’interfaces parallèles qui fabrique le site faussement responsive.

La détection ne demande que le navigateur, et quatre gestes suffisent à établir le diagnostic complet en moins de dix minutes :

compter les nœuds dans la console avec document.querySelectorAll('*').length, aux deux tailles de fenêtre ;
comparer le HTML servi au viewport mobile et au viewport desktop, qui devrait être identique et l’est rarement ;
rechercher les blocs en display:none porteurs de contenu dupliqué, en commençant par l’en-tête ;
lancer l’audit de taille du DOM de Lighthouse, qui liste les zones les plus denses de l’arbre.

La correction suit un ordre de préférence strict, et le premier réflexe couvre l’immense majorité des cas : un seul balisage, restylé par CSS. Le même élément nav devient tiroir ou barre horizontale selon le viewport, et aucun contenu n’existe en double dans le document.

<nav>
  <button class="nav-bouton" aria-expanded="false" aria-controls="menu">Menu</button>
  <ul id="menu" class="nav-liens">…</ul>
</nav>

.nav-liens {            /* base : tiroir mobile */
  position: fixed;
  inset: 0;
  transform: translateX(100%);
  transition: transform 0.2s;
}
.nav-liens.ouverte { transform: none; }

@media (width >= 64rem) {  /* grand ecran : barre horizontale */
  .nav-bouton { display: none; }
  .nav-liens {
    position: static;
    transform: none;
    display: flex;
  }
}

Le déclencheur est un vrai bouton avec aria-expanded, pas le vieux hack de la case à cocher, et l’élément details fournit une alternative sans JavaScript pour les menus simples. Quand la structure doit réellement différer entre appareils, le balisage secondaire se génère à la demande, un élément template cloné en JavaScript à la première ouverture. Deux propriétés complètent l’arsenal : content-visibility réduit le coût de rendu des blocs hors écran, en précisant honnêtement qu’elle n’empêche ni le téléchargement ni le parsing, et l’attribut inert sort le tiroir fermé de la tabulation et des lecteurs d’écran. La Popover API, désormais disponible dans tous les moteurs, gère nativement l’ouverture et la fermeture de ces panneaux.

Un dernier poste concerne l’en-tête lui-même : les barres fixes recouvrent le contenu et provoquent des décalages de mise en page à leur apparition, comptés dans le CLS dont le guide dédié détaille la mécanique. La règle courte : position:sticky réserve son espace dans le flux quand position:fixed le retire, et un menu mobile, burger ou non, doit ouvrir son tiroir sans jamais décaler le contenu sous lui. Ce DOM assaini, reste à ne plus livrer tout le CSS à tout le monde.

Le CSS non conditionnel

Le deuxième symptôme est une feuille de style unique qui embarque les trois mises en page : le mobile télécharge et parse la grille desktop, le desktop télécharge les styles du tiroir mobile, et les sites sous framework y ajoutent tout ce qui n’est utilisé nulle part. Le CSS étant bloquant pour le rendu, chaque kilooctet retarde le premier affichage, donc le LCP dont l’optimisation est détaillée par ailleurs : sur mobile, c’est le chemin critique du rendu qui s’allonge.

<!-- Avant : tout le CSS bloque le rendu de tous les appareils -->
<link rel="stylesheet" href="styles.css">

<!-- Apres : trois feuilles, seules celles qui correspondent bloquent -->
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="mobile.css" media="(max-width: 47.99rem)">
<link rel="stylesheet" href="desktop.css" media="(min-width: 48rem)">

La feuille au media non correspondant est téléchargée en priorité basse, sans bloquer le premier rendu.

Ce découpage exploite précisément le fait posé plus haut : le navigateur télécharge les trois feuilles, mais seule celle dont le media correspond bloque le rendu. Le bénéfice ne porte donc pas sur les octets transférés, il porte sur les octets placés sur le chemin critique, ceux que le premier affichage attend. Le CSS critique par viewport, qui inline les styles au-dessus de la ligne de flottaison, pousse la logique plus loin ; sa maintenance est réelle et l’approche ne se justifie que sur des gabarits stables et à fort trafic.

Les frameworks CSS méritent des chiffres plutôt qu’un procès, et nous les avons mesurés le 26 août 2026. Le bootstrap.min.css complet de Bootstrap 5.3.3 pèse 232 803 octets minifié, soit 30 777 octets compressés en gzip ; passé dans PurgeCSS contre une page type complète, navigation, grille, carte, tableau et formulaire, il tombe à 24 598 octets, soit 5 549 compressés. Autrement dit, près de 90 % de la feuille n’est jamais utilisée sur une page représentative : le framework n’est pas lent, son build par défaut l’est.

Tailwind prend le problème à l’envers en ne générant que les classes employées, ce qui produit d’après sa documentation officielle des feuilles finales sous les 10 Ko compressés, au prix d’un HTML alourdi de classes utilitaires : le poids se déplace vers le document, ce qui renvoie au symptôme précédent. L’onglet Coverage des DevTools donne la mesure de votre propre cas en listant le CSS jamais exécuté au viewport courant : sur les sites que nous auditons, cette part inutilisée dépasse régulièrement la moitié de la feuille au viewport mobile, et c’est le premier chiffre à relever avant toute refonte de l’intégration.

Les ressources masquées mais téléchargées

Le troisième symptôme regroupe les images du slider desktop chargées sur téléphone, la vidéo d’arrière-plan téléchargée puis masquée, l’iframe de carte instanciée dans un bloc invisible et les graisses de police récupérées pour un mega-menu qui ne s’affichera jamais. L’intuition « c’est masqué, donc ce n’est pas chargé » est fausse dans la plupart des cas, car le comportement dépend du type de ressource et de la façon de masquer.

La raison de fond tient au fonctionnement du navigateur : le preload scanner, documenté par web.dev, parcourt le HTML brut et lance les téléchargements d’images avant même que le CSS soit appliqué : une balise img est récupérée quelle que soit sa visibilité future. Les images d’arrière-plan dépendent au contraire du calcul de style, avec les subtilités mesurées par Tim Kadlec dans ses tests de référence publiés en avril 2012, dont les enseignements structurent le tableau de synthèse ci-dessous, confronté aux comportements documentés actuels.

Ressource	Élément masqué en `display:none`	Parent masqué	Parade fiable
Image (balise `img`)	Téléchargée (preload scanner)	Téléchargée	Balisage conditionnel, lazy loading (guide images)
Image d’arrière-plan CSS	Téléchargée	Non téléchargée	La définir uniquement dans les media queries concernées
Police `@font-face`	Variable selon le navigateur	Variable selon le navigateur	Ne déclarer que les graisses réellement affichées
Vidéo et son poster	Poster téléchargé, flux selon `preload`	Idem	`preload="none"` et chargement à l’interaction
Iframe	Chargée et exécutée	Chargée et exécutée	`loading="lazy"` et façade cliquable

La ligne des arrière-plans porte la règle la plus rentable : un fond décoratif réservé au desktop se déclare dans une media query min-width, jamais en base avec un masquage par-dessus. Le doute doit toujours se lever par la mesure, panneau réseau ouvert aux deux viewports, car ces comportements ont évolué et varient encore entre moteurs sur les cas limites, la ligne des polices en tête.

/* Avant : telechargee partout, meme masquee sur mobile */
.hero { background-image: url(hero-large.avif); }

/* Apres : demandée uniquement quand elle sert */
@media (width >= 64rem) {
  .hero { background-image: url(hero-large.avif); }
}

Les iframes se traitent par façade : une image statique cliquable remplace la carte ou la vidéo embarquée, et l’iframe réelle ne s’instancie qu’à l’interaction. Les polices suivent la même logique de sobriété, ne charger que les graisses réellement affichées au viewport courant, un sujet que prolonge notre analyse de l’impact des polices d’écriture ; le reste du volet images, formats, srcset et direction artistique, relève du guide images déjà cité, qui se suffit. Reste le quatrième symptôme, le plus coûteux en interactivité.

Un JavaScript unique pour deux interfaces

Le dernier symptôme se lit dans le bundle : le même fichier initialise le mega-menu desktop et le tiroir mobile instancie un slider sur un bloc masqué et attache des écouteurs de redimensionnement qui recalculent en continu. Le mobile paie le parse et l’exécution de tout ce code sur un processeur modeste : Lighthouse émule d’ailleurs un Moto G Power avec un ralentissement processeur de facteur 4, comme le documente sa page officielle sur le throttling, précisément pour représenter cet appareil médian.

const mq = window.matchMedia('(width >= 64rem)');

function initSelonViewport(e) {
  if (e.matches) {
    initMegaMenu();      // uniquement quand la barre desktop existe
  }
}
mq.addEventListener('change', initSelonViewport);
initSelonViewport(mq);

// Le code du tiroir mobile n'arrive qu'a la premiere ouverture
bouton.addEventListener('click', async () => {
  const { ouvrirTiroir } = await import('./tiroir.js');
  ouvrirTiroir();
}, { once: true });

Deux mécanismes portent toute la correction. matchMedia et son événement change remplacent l’écouteur resize, qui se déclenche des dizaines de fois par seconde pendant un simple pivot d’écran là où le premier ne s’active qu’au franchissement réel du point de rupture. L’import dynamique repousse ensuite le code de chaque interface au moment où elle sert : le tiroir mobile ne coûte rien tant qu’il n’est pas ouvert, le mega-menu n’existe pas sur téléphone. Les scripts tiers obéissent à la même discipline, ne pas charger sur mobile les widgets de blocs invisibles, un chantier entier couvert par notre guide de réduction de l’impact des JavaScript tiers. Ces quatre symptômes corrigés, une question de méthode demeure : le fameux mobile-first.

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

Découvrez comment nous pouvons vous accompagner

Le mobile-first s’applique-t-il au CSS ou à la conception ?

Aux deux, et ce sont deux pratiques distinctes qu’il ne faut ni confondre ni prescrire l’une pour l’autre. Le mobile-first CSS est une technique d’écriture, les styles de base pour petit écran enrichis en min-width ; le mobile-first de conception est une méthode projet, née en 2009, qui hiérarchise le contenu pour le petit écran d’abord.

/* Base : le petit ecran, sans media query */
.fiche { display: block; }

/* Enrichissement progressif vers le grand ecran */
@media (width >= 48rem) {
  .fiche {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

Le bénéfice du mobile-first CSS se formule précisément : la cascade la plus simple est servie à l’appareil le plus contraint, et l’on évite la dette d’annulations, ces blocs max-width qui passent leur temps à défaire le desktop. Ce que la technique ne fait pas mérite d’être dit aussi nettement : le CSS est téléchargé en entier dans tous les cas, et le bénéfice est de structure, pas de poids. Un fichier mobile-first mal découpé pèse exactement le même prix qu’un desktop-first mal découpé.

Le mobile-first de conception joue à un autre niveau : c’est lui qui prévient le DOM dupliqué. Quand le mobile est pensé après coup comme une réduction du desktop, la duplication est la solution de facilité qui s’impose à l’intégration ; quand la hiérarchie de contenu est arbitrée pour le petit écran d’abord, un seul balisage suffit naturellement. On peut donc écrire du CSS mobile-first sur un site conçu desktop-first, et c’est précisément le profil type du site faussement responsive. Dernière précision, tournée vers l’indexation mobile-first évoquée plus haut : penser mobile d’abord ne signifie jamais appauvrir le mobile, la parité de contenu étant désormais un enjeu de référencement autant que d’expérience.

Faut-il encore une version m. de son site ?

Non, plus aucun cas d’usage ne justifie en 2026 un domaine m. séparé, et la réponse vaut pour toute la famille des approches à deux versions. Le coût structurel est documenté : URL bifurquées, redirection par détection d’appareil qui ajoute un aller-retour réseau avant la première ressource, annotations à maintenir des deux côtés, signaux de référencement dilués.

Le domaine m. impose de rediriger chaque visiteur mobile arrivant sur une URL desktop, au prix d’un saut dont la mécanique et le coût sont détaillés dans notre guide des codes de statut HTTP. La sortie propre existe et se résume en une ligne : des redirections 301 de chaque URL m. vers l’URL unique responsive correspondante, puis la mise à mort du sous-domaine. Le dynamic serving, même URL mais HTML différent selon le User-Agent, est l’adaptatif côté serveur annoncé plus haut : il fragmente le cache par l’en-tête Vary, et son reniflage d’agent devient chaque année plus fragile depuis la réduction des informations du User-Agent au profit des Client Hints.

AMP ferme la liste du legacy. Le format imposait un jeu de pages parallèle en échange d’une place dans le carrousel Top Stories ; cette exigence a été levée avec la mise à jour Page Experience de juin 2021, qui a ouvert le carrousel à toute page quel que soit son format. L’écosystème s’est éteint depuis, et maintenir des pages AMP en 2026 revient à payer deux fois chaque gabarit pour un avantage disparu. Les thèmes mobiles séparés, plugins WordPress d’un autre âge ou thèmes mobiles encore actifs sur des boutiques PrestaShop, relèvent du même verdict multiplateforme : une seule base HTML, restylée.

Une question revient souvent en filigrane de ce legacy : Google pénalise-t-il les sites non responsive ? La réponse est indirecte mais bien réelle. Aucune sanction n’existe au motif du non-responsive en soi ; en revanche, l’indexation se fait sur la version mobile depuis fin 2023, et les signaux d’expérience de page intègrent des Core Web Vitals mesurés sur mobile : un site pénible sur téléphone cumule donc un contenu mal indexé et des signaux dégradés, sans qu’aucune pénalité formelle n’ait besoin d’exister. Le présent offre heureusement des outils autrement plus fins que ces doubles versions.

Quelles techniques modernes complètent les media queries ?

Quatre outils CSS récents réduisent le besoin même de points de rupture, en complément des media queries et non à leur place. La typographie fluide via clamp en est l’exemple le plus accessible, avec une taille qui glisse continûment entre deux bornes :

h1 {
  /* minimum 1.5rem, preferee 1.1rem + 2vw, maximum 2.5rem */
  font-size: clamp(1.5rem, 1.1rem + 2vw, 2.5rem);
}

Le gain dépasse l’esthétique : moins de paliers, ce sont moins de sauts de mise en page au franchissement des points de rupture, donc une stabilité visuelle mieux tenue. La borne minimale en rem garde le texte agrandissable, et la composante en vw se calcule pour que la transition reste douce entre les deux extrêmes : un générateur de typographie fluide fait ce calcul en quelques secondes.

Les container queries changent d’échelle de raisonnement : le composant s’adapte à la largeur de son conteneur, pas à celle de la fenêtre. Une carte produit passe d’elle-même en disposition horizontale quand sa colonne le permet, qu’elle vive dans une sidebar étroite ou une zone principale, ce qui en fait l’outil naturel des design systems. Le support est acquis dans tous les moteurs depuis début 2023, état vérifiable sur la table caniuse dédiée, en gardant les media queries pour la structure globale de la page.

.colonne { container-type: inline-size; }

@container (width >= 30rem) {
  .carte {
    display: grid;
    grid-template-columns: auto 1fr;
  }
}

/* Grille intrinseque : s'adapte sans aucune media query */
.galerie {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
  gap: 1rem;
}

La grille intrinsèque du second bloc illustre la direction générale : auto-fit et minmax produisent une galerie qui se recompose à toute largeur sans une seule condition, ce qui réduit mécaniquement la tentation de dupliquer des variantes par appareil. Les unités rem et em complètent l’ensemble en respectant le réglage de taille de texte de l’utilisateur, et aspect-ratio réserve l’espace des médias avant leur chargement, un levier de stabilité dont le détail appartient au guide des images. Tout cela s’écrit vite ; encore faut-il vérifier ce que reçoit réellement un téléphone.

Comment tester si un site est vraiment responsive ?

L’outil de test d’optimisation mobile de Google et le rapport d’ergonomie mobile de la Search Console ont été retirés le 1ᵉʳ décembre 2023, retrait annoncé par Google en avril 2023. Leurs remplaçants sont Lighthouse pour le laboratoire, les données CrUX segmentées par appareil pour le terrain, et le test sur un téléphone réel, irremplaçable.

Le piège classique de l’émulation mérite d’être nommé : le mode appareil des DevTools simule le viewport, pas le processeur ni le réseau. Un site jugé fluide sur une station de travail en fibre peut s’effondrer sur l’appareil médian du web, et c’est ce que corrige l’émulation calibrée de Lighthouse citée plus haut : viewport, réseau et processeur bridés ensemble, pour une mesure représentative du mobile réel plutôt que d’un desktop étroit. Un téléphone Android de milieu de gamme âgé de trois ans, gardé au bureau pour les recettes, reste malgré tout le juge de paix : il révèle les saccades de défilement et les délais de premier tap qu’aucune émulation ne reproduit fidèlement.

Le diagnostic complet du faussement responsive s’exécute ensuite pas à pas, chaque étape produisant un chiffre comparable d’une visite d’audit à l’autre :

comparer les octets transférés aux deux viewports dans le panneau réseau, l’écart légitime devant rester faible ;
compter les nœuds du DOM aux deux tailles et confronter le résultat aux seuils Lighthouse ;
passer l’onglet Coverage sur le CSS et le JavaScript au viewport mobile pour mesurer la part jamais exécutée ;
filtrer le panneau réseau sur les images et iframes chargées puis invisibles à l’écran ;
opposer les données CrUX mobile et desktop du site pour objectiver l’écart vécu par les visiteurs.

Chacun de ces gestes correspond à un symptôme du cœur de ce guide, et leur enchaînement tient en une heure sur un site de taille moyenne. Le suivi dans le temps relève des outils de test synthétique à profils mobiles et du monitoring continu, et les fondamentaux de mesure sont rassemblés dans notre liste de conseils d’optimisation : la régression responsive typique naît d’une refonte de menu ou d’un nouveau slider, précisément les composants que personne ne re-mesure après mise en ligne. Un budget de nœuds et d’octets par gabarit, vérifié à chaque évolution, transforme ce contrôle ponctuel en garde-fou permanent.

Une adaptation qui se juge aux octets, pas à l’écran

Quinze ans après l’article fondateur, le responsive a gagné la bataille de l’affichage et perdu, sur beaucoup de sites, celle de la sobriété. Les données CrUX le rappellent chaque mois : l’écart entre mobile et desktop ne se referme pas en ajoutant des points de rupture, il se referme en cessant d’envoyer aux téléphones des interfaces qu’ils n’afficheront jamais.

La bonne nouvelle de ce dossier est que tout s’y mesure : un DOM se compte, une feuille de style se pèse, une ressource masquée se voit dans un panneau réseau. Le responsive des prochaines années se jouera moins dans les media queries que dans cette discipline de l’envoi juste, où container queries et grilles intrinsèques rendent la duplication inutile : les sites qui l’auront comprise tôt aborderont chaque nouvelle génération d’appareils avec une longueur d’avance déjà payée.