Les sites Drupal modernes font face à un paradoxe courant : des mises en page parfaitement responsives qui chargent pourtant bien plus de données que nécessaire. En travaillant sur nos architectures multi-colonnes, nous avons identifié deux problèmes liés : l'inadaptation des composants à leur espace réel, et le chargement d'images surdimensionnées par rapport à leur contexte d'affichage. Retour sur notre démarche, des container queries CSS jusqu'au développement de notre module Container Query Images pour Drupal.
Un paradoxe persistant
La performance d'un site web ne se joue plus uniquement dans son hébergement ou ses scores techniques. Elle se joue aussi dans des détails souvent invisibles : la manière dont les composants s'adaptent à leur contexte, dont les images sont servies, dont chaque ressource est réellement nécessaire au rendu.
Sur beaucoup de projets web, un paradoxe persiste : un site peut sembler parfaitement responsive… tout en chargeant bien plus de données que nécessaire. Une image affichée dans un petit bloc continue de télécharger une version pensée pour un affichage trois fois plus large. À l'échelle d'une page, c'est imperceptible. À l'échelle d'un site entier, cela pèse sur le temps de chargement, les performances mobiles, les Core Web Vitals et l'empreinte numérique globale du service.
Pour les équipes qui gèrent des sites à fort volume éditorial, ces sujets deviennent stratégiques : un site doit rester performant dans la durée, même lorsque les contenus se multiplient et que les composants circulent dans des contextes variés.
C'est précisément en travaillant sur cette question que nous avons identifié un double problème dans nos architectures Drupal et développé une réponse en deux temps : les container queries CSS pour l'adaptation visuelle, puis notre module Container Query Images pour aligner le chargement réel des images sur leur contexte d'affichage.
Premier constat : le responsive classique ne suffisait plus
Pendant longtemps, le responsive design a très bien répondu aux besoins des sites web.
Le principe était simple. On définissait des points de rupture (breakpoints) selon la largeur de l’écran. En fonction de ces seuils, les composants changeaient de comportement.
Par exemple :
@media (min-width: 500px) {
.key-number {width: 50%; }
}Concrètement, cette règle signifie que si l’écran dépasse 500 pixels, le composant passe en affichage horizontal. Cette logique fonctionne très bien… tant que les composants vivent dans un contexte stable. Mais dès qu’on commence à construire des pages plus modulaires, la limite apparaît.
Le vrai problème : un composant ne connaît pas la largeur réelle de sa colonne
Imaginez une page composée de trois colonnes.
Sur cette page, un même bloc contient un titre, une image, un texte.
Avec une media query classique, ce bloc continue de raisonner uniquement à partir de la taille de l’écran. Autrement dit, il croit disposer de beaucoup d’espace parce que l’écran est large. Alors qu’en réalité, il n’occupe qu’un tiers de la page.
C’est là que le rendu devient moins satisfaisant :
- les proportions changent mal,
- les titres prennent trop de place,
- les images ne trouvent plus leur équilibre,
- les composants perdent en cohérence visuelle.
En conclusion, le responsive adapte bien la page… mais pas toujours le composant lui-même.
La réponse : rendre le composant autonome grâce aux container queries
Pour résoudre cela, nous avons introduit les container queries dans notre Starter.
La différence est très simple. Là où une media query se demande “Quelle est la largeur de l’écran ?”, une container query pose la question : “Quelle est la largeur réelle de l’espace que j’occupe ?”. C’est une nuance, mais elle change tout.
Concrètement, comment cela fonctionne ?
On commence par déclarer qu’un élément devient un conteneur :
.content-block {
container-type: inline-size;
}Cette ligne signifie : observe la largeur réelle de ce bloc.
Ensuite, on peut écrire une règle conditionnelle :
@container (min-width: 500px) {
.card {
display: flex;
}
}Cette fois, on dit : si ce bloc dépasse 500 pixels, adapte son affichage. Et non plus : si l’écran dépasse 500 pixels. Ainsi, le composant devient autonome. Il regarde son propre espace et s’adapte à sa colonne, pas à toute la page.
Et immédiatement, les composants retrouvent un équilibre visuel !
Un deuxième problème, plus discret : le poids réel des images
Visuellement, tout fonctionnait mieux. Mais en observant plus finement les performances, nous avons constaté un second décalage. Prenons un exemple simple.
Une image s’affiche :
- une première fois dans une colonne large,
- une seconde fois dans une petite colonne.
Grâce aux container queries, visuellement, sa taille change très bien. Mais techniquement… ce n’est souvent pas la bonne image qui est chargée.
Pourquoi ? Parce que les images ne fonctionnent pas comme le CSS.
CSS et images : deux logiques différentes
Avec les container queries, un composant adapte parfaitement son apparence à l'espace qu'il occupe. Mais le CSS agit uniquement sur l'affichage : il ne choisit pas le fichier image téléchargé. Ce choix intervient plus tôt, côté serveur.
Dans Drupal, le système responsive image génère plusieurs variantes d'un même visuel, et le navigateur sélectionne la version à charger selon des règles basées sur la largeur de l'écran. Efficace en responsive classique, mais inadapté aux container queries : un composant peut occuper une petite colonne sur un grand écran, et Drupal continuera à servir une image large. Le composant paraît petit visuellement… mais son poids reste celui d'une grande version.
Container Query Images : notre réponse native pour Drupal
Pour corriger ce décalage, nous avons développé le module Container Query Images. Il prolonge la logique native des images responsives de Drupal en y intégrant la notion de conteneur.
Le principe : on définit plusieurs variantes d'une même image (small, medium, large), comme dans un style d'image Drupal classique. Mais au lieu de sélectionner la variante en fonction de la largeur du viewport, le module s'appuie sur la largeur réelle du conteneur dans lequel l'image s'affiche.
Concrètement, une image placée dans une colonne étroite chargera automatiquement une version allégée, même si l'utilisateur consulte le site sur un grand écran. Le composant est alors cohérent à la fois visuellement et techniquement : il affiche la bonne taille, et télécharge le bon fichier.
Résultat direct : moins de données transférées, un rendu plus rapide, et une meilleure cohérence entre ce que voit l'utilisateur et ce que consomme réellement la page.
Exemple concret
Une image placée dans un petit bloc peut charger automatiquement une version small. Même si l’utilisateur consulte le site sur un grand écran.
Résultats :
- moins de données téléchargées,
- rendu plus rapide,
- meilleure performance et l'éco-conception globale.
Autrement dit : le composant est cohérent visuellement et techniquement.
Un équilibre nécessaire : pourquoi nous avons limité à trois colonnes
Ce type d’optimisation demande aussi de rester pragmatique. Car multiplier les cas possibles signifie multiplier les versions d’images générées côté serveur.
Et trop de variantes finit par devenir contre-productif (stockage plus important, génération plus lourde). C’est pourquoi, dans notre starter, nous avons volontairement limité le système à trois colonnes. Cela permet de couvrir les cas éditoriaux réellement utiles, sans créer une inflation inutile des déclinaisons d’images.
Ce que cela change, concrètement
Les container queries ont rendu les composants plus intelligents. Il fallait que les images suivent cette logique.
Avec Container Query Images, nous avons simplement prolongé cette évolution dans Drupal.
Parce qu’aujourd’hui, un composant ne vit plus dans une seule page. Il circule. Il change de contexte. Et il doit rester performant et éco-conçu partout. Au fond, c’est souvent là que se joue la qualité réelle d’un site : dans ces optimisations peu visibles pour l’utilisateur final, mais décisives pour la cohérence, la rapidité et la durabilité de l’outil.
À mesure que les architectures éditoriales deviennent plus modulaires, ces sujets ne relèvent plus seulement du front-end : ils concernent directement la capacité d’un site à rester performant dans le temps, sans complexifier sa maintenance.
Vous travaillez sur un projet Drupal ou une refonte de votre socle éditorial ?
À mesure que les architectures éditoriales deviennent plus modulaires, ces optimisations ne relèvent plus seulement du front-end. Elles conditionnent directement la capacité d'un site à rester performant dans le temps, sans alourdir sa maintenance.
Chez bluedrop.fr, nous travaillons précisément sur ces sujets. Si vous réfléchissez à une évolution de votre socle Drupal ou à une refonte éditoriale, nous serons heureux d'en discuter avec vous.
