What does re­spon­sive design mean?

Re­spon­sive web design refers to the approach of de­vel­op­ing a website that displays optimally across different devices. The term re­spon­sive design is as old as the mobile web and is es­tab­lished as a standard approach in web design.

Re­spon­sive design at a glance

Before the rise of the mobile web, the landscape of internet-enabled devices was rel­a­tive­ly ho­mo­ge­neous. There were desktop or laptop computers, which were quite similar in terms of input and output devices. Both types of devices featured a keyboard and mouse or trackpad, as well as a screen with a width of around 1,000 to 2,000 pixels.

Back then, creating a website that displayed properly on most devices did not require excessive effort. The easiest solution was to limit the page width to the smallest common de­nom­i­na­tor. A popular approach was to display pages 800 pixels wide and centered or left-aligned. On a larger screen, this might result in a bit more white space, but the pages were easy to read on all devices.

With the rise of mobile devices, the landscape of internet-enabled devices has changed fun­da­men­tal­ly. While early internet-capable devices had fairly similar screen sizes, modern devices such as smart­phones and tablets vary sig­nif­i­cant­ly. Today, screen widths range from 320 pixels to well over 4,000 pixels. Beyond basic pixel di­men­sions, factors like physical res­o­lu­tion (“pixels per inch”, ppi), Retina displays, and the device pixel ratio (DPR) also play an important role. In­ter­ac­tion has evolved as well. Nav­i­ga­tion is no longer limited to a mouse but in­creas­ing­ly happens via touch.

A re­spon­sive website adapts to the available space on the screen. This is also referred to as “screen real estate.” The website should look good on all devices and provide an optimal user ex­pe­ri­ence (UX).

Re­spon­sive design includes a wide range of tech­niques and ap­proach­es that are combined to develop a fully re­spon­sive website. These include in par­tic­u­lar:

• HTML5 elements such as picture and at­trib­ut­es like srcset and sizes
• CSS media queries
• CSS units
• Use of multiple assets for a resource
• Mobile-first approach

In addition to classic smart­phones and tablets, foldables and dual-screen devices are becoming in­creas­ing­ly important. These devices can change their display area dy­nam­i­cal­ly, for example when unfolded or when switching between single- and split-screen views. For re­spon­sive design, this means that layouts must not only react to different screen sizes, but also to sudden changes in available space during use. Modern re­spon­sive websites should therefore be flexible enough to present content con­sis­tent­ly and user-friendly, even with changing form factors.

Why should a website be built with re­spon­sive design?

De­vel­op­ing a re­spon­sive website offers several ad­van­tages, with user ex­pe­ri­ence taking center stage. In principle, a good user ex­pe­ri­ence can also be achieved without re­spon­sive design. However, this then requires either a separate mobile site or the use of JavaScript. Overall, this is often sig­nif­i­cant­ly more complex than the CSS-based re­spon­sive design approach and results in more effort to maintain the different site versions.

Re­spon­sive design for optimal layout

The design of a website has a decisive impact on how visitors perceive the in­for­ma­tion presented. A well-crafted design reflects the identity of the or­ga­ni­za­tion behind the website and helps to build a con­nec­tion with the brand. Visitors should feel com­fort­able on the site and have a positive ex­pe­ri­ence. Let’s look at two examples of how re­spon­sive design con­tributes to an optimal user ex­pe­ri­ence:

• Imagine a headline that fills the entire screen on a mobile device. However, on the desktop version, the same font size hardly stands out. On desktop, the headline must be displayed larger to truly grab the visitors’ attention.
• On a blog, a sidebar is shown to the right of the article. The sidebar contains links to ad­di­tion­al articles with small preview images. On desktop, the sidebar helps limit the article width and improves read­abil­i­ty. On mobile devices, however, the sidebar would take up nearly half the screen. The layout must adjust on mobile devices so that the sidebar content appears below the article.

Re­spon­sive design for optimal user ex­pe­ri­ence (UX)

In principle, a website not built with re­spon­sive design is displayed on the small screen of a mobile device exactly as it is on the desktop, just much smaller. This forces users to zoom in on in­di­vid­ual sections of the page. It is therefore better to offer an optimized version. Here are a few examples:

• A button on a website is clicked with a mouse on a desktop, but a mobile device is operated with a finger. The button needs to be larger for the mobile version and should have more spacing from other elements.
• Imagine a form on a page. Normally, CSS assigns it inner spacing (padding) so the text is easy to read and doesn’t touch the form’s edges. An inner spacing of 20 pixels on both the right and left is standard and looks good on large screens. But on a mobile device with only 320 pixels of screen width, 40 out of 320 pixels are lost (about one eighth). If the form also has outer spacing (margin), say another 20 pixels per side, 25 percent of the available space is lost on the mobile device. To prevent this, the spacing should be reduced on mobile devices.

The con­se­quences of not using re­spon­sive design

A sig­nif­i­cant number of users now access web content through mobile devices. If a website isn’t fully built with re­spon­sive design, there are serious drawbacks. These include:

• Low con­ver­sion rates and high bounce rates due to subpar design and dis­rup­tions to the user ex­pe­ri­ence
• Poor search engine ranking, as Google takes into account factors like mobile usability, Core Web Vitals, and touch target sizes
• Reduced per­for­mance caused by loading non-optimized resources, which can be measured through metrics such as Largest Con­tent­ful Paint (LCP) and In­ter­ac­tion to Next Paint (INP)

Core web vitals and un­der­stand­ing user ex­pe­ri­ence metrics

Google uses Core Web Vitals to ob­jec­tive­ly evaluate the real user ex­pe­ri­ence. These are stan­dard­ized per­for­mance metrics that assess how fast content loads, how stable the layout remains, and how quickly a re­spon­sive website responds to user in­ter­ac­tions. The key Core Web Vitals are:

• Largest Con­tent­ful Paint (LCP): measures how long it takes until the largest visible content element is rendered (target value ≤ 2.5 s)
• In­ter­ac­tion to Next Paint (INP): captures how re­spon­sive a page is during user in­ter­ac­tions (target value ≤ 200 ms)
• Cu­mu­la­tive Layout Shift (CLS): evaluates whether content shifts un­ex­pect­ed­ly while loading (target value ≤ 0.1)

Non‑re­spon­sive websites often perform worse on these metrics, for example due to oversized image files, lazy‑loaded content, or layout ad­just­ments that are not tailored to mobile devices.

Tools for analyzing Core Web Vitals

Core Web Vitals can be measured using various tools. Some of the most commonly used ones are:

• Google PageSpeed Insights: analyzes in­di­vid­ual pages, combining real user data with lab results
• Google Light­house: in­te­grat­ed into Chrome developer tools, perfect for in-depth per­for­mance analysis
• Google Search Console: displays ag­gre­gat­ed Core Web Vitals data for entire websites and high­lights prob­lem­at­ic URLs

These tools help you identify weak­ness­es and assess how changes in re­spon­sive design impact the user ex­pe­ri­ence.

Which aspects of web de­vel­op­ment are affected by re­spon­sive design?

Re­spon­sive design includes various ap­proach­es and tech­nolo­gies. Typically, there are multiple solutions for the different scenarios. De­vel­op­ment in this area continues to evolve.

Re­spon­sive layout

Im­ple­ment­ing complex layouts on websites has been a science of its own since the early days of the World Wide Web. HTML includes different element types: block, inline, and inline-block. Block elements take up the full available width and are stacked ver­ti­cal­ly. Inline elements only use the width actually required by their content and are po­si­tioned next to each other. Here is an overview of the most important element types for re­spon­sive design:

In the past, table-based or float-based layouts were used to arrange content side by side. These ap­proach­es are now con­sid­ered outdated. Modern re­spon­sive design layouts are based almost ex­clu­sive­ly on CSS Flexbox and CSS Grid. Flexbox is par­tic­u­lar­ly suitable for one-di­men­sion­al layouts, such as hor­i­zon­tal or vertical lists, while CSS Grid is used for complex, two-di­men­sion­al page struc­tures.

A clear example is a page with four preview elements for blog articles. Each preview contains an image, headline, teaser, and a “Read more” button. Flexbox makes it easy to implement the following re­spon­sive layout:

• On a large screen, all preview elements are displayed side by side in a single row, with each element taking up 25 percent of the available space.
• On a medium-sized screen, two preview elements are displayed side by side in two rows, with each element taking up 50 percent of the available space.
• On a small screen, all four preview elements are stacked ver­ti­cal­ly in a single column, with each element taking up 100 percent of the available space.

Re­spon­sive layout with CSS Grid and media queries

