What does re­spons­ive design mean?

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

Re­spons­ive design at a glance

Before the rise of the mobile web, the landscape of internet-enabled devices was re­l­at­ively ho­mo­gen­eous. 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­in­at­or. A popular approach was to display pages 800 pixels wide and centred 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­ment­ally. While early internet-capable devices had fairly similar screen sizes, modern devices such as smart­phones and tablets vary sig­ni­fic­antly. Today, screen widths range from 320 pixels to well over 4,000 pixels. Beyond basic pixel di­men­sions, factors like physical res­ol­u­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­ig­a­tion is no longer limited to a mouse but in­creas­ingly happens via touch.

A re­spons­ive 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­per­i­ence (UX).

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

• HTML5 elements such as picture and at­trib­utes 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­ingly important. These devices can change their display area dy­nam­ic­ally, for example when unfolded or when switching between single- and split-screen views. For re­spons­ive 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­spons­ive websites should therefore be flexible enough to present content con­sist­ently and user-friendly, even with changing form factors.

Why should a website be built with re­spons­ive design?

De­vel­op­ing a re­spons­ive website offers several ad­vant­ages, with user ex­per­i­ence taking centre stage. In principle, a good user ex­per­i­ence can also be achieved without re­spons­ive design. However, this then requires either a separate mobile site or the use of JavaS­cript. Overall, this is often sig­ni­fic­antly more complex than the CSS-based re­spons­ive design approach and results in more effort to maintain the different site versions.

Re­spons­ive design for optimal layout

The design of a website has a decisive impact on how visitors perceive the in­form­a­tion presented. A well-crafted design reflects the identity of the or­gan­isa­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­per­i­ence. Let’s look at two examples of how re­spons­ive design con­trib­utes to an optimal user ex­per­i­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­ab­il­ity. 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­spons­ive design for optimal user ex­per­i­ence (UX)

In principle, a website not built with re­spons­ive 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­vidu­al sections of the page. It is therefore better to offer an optimised 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­sequences of not using re­spons­ive design

A sig­ni­fic­ant number of users now access web content through mobile devices. If a website isn’t fully built with re­spons­ive 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­per­i­ence
• Poor search engine ranking, as Google takes into account factors like mobile usability, Core Web Vitals, and touch target sizes
• Reduced per­form­ance caused by loading non-optimised 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­per­i­ence metrics

Google uses Core Web Vitals to ob­ject­ively evaluate the real user ex­per­i­ence. These are stand­ard­ised per­form­ance metrics that assess how fast content loads, how stable the layout remains, and how quickly a re­spons­ive 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­spons­ive a page is during user in­ter­ac­tions (target value ≤ 200 ms)
• Cu­mu­lat­ive Layout Shift (CLS): evaluates whether content shifts un­ex­pec­tedly while loading (target value ≤ 0.1)

Non‑re­spons­ive 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 analysing Core Web Vitals

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

• Google PageSpeed Insights: analyses in­di­vidu­al pages, combining real user data with lab results
• Google Light­house: in­teg­rated into Chrome developer tools, perfect for in-depth per­form­ance analysis
• Google Search Console: displays ag­greg­ated Core Web Vitals data for entire websites and high­lights prob­lem­at­ic URLs

These tools help you identify weak­nesses and assess how changes in re­spons­ive design impact the user ex­per­i­ence.

Which aspects of web de­vel­op­ment are affected by re­spons­ive design?

Re­spons­ive design includes various ap­proaches and tech­no­lo­gies. Typically, there are multiple solutions for the different scenarios. De­vel­op­ment in this area continues to evolve.

Re­spons­ive 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­tic­ally. 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­spons­ive design:

In the past, table-based or float-based layouts were used to arrange content side by side. These ap­proaches are now con­sidered outdated. Modern re­spons­ive design layouts are based almost ex­clus­ively on CSS Flexbox and CSS Grid. Flexbox is par­tic­u­larly suitable for one-di­men­sion­al layouts, such as ho­ri­zont­al 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­spons­ive 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­tic­ally in a single column, with each element taking up 100 percent of the available space.

Re­spons­ive layout with CSS Grid and media queries

Modern re­spons­ive design layouts can often be im­ple­men­ted 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­larly 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­ent­a­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­ment­a­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­spons­ive 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­larly useful in modular layouts where com­pon­ents 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­tic­ally. 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­nated as a ‘query container’.

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

The preview component itself gets a simple basic layout that is optimised 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 auto­mat­ic­ally 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­spons­ive 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­vidu­al com­pon­ents, ensuring a fully re­spons­ive website.

Re­spons­ive ty­po­graphy and text content

To provide an optimal user ex­per­i­ence, the font size of a website’s text elements must adapt to the available screen space and usage contexts. Beyond read­ab­il­ity, factors like scalab­il­ity, ac­cess­ib­il­ity, and layout stability are also crucial. To achieve this, various font tech­niques are employed in re­spons­ive design.

A fun­da­ment­al approach involves using the CSS unit rem (‘root element’), which links an element’s font size pro­por­tion­ally 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­fect­ively combined with media queries in a mobile-first strategy to mod­er­ately increase the base font size on larger screens:

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

In modern layouts, fluid ty­po­graphy is in­creas­ingly 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­ic­ally on larger screens, and ensures it never exceeds the defined limits. Today, clamp() is con­sidered best practice for re­spons­ive ty­po­graphy in modern re­spons­ive design.

Re­spons­ive images

Along with layout and ty­po­graphy, op­tim­ising image rendering is a crucial aspect of re­spons­ive 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­cessing 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­ni­fic­antly longer. Overall, this has a negative impact on website per­form­ance and usability if images aren’t optimised for different screen sizes.

For re­spons­ive images, the srcset and sizes at­trib­utes 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 auto­mat­ic­ally de­term­ines which image variant to load. De­velopers only need to specify ap­pro­pri­ate image sizes, without having to manually manage the selection process.

Tra­di­tion­ally, 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 spe­cific­ally for that purpose. Choosing different crops of an image is called ‘art direction’. This can be achieved using the <picture> element, which enables the defin­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­ent­a­tions, with multiple versions optimised 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­fect­ively on small, portrait‑format displays as it is on large screens.

Re­spons­ive nav­ig­a­tion

Nav­ig­a­tion is a key element of a website and presents a unique challenge in re­spons­ive design. Tra­di­tion­ally, nav­ig­a­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­ig­a­tion menus on mobile devices, all of which save space and do not require a mouse pointer. Nav­ig­a­tion ac­tiv­a­tion is often ac­com­pan­ied by an animation to capture the user’s attention. Some of the most common ap­proaches for re­spons­ive nav­ig­a­tion include:

• The ‘hamburger menu’ icon (three ho­ri­zont­al lines): This serves as the main control to activate the menu.
• The ‘off-canvas’ nav­ig­a­tion: The menu slides in from the edge of the screen, pushing the page content aside.

In practice, other es­tab­lished nav­ig­a­tion patterns are also used, each offering benefits depending on the context. For example, bottom nav­ig­a­tion places key nav­ig­a­tion items at the bottom edge of the screen for easy access with the thumb. ‘Priority+’ menus pri­or­it­ise important items, dy­nam­ic­ally moving less relevant entries into a submenu. For large, content-heavy websites, mega menus with touch op­tim­isa­tion are also used, providing clear or­gan­isa­tion even on larger tablets and hybrid devices.