Feste Pixelbreiten stammen aus einer Zeit, in der Designer davon ausgingen, dass alle Besucher mit 1024×768 unterwegs sind.

Setzen Sie heute width: 960px auf Ihren Seitencontainer, bekommt jeder Besucher mit schmalerem Fenster einen horizontalen Scrollbalken, und wer auf 400 Prozent zoomt, weil er schlecht sieht, ebenfalls.

Letzteres ist nicht nur unschön, es ist ein Verstoß gegen WCAG 1.4.10, und bei rechtlich verpflichteten Seiten kann Ihnen das teuer werden.

Ein Fluid Layout löst das an der Wurzel, weil es keine feste Zielbreite mehr kennt.

Was ein Fluid Layout ist

Bei einem Fluid Layout werden Breiten relativ angegeben, klassischerweise in Prozent.

.sidebar { width: 20%; }
.main-content { width: 80%; }

Die Sidebar nimmt immer 20 Prozent des Elternelements ein, ob das 200 px, 600 px oder 1400 px sind.

Für dasselbe Konzept lesen Sie auch „Liquid Design“ oder „Liquid Layout“.

Das ist kein anderer Ansatz, sondern ein Synonym, im Deutschen ist „Fluid Layout“ gebräuchlicher.

Nachweisbar ist der Begriff seit November 2002, damals auf SitePoint.

Reines Prozent-Layout aus den frühen 2000ern ist allerdings nicht das, was Sie heute bauen sollten, denn ohne Grenzen wird es auf breiten Bildschirmen unlesbar und auf schmalen zu eng.

Genau deshalb kombiniert man Prozentwerte heute mit clamp(), minmax() und Container Queries.

Fixed, Fluid, Adaptive, Responsive: die Abgrenzung

Diese vier Begriffe werden ständig verwechselt, und das führt dazu, dass Kunden fluide Seiten bestellen und adaptive bekommen.

Fixed Layout: Alle Elemente haben feste Pixelbreiten, die Seite sieht überall gleich aus. Dominant von Mitte der 1990er bis etwa 2005, mit Zielbreiten von 640 px, 800 px und später 960 px.

Fluid Layout (liquid): Breiten in Prozent, alles skaliert proportional mit dem verfügbaren Platz. Keine Media Queries, keine Sprünge.

Elastic Layout: Breiten und Schriftgrößen in em, das Layout skaliert mit der Schriftgröße des Nutzers statt mit dem Viewport. Diskutiert zwischen 2004 und 2009, heute kaum noch als eigener Ansatz verbreitet.

Adaptive Layout: Feste Layouts für definierte Breakpoints. Das Design springt an bestimmten Viewport-Breiten auf eine andere feste Version, dazwischen passiert nichts.

/* Adaptive: springt, fließt nicht */
.wrapper { width: 320px; }

@media (min-width: 768px)  { .wrapper { width: 768px; } }
@media (min-width: 1024px) { .wrapper { width: 1024px; } }

Responsive Web Design: Die Kombination aus fluiden Grids, flexiblen Bildern und Media Queries, definiert von Ethan Marcotte am 25. Mai 2010 auf A List Apart.

Der entscheidende Punkt wird dabei fast immer übersehen: Responsive ersetzt Fluid nicht, es baut darauf auf.

Ein Fluid Layout passt die Proportionen an, ein Responsive Layout ändert zusätzlich das Design selbst, etwa wenn die Navigation zum Hamburger-Menü kollabiert.

Typ	Einheit	Media Queries	Layout ändert sich
Fixed	px	nein	nein
Fluid/Liquid	%	nein	fließend proportional
Elastic	em	nein	mit Schriftgröße
Adaptive	px + Breakpoints	ja	springt an definierten Punkten
Responsive	% + px gemischt	ja	fließend + gesteuerte Sprünge

Mehr zum Gesamtbild finden Sie unter Responsive Webdesign.

Die Einheiten, mit denen Sie arbeiten

