Modern Drupal sites face a common paradox: perfectly responsive layouts that nonetheless load far more data than necessary. While working on our multi-column architectures, we identified two related issues: components not adapting to their actual space, and oversized images being loaded compared to their display context. Here’s a look back at our approach, from CSS container queries to the development of our Container Query Images module for Drupal.
A persistent paradox
The performance of a website is no longer just about its hosting or its technical scores. It also depends on details that are often invisible: how components adapt to their context, how images are delivered, and whether each resource is truly necessary for rendering.
On many web projects, a paradox persists: a site may appear perfectly responsive… while actually loading far more data than needed. An image displayed in a small block still downloads a version intended for a display three times larger. On the scale of a single page, this goes unnoticed. On the scale of an entire site, it impacts loading times, mobile performance, Core Web Vitals, and the site's overall digital footprint.
For teams managing sites with a high volume of editorial content, these issues become strategic: a site must remain high-performing over time, even as content multiplies and components move through various contexts.
It was precisely while working on this issue that we identified a dual problem in our Drupal architectures and developed a two-pronged solution: CSS container queries for visual adaptation, then our Container Query Images module to align actual image loading with their display context.
First observation: classic responsiveness was no longer enough
For a long time, responsive design met the needs of websites very well.
The concept was simple. Breakpoints were defined according to the screen width. Depending on these thresholds, components would change their behavior.
For example:
@media (min-width: 500px) {
.key-number {width: 50%; }
}Specifically, this rule means that if the screen is wider than 500 pixels, the component switches to horizontal display. This logic works very well... as long as components live in a stable context. But as soon as you start building more modular pages, the limitation becomes apparent.
The real problem: a component does not know the true width of its column
Imagine a page made up of three columns.
On this page, the same block contains a title, an image, and some text.
With a traditional media query, this block continues to reason only based on the screen size. In other words, it thinks it has a lot of space because the screen is wide. But in reality, it only takes up a third of the page.
This is where the result becomes less satisfying:
- the proportions are off,
- the headings take up too much space,
- the images no longer find their balance,
- the components lose visual harmony.
In conclusion, responsive design adapts the page well… but not always the component itself.
The answer: make the component autonomous thanks to container queries
To solve this, we introduced container queries in our Starter.
The difference is very simple. While a media query asks “What is the width of the screen?”, a container query asks: “What is the actual width of the space I occupy?” It’s a subtle distinction, but it changes everything.
Specifically, how does it work?
We start by declaring that an element becomes a container:
.content-block {
container-type: inline-size;
}This line means: observe the actual width of this block.
Next, we can write a conditional rule:
@container (min-width: 500px) {
.card {
display: flex;
}
}This time, we're saying: if this block exceeds 500 pixels, adjust its display. No longer: if the screen exceeds 500 pixels. In this way, the component becomes autonomous. It looks at its own space and adapts to its column, not to the whole page.
And immediately, the components regain visual balance!
A second, more subtle problem: the actual weight of the images
Visually, everything worked better. But by looking more closely at the performance, we noticed a second issue. Let's take a simple example.
An image is displayed:
- first in a wide column,
- then a second time in a small column.
Thanks to container queries, visually, its size changes just fine. But technically… it's often not the right image that's loaded.
Why? Because images don't work like CSS does.
CSS and images: two different approaches
With container queries, a component perfectly adapts its appearance to the space it occupies. But CSS only affects the display: it doesn't choose which image file is downloaded. That choice happens earlier, on the server side.
In Drupal, the responsive image system generates several variants of the same visual, and the browser selects which version to load based on rules tied to screen width. This is effective for classic responsive design but unsuitable for container queries: a component may occupy a small column on a large screen, yet Drupal will continue to serve a large image. The component may look small visually… but its weight remains that of the large version.
Container Query Images: our native solution for Drupal
To correct this discrepancy, we developed the Container Query Images module. It extends Drupal's native responsive image logic by incorporating the concept of a container.
The principle: you define several variants of the same image (small, medium, large), just like in a classic Drupal image style. But instead of selecting the variant based on the viewport width, the module relies on the actual width of the container in which the image is displayed.
In practice, an image placed in a narrow column will automatically load a lighter version, even if the user is viewing the site on a large screen. The component is therefore both visually and technically consistent: it displays the right size and downloads the right file.
Direct result: less data transferred, faster rendering, and better consistency between what the user sees and what the page actually consumes.
Concrete example
An image placed in a small block can automatically load a small version. Even if the user is viewing the site on a large screen.
Results:
- less data downloaded,
- faster rendering,
- better performance and overall eco-design.
In other words: the component is visually and technically consistent.
A necessary balance: why we limited it to three columns
This type of optimization also requires a pragmatic approach. Because multiplying the possible cases means multiplying the versions of images generated on the server side.
And too many variants ends up being counterproductive (increased storage, heavier generation). That’s why, in our starter, we deliberately limited the system to three columns. This allows us to cover the truly useful editorial cases without creating unnecessary inflation in image variations.
What this actually changes
Container queries have made components smarter. Images needed to follow this logic as well.
With Container Query Images, we've simply extended this evolution in Drupal.
Because today, a component no longer lives only on a single page. It moves around. It changes context. And it must remain efficient and sustainably designed everywhere. Deep down, this is often where the true quality of a site lies: in these optimizations that are barely visible to the end user, yet crucial for the coherence, speed, and durability of the tool.
As editorial architectures become more modular, these issues are no longer just front-end matters: they directly affect a site's ability to remain efficient over time without making its maintenance more complex.
Are you working on a Drupal project or a redesign of your editorial platform?
As editorial architectures become more modular, these optimizations are no longer just a matter of the front end. They directly determine a site's ability to remain efficient over time, without increasing maintenance effort.
At bluedrop.fr, we focus precisely on these issues. If you are considering an upgrade to your Drupal platform or an editorial redesign, we would be happy to discuss it with you.