Modern re­spon­sive design layouts can often be im­ple­ment­ed without the need for an ad­di­tion­al CSS framework. Native layout tools like CSS Grid and Flexbox are widely supported, making it easier to create flexible and main­tain­able struc­tures. A key tool in this process is CSS media queries. These allow CSS rules to be applied based on the prop­er­ties of the output device, par­tic­u­lar­ly the viewport width. Media queries determine under what con­di­tions a specific layout should be used, such as a certain screen size or device ori­en­ta­tion.

Let’s consider a page with four preview elements for blog articles. Each element includes an image, a headline, a short text, and a link to the full article. The goal is to adjust the number of elements displayed side by side based on the available screen width.

HTML structure:

<div class="blog-grid">
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
</div>

CSS im­ple­men­ta­tion with CSS Grid:

.blog-grid {
    display: grid;
    grid-template-columns: 1fr;
    gap: 1.5rem;
}
/ *medium screens* /
@media screen and (min-width: 600px) {
    .blog-grid {
        grid-template-columns: repeat(2, 1fr);
    }
}
/ *large screens* /
@media screen and (min-width: 1024px) {
    .blog-grid {
        grid-template-columns: repeat(4, 1fr);
    }
}

Without a media query, a simple layout for small screens is defined first. Starting at a width of 600 pixels, two columns are displayed, and from 1,024 pixels, four columns. This approach follows the mobile-first principle and ensures that content remains clear on small displays and is used optimally on larger screens. Media queries always respond to the viewport, meaning the size of the browser window or screen.

How container queries enable re­spon­sive design at the component level

While media queries respond to the viewport size, CSS container queries take a different approach. They allow styles to be applied based on the size of a sur­round­ing container, rather than the screen size. This means elements no longer react to the entire browser window but to the available space within a specific layout. This is par­tic­u­lar­ly useful in modular layouts where com­po­nents are used multiple times in different contexts, such as in a narrow sidebar or a wide main content area. Media queries alone can only represent these scenarios in a limited way.

A common example is a preview element for articles. When placed in a narrow sidebar, the image and text should be stacked ver­ti­cal­ly. In a wider main content area, however, the image and text can be displayed side by side. Container queries allow for this context-based ad­just­ment without needing to define ad­di­tion­al break­points for every layout variation. First, the parent container is des­ig­nat­ed as a “query container.”

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

The preview component itself gets a simple basic layout that is optimized for limited space:

.article-preview {
    display: flex;
    flex-direction: column;
    gap: 1rem;
}

Next, a container query specifies that the layout adjusts once the container exceeds a certain width:

@container (min-width: 500px) {
    .article-preview {
        flex-direction: row;
    }
}

The component au­to­mat­i­cal­ly adjusts to the available space within its container, re­gard­less of whether it’s in a sidebar or the main content area. The key factor is the container’s width, not the viewport size. Container queries enable a component-based approach to re­spon­sive design and serve as a valuable com­ple­ment to tra­di­tion­al media queries. In modern projects, both tech­niques are often combined to achieve broad layout changes as well as detailed ad­just­ments of in­di­vid­ual com­po­nents, ensuring a fully re­spon­sive website.

Re­spon­sive ty­pog­ra­phy and text content

To provide an optimal user ex­pe­ri­ence, the font size of a website’s text elements must adapt to the available screen space and usage contexts. Beyond read­abil­i­ty, factors like scal­a­bil­i­ty, ac­ces­si­bil­i­ty, and layout stability are also crucial. To achieve this, various font tech­niques are employed in re­spon­sive design.

A fun­da­men­tal approach involves using the CSS unit rem (“root element”), which links an element’s font size pro­por­tion­al­ly to the HTML root element. By adjusting the font size of the root element through CSS break­points, all fonts can be scaled uniformly.

html {
    font-size: 16px;
}
h1 {
    font-size: 3rem;
}

This approach can be ef­fec­tive­ly combined with media queries in a mobile-first strategy to mod­er­ate­ly increase the base font size on larger screens:

@media screen and (min-width: 30em) {
    html {
        font-size: 18px;
    }
}

In modern layouts, fluid ty­pog­ra­phy is in­creas­ing­ly used, adapting smoothly to the available space. The CSS clamp() function is now the preferred tool for this. It lets you define a minimum, a preferred, and a maximum font size, all without ad­di­tion­al break­points.

h1 {
    font-size: clamp(2rem, 4vw, 3.5rem);
}

This keeps the text easily readable on small displays, lets it grow dy­nam­i­cal­ly on larger screens, and ensures it never exceeds the defined limits. Today, clamp() is con­sid­ered best practice for re­spon­sive ty­pog­ra­phy in modern re­spon­sive design.