• %: relativ zum Elternelement, die klassische Fluid-Einheit.
• em: relativ zur Schriftgröße des Elternelements, kaskadierend und dadurch schwer vorhersehbar.
• rem: relativ zur Schriftgröße des <html>-Elements, nicht kaskadierend und damit berechenbar. Der Standard für Schriften und Abstände.
• vw / vh: 1 vw entspricht 1 Prozent der Viewport-Breite.
• vmin / vmax: der kleinere beziehungsweise größere Wert aus beiden.
• ch: die Breite des Zeichens „0“ der aktuellen Schrift, ideal für Zeilenlängen.

Dazu kommen svh, lvh und dvh, seit 2022 verfügbar und seit 2023 Baseline.

Sie lösen ein Ärgernis auf dem Smartphone, denn 100vh rechnet die einklappbare Browserleiste nicht mit, weshalb eine Hero-Sektion beim Scrollen springt.

.hero { min-height: 100dvh; }

clamp(): der wichtigste Baustein

clamp(), min() und max() sind seit Chrome 79, Firefox 75 und Safari 13.1 verfügbar, also seit etwa 2020.

min() nimmt den kleinsten Wert und ersetzt damit Breite plus Deckelung:

.container { width: min(90%, 1200px); }
/* Ab etwa 1333px Viewport greift die Grenze von 1200px, darunter 90% */

clamp(MINIMUM, BEVORZUGT, MAXIMUM) fasst Unter- und Obergrenze in einem Wert zusammen:

font-size: clamp(1rem, 2.5vw + 0.5rem, 2rem);
padding:   clamp(1rem, 5%, 3rem);
width:     clamp(280px, 90%, 1200px);

Technisch ist das eine Kurzform für max(MINIMUM, min(BEVORZUGT, MAXIMUM)).

Der bevorzugte Wert darf allerdings nicht aus reinem vw bestehen.

Warum nicht?

Weil font-size: 5vw nicht auf den Browserzoom reagiert, der Text beim Zoomen also gleich groß bleibt, und damit fällt Ihre Seite bei WCAG 1.4.4 durch.

Die Mischung aus vw und rem löst das, weil der rem-Anteil auf Zoom reagiert:

h1 { font-size: clamp(1.5rem, 2.5vw + 1rem, 3rem); }

Die Formel dahinter

Angenommen, die Überschrift soll bei 320 px Viewport 24 px groß sein und bei 1280 px Viewport 48 px:

Steigung          = (48 - 24) / (1280 - 320) = 0,025 = 2.5vw
Y-Achsenabschnitt = 24 - (0,025 × 320) = 16px = 1rem
Ergebnis          = clamp(1.5rem, 2.5vw + 1rem, 3rem)

Für ein ganzes Projekt legen Sie das einmal als Custom Properties an:

:root {
  --fs-base: clamp(1rem,     0.21vw + 0.96rem, 1.125rem);
  --fs-xl:   clamp(1.5rem,   0.83vw + 1.33rem, 2rem);
  --fs-3xl:  clamp(2.25rem,  2.81vw + 1.69rem, 4.5rem);
  --space-md: clamp(1rem, 1.67vw + 0.67rem, 2rem);
}

h1 { font-size: var(--fs-3xl); }
p  { font-size: var(--fs-base); }

Die Browserunterstützung für dieses Muster liegt bei über 97 Prozent weltweit, Stand 2026.

Raster ohne Media Queries: minmax() und auto-fit

Ein Kartenraster, das sich selbst umbricht, brauchte früher drei oder vier Media Queries.

Heute ist es eine Zeile:

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(300px, 100%), 1fr));
  gap: clamp(1rem, 3vw, 2rem);
}

Das erzeugt so viele Spalten, wie hineinpassen, jede mindestens 300 px breit, und min(300px, 100%) verhindert, dass die Karten auf schmalen Displays über den Rand hinausragen.

auto-fit kollabiert dabei leere Spalten, die vorhandenen Elemente wachsen und füllen die Zeile aus.

auto-fill behält die leeren Spalten, die Struktur bleibt konstant.

.cards      { grid-template-columns: repeat(auto-fit,  minmax(250px, 1fr)); }
.grid-fixed { grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); }

Für ein Layout mit Sidebar kombinieren Sie grid direkt mit clamp():

.layout {
  display: grid;
  grid-template-columns: clamp(200px, 25%, 350px) 1fr;
  gap: 2rem;
}

Die Sidebar ist fluid, wird aber nie schmaler als 200 px und nie breiter als 350 px.

aspect-ratio für Medien

Videos und Bildkacheln brauchten früher den Padding-Bottom-Trick, den aspect-ratio vollständig ersetzt, verfügbar seit Chrome 88, Firefox 89 und Safari 15 aus dem Jahr 2021.

.video-wrapper {
  width: 100%;
  aspect-ratio: 16 / 9;
}

.card-image {
  width: 100%;
  aspect-ratio: 4 / 3;
  object-fit: cover;
}

Das hält den Platz frei, bevor die Datei geladen ist, und verhindert damit einen Layout Shift.

Container Queries: die Komponente fragt ihren Platz ab

Media Queries reagieren auf die Viewport-Breite, nicht auf den Platz, den eine Komponente tatsächlich hat.

Liegt dieselbe Karte einmal im Hauptbereich und einmal in einer schmalen Sidebar, ist der Viewport beide Male breit, die Karte aber nicht, und das Layout bricht.

Container Queries fragen stattdessen die Breite des Elternelements ab.

.card-wrapper {
  container-type: inline-size;
  container-name: karte;
}

.card { display: block; }

@container karte (width > 400px) {
  .card { display: flex; }
}

@container karte (width > 700px) {
  .card { display: grid; grid-template-columns: 1fr 2fr; }
}

Die Karte verhält sich jetzt überall korrekt, ohne ihren Einbauort zu kennen.

Dazu kommen eigene Einheiten, die sich auf den Container statt auf den Viewport beziehen:

.card {
  padding:      5cqi;  /* 5% der Inline-Breite des Containers */
  font-size:    3cqw;  /* 3% der Container-Breite */
  margin-block: 2cqb;  /* 2% der Container-Blockhöhe */
}

Verfügbar sind cqw, cqh, cqi, cqb, cqmin und cqmax.

Container size queries sind seit 2023 Baseline, konkret Chrome 105 ab August 2022, Safari 16 ab September 2022 und Firefox 110 ab Februar 2023, die Container Query Units ebenfalls seit 2023.

Zwei Randbereiche fehlen noch: Bei den container style queries unterstützt Firefox keine Custom-Property-Bedingungen, und container scroll-state queries gibt es seit Anfang 2025 nur in Chrome, Edge und Opera.

Laut LogRocket Blog 2026 kennen 86 Prozent der Entwickler Container Queries, aber nur 41 Prozent haben sie aktiv eingesetzt.

Am Browser liegt es also nicht mehr.

Wo fluides Layout bricht

Fluid Design ohne Grenzen ist kein gutes Design, sondern nur ein anders kaputtes.

Das sind die fünf Stellen, an denen es zuverlässig schiefgeht.

Sehr breite Viewports

Bei width: 80% und 2560 px Viewport ist Ihr Textblock 2048 px breit.

Das ist keine Website mehr, das ist eine Tapete.

.article {
  width: min(90%, 75ch);
  margin-inline: auto;
}

Zeilenlänge

Die typografische Daumenregel liegt bei 45 bis 75 Zeichen pro Zeile, ab etwa 90 Zeichen wird Text spürbar schlechter lesbar.

Die ch-Einheit trifft das direkt:

p  { max-width: 65ch; }
h1 { max-width: 30ch; }

Chris Coyier hat es 2007 auf CSS-Tricks auf den Punkt gebracht: „Nobody wants to read a line of text 1980px long.“

Bilder

img {
  width: 100%;
  height: auto;
  max-width: 100%;
}

Setzen Sie zusätzlich immer die Attribute width und height im HTML, damit der Browser das Seitenverhältnis vorab reservieren kann.

Tabellen

Tabellen sind von Natur aus nicht fluid, weil ihr Inhalt eine Mindestbreite erzwingt.

.table-wrapper { overflow-x: auto; }
table { min-width: 600px; width: 100%; }

Die Alternative sind Karten statt Tabellen auf Mobilgeräten, was JavaScript oder zusätzliche CSS-Klassen erfordert.

min-width und max-width als Korrektiv

Das Standardmuster für einen kontrollierten fluiden Container:

.container {
  width: 90%;
  min-width: 280px;
  max-width: 1280px;
  margin-inline: auto;
}

Und eine Warnung genau an der Stelle, an der der Fehler passiert: Setzen Sie niemals min-width: 100vw auf innere Elemente.

Das zerstört die horizontale Begrenzung auf Mobilgeräten und erzeugt exakt den Scrollbalken, den Sie vermeiden wollten.

Barrierefreiheit: Reflow und Textvergrößerung

Hier wird aus einer Designfrage eine Anforderung.

WCAG 1.4.10 Reflow (Level AA)

Das Kriterium kam mit WCAG 2.1 im Jahr 2018 und verlangt, dass Inhalte ohne Verlust von Information oder Funktionalität und ohne Scrollen in zwei Richtungen darstellbar sind, und zwar bei 320 CSS-Pixeln Breite.

320 CSS-Pixel entsprechen 400 Prozent Zoom auf einem 1280 px breiten Display, bei horizontal scrollenden Inhalten gilt zusätzlich 256 CSS-Pixel Höhe.

Im Klartext: Bei 400 Prozent Zoom darf Ihre Seite keinen horizontalen Scrollbalken erzwingen.

/* Fällt durch */
.nav { width: 960px; display: flex; }

/* Besteht */
.nav { width: 100%; display: flex; flex-wrap: wrap; }

Die Checkpunkte dazu:

• Navigationen brauchen bei 320 px Breite eine vertikale Alternative, üblicherweise ein Hamburger-Menü.
• Tabellen brauchen einen Wrapper mit overflow-x: auto.
• Horizontale Scrollmenüs müssen per Media Query auf vertikal umschalten.
• Absolut positionierte Elemente mit width: 100vw brauchen ein Overflow-Handling.

WCAG 1.4.4 Resize Text (Level AA)

Text muss sich bis 200 Prozent vergrößern lassen, ohne dass Inhalt oder Funktion verloren gehen.

Testen Sie das mit dem Browserzoom in den Entwicklertools, nicht mit der Skalierung des Betriebssystems, denn nur der Browserzoom prüft das Kriterium.

Genau hier fällt reines font-size: 5vw durch, während clamp() mit rem-Anteil besteht.

Korrekt gebautes Fluid Design erfüllt Reflow fast von selbst, weil Prozentbreiten sich dem zoombedingt verkleinerten Viewport anpassen und flex-wrap: wrap sowie grid mit auto-fit von Haus aus umbrechen. Weitere Kriterien behandelt Barrierefreie Website.

Ladezeit und Core Web Vitals

An dieser Stelle muss ein hartnäckiger Mythos weg.

Man liest oft, fluide Layouts verkürzten die Ladezeit, weil man weniger Media Queries brauche.

Das stimmt nicht.

Fluide Layouts sind nicht leichter als feste, und eingesparte Media Queries bewegen bei der CSS-Dateigröße praktisch nichts.

Der Core Web Vital, den fluides Design tatsächlich beeinflusst, ist Cumulative Layout Shift.

Die Schwellenwerte liegen bei 0,1 oder weniger für „gut“, 0,1 bis 0,25 für „Verbesserungsbedarf“ und über 0,25 für „schlecht“, gemessen an 75 Prozent der Seitenbesuche.

Fluide Layouts können CLS sogar verschlechtern, wenn Sie vier Punkte übersehen:

• Bilder ohne width– und height-Attribute, weil der Browser dann keinen Platz reserviert.
• Werbung und Embeds ohne min-height oder aspect-ratio.
• Webfonts, die beim Nachladen die Textgröße verändern, wogegen font-display: optional oder size-adjust im @font-face hilft.
• Nachträglich eingefügte Inhalte wie Cookie-Banner, für die kein Platz vorgehalten wurde.

<img src="hero.jpg" width="1200" height="630" alt="Hero">

Fluid Typography mit clamp() verursacht dagegen keinen CLS, weil die Berechnung vor dem ersten Rendern passiert, anders als bei JavaScript-Lösungen.

Ein echtes Ladezeitproblem hat fluides Design aber doch, und zwar bei Bildern.

Ein Bild mit width: 100% lädt auf dem Desktop eine unnötig große Datei, wenn nur eine Bildquelle existiert.

<img
  src="image-800.jpg"
  srcset="image-400.jpg 400w, image-800.jpg 800w, image-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1000px"
  alt="Beschreibung"
  width="1600" height="900">

Mehr zu den Messwerten selbst finden Sie unter Core Web Vitals verbessern.

Umsetzung in WordPress

Wie fluid Ihre Seite wird, hängt fast vollständig davon ab, womit Sie bauen.

theme.json in Block Themes

Seit WordPress 6.1 vom November 2022 erzeugt WordPress die clamp()-Werte selbst, sobald Sie Fluid Typography aktivieren.

{
  "version": 3,
  "settings": {
    "typography": {
      "fluid": true,
      "fontSizes": [
        {
          "name": "Large",
          "slug": "large",
          "size": "2.375rem",
          "fluidSize": { "min": "1.875rem", "max": "2.375rem" }
        },
        { "name": "Small", "slug": "small", "size": "1rem", "fluid": false }
      ]
    }
  }
}

Daraus generiert WordPress Werte wie diesen:

--wp--preset--font-size--large: clamp(1.875rem, 4.3vw + 0.52rem, 2.375rem);

Vier Einschränkungen sollten Sie vorher kennen:

• Fluid Typography ist standardmäßig deaktiviert und muss explizit eingeschaltet werden.
• Die Standard-Breakpoints 768 px und 1600 px sind fest verdrahtet und ohne eigenes PHP nicht konfigurierbar.
• Einzelne Schriftgrößen lassen sich mit "fluid": false ausnehmen.
• Fluide Abstände über settings.spacing.fluid sind weniger ausgereift als fluide Typografie.

Elementor

Elementor startet mit einer Boxed-Breite von 1140 px, änderbar unter Site Settings → Layout → Default Content Width, pro Container sind auch „Stretched“, Prozent- und vw-Werte möglich.

Und jetzt die Stellen, an denen Elementor Ihnen feste Pixel aufzwingt.

Widget-Einstellungen wie Icon Box oder Button arbeiten oft mit px als Standard.

Margin und Padding werden im Editor in px eingegeben und müssen manuell auf Prozent oder em umgestellt werden.

Schriftgrößen kennen kein natives clamp(), sondern nur drei manuelle Breakpoints für Mobile, Tablet und Desktop.

Der Responsive Mode von Elementor ist damit streng genommen kein fluides, sondern ein adaptives Verhalten mit drei festen Werten.

Fluide Typografie bekommen Sie nur über Custom CSS im Widget, bei vielen Widgets ist ein globales Override im Theme-CSS jedoch sauberer:

selector h1 {
  font-size: clamp(1.5rem, 3vw + 1rem, 3rem) !important;
}

Divi

Divi 5 aus den Jahren 2024 und 2025 ist bei den Einheiten weiter: Container in %, px, vw, vh, em und rem, Schriftgrößen in px, em, rem, vw und %.

Elegant Themes listet sechs Wege zu fluider Typografie in Divi: reines vw, calc() mit vw, die eigenen Responsive-Breakpoints, eigene Media Queries, min() und max() sowie clamp().

Die ersten vier haben Einschränkungen, wirklich fluid sind nur die letzten beiden, und beide erfordern Custom CSS.

Ein bekanntes Ärgernis: Safari zeigt beim Verändern der Fenstergröße gelegentlich Skalierungsfehler, die nach einem Reload verschwunden sind.

WPBakery

WPBakery ist der älteste der großen Drei und am wenigsten fluid-freundlich.

Spaltenbreiten als Bruchteile wie 1/2 oder 1/3 beziehungsweise in Prozent sind fluid.

Schriftgrößen und Abstände sind im visuellen Editor jedoch überwiegend px-basiert, fluide Typografie geht nur über Custom CSS, und Container Queries unterstützt WPBakery nicht nativ.

Rüsten Sie fluides Sizing hier über die style.css eines Child-Themes nach.

Wenn der Builder die Pixel nicht hergibt

Gibt Ihr Page Builder trotz aller Einstellungen weiter feste Pixel aus, schauen Sie in den Entwicklertools nach, welche Regel gewinnt.

Meistens ist es ein Inline-Style des Builders, und den überschreiben Sie nur mit einer spezifischeren Regel im Child-Theme, notfalls mit !important.

Hilfe bei der Umsetzung gibt es unter Website erstellen lassen.

FAQ

Was ist der Unterschied zwischen Responsive und Fluid Design?

Fluid Design skaliert Elemente proportional über relative Einheiten, ohne Media Queries und ohne Sprünge.

Responsive Design nutzt genau dieses fluide Grid als eine von drei Zutaten und ergänzt es um flexible Bilder und Media Queries, mit denen sich das Design selbst ändern kann.

Fluid ist ein Bestandteil von Responsive, kein Gegenentwurf.

Was bedeutet Liquid Layout?

Liquid Layout ist ein Synonym für Fluid Layout, beide bezeichnen prozentbasierte, proportional mitwachsende Breiten. Der Begriff ist seit November 2002 nachweisbar, im Deutschen ist „Fluid Layout“ heute gebräuchlicher.

Was ist der Unterschied zwischen auto-fit und auto-fill?

auto-fit kollabiert leere Spalten, sodass die vorhandenen Elemente den freien Platz aufteilen und breiter werden.

auto-fill behält die leeren Spalten, Struktur und Elementbreite bleiben gleich.

Für Kartenraster nehmen Sie auto-fit, für gleichbleibende Raster auto-fill.

Warum bricht mein fluides Layout auf großen Bildschirmen?

Weil prozentbasierte Breiten nach oben keine Grenze haben: Bei 2560 px Viewport wird aus width: 80% ein 2048 px breiter Textblock.

Deckeln Sie den Inhalt mit width: min(90%, 75ch) und zentrieren Sie ihn mit margin-inline: auto.

Warum springt eine Sektion mit 100vh auf dem Smartphone?

Weil vh die einklappbare Browserleiste nicht berücksichtigt und die Höhe daher nicht zu dem passt, was tatsächlich sichtbar ist.

Nutzen Sie stattdessen min-height: 100dvh, seit 2023 Baseline, das sich anpasst, wenn die Browser-UI beim Scrollen kollabiert.

Wie teste ich WCAG 1.4.10 Reflow?

Stellen Sie den Browserzoom in den Entwicklertools auf 400 Prozent bei einer Fensterbreite von 1280 px, was 320 CSS-Pixeln entspricht.

Besteht die Seite, gibt es keinen horizontalen Scrollbalken und es fehlt weder Inhalt noch Funktion.

Prüfen Sie gezielt Navigation, Tabellen, Scrollbereiche und alles, was mit 100vw oder festen Pixeln arbeitet.

Fazit

Sie bauen ein Fluid Layout mit clamp() für Schriften und Abstände, min() als Deckelung, minmax() mit auto-fit für Raster, aspect-ratio für Medien und Container Queries für Komponenten.

Die Ladezeit verbessert das nicht von allein, wohl aber die Stabilität des Layouts und die Bedienbarkeit bei 400 Prozent Zoom, und Letzteres ist eine Anforderung, keine Kür.

Fangen Sie mit einem Container an, ersetzen Sie dort die feste Pixelbreite durch width: min(90%, 1200px) und arbeiten Sie sich nach innen vor!