Re­spon­sive images

Along with layout and ty­pog­ra­phy, op­ti­miz­ing image rendering is a crucial aspect of re­spon­sive design. It clearly doesn’t make sense to load an image with a 1,920‑pixel width onto a phone with a 400‑pixel-wide screen. First, the browser must downscale the oversized image, which consumes extra pro­cess­ing power. Second, the file size of an image increases with the number of pixels.

For example, an image with 1,920 x 1,080 pixels will require about four times more storage than an image with 960 x 540 pixels. Down­load­ing such a large image to a mobile device also takes sig­nif­i­cant­ly longer. Overall, this has a negative impact on website per­for­mance and usability if images aren’t optimized for different screen sizes.

For re­spon­sive images, the srcset and sizes at­trib­ut­es have become standard, enabling browsers to select the ap­pro­pri­ate image based on the context. These are often referred to as “assets.” Each image file is linked to a CSS media feature query. This allows the browser to choose the most suitable asset from the list based on the specific device.

Here’s a brief example. The following HTML code defines an image with two assets using srcset: one with a 480‑pixel width and another with an 800‑pixel width. The sizes attribute specifies that the 480‑pixel image should be used for screens up to 600 pixels wide. For larger screens, the browser will load the 800‑pixel image:

<img
    src="image-800w.jpg"
    srcset="image-480w.jpg 480w,
                    image-800w.jpg 800w"
    sizes="(max-width: 600px) 480px,
                 800px"
    alt="Image description">

The main advantage of this approach is that the browser au­to­mat­i­cal­ly de­ter­mines which image variant to load. De­vel­op­ers only need to specify ap­pro­pri­ate image sizes, without having to manually manage the selection process.

Tra­di­tion­al­ly, screens were designed in landscape format, but mobile phone screens are oriented in portrait format. A landscape image appears quite small on a portrait device. To improve the result, it’s better to use a square or portrait image cropped specif­i­cal­ly for that purpose. Choosing different crops of an image is called “art direction.” This can be achieved using the <picture> element, which enables the de­f­i­n­i­tion of multiple image variants for different scenarios.

Here’s an example. The following HTML code defines a <picture> element that specifies different assets for landscape and portrait ori­en­ta­tions, with multiple versions optimized for different screen sizes in both cases:

<picture>
<source
media="(orientation: landscape)"
srcset="image-small-landscape.png 320w,
image-large-landscape.png 1200w"
sizes="(min-width: 60rem) 80vw,
(min-width: 40rem) 90vw,
100vw">
<source
media="(orientation: portrait)"
srcset="image-small-portrait.png 160w,
image-large-portrait.png 600w"
sizes="(min-width: 60rem) 80vw,
(min-width: 40rem) 90vw,
100vw">
<img src="image-small.png" alt="Image description">
</picture>

This ensures that a subject is displayed just as ef­fec­tive­ly on small, portrait‑format displays as it is on large screens.

Re­spon­sive nav­i­ga­tion

Nav­i­ga­tion is a key element of a website and presents a unique challenge in re­spon­sive design. Tra­di­tion­al­ly, nav­i­ga­tion is placed in the header on large screens and includes submenus that appear when hovered over with a mouse pointer. This approach doesn’t work on mobile devices. On small screens, there isn’t enough space for the menu, and in­ter­ac­tion is via touch, not a mouse.

There are several ways to display nav­i­ga­tion menus on mobile devices, all of which save space and do not require a mouse pointer. Nav­i­ga­tion ac­ti­va­tion is often ac­com­pa­nied by an animation to capture the user’s attention. Some of the most common ap­proach­es for re­spon­sive nav­i­ga­tion include:

• The “hamburger menu” icon (three hor­i­zon­tal lines): This serves as the main control to activate the menu.
• The “off-canvas” nav­i­ga­tion: The menu slides in from the edge of the screen, pushing the page content aside.

In practice, other es­tab­lished nav­i­ga­tion patterns are also used, each offering benefits depending on the context. For example, bottom nav­i­ga­tion places key nav­i­ga­tion items at the bottom edge of the screen for easy access with the thumb. “Priority+” menus pri­or­i­tize important items, dy­nam­i­cal­ly moving less relevant entries into a submenu. For large, content-heavy websites, mega menus with touch op­ti­miza­tion are also used, providing clear or­ga­ni­za­tion even on larger tablets and hybrid devices.