# Header-Größen: Wie groß darf der Kopf einer Website sein?

> Header-Dimensionen mit Zahlen statt Bauchgefühl: Geräte- und Auflösungsdaten für Deutschland, CSS-Pixel vs. 4K, Breakpoints, Größentabellen, A11y-Grenzen und Konversions-Evidenz.

Source: https://www.jpkc.com/db/blog/header-groessen/

Es ist die Frage, die mir in der Beratung am häufigsten gestellt wird — und das Thema, bei dem ich die meisten Entwürfe ablehnen muss: **Wie groß darf der Header sein?** Wie hoch, wie breit, was darf hinein, was gehört darunter?

Der Anlass für diesen Artikel ist ein Muster, das mir immer wieder begegnet. Da kommt ein Entwurf, der auf dem 32-Zoll-Monitor des Designers großartig aussieht — und für den man einen Breakpoint jenseits von Bootstraps `xxl` erfinden müsste, damit er überhaupt aufgeht. Ein „XXXL", das es in keinem etablierten Framework gibt. Meine Vermutung war immer: Das kann nicht gut sein, weil die große Mehrheit der Besucher solche Bildschirme gar nicht hat.

Dieser Artikel prüft diese Vermutung — mit Daten. Und die Datenlage ist deutlicher, als ich selbst erwartet hatte.

Er behandelt danach alles, was an der Header-Größe hängt: responsives Verhalten, Barrierefreiheit, SEO, Konversion, Ladeperformance, die tatsächlichen Geräte deiner Zielgruppe, den Unterschied zwischen Auflösung und nutzbarem Platz, Mobile First — und was passiert, wenn man es nicht macht. Am Ende stehen Tabellen mit konkreten Zahlen und die Herleitung jeder einzelnen davon.

## Vorab: Was in diesem Artikel *nicht* steht

Zu diesem Thema kursieren Faustregeln, die zwar überall zitiert werden, aber keiner Quelle standhalten. Drei davon räume ich gleich zu Beginn weg, weil sie sonst den Rest vergiften:

- **„Der Header darf maximal 10 % der Viewport-Höhe einnehmen"** — diese Regel wird regelmäßig der Nielsen Norman Group zugeschrieben. Sie steht dort nicht. Ich habe den einschlägigen Artikel geprüft: NN/g nennt *keine* Prozentgrenze, sondern eine funktionale. Auch die WCAG kennt keine maximale Header-Höhe. Wo ich in diesem Artikel Zahlen nenne, leite ich sie transparent her — und schreibe sie niemandem zu, der sie nie gesagt hat.
- **„Karussells konvertieren nur mit 1 %"** — die berühmte Zahl stammt aus *einer* Messung von *einer* Website im Jahr 2013. Dieselbe Quelle nennt für drei weitere Sites 1,7 bis 2,3 % und für eine sogar 8,8 %. Wer nur die 1 % zitiert, zitiert gegen die eigene Quelle.
- **„Navigationen brauchen maximal 7±2 Punkte"** — Jakob Nielsen selbst nennt das ein „common misconception".

Was in diesem Artikel steht, ist entweder belegt und verlinkt, oder als eigene Herleitung gekennzeichnet. Wo die Datenlage dünn ist, sage ich das.

## Teil 1: Zahlen zuerst — wer besucht deine Seite wirklich?

Bevor irgendeine Empfehlung Sinn ergibt, muss geklärt sein, wer da eigentlich vor dem Bildschirm sitzt. Und hier trennt sich Deutschland überraschend deutlich vom internationalen Durchschnitt.

### Deutschland ist ein Desktop-Land

| Plattform | Deutschland | Weltweit |
| --- | --- | --- |
| **Desktop** | **54,7 %** | 47,12 % |
| Mobile | 43,56 % | **51,51 %** |
| Tablet | 1,74 % | 1,36 % |

Quelle: [StatCounter GlobalStats, Plattform-Vergleich Deutschland](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/germany) und [weltweit](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide) (englisch), Stand Juni 2026.

Das ist der erste wichtige Befund: **Weltweit liegt Mobile vorn, in Deutschland liegt Desktop vorn** — und zwar mit gut elf Prozentpunkten Vorsprung. Wer für den deutschen Markt baut, kann Desktop nicht als Randfall behandeln, wie es die internationale „Mobile hat gewonnen"-Rhetorik nahelegt.

Aber Achtung, und das ist wichtig: Das ist **kein** Argument gegen Mobile First. Warum nicht, kläre ich in Teil 7 — es ist ein häufiger und teurer Fehlschluss.

Tablets sind mit 1,7 % übrigens praktisch bedeutungslos. Sie brauchen kein eigenes Design, sie brauchen nur ein Layout, das im Bereich zwischen rund 768 und 1030 px nicht zusammenbricht.

### Es gibt keine Standardauflösung

Hier die zehn häufigsten Bildschirmauflösungen über alle Gerätetypen hinweg:

| # | Deutschland | Anteil | Weltweit | Anteil |
| --- | --- | --- | --- | --- |
| 1 | 1920×1080 | 13,28 % | 1920×1080 | 9,43 % |
| 2 | 375×812 | 10,07 % | 414×896 | 6,38 % |
| 3 | 414×896 | 7,18 % | 360×800 | 5,71 % |
| 4 | 384×832 | 4,25 % | 375×812 | 4,35 % |
| 5 | 1536×864 | 3,75 % | 384×832 | 3,72 % |
| 6 | 390×844 | 3,53 % | 390×844 | 3,31 % |
| 7 | 800×600 | 3,12 % | 1536×864 | 3,22 % |
| 8 | 2560×1440 | 3,02 % | 1280×720 | 2,85 % |
| 9 | 360×780 | 2,82 % | 1366×768 | 2,65 % |
| 10 | 393×873 | 2,41 % | 800×600 | 2,55 % |
| — | **Summe dieser Top 10** | **53,4 %** | **Summe dieser Top 10** | **44,2 %** |

Quelle: [StatCounter Screen Resolution Stats, Deutschland](https://gs.statcounter.com/screen-resolution-stats/all/germany) und [weltweit](https://gs.statcounter.com/screen-resolution-stats/all/worldwide) (englisch), Stand Juni 2026.

Die wichtigste Zeile ist die letzte. **Die zehn häufigsten Auflösungen zusammen decken in Deutschland nur 53 % des Traffics ab — weltweit sogar nur 44 %.** Fast die Hälfte aller Besucher kommt also mit einer Auflösung, die nicht einmal in den Top 10 auftaucht. Und selbst der Spitzenreiter 1920×1080 kommt nur auf 13 %.

Es gibt also schlicht keine Auflösung, auf die man designen könnte. Wer „für 1920×1080 optimiert", optimiert für ein Achtel seiner Besucher. Das ist die eigentliche Begründung für responsives Design — nicht „damit es auch auf dem Handy geht", sondern weil der Zielraum ein Kontinuum ist und kein Punkt.

### Der Mobile-Korridor: 360 bis 440 Pixel

Bei Mobilgeräten sieht die Lage anders aus — hier gibt es tatsächlich so etwas wie einen Standard:

| # | Deutschland | Anteil | Weltweit | Anteil |
| --- | --- | --- | --- | --- |
| 1 | 414×896 | 16,27 % | 414×896 | 12,12 % |
| 2 | 375×812 | 13,60 % | 360×800 | 9,19 % |
| 3 | 390×844 | 8,01 % | 390×844 | 6,33 % |
| 4 | 393×873 | 5,32 % | 375×812 | 5,89 % |
| 5 | 384×832 | 5,24 % | 393×873 | 4,49 % |
| 6 | 360×780 | 4,69 % | 384×832 | 3,94 % |
| 7 | 360×800 | 3,98 % | 360×780 | 3,01 % |
| 8 | 412×915 | 3,59 % | 412×915 | 2,96 % |

Quelle: StatCounter, Mobile, Deutschland/weltweit, Juni 2026.

**Die gesamte relevante Mobile-Breite liegt zwischen 360 und 440 CSS-Pixeln** (nach oben abgerundet: Das aktuelle iPhone Pro Max liefert 440, siehe Teil 2). Das ist die belastbarste Zahl dieses ganzen Artikels. Wenn dein Header bei 360 px funktioniert und bei 440 px nicht auseinanderfällt, hast du praktisch das gesamte Mobile-Publikum abgedeckt.

Der Unterschied zwischen Deutschland und der Welt ist hier nur ein Geräte-Unterschied: Deutschland ist iPhone-lastiger (375/390/414 dominieren), weltweit hat der Android-Standard 360×800 mehr Gewicht. Für dein Layout macht das keinen Unterschied — beide liegen im selben Korridor.

### Und jetzt die Kernfrage: Wie breit ist der Desktop wirklich?

Das war der Auslöser dieses Artikels. Hier die Desktop-Auflösungen, die StatCounter für Deutschland meldet:

| Auflösung | Desktop DE | Desktop weltweit |
| --- | --- | --- |
| 1920×1080 | 24,44 % | 20,31 % |
| 1536×864 | 6,91 % | 6,96 % |
| 2560×1440 (WQHD/1440p) | **5,57 %** | 2,60 % |
| 1280×720 | 3,38 % | 6,12 % |
| 1366×768 | 2,41 % | 5,71 % |
| 1600×900 | 2,23 % | — |
| 1920×1200 | 1,52 % | — |
| 3440×1440 (Ultrawide) | **0,94 %** | nicht in den Top 20 |
| 2048×1152 | 0,69 % | — |
| 3840×2160 (4K/UHD) | **nicht in den Top 20** | nicht in den Top 20 |

Quelle: StatCounter Screen Resolution Stats, Desktop, Deutschland/weltweit, Juni 2026. **Gekürzt:** Die Original-Liste enthält außerdem zwei unplausible Ausreißer (375×812 mit 7,53 % und 800×600 mit 5,69 %), die ich hier weggelassen habe — warum, steht im Methodenkasten am Ende dieses Kapitels. Deshalb summieren sich die Spalten nicht auf 100 %.

**Und jetzt der entscheidende Hinweis, ohne den diese Tabelle falsch gelesen wird:** Das sind **CSS-Pixel**, keine Panel-Auflösungen. StatCounter erhebt die Werte im Browser, und dort ist die Skalierung des Betriebssystems bereits eingerechnet. Warum das so ist und wie man es der Tabelle ansieht, zeigt Teil 2 — die Zeile 1536×864 ist der Beweis.

Das heißt konkret: Die Zeile „3840×2160" zählt **nicht die 4K-Besitzer**, sondern nur die 4K-Besitzer, die bei 100 % Skalierung fahren. Alle anderen stecken in den Zeilen 1920×1080 und 2560×1440. Die ehrliche Aussage lautet deshalb nicht „so viele haben 4K", sondern:

> **So viel Platz kommt in deinem CSS an.** Und danach gestaffelt: Mehr als **1920** CSS-Pixel Breite melden in Deutschland zusammen nur rund **7 %** der Desktop-Besucher (2560×1440, 3440×1440 und 2048×1152 addiert). Mehr als **2560** melden **unter 1 %**.

Das ist die Zahl, die zählt — und sie ist vernichtender als jede Hardware-Statistik. Denn sie lässt sich nicht wegdiskutieren mit „aber 4K verkauft sich doch so gut". Es ist völlig egal, wie viele 4K-Panels ausgeliefert werden. **Was im Browser ankommt, ist fast nie mehr als 1920.**

*(Kleingedrucktes, weil ich es selbst nachgerechnet habe: StatCounter veröffentlicht nur die Top 20 plus eine Sammelkategorie. Die 7 % sind daher eine Untergrenze — in der Sammelkategorie können weitere breite Auflösungen stecken. An der Größenordnung ändert das nichts, umkehren lässt sie sich damit nicht.)*

### Warum Designer und Entwickler das systematisch falsch einschätzen

Jetzt zu der Erklärung, warum solche Entwürfe überhaupt entstehen. Schau dir an, welche Hardware die Steam-Umfrage bei Gaming-PCs findet:

| Auflösung | Steam (Gaming-PCs, Juni 2026) |
| --- | --- |
| 1920×1080 | 51,12 % |
| 2560×1440 | **21,44 %** |
| 2560×1600 | 5,64 % |
| 3840×2160 (4K) | **4,95 %** |
| 3440×1440 (Ultrawide) | 3,09 % |

Quelle: [Steam Hardware & Software Survey](https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam) (englisch), Stand Juni 2026.

In der Steam-Population haben **gut 35 % einen Monitor jenseits von Full HD** — 1440p allein über ein Fünftel. Steam misst Hardware-Enthusiasten mit Gaming-Rechnern, und **genau in dieser Population sitzen auch Webdesigner und Frontend-Entwickler.** Wir haben die guten Monitore. Unsere Kunden und deren Kunden haben sie nicht.

**Wichtiger methodischer Vorbehalt, den ich nicht unterschlagen will:** Diese Steam-Zahlen sind **nicht** direkt mit den StatCounter-Zahlen oben vergleichbar. Steam meldet unter Windows die **physische Panel-Auflösung**, StatCounter die **CSS-Auflösung nach Skalierung**. Man sieht das der Steam-Liste direkt an: Sie kennt kein 1536×864 (den skalierten Full-HD-Laptop), führt aber 1512×982 und 1470×956 — die logischen macOS-Standardmodi. Wer beide Tabellen als „Faktor X mehr" gegeneinanderrechnet, vergleicht zwei verschiedene Größen. Ich tue das deshalb nicht.

Was der Vergleich *sehr wohl* zeigt, ist der Mechanismus hinter dem XXXL-Breakpoint: Ein Design entsteht auf dem Arbeitsgerät des Gestalters und wird dort geprüft. Es optimiert unbemerkt für die Hardware-Welt, in der der Gestalter lebt. Kein Böswille, keine Inkompetenz — eine **Stichprobe von eins**.

Und die Pointe, die alles zusammenbindet: Selbst *dieser* Gestalter, auf *diesem* Monitor, hat in seinem CSS keine 3840 Pixel. Er hat 2560, wenn er skaliert — oder 1512, wenn er ein MacBook Pro benutzt.

### Der Methodenkasten: Was diese Zahlen *nicht* können

Ich wäre ein schlechter Ratgeber, wenn ich dir Zahlen ohne ihre Grenzen gäbe. StatCounter ist die beste öffentlich verfügbare Quelle, aber sie hat handfeste Schwächen ([StatCounter FAQ](https://gs.statcounter.com/faq), englisch):

- **Sie zählt Seitenaufrufe, keine Personen.** Wörtlich: „To accurately measure usage, we have to base our stats on page views (and not unique visitors)." Ein Vielsurfer zählt also mehrfach.
- **Es ist kein repräsentatives Panel, sondern ein Gelegenheits-Sample** — nämlich die Websites, die StatCounters Tracking-Code einsetzen. StatCounter sagt selbst: „We do not impose artificial weightings on our stats — this is a conscious and deliberate decision."
- **Die Zahlen sind 45 Tage lang revidierbar.**
- **Die Desktop-Kategorie ist erkennbar verunreinigt.** In der deutschen Desktop-Liste steht 375×812 (eine reine iPhone-Auflösung) mit 7,53 %, und 800×600 mit 5,69 %. Beides ist für echte Desktop-Rechner unplausibel. Ob das an Geräte-Fehlklassifikation, DevTools-Emulation oder Bot-Traffic liegt, sagt StatCounter nicht — es ist meine Vermutung, kein Befund. Die praktische Konsequenz: Die echten Desktop-Anteile der großen Auflösungen sind vermutlich *etwas höher* als die Tabelle zeigt. An der Größenordnung „4K ist eine Randerscheinung" ändert das nichts.

**Der wichtigste Vorbehalt kommt aber jetzt** — und er führt direkt in Teil 2:

Diese Zahlen sind **Bildschirmgrößen, keine Viewport-Größen**. Was der Browser tatsächlich zum Zeichnen zur Verfügung hat, ist nach Abzug von Browser-Chrome, Scrollbar und nicht maximiertem Fenster noch einmal kleiner. Und öffentliche Daten zu echten Viewport-Größen gibt es praktisch nicht: Der [Chrome UX Report kennt keine Viewport-Dimension](https://developer.chrome.com/docs/crux/methodology/dimensions) (englisch), er unterscheidet nur Phone/Tablet/Desktop. Wer im Netz eine Liste „die häufigsten Viewport-Größen" findet, liest fast immer StatCounter-Daten, die jemand falsch etikettiert hat.

## Teil 2: Die Auflösungslüge — warum 4K nicht 4K ist

Jetzt zum Kern der Sache — und zu dem Punkt, den die Eingangsvermutung schon streifte: **Ein hochauflösender Bildschirm hat nicht mehr Platz. Er hat feinere Pixel.**

### CSS-Pixel sind keine Hardware-Pixel

Der `px` in CSS ist keine Hardware-Einheit. Er ist an einen **Referenzpixel** gebunden, den das W3C so definiert: „the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm's length" ([CSS Values 4, Referenzpixel](https://www.w3.org/TR/css-values-4/#reference-pixel), englisch).

Lies das noch einmal: Der CSS-Pixel ist über einen **Sehwinkel** definiert. Er ist eine Wahrnehmungsgröße, keine Hardwaregröße. Bei einer nominellen Armlänge von 28 Zoll entspricht er ungefähr 0,26 mm.

Das Bindeglied zur Hardware heißt `devicePixelRatio` — laut [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio) (englisch) „the ratio of the resolution in physical pixels to the resolution in CSS pixels". Also: wie viele echte Bildschirmpixel der Browser für einen CSS-Pixel aufwendet. In CSS ist dieselbe Größe als `resolution` in `dppx` ansprechbar, wobei `1dppx = 96dpi` gilt.

Daraus folgt die Gleichung, um die sich dieser ganze Artikel dreht:

```text
CSS-Viewport-Breite  =  physische Panel-Breite  ÷  Skalierungsfaktor
                        (danach noch: minus Browser-Chrome, minus Scrollbar,
                         minus alles, was der Nutzer wegzoomt)
```

**Mehr Hardware-Pixel erzeugen keine zusätzlichen CSS-Pixel. Sie erzeugen dichtere CSS-Pixel.** Ein Retina-Display ist nicht größer — es ist schärfer.

### Die Tabelle, die alles erklärt

Hier ist, was von der beeindruckenden Auflösung real übrig bleibt:

| Gerät | Physische Auflösung | Skalierung | **CSS-Breite** |
| --- | --- | --- | --- |
| MacBook Pro 14" (M-Serie) | 3024×1964 | 2× | **1512** |
| MacBook Air 13" (M2–M4) | 2560×1664 | Standardmodus (s. u.) | **1470** |
| 4K-Monitor bei 125 % | 3840×2160 | 1,25× | **3072** |
| 4K-Monitor bei 150 % | 3840×2160 | 1,5× | **2560** |
| 4K-Monitor bei 200 % | 3840×2160 | 2× | **1920** |
| 24" WQHD bei 125 % | 2560×1440 | 1,25× | **2048** |
| Full-HD-Laptop bei 125 % | 1920×1080 | 1,25× | **1536** |
| 13,3" WQHD-Laptop bei 200 % | 2560×1440 | 2× | **1280** |
| iPhone 17 Pro Max | 1320×2868 | 3× | **440** |
| iPhone 16 Plus / 15 Pro Max | 1290×2796 | 3× | **430** |
| iPhone 17 / 16 Pro | 1206×2622 | 3× | **402** |
| iPhone 16 / 15 | 1179×2556 | 3× | **393** |
| iPhone 14 / 13 / 12 | 1170×2532 | 3× | **390** |
| iPhone 11 / XR | — | 2× | **414** |
| iPhone SE (2./3. Gen.) | — | 2× | **375** |
| iPad Pro 13" (M4/M5) | 2064×2752 | 2× | **1032** |
| iPad Air 11" | 1640×2360 | 2× | **820** |
| Samsung Galaxy S25 | — | 3× | **360** |

Quellen und Vorbehalte, sauber getrennt:

- Die **nativen Auflösungen** der MacBooks stammen aus Apples Tech Specs ([MacBook Pro](https://www.apple.com/de/macbook-pro/specs/), [MacBook Air](https://www.apple.com/de/macbook-air/specs/)). **Die Standardmodi stehen dort nicht.** Apple dokumentiert die skalierten Modi nirgends öffentlich — die Werte 1512×982 und 1470×956 sind beobachtbar (und tauchen z. B. in der Steam-Hardware-Umfrage als eigene Einträge auf), aber sie sind **nicht von Apple bestätigt**. Ich kennzeichne das, weil ich es an anderer Stelle in diesem Artikel von anderen einfordere.
- Die **iOS-Punktgrößen** stammen aus [iOS Resolution Reference](https://iosref.com/res) und [Use Your Loaf](https://useyourloaf.com/blog/iphone-17-screen-sizes/) (beide englisch) — zwei unabhängige Referenzen, die übereinstimmen, aber ebenfalls keine Apple-Primärquellen sind.
- Die **4K-, WQHD- und Full-HD-Zeilen sind reine Division** (3840 ÷ 1,5 = 2560) und als solche zu lesen — sie belegen nichts, sie rechnen nur vor.

Ein paar Beobachtungen, die es in sich haben:

**Ein MacBook Pro 14" mit 3024 Pixeln Panel-Breite liefert 1512 CSS-Pixel.** Das ist weniger als ein billiger Full-HD-Monitor bei 100 % Skalierung. Der Designer, der sein Layout auf dem MacBook baut, arbeitet effektiv auf 1512 px — er merkt es nur nicht, weil alles gestochen scharf aussieht.

**Ein 4K-Monitor liefert je nach Skalierung 1920, 2560 oder 3072 CSS-Pixel.** Bei der auf 27 Zoll üblichen 150 %-Einstellung sind es 2560 — dieselbe CSS-Breite wie ein schlichter WQHD-Monitor bei 100 %. Die vier Millionen Extra-Pixel gehen komplett in die Schärfe, nicht in die Fläche.

**Die MacBook-Air-Zeile ist der Sonderfall, an dem die Gleichung scheitert** — und sie ist zu lehrreich, um sie wegzulassen: 2560 ÷ 2 wäre 1280, tatsächlich sind es 1470. Der Grund ist Supersampling. macOS rendert im Standardmodus einen Framebuffer von 2940×1912 (also 1470 × 2) und **skaliert ihn anschließend auf das 2560×1664-Panel herunter**. `devicePixelRatio` meldet brav 2 — aber diese 2 beziehen sich nicht mehr auf das Panel. Das kostet Schärfe, GPU-Leistung und Akku, und die meisten Nutzer wissen nicht einmal, dass es passiert.

Daraus folgt die Konsequenz, die den ganzen 4K-Streit entschärft: **Es ist egal, wie viele 4K-Panels es gibt.** Was in deinem CSS ankommt, ist nie 3840. Es ist 1920, 2560 oder — bei den wenigen, die 125 % fahren — 3072. Die Frage „Wie viele haben 4K?" ist die falsche Frage. Die richtige lautet: „**Wie viele haben mehr als 1920 CSS-Pixel?**" Und darauf antwortet die Statistik aus Teil 1: rund 7 % der Desktop-Besucher.

### Der Beweis versteckt sich in den Daten selbst

Schau noch einmal in die Auflösungstabelle aus Teil 1. Auf Platz 5 in Deutschland steht **1536×864** mit 3,75 %.

Es gibt kein Display, das nativ 1536×864 Pixel hat. Diese Auflösung wurde nie gebaut. Aber:

```text
1920 ÷ 1,25 = 1536
1080 ÷ 1,25 =  864
```

**1536×864 ist ein ganz normaler Full-HD-Laptop bei 125 % Skalierung.** `screen.width` liefert im Browser CSS-Pixel — die Skalierung ist da bereits eingerechnet. Genau dieser Wert landet in solchen Statistiken.

Das heißt: **In der Statistik siehst du die Skalierung bereits am Werk.** Der weitaus größte Teil dieser 3,75 % sind Rechner, deren Aufkleber „Full HD" verspricht und die in deinem CSS mit 1536 px ankommen. (Ganz sauber ist die Zuordnung nicht: Auch ein *Browser-Zoom* von 125 % auf einem unskalierten Full-HD-Schirm ergibt 1536×864, und ChromeOS liefert manche Geräte ab Werk so aus. Die Ursache variiert — das Ergebnis für dein CSS ist dasselbe.)

Und dieselbe Logik gilt nach oben: Ein Teil der 2560×1440-Einträge sind gar keine WQHD-Monitore, sondern **4K-Monitore bei 150 %**. Auch das lässt sich nicht auseinanderdividieren — aber es ist auch egal. Was zählt, ist der Platz, der im Browser ankommt. Und der ist bei beiden 2560.

### Fractional Scaling: wenn der Faktor krumm ist

Bisher habe ich mit glatten Faktoren gerechnet. In der Praxis sind sie es oft nicht — und das hat Nebenwirkungen.

**Windows** bietet in den Anzeige-Einstellungen die Stufen 100 %, 125 %, 150 %, 175 %, 200 % und darüber. Welche als „empfohlen" markiert ist, hängt von Panelgröße und Auflösung ab — bei Notebooks der 15-Zoll-Klasse mit Full HD sind das typischerweise 125 %. (Eine normative, aktuelle Microsoft-Tabelle dazu gibt es nicht: Das [einzige öffentliche Dokument mit einer Zuordnung Panelgröße → Skalierung](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dpi-related-apis-and-registry-settings) (englisch) stammt aus der Windows-8.1-Ära, kennt noch kein 175 % und ist laut Microsoft selbst „by no means exhaustive". Ich führe es als Beleg für die *Existenz* der Stufen, nicht als geltende Empfehlung.)

Praktisch heißt das: `devicePixelRatio`-Werte von **1,25, 1,5 und 1,75** sind im deutschen Windows-Alltag völlig normal. `devicePixelRatio` ist laut MDN ausdrücklich ein `double` — also nicht ganzzahlig. Wenn du wissen willst, was dein eigener Rechner meldet, tippe `devicePixelRatio` in die Konsole.

**Linux/Wayland** hat das Problem protokollarisch gelöst: `wp-fractional-scale-v1` überträgt den Wunsch-Skalierungsfaktor als Bruch mit dem festen Nenner 120 — der Wert 150 bedeutet also 150/120 = 1,25× ([Wayland-Protokoll](https://wayland.app/protocols/fractional-scale-v1), englisch). In GNOME ist Fractional Scaling upstream weiterhin als experimentell geführt.

**ChromeOS** nennt die Einstellung sogar ehrlich beim Namen: Sie heißt „Display size" und zeigt den Wert unter **„Looks like"** an. Google beschreibt den Fall selbst: Ein Gerät mit einem Panel von 1920×1080 „**may** show 1536x864 in the ChromeOS settings tool" — abhängig von der Pixeldichte des Panels ([chromeos.dev](https://chromeos.dev/en/games/optimizing-games-display), englisch). Also exakt unsere 125 %, und diesmal steht die effektive Größe sogar im Menü.

Was dabei technisch passiert, erklärt, warum krumme Faktoren spürbar sind: Blink und WebKit rechnen Layout intern nicht in ganzen CSS-Pixeln, sondern in `LayoutUnit`-Einheiten von **1/64 CSS-Pixel** ([WebKit LayoutUnit](https://trac.webkit.org/wiki/LayoutUnit), englisch). Alles muss am Ende auf physische Pixel gerastert werden. Bei einem Faktor von 1,25 oder 1,5 fällt eine 1px-Trennlinie zwangsläufig auf eine halbe Gerätepixel-Grenze — und wird per Anti-Aliasing über zwei Pixelreihen verschmiert. Das ist der Grund, warum feine Rahmen, Tabellen-Trennlinien und Header-Unterkanten auf skalierten Displays grau und ungleichmäßig aussehen.

**Praxisregel:** Verlasse dich im Header nicht auf 1px-Linien als tragendes Gestaltungselement. Wenn eine Trennlinie wichtig ist, gib ihr Kontrast statt Präzision — sie wird auf einem nennenswerten Teil der Geräte nicht sauber sitzen.

## Teil 3: Vom Bildschirm zum Viewport — was wirklich übrig bleibt

Wir sind noch nicht fertig mit dem Schrumpfen. Zwischen Bildschirmauflösung und dem Platz, den dein Header wirklich bekommt, liegen mehrere Abzüge:

```text
┌─────────────────────────────────────────────────────────────┐
│ BILDSCHIRM  z.B. 1920 × 1080 physisch                       │
│  ├─ minus OS-Skalierung (125 %)         →  1536 × 864 CSS   │
│  │                                                          │
│  │  ┌────────────────────────────────────────────────────┐  │
│  │  │ BROWSERFENSTER  (selten maximiert)                 │  │
│  │  │  ┌──────────────────────────────────────────────┐  │  │
│  │  │  │ ▸ Tableiste, Adressleiste, Lesezeichen       │  │  │
│  │  │  ├──────────────────────────────────────────────┤  │  │
│  │  │  │ VIEWPORT   ← hier lebt dein CSS       ░│     │  │  │
│  │  │  │ ┌──────────────────────────────────┐  ░│     │  │  │
│  │  │  │ │ HEADER                           │  ░│Scr. │  │  │
│  │  │  │ ├──────────────────────────────────┤  ░│bar  │  │  │
│  │  │  │ │ HERO / erster Inhalt             │  ░│     │  │  │
│  │  │  │ │                                  │  ░│     │  │  │
│  │  │  ╞══════════════════════════════════════════════╡  │  │
│  │  │  │        ↑ DIE FALZ ↑                          │  │  │
│  │  │  │   57 % der Betrachtungszeit liegen darüber   │  │  │
│  │  │  │                                              │  │  │
│  │  │  └──────────────────────────────────────────────┘  │  │
│  │  └────────────────────────────────────────────────────┘  │
│  └─ minus Taskleiste                                        │
└─────────────────────────────────────────────────────────────┘
```

### Auf dem Desktop: Bildschirm ≠ Fenster

Hier ist die Datenlage ehrlich gesagt schlecht, und ich sage das lieber, als es zu kaschieren. Die einzige öffentlich zugängliche Messung stammt von [CSS-Tricks](https://css-tricks.com/screen-resolution-notequalto-browser-window/) (englisch) — und sie ist **von 2011**. Der Autor deklariert die Stichprobe selbst als nicht repräsentativ („a bunch of designer nerds, probably").

Die *quantitativen* Werte von damals sind für heute unbrauchbar. Der *qualitative* Befund ist es nicht:

- Nur **0,85 %** surften exakt im Vollbild.
- **61 %** lagen innerhalb von 200 px der Vollbildbreite.
- Das durchschnittliche Browserfenster war **1366×784** bei einer durchschnittlichen Bildschirmauflösung von 1526×967.

Übersetzt: Die meisten Menschen surfen *nahe* Vollbild, aber fast niemand *exakt* Vollbild. Und in der Höhe geht durch Browser-UI und Taskleiste ein dreistelliger Pixelbetrag verloren — bei einem 864-CSS-px-Laptop bleiben realistisch um die **700 px Viewport-Höhe** übrig. Das ist der Raum, in dem dein Header und dein Hero konkurrieren.

Eine konkrete Pixelhöhe für die Chrome-Toolbar konnte ich in keiner belastbaren Quelle finden — deshalb behaupte ich auch keine. Miss es lieber selbst:

```js
// Run this in the console on any page to see the real numbers
console.table({
	'Screen (CSS px)': `${screen.width} × ${screen.height}`,
	'Window (outer)': `${outerWidth} × ${outerHeight}`,
	'Viewport (inner)': `${innerWidth} × ${innerHeight}`,
	'devicePixelRatio': devicePixelRatio,
	'Physical panel': `${screen.width * devicePixelRatio} × ${screen.height * devicePixelRatio}`,
});
```

Lass das auf deinem eigenen Rechner laufen. Bei den meisten Entwicklern ist die Differenz zwischen der ersten und der dritten Zeile der Moment, in dem der Groschen fällt.

### Auf dem Handy: das kaputte `100vh`

Mobil kommt ein eigenes Problem dazu. `100vh` ist auf Mobilgeräten **falsch** — und zwar systematisch. Die Adressleiste fährt beim Scrollen ein und aus, die Viewport-Höhe ändert sich dabei, und `vh` bezieht sich auf den Zustand mit *eingefahrenen* Leisten. Ein Hero mit `height: 100vh` ragt beim Laden also unten aus dem sichtbaren Bereich heraus.

Die Lösung ist seit Jahren da und heute uneingeschränkt einsetzbar ([web.dev: The large, small, and dynamic viewport units](https://web.dev/blog/viewport-units), englisch):

| Einheit | Bedeutung |
| --- | --- |
| `lvh` | **L**arge — alle Browser-Leisten *eingefahren* (der optimistische Fall, entspricht `vh`) |
| `svh` | **S**mall — alle Browser-Leisten *ausgefahren* (der pessimistische, garantiert sichtbare Fall) |
| `dvh` | **D**ynamic — folgt dem tatsächlichen Zustand, ändert sich also beim Scrollen |

Browsersupport: Chrome ab 108, Firefox ab 101, Safari ab 15.4 — laut [caniuse](https://caniuse.com/viewport-unit-variants) (englisch) rund 92 % globale Abdeckung. Die letzte Engine lieferte im November 2022. Ein `vh`-Fallback ist 2026 nur noch Kosmetik.

**Meine Empfehlung für Header und Hero:** Nimm `svh`. Das ist der Wert, der *garantiert* sichtbar ist. Wenn dein Hero mit `min-height: 60svh` gestaltet ist, ist er in *jedem* Toolbar-Zustand vollständig da. `dvh` klingt verlockend, hat aber einen Haken, den web.dev ausdrücklich nennt: „The values for the dynamic viewport do not update at 60fps. In all browsers updating is throttled" — ein an `dvh` gekoppelter Hero zappelt beim Scrollen.

## Teil 4: Breakpoints — der Korridor, den es wirklich gibt

Jetzt zur Ausgangsfrage: Was ist eigentlich der Standard, und was heißt es, ihn zu verlassen?

### Bootstrap 5

Aktuell ist Bootstrap 5.3.8. Bootstrap 6 ist zwar seit 2025 in Entwicklung, aber nicht erschienen und ohne Release-Termin — für die Praxis gelten also weiterhin die 5er-Werte.

| Breakpoint | Kürzel | Ab Viewport | **Container-Breite** |
| --- | --- | --- | --- |
| Extra small | *(keins)* | 0 | 100 % |
| Small | `sm` | 576 px | 540 px |
| Medium | `md` | 768 px | 720 px |
| Large | `lg` | 992 px | 960 px |
| Extra large | `xl` | 1200 px | 1140 px |
| Extra extra large | `xxl` | **1400 px** | **1320 px** |

Quelle: [Bootstrap Breakpoints](https://getbootstrap.com/docs/5.3/layout/breakpoints/) und [Containers](https://getbootstrap.com/docs/5.3/layout/containers/) (englisch).

Die rechte Spalte wird fast immer übersehen und ist der eigentliche Punkt: **Der breiteste Standard-Inhaltscontainer in Bootstrap ist 1320 px.** Nicht 1400, nicht 1920. Ab 1400 px Viewport-Breite wächst der Inhalt *nicht mehr mit* — er bleibt bei 1320 px stehen und zentriert sich. Der zusätzliche Platz wird zu Rand.

Das ist kein Versäumnis. Das ist die Lösung.

### Tailwind CSS v4

Aktuell ist Tailwind 4.3.2.

| Kürzel | Wert | Entspricht |
| --- | --- | --- |
| `sm` | 40rem | 640 px |
| `md` | 48rem | 768 px |
| `lg` | 64rem | 1024 px |
| `xl` | 80rem | 1280 px |
| `2xl` | **96rem** | **1536 px** |

Quelle: [Tailwind CSS: Responsive design](https://tailwindcss.com/docs/responsive-design) (englisch).

Zwei Dinge sind hier wichtig. Erstens: **Tailwind v4 definiert Breakpoints in `rem`, nicht in `px`.** Das ist kein kosmetischer Unterschied. `rem` skaliert mit der Grundschriftgröße des Browsers — wer sie auf 20 px gestellt hat (weil er schlecht sieht), erreicht `md` erst bei 960 statt bei 768 CSS-px Viewport. Für die Barrierefreiheit ist das ein echter Gewinn; für die pixelgenaue Design-Abnahme ist es eine Stolperfalle.

Zweitens, und das ist die Antwort auf die Eingangsfrage: **Es gibt kein `3xl`.** Weder in Tailwind noch in Bootstrap. Die Tailwind-Doku führt `3xl` nur als *Beispiel* dafür, wie man einen Breakpoint **hinzufügt** — wer ihn will, muss ihn also selbst definieren:

```css
@theme {
	--breakpoint-3xl: 120rem; /* 1920px — you are on your own here */
}
```

Eine fiese Verwechslungsfalle nebenbei: Tailwind *hat* ein `--container-3xl` und sogar ein `--container-7xl`. Das sind aber **Container-Query- und `max-w-*`-Größen**, keine Viewport-Breakpoints. Die Namensgleichheit führt regelmäßig zu Fehlzitaten — auch in Design-Abnahmen.

### Beide Systeme nebeneinander

Weil die eine Doku in Pixeln rechnet und die andere in `rem`, lassen sich die beiden Tabellen oben nicht direkt vergleichen — und genau daraus entstehen in Abnahmen die Missverständnisse. Deshalb hier alles in **CSS-Pixeln**, auf einer Skala:

| CSS-px | Bootstrap 5 | Tailwind v4 | Typisches Gerät |
| --- | --- | --- | --- |
| 576 | `sm` | — | (zwischen den Stühlen) |
| 640 | — | `sm` | großes Handy quer |
| **768** | **`md`** | **`md`** | Tablet hoch — der einzige Breakpoint, den beide teilen |
| 992 | `lg` | — | kleines Tablet quer |
| 1024 | — | `lg` | Tablet quer |
| 1200 | `xl` | — | kleiner Laptop |
| 1280 | — | `xl` | Laptop |
| **1400** | **`xxl`** *(Ende)* | — | Desktop |
| **1536** | — | **`2xl`** *(Ende)* | Full-HD-Laptop bei 125 % |
| 1920+ | — | — | **Niemandsland. Hier gibt es nichts mehr.** |

Zwei Dinge springen ins Auge. Erstens: **Die beiden Systeme sind fast nirgends deckungsgleich** — nur bei 768 px treffen sie sich. Wer ein Bootstrap-Design in Tailwind nachbaut (oder umgekehrt) und die Breakpoints „übernimmt", baut sich stillschweigend ein anderes Layout.

Zweitens: **Oberhalb von 1536 px hört die Welt auf.** Beide Marktführer, zusammen der überwiegende Teil aller CSS-Frameworks im Einsatz, sagen dort: Schluss. Kein `xxxl`, kein `3xl`, nichts. Ein Design, das dort weitermachen will, ist nicht fortschrittlich — es ist allein.

### Was ein XXXL-Breakpoint tatsächlich bedeutet

Damit lässt sich die Vermutung aus dem Einstieg jetzt beziffern. Entscheidend ist, **wo genau** die Schwelle liegt, unterhalb derer das Design nicht mehr funktioniert. Die Leiter, gerechnet auf die deutschen Desktop-Zahlen aus Teil 1:

```text
Ein Design, das MINDESTENS … CSS-Pixel Breite braucht,
erreicht von den Desktop-Besuchern (DE) noch etwa …

  1280 px  (Tailwind xl)     ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  fast alle echten Desktops
  1536 px  (Tailwind 2xl)    ▓▓▓▓▓▓▓▓               ~42 %   ← v. a. 1920×1080
  1920 px                    ▓▓▓▓▓▓▓                ~33 %
  über 1920 px               ▓                      ~7 %    ← hier beginnt XXXL
  über 2560 px               ▏                      < 1 %

Und das sind nur die DESKTOP-Besucher. Auf alle Besucher gerechnet
(Desktop = 54,7 % in Deutschland) halbiert sich jede dieser Zahlen noch einmal:
„über 1920 px" trifft dann noch rund 4 % deiner Gesamtbesucher.
```

**Der Sprung von 33 % auf 7 % ist die eigentliche Nachricht dieser Leiter.** Zwischen „mindestens 1920" und „mehr als 1920" liegt eine Wand: Fast der gesamte breite Desktop-Verkehr ist *genau* 1920 px breit und keinen Pixel mehr. 1920 ist kein Zwischenschritt auf dem Weg nach oben — **1920 ist die Endstation.** Wer darüber hinaus plant, plant für den leeren Raum dahinter.

Das ist die ehrliche Antwort, und sie ist differenzierter, als ich sie gern hätte: Ein Design, das ab 1536 px aufgeht, erreicht immerhin noch gut zwei Fünftel der Desktop-Nutzer — das ist schlecht, aber nicht absurd. **Ein Design aber, das echte XXXL-Breiten jenseits von 1920 px braucht, erreicht rund 4 % deiner Besucher.** Und darunter sieht es kaputt aus oder verschenkt seine Wirkung.

Dazu kommen die Abzüge, die in keiner Statistik stehen:

```text
Wer das Design NICHT sieht — selbst wenn die Statistik ihn mitzählt:
   ├─ jeder Mobile-Nutzer                       43,6 % (DE)
   ├─ jedes Tablet                               1,7 %
   ├─ jedes MacBook Pro 14"    → 1512 CSS-px    ← unter Tailwinds 2xl!
   ├─ jedes MacBook Air 13"    → 1470 CSS-px    ← unter Tailwinds 2xl!
   ├─ jeder Full-HD-Laptop bei 125 %  → 1536 CSS-px, exakt auf der Kante
   ├─ jeder, der sein Browserfenster nicht maximiert hat
   └─ jeder, der zoomt — und Zoom ist ein Recht, kein Sonderfall
```

Die bittere Pointe: **Nicht einmal der Designer selbst sieht sein Design, wenn er auf einem MacBook Pro arbeitet.** 1512 CSS-Pixel liegen *unterhalb* von Tailwinds `2xl`.

Die Intuition war also richtig — aber aus einem anderen Grund als gedacht. Es geht nicht nur darum, dass zu wenige Leute große Monitore haben. Es geht darum, dass **selbst die Leute mit großen Monitoren keine großen CSS-Viewports haben.** Die Skalierung frisst sie auf.

### Die richtige Antwort: `max-width`, nicht `3xl`

Ein Layout, das ab einer bestimmten Breite „aufgeht", ist ein Layout, das falsch gedacht ist. Die Frage ist nie „Ab wann sieht es gut aus?", sondern „**Bis wann darf es mitwachsen, und was passiert danach?**"

Die Antwort der Frameworks ist eindeutig: Der Inhalt wächst bis zu einem Maximum und hört dann auf. Bootstrap deckelt bei 1320 px, Tailwinds größte Content-Utility `max-w-7xl` bei 80rem = 1280 px. Beide sagen dasselbe: **Jenseits von ~1300 px wird Platz zu Rand, nicht zu Inhalt.**

Das hat einen sachlichen Grund, der nichts mit Statistik zu tun hat: Eine **Fließtext**-Zeile über 75 Zeichen wird schwer lesbar, weil das Auge beim Zeilenumbruch die nächste Zeile nicht mehr sicher findet. Das gilt für den Lesetext — die *Layout*-Breite darf durchaus etwas darüber liegen, solange der Fließtext darin noch einmal gedeckelt wird. Und ein Header, der sich über 2560 px spannt, hat Navigationspunkte, zwischen denen der Blick reisen muss.

Der moderne Werkzeugkasten für den Rest:

```css
.site-header {
	/* Full-bleed background, bounded content — the standard pattern */
	--content-max: 80rem; /* 1280px at default root font size */
}

.site-header__inner {
	max-width: var(--content-max);
	margin-inline: auto;
	/* Fluid padding instead of a cascade of breakpoints.
	   Note: the PADDING is fluid, the HEIGHT is not — a header has a
	   job (fit the touch targets), not a share of the viewport. */
	padding-inline: clamp(1rem, 4vw, 3rem);
	min-height: 4rem;
}
```

`clamp()` ist seit Juli 2020 „widely available" und ersetzt in genau solchen Fällen eine ganze Kaskade von Media Queries ([MDN: clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp), englisch).

Für Komponenten *innerhalb* des Headers — eine Navigation, die je nach verfügbarem Platz umbricht — sind **Container Queries** das richtige Werkzeug: Sie fragen nicht den Viewport, sondern den Platz im Elternelement. Seit Februar 2023 in allen Engines verfügbar, rund 92,6 % Abdeckung ([MDN: @container](https://developer.mozilla.org/en-US/docs/Web/CSS/@container), englisch).

Wichtig ist dabei die Einordnung, die Una Kravets von Google gibt ([web.dev: The new responsive](https://web.dev/articles/new-responsive), englisch): Container Queries **ersetzen** Media Queries nicht, sie ergänzen sie. Media Queries machen das **Makro-Layout** (Seitenebene), Container Queries das **Mikro-Layout** (Komponentenebene). Wer das eine gegen das andere ausspielt, hat beides nicht verstanden.

### Die CMS-Realität

In der Praxis begegnet dir das selten auf der grünen Wiese, sondern in einem CMS. Kurz eingeordnet:

- **Contao** bringt zwar noch ein hauseigenes Grid mit (float-basiert, auf 960.gs aufgebaut, seit Contao 3 dabei), aber das ist Altlast und wird nicht mehr empfohlen — die Breiten kommen in der Praxis aus dem Theme. Wichtiger ist die strukturelle Eigenheit: Der Header ist ein **Modul-Slot**. Was hineinwandert, ist eine Redaktions- und Konfigurationsentscheidung, keine Design-Entscheidung. **Genau deshalb entgleisen Contao-Header so oft**: Es gibt niemanden, der „nein" sagt, wenn noch ein Modul dazukommt.
- **WordPress** ist seit dem Full-Site-Editing der Wilde Westen. Block-Themes definieren ihre Breiten in `theme.json` über `layout.contentSize` und `layout.wideSize` — das ist die Stelle, an der du die Deckelung erzwingst. Wenn ein Kunde „Vollbild-Header" verlangt, ist `wideSize` der Hebel, nicht ein neuer Breakpoint. Klassische Themes bringen ihre eigene Suppe mit, oft Bootstrap oder ein hausgemachtes Grid.
- **TYPO3** trennt sauber zwischen Backend-Layout und Frontend-Rendering (Fluid-Templates). Die Breiten stecken im Site-Package. Der typische Fehler in TYPO3-Projekten ist ein anderer: Der Header wird als „Backend-Layout" konfigurierbar gemacht, und die Redaktion füllt ihn dann bis zum Rand.

Das Muster ist in allen drei Systemen dasselbe: **Die Technik erlaubt mehr, als die Gestaltung verträgt.** Ein CMS-Header braucht keine technischen Grenzen, er braucht redaktionelle. Dazu gleich mehr.

## Teil 5: Der Header, seziert

Reden wir darüber, was überhaupt hineingehört.

### Die Anatomie auf dem Desktop

```text
┌────────────────────────────────────────────────────────────────────┐
│ ◇ Meta-Leiste (optional, 28–36px)  Sprache · Login · Telefon       │  ← Kür
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [LOGO]        Leistungen  Referenzen  Über uns  Blog   [ CTA  ]   │  ← Pflicht
│  ↑ Startseite  ↑ 3–7 Punkte, sichtbar, KEIN Burger      ↑ 1 Stück  │     56–96px
│                                                                    │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│                     H1: Die eine Aussage                           │  ← HERO
│           Teaser: ein bis zwei Sätze, die sie stützen              │     40–70svh
│                                                                    │
│                        [ Primäre Aktion ]                          │
│                                                                    │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┤
│  ▓▓▓ Ein sichtbarer Streifen des nächsten Inhalts ▓▓▓              │  ← PFLICHT!
└────────────────────────────────────────────────────────────────────┘
   ↑ Die Falz. Was darüber liegt, bekommt 57 % der Aufmerksamkeit.
```

Der letzte Streifen ist kein Schmuck. Er ist der Grund, warum ein Hero die volle Viewporthöhe **nur mit sehr gutem Grund** füllen sollte — dazu in Teil 10 die Evidenz.

### Die Anatomie auf dem Handy

```text
┌──────────────────────────┐  360–440 CSS-px, mehr gibt es nicht
│ [LOGO]         [☰]  [→]  │  ← 48–64px. Logo + Burger + max. 1 Aktion.
├──────────────────────────┤
│                          │
│  H1: Die eine Aussage    │  ← Hero, max. 60svh
│  Teaser, kurz.           │
│                          │
│    [ Primäre Aktion ]    │  ← min. 44×44px Trefferfläche
│                          │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┤
│ ▓▓▓ nächster Inhalt ▓▓▓  │
└──────────────────────────┘
```

Auf 360 px Breite ist der Header kein Gestaltungsraum. Er ist ein Kompromiss zwischen drei Dingen, von denen nur zwei hineinpassen.

### Was darf hinein — und was nicht

| Element | Status | Position | Empfehlung |
| --- | --- | --- | --- |
| **Logo / Wortmarke** | Pflicht | links, verlinkt auf Startseite | 32–48 px hoch. `width`/`height` im HTML setzen (CLS!). Auf Mobile ggf. Bildmarke statt Wortmarke. |
| **Hauptnavigation** | Pflicht | rechts oder mittig, **sichtbar** | Desktop: 3–7 Punkte, ausgeschrieben. **Kein Burger auf dem Desktop** — dazu Teil 10, die Zahlen sind eindeutig. |
| **Skip-Link** | Pflicht (WCAG 2.4.1, Level A) | erstes fokussierbares Element | Darf visuell versteckt sein, muss bei Fokus sichtbar werden. |
| **Primärer CTA** | empfohlen | rechts außen, visuell abgesetzt | **Genau einer.** Zwei gleichrangige CTAs sind null CTAs. |
| **`<h1>`** | Pflicht (SEO + WCAG 2.4.6) | im Hero | Eine pro Seite, beschreibend. Kein Marketing-Claim ohne Aussage („Wir denken Zukunft" ist keine H1). |
| **Teaser-Text** | empfohlen | unter der H1 | 1–2 Sätze, max. ~160 Zeichen. Er stützt die H1, er wiederholt sie nicht. |
| **Hero-Bild** | optional | Hintergrund oder daneben | Auf 73 % (mobil) bzw. 83 % (Desktop) aller Websites ist ein Bild das LCP-Element — meist genau dieses. Behandle es entsprechend (Teil 9). |
| **Suchfeld** | kontextabhängig | rechts | Nur wenn die Site wirklich Suchvolumen hat. Sonst ein Icon, das eine Palette öffnet. |
| **Sprachumschalter** | Pflicht bei mehrsprachigen Sites | Meta-Leiste oder rechts | Sichtbar, nicht nur `hreflang`. |
| **Meta-Leiste** | optional | ganz oben, 28–36 px | Telefon, Login, Sprache. Nur, wenn diese Dinge *wirklich* auf jeder Seite gebraucht werden. |
| **Breadcrumb** | empfohlen ab Tiefe 3 | **unter** dem Header, nicht darin | Gehört zum Inhalt, nicht zum Kopf. |
| **Slider / Karussell** | **abraten** | — | Siehe Teil 10. Wenn er sein muss: max. 5 Frames, kein Auto-Rotate ohne Pause-Knopf (WCAG 2.2.2, Level A). |
| **Cookie-Banner** | juristisch, nicht gestalterisch | Overlay | Er gehört *nicht* in den Header-Fluss. Wenn er ihn verschiebt, ist er eine CLS-Quelle. |

Die Zeile, die am meisten Diskussion auslöst, ist der Slider. Die Zahlen dazu kommen in Teil 10 — sie sind differenzierter, als beide Lager behaupten.

## Teil 6: Die Größentabellen

Jetzt die konkreten Zahlen. **Wichtig zur Lesart:** Die WCAG kennt keine maximale Header-Höhe, und die Nielsen Norman Group nennt keine. Die folgenden Werte sind daher **meine Empfehlungen** — aber keine ausgedachten. Jede Zahl hat eine Herleitung, und die steht dabei.

### Erst die Maßstäbe: zwei Referenz-Viewports

Damit die Tabellen unten überhaupt vorstellbar sind, brauchen wir feste Bezugsgrößen. Ich lege sie hier einmal fest, und alle Prozent- und Vergleichswerte im Rest des Artikels rechnen dagegen:

```text
                       Bildschirm      abzüglich          sichtbare Höhe
                       (CSS-px)        Browser-UI &       = 100 svh
                                       Taskleiste         = bis zur Falz
──────────────────────────────────────────────────────────────────────────
MOBIL                  390 × 844       Adress-/Tableiste  ≈ 700 px
  (iPhone-Klasse)

DESKTOP, Laptop       1536 ×  864      Chrome + Taskbar   ≈ 700 px
  (Full HD @ 125 %)

DESKTOP, groß         1920 × 1080      Chrome + Taskbar   ≈ 900 px

──────────────────────────────────────────────────────────────────────────
RECHENWERT DESKTOP, mit dem ich unten arbeite:            ≈ 800 px
  (Mitte zwischen Laptop und großem Monitor)
```

**Die Überraschung steckt in der ersten und zweiten Zeile:** Ein typischer Windows-Laptop hat vertikal **nicht mehr Platz als ein Smartphone**. Beide landen bei rund 700 Pixeln sichtbarer Höhe. Der Laptop ist nur breiter — nicht höher. Wer glaubt, auf dem Desktop sei „ja genug Platz nach unten", irrt sich um genau null Pixel.

Das sind Näherungen, keine Messwerte — die echte Höhe schwankt je nach Browser, Lesezeichenleiste und Fensterzustand um einige Dutzend Pixel. Als Vorstellungshilfe reichen sie: **1 svh ≈ 7 px auf dem Handy, ≈ 8 px auf dem Desktop.**

### Warum die Tabellen mit zwei verschiedenen Einheiten arbeiten

Das ist keine Schlamperei, sondern Absicht — und der Grund lohnt eine Minute:

- **Der Header wird in `px` bemessen**, weil seine Höhe von *absoluten* Dingen bestimmt wird: Ein Fingertipp braucht 44 px, egal wie hoch der Bildschirm ist. Ein Header, der auf großen Bildschirmen mitwächst, wächst ohne jeden Grund.
- **Der Hero wird in `svh` bemessen**, weil seine Höhe von einem *relativen* Ding bestimmt wird: der Falz. Er soll den sichtbaren Bereich zu einem bestimmten Anteil füllen — und der ist auf jedem Gerät anders hoch.

Kurz: **Der Header hat eine Aufgabe, der Hero hat einen Anteil.** Deshalb misst man sie unterschiedlich. In den Tabellen unten steht trotzdem überall beides.

### Header-Höhe

| Kontext | Empfehlung | Obergrenze | Anteil am sichtbaren Bereich | Herleitung |
| --- | --- | --- | --- | --- |
| **Mobile, statisch** | 56–64 px | 72 px | 8–9 % von 700 px | 44 px Trefferfläche (Apple) + 2×8 px Innenabstand. Mehr braucht ein Logo-plus-Burger nicht. |
| **Mobile, sticky** | 48–56 px | 64 px | 7–8 % von 700 px | Klebt auf *jedem* Screenful. Jeder Pixel geht dauerhaft vom Inhalt ab. Bei 48 px bleibt für den 44-px-Burger allerdings kein vertikaler Innenabstand mehr — 56 px sind die bequemere Wahl. |
| **Desktop, statisch** | 72–96 px | 120 px | 9–12 % von 800 px | 44 px Klickziel + großzügiger Innenabstand. Darüber wird es Dekoration. |
| **Desktop, sticky (gescrollt)** | 56–72 px | 96 px | 7–9 % von 800 px | Herleitung unten — das ist die kritische Zahl. |
| **Meta-Leiste (falls vorhanden)** | 28–36 px | 40 px | 3,5–4,5 % von 800 px | Muss lesbare Schrift (≥14 px) plus Luft tragen, mehr nicht. |

Zur Einordnung, damit die Zahlen ein Gefühl bekommen: **64 px sind etwa zwei Zeilen Fließtext.** 120 px — meine Obergrenze für den statischen Desktop-Header — sind rund **vier Zeilen**. Und 160 px, was in freier Wildbahn ständig vorkommt, sind über **fünf Zeilen Text, die niemand lesen will**, auf jeder Seite, ganz oben.

**Die Herleitung der 96px-Obergrenze für sticky Header** — und ich lege sie offen, damit du sie prüfen kannst:

Der Anker ist **WCAG 1.4.10 Reflow** (Level AA). Das Kriterium leitet sich laut W3C ausdrücklich aus **400 % Zoom auf einem 1280-px-Viewport** her. Zoom vergrößert CSS-Pixel — die verfügbare Höhe schrumpft also entsprechend. Ein sticky Header behält dabei seine CSS-Höhe und belegt damit einen **immer größeren relativen Anteil**:

```text
Ausgangslage: Desktop-Viewport ≈ 800 CSS-px Höhe

Header-Höhe      bei 100 % Zoom    bei 200 % Zoom    bei 400 % Zoom
                 (800px sichtbar)  (400px sichtbar)  (200px sichtbar)
────────────────────────────────────────────────────────────────────
  64 px               8 %              16 %              32 %
  96 px              12 %              24 %              48 %
 120 px              15 %              30 %              60 %   ← Alarm
 160 px              20 %              40 %              80 %   ← unbenutzbar
```

Bei 120 px und 400 % Zoom bleiben dem eigentlichen Inhalt noch 80 von 200 Pixeln. Das ist keine Website mehr, das ist ein Guckloch.

**Damit das klar ist: Die 96 px sind meine Ableitung, keine Norm.** In der WCAG steht keine Header-Höhe — weder in 1.4.10 noch sonst wo. Was in der WCAG steht, ist die *Anforderung*, dass bei 400 % Zoom noch Inhalt lesbar sein muss. Die 96 px sind der Wert, bei dem ich diese Anforderung mit einem sticky Header noch für erfüllbar halte. Prüf die Rechnung, und wenn du zu 80 oder 110 kommst, sind wir uns trotzdem einig.

Und die eigentliche Lösung heißt sowieso nicht „kleinerer Header", sondern „**bei wenig Höhe gar nicht sticky**" — dazu Teil 8.

Die Nielsen Norman Group formuliert die Grenze **funktional** statt prozentual, und das ist die klügere Formulierung. (Ob sie das absichtlich tut, weiß ich nicht — sie sagt es nicht. Sie nennt schlicht keine Prozentzahl, und wer ihr eine zuschreibt, hat sie nicht gelesen.) Ihre Vorgabe in [Sticky Headers: 5 Ways to Make Them Better](https://www.nngroup.com/articles/sticky-headers/) (englisch): so hoch, wie 1 cm große Trefferflächen und rund 16 pt Schrift es zwingend erfordern — und „minimize any additional vertical height beyond those sizes". Kein Pixel mehr als nötig.

*(Umgerechnet in die Einheit, in der du baust: **1 cm ≈ 38 CSS-px**, **16 pt ≈ 21 CSS-px** — nicht 16! Warum die Regelwerke in vier verschiedenen Einheiten rechnen und wie du sie ineinander umrechnest, steht gleich unten in eigener Tabelle.)*

### Hero-Höhe

Hier ist die entscheidende Rechnung nicht der Hero selbst, sondern **was unter ihm übrig bleibt**. Denn der Header sitzt ja noch darüber. Die letzte Spalte ist deshalb die wichtigste der ganzen Tabelle:

| Kontext | Empfehlung | ≈ in Pixeln | Rest unter der Falz *(nach Abzug des Headers)* |
| --- | --- | --- | --- |
| **Mobile** | `min-height: 50–60svh` | ~350–420 px *(von 700)* | 224–294 px — **ein klar sichtbarer Inhaltsstreifen** |
| **Desktop** | `min-height: 40–60svh` | ~320–480 px *(von 800)* | 240–400 px — **reichlich Scroll-Einladung** |
| **Absolute Obergrenze** | 70 svh | ~490 px mobil / ~560 px Desktop | ~150–160 px — knapp, aber noch sichtbar |
| **Vollbild (`100svh`)** | **nur mit Grund** | 700 px mobil / 800 px Desktop | **0 px — nichts. Genau das ist das Problem.** |

*(Gerechnet mit einem **statischen** Header: 56 px mobil, 80 px Desktop — der ungünstigste Fall, weil ein statischer Header höher sein darf als ein sticky. Die Rest-Spalte gilt für die jeweils **untere** Grenze des Hero-Korridors; wer den Hero größer zieht, bekommt entsprechend weniger. Die Referenz-Implementierung in Teil 12 nutzt einen **sticky** Header mit 56/72 px und hat deshalb sogar noch etwas mehr Luft.)*

Die letzte Zeile ist der ganze Punkt. Ein `100svh`-Hero lässt unter der Falz **buchstäblich nichts** übrig — der Header schiebt ihn sogar noch darüber hinaus, sodass der Hero selbst unten angeschnitten wird. Der Nutzer sieht eine Seite, die aussieht, als wäre sie hier zu Ende.

Und im empfohlenen Korridor von 50–60 svh? Da bleiben rund **220 bis 300 Pixel** — genug für eine Überschrift und zwei, drei Zeilen des nächsten Abschnitts. Genug, dass das Auge erkennt: *Da geht es weiter.* Das ist keine Ästhetik-Frage, das ist die Scroll-Einladung.

**Warum `svh` und nicht `vh`:** `svh` rechnet mit *ausgefahrenen* Browser-Leisten, ist also der **garantiert sichtbare** Fall. `vh` (= `lvh`) ist der optimistische Fall und stimmt auf dem Handy beim Laden nie — ein `100vh`-Hero ragt dort beim Laden unten aus dem Bild. Merksatz: **`svh` ist das, was du sicher hast. `lvh` ist das, was du gern hättest.**

**Warum nicht `100svh`:** Die Nielsen Norman Group nennt das Problem [„false floor"](https://www.nngroup.com/articles/page-fold-manifesto/) (englisch) — ein Layout, das aussieht, als wäre die Seite hier zu Ende. Der Nutzer scrollt nicht, weil nichts andeutet, dass es weitergeht. Ein bildschirmfüllender Hero ohne sichtbaren Inhaltsstreifen darunter ist die Musterform dieses Fehlers.

Wenn ein Vollbild-Hero unbedingt sein muss (Kampagnenseite, Portfolio), dann **immer mit Scroll-Affordanz**: ein angeschnittenes Element, ein Pfeil, ein Textanriss. Irgendetwas, das sagt „hier geht's weiter".

### Header-Breite und Content-Container

Bis hierhin ging es nur um Höhe. Die Breite ist der zweite, unabhängige Hebel — und der, an dem das XXXL-Problem hängt:

| Maß | Empfehlung | Obergrenze | ≈ Zeichen pro Zeile | Herleitung |
| --- | --- | --- | --- | --- |
| **Content-Container** *(Layout-Breite)* | 1280–1320 px | **1440 px** | (Layout, kein Fließtext) | Bootstrap deckelt bei 1320, Tailwind `max-w-7xl` bei 1280 — das ist der belegte Korridor beider Marktführer. Die 1440 sind meine Toleranzgrenze, keine Framework-Vorgabe. |
| **Header-Hintergrund** | volle Breite | — | — | Der *Hintergrund* darf ruhig über den ganzen Bildschirm laufen. Nur der **Inhalt** wird gedeckelt. |
| **Textspalte im Hero** | 45–75 Zeichen | — | 45–75 | Typografische Grundregel. Wer die H1 über 1400 px zieht, zwingt das Auge auf eine Reise. |

**Der Unterschied zwischen den ersten beiden Zeilen ist die ganze Lösung des XXXL-Problems.** Ein Header darf und soll bildschirmfüllend aussehen — sein Hintergrund läuft von Kante zu Kante. Aber sein *Inhalt* — Logo, Navigation, CTA — sitzt in einem Container, der bei rund 1300 px aufhört zu wachsen. Alles darüber wird Rand.

Deshalb braucht niemand einen XXXL-Breakpoint: **Man baut kein Layout für 2560 px. Man baut ein Layout für 1300 px und lässt den Rest Rand sein.**

### Trefferflächen und Schriftgrößen im Header

Hier lauert die größte Verwirrungsquelle des ganzen Themas: **Die maßgeblichen Regelwerke rechnen in vier verschiedenen Einheiten.** WCAG in CSS-Pixeln, Apple in Punkt (pt), Google in dichteunabhängigen Pixeln (dp), die Nielsen Norman Group sogar in Zentimetern. Wer die Zahlen 24, 44, 48 und 16 nebeneinanderlegt, vergleicht Äpfel mit Birnen.

Deshalb zuerst der Umrechnungsschlüssel — **alles in CSS-Pixeln**, der einzigen Einheit, in der du am Ende tatsächlich baust:

| Quelle sagt | Einheit | **≈ in CSS-Pixeln** | Bedeutet |
| --- | --- | --- | --- |
| WCAG 2.5.8 (AA) | 24 CSS-px | **24 px** | Harte Untergrenze. Darunter: Verstoß. |
| WCAG 2.5.5 (AAA) | 44 CSS-px | **44 px** | Empfohlenes Ziel. |
| Apple | 44 **pt** ¹ | **44 px** | Apple-Point: 1 pt = 1 CSS-px. Deckt sich mit WCAG AAA. |
| Material / Android | 48 **dp** | **48 px** | 1 dp = 1 CSS-px. Etwa 9 mm physisch. |
| Material, Abstand | 8 **dp** | **8 px** | Sichtabstand — **nicht** die WCAG-Ausnahme, s. u. |
| NN/g, sticky Header | 1 **cm** | **≈ 38 px** | Physisches Maß, umgerechnet bei 96 dpi. |
| NN/g, Schriftgröße | 16 **pt** ¹ | **≈ 21 px** | Typografischer Punkt: 1 pt = 1,333 CSS-px. **Nicht 16 px!** |

¹ **Die Falle steckt in „pt".** Das Kürzel bedeutet in den beiden Zeilen **nicht dasselbe**: Apples „point" ist eine Layout-Einheit und entspricht 1 CSS-Pixel. Der typografische Punkt bei Schriftgrößen ist ein Drittel größer (1 pt = 1⅓ px). Beide Umrechnungen oben sind korrekt — aber wer „44 pt" und „16 pt" für dieselbe Einheit hält, verrechnet sich garantiert.

Die gute Nachricht: **Für Trefferflächen sind pt, dp und CSS-px praktisch dasselbe** — Apples 44 pt und Materials 48 dp sind schlicht 44 bzw. 48 CSS-Pixel. Nur Zentimeter und der typografische Punkt tanzen aus der Reihe.

Und jetzt die eigentliche Tabelle, komplett in CSS-Pixeln:

| Element | Minimum | Empfehlung | Herleitung |
| --- | --- | --- | --- |
| Jedes Klick-/Tap-Ziel | **24 × 24 px** | 44 × 44 px | WCAG 2.5.8 (AA) ist das Minimum; 2.5.5 (AAA) und Apple sagen 44. |
| Icon-Buttons (Burger, Suche) | 24 × 24 px | **44–48 px** | Apple 44, Material 48 — nimm 48, dann erfüllst du beide. |
| Abstand zwischen kleinen Zielen | — | ≥ 8 px | Material-Empfehlung. **Achtung:** ersetzt nicht die WCAG-Spacing-Ausnahme — siehe unten. |
| Navigations-Schrift | 14 px | **16–18 px** | Erfahrungswert. NN/g nennt für sticky Header sogar ~21 px (16 pt). |
| H1 im Hero | — | `clamp(1.75rem, 4vw, 3.5rem)` = **28–56 px** | Fluid, aber gedeckelt — Begründung gleich. |
| Teaser | 16 px | 18–20 px | Fließtextgröße, nicht kleiner. |

**Die WCAG-Zahlen sauber getrennt**, weil sie ständig durcheinandergehen:

- **24×24 CSS-px** — das ist [SC 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) (englisch), **Level AA, neu in WCAG 2.2**. Die Spacing-Ausnahme ist präziser, als sie meist wiedergegeben wird: Kleinere Ziele sind erlaubt, wenn ein Kreis von **24 px Durchmesser**, **zentriert auf der Bounding-Box** jedes Ziels, weder ein anderes Ziel noch den Kreis eines anderen unterdimensionierten Ziels schneidet. Praktisch heißt das **rund 24 px Abstand von Mitte zu Mitte** — die 8 dp aus dem Material Design erfüllen das *nicht* automatisch.
- **44×44 CSS-px** — [SC 2.5.5 Target Size (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html), **Level AAA**. Häufiger Irrtum: Dieses Kriterium ist *nicht* neu in 2.2 — es kam in WCAG 2.1 und wurde nur umbenannt.
- **44 pt** — [Apple, UI Design Dos and Don'ts](https://developer.apple.com/design/tips/) (englisch): „Create controls that measure at least 44 points x 44 points."
- **48 dp** — [Android Accessibility Help](https://support.google.com/accessibility/android/answer/7101858): „at least 48x48dp, separated by 8dp of space" — das entspricht physisch etwa 9 mm.

Für einen Header mit Icon-Buttons ist **44–48 px die praktikable Zielgröße, 24 px die harte Untergrenze**, unter die du nicht fallen darfst. Wer 44–48 px nimmt, muss sich um die Spacing-Ausnahme ohnehin nicht mehr kümmern — sie greift nur für unterdimensionierte Ziele.

### Eine Warnung zu `vw`-Schriftgrößen

Die verlockende Zeile `font-size: 4vw` für die Hero-Überschrift ist ein Barrierefreiheits-Risiko. Es gibt dafür ein offizielles W3C-Failure: **F94, „Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize text"**.

Adrian Roselli bringt das Problem auf den Punkt ([Responsive Type and Zoom](https://adrianroselli.com/2019/12/responsive-type-and-zoom.html), englisch): „When people zoom a page, it is typically because they want the text to be bigger. When we anchor the text to the viewport size, even with a (fractional) multiplier, we can take away their ability to do that."

Reines `vw` skaliert nicht mit dem Zoom des Nutzers — du nimmst ihm also genau die Fähigkeit, die er ausüben wollte. Die Lösung ist `clamp()` mit einem **`rem`-basierten Minimum und Maximum**:

```css
h1 {
	/* Min and max in rem → still scales with user zoom.
	   The vw part only handles the fluid middle range.
	   Max is exactly 2× min — see the MDN rule below. */
	font-size: clamp(1.75rem, 4vw, 3.5rem);
}
```

Die Faustregel von MDN: **Der Maximalwert muss mindestens doppelt so groß sein wie der Minimalwert** — sonst ist die 200-%-Skalierbarkeit aus 1.4.4 rechnerisch gar nicht mehr erreichbar. Deshalb steht dort oben `3.5rem` und nicht `3.25rem`: 2 × 1,75 = 3,5. Wer hier knausert, baut sich den Verstoß selbst ein.

## Teil 7: Mobile First — und was passiert, wenn nicht

Jetzt zu der Frage, die durch die deutschen Desktop-Zahlen scheinbar neu gestellt wird.

### Was Mobile First technisch überhaupt heißt

Mobile First ist keine Design-Philosophie, sondern eine **CSS-Kaskaden-Entscheidung**. Es bedeutet: Die Basis-Styles gelten für den kleinsten Viewport, und Media Queries *erweitern* sie nach oben mit `min-width`.

```css
/* MOBILE FIRST — the base case is the small screen */
.nav {
	display: none; /* hidden behind the burger */
}

@media (min-width: 48rem) {
	.nav {
		display: flex; /* progressively enhanced upward */
	}
}
```

```css
/* DESKTOP FIRST — the base case is the big screen */
.nav {
	display: flex;
}

@media (max-width: 47.99rem) {
	.nav {
		display: none; /* stripped back downward */
	}
}
```

Beide Marktführer sind Mobile First: Bootstrap nutzt `min-width` als Standard und schreibt in der Doku ausdrücklich, dass für `xs` gar keine Media Query nötig ist (Abwärts-Queries gibt es dort zwar auch — `media-breakpoint-down` —, aber als Ausnahme, nicht als Grundlage). Tailwind generiert für `sm:`…`2xl:` durchweg `@media (width >= …)`.

Wer Desktop First arbeitet, arbeitet also **gegen** sein Framework.

### Die Gegenüberstellung

| | **Mobile First** (`min-width`) | **Desktop First** (`max-width`) |
| --- | --- | --- |
| **Grundhaltung** | Was ist unverzichtbar? | Was kann weg? |
| **Ergebnis** | Additiv — Features kommen dazu | Subtraktiv — Features werden abgeschnitten |
| **Typische Folge** | Sparsamer Header, der oben wächst | Überladener Header, der unten bricht |
| **Performance** | Kleines Gerät lädt kleine Regeln zuerst | Kleines Gerät lädt die volle Desktop-Kaskade und überschreibt sie |
| **CSS-Spezifität** | bleibt flach | wächst — Overrides von Overrides |
| **Framework-Support** | Bootstrap, Tailwind, Bulma nativ | gegen den Strich |
| **Typische Fehlerklasse** | Desktop wirkt leer, Platz ungenutzt | Mobile ist kaputt und wird „später gefixt" |
| **Wann sinnvoll?** | Fast immer | Interne Tools, Admin-Backends, Dashboards mit garantierter Desktop-Hardware |
| **Der wahre Grund, warum es scheitert** | — | Der Header wurde für 1920 px gedacht. Auf 360 px passt er nicht — also wird gekürzt, bis es „irgendwie geht". |

Der entscheidende Unterschied ist nicht technisch, er ist **disziplinarisch**. Mobile First zwingt dich, auf 360 px zu entscheiden, was wirklich wichtig ist. Desktop First erlaubt dir, diese Entscheidung zu vertagen — und vertagte Entscheidungen werden nie getroffen, sie werden am Ende von der Deadline getroffen.

**Der überladene Header ist fast immer ein Symptom von Desktop First.** Nicht weil `max-width` schlechteres CSS wäre, sondern weil niemand gezwungen war, „nein" zu sagen.

### Kippen die deutschen Desktop-Zahlen das?

Die naheliegende Frage: Wenn in Deutschland 54,7 % Desktop nutzen — sollte man dann nicht Desktop First arbeiten?

**Nein.** Und der Fehlschluss lohnt sich zu sezieren, weil er so verführerisch ist.

1. **43,6 % Mobile sind kein Randfall.** Auch wenn Desktop vorn liegt: Fast die Hälfte deiner Besucher kommt mit 360–440 px an. „Mehrheit" ist nicht „alle".
2. **Mobile First heißt nicht „Mobile ist wichtiger".** Es heißt: „Die Basis ist der engste Fall." Ein Mobile-First-CSS kann einen prachtvollen Desktop-Header haben — es kommt nur *nach* dem einfachen.
3. **Der enge Fall ist ohnehin verpflichtend.** WCAG 1.4.10 verlangt Nutzbarkeit bei **320 CSS-px** — das ist enger als jedes reale Handy. Du musst den engen Fall lösen, ob du willst oder nicht. Dann kannst du auch dort anfangen.
4. **Der Desktop-Anteil ist kein Naturgesetz.** Er ist zum Teil ein Spiegel dessen, wer überhaupt kommt. Eine Seite mit schlechtem Mobile-Erlebnis misst wenig Mobile-Traffic — und schließt daraus fälschlich, Mobile sei unwichtig. Das ist eine sich selbst erfüllende Prophezeiung, und ich habe sie in Analytics-Auswertungen oft genug gesehen.

Was die deutschen Zahlen *tatsächlich* bedeuten: **Der Desktop-Header darf nicht als Nachgedanke behandelt werden.** Das international übliche „Mobile ist alles, Desktop ist Mobile mit mehr Rand" ist für den deutschen Markt zu wenig. Beide Fälle verdienen echte Gestaltung. Aber die *Reihenfolge*, in der du sie baust, bleibt: klein zuerst.

Die ehrlichste Formulierung ist ohnehin **Content First**. Mobile First ist nur die Methode, die dich dazu zwingt.

## Teil 8: Barrierefreiheit — die Grenzen, die nicht verhandelbar sind

Alles bisher war Empfehlung. Was jetzt kommt, ist teils Rechtspflicht — und weil das regelmäßig durcheinandergeht, hier die Rechtslage präzise:

**Was heute (Stand Juli 2026) in Deutschland verbindlich ist:** BITV 2.0 (öffentliche Stellen) und das BFSG (seit 28. Juni 2025) hängen an der harmonisierten Norm **EN 301 549**. Die im EU-Amtsblatt zitierte Fassung ist **v3.2.1**, und die verweist auf **WCAG 2.1 Level AA**. Eine Fassung mit WCAG 2.2 ist in Vorbereitung, aber noch nicht in Kraft.

**Das heißt konkret:** Die beiden Kriterien, die in diesem Kapitel für Header am wichtigsten sind — **2.4.11 Focus Not Obscured** und **2.5.8 Target Size (Minimum)** — sind **WCAG-2.2-Neuzugänge und damit derzeit noch nicht rechtsverbindlich**. Sie werden es aller Voraussicht nach werden. Ich behandle sie hier als das, was sie sind: **absehbar geltendes Recht und heute schon guter Stil.** Alles andere in diesem Kapitel (1.4.10, 1.4.4, 2.4.1, 2.2.2) steckt bereits in WCAG 2.1 und gilt heute.

Und noch eine Einschränkung, weil sie oft zu breit erzählt wird: **Das BFSG gilt nicht pauschal für „die Privatwirtschaft".** Es erfasst bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft — E-Commerce, Bankdienstleistungen, Telekommunikation, E-Books, Personenverkehr. Eine rein informative Firmenwebsite ohne Vertragsanbahnung fällt nicht darunter, und Kleinstunternehmen sind bei Dienstleistungen ausgenommen. Ob dich das BFSG trifft, ist eine juristische Frage — keine, die dir ein Blogartikel beantwortet.

Der Rest dieses Kapitels ist trotzdem für **alle** relevant. Denn ob dich ein Gesetz zwingt oder nicht: Ein Header, der bei 400 % Zoom den halben Bildschirm frisst, ist einfach kaputt.

### 1.4.10 Reflow: die 320-Pixel-Grenze

[SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) (Level AA, englisch) verlangt wörtlich, dass Inhalt „ohne Verlust von Information oder Funktionalität und ohne Scrollen in zwei Dimensionen" darstellbar ist bei einer Breite von **320 CSS-Pixeln**.

Die Herleitung steht im Understanding-Dokument selbst: „320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom."

*(Kurz zur Buchhaltung: Die WCAG rechnet mit einem Referenz-Viewport von 1280 × 1024 px — bei 400 % Zoom bleiben davon 320 × 256 px. Ich habe in Teil 6 mit dem realistischeren Wert von 800 px Höhe gerechnet, weil echte Browser Chrome und Taskleiste abziehen. Die WCAG-Zahl ist die normative, meine die pessimistischere. Wer meine besteht, besteht auch die andere.)*

**Das ist der Punkt, den fast alle übersehen:** 1.4.10 ist kein Handy-Kriterium. Es ist ein **Zoom-Kriterium**. Der Mensch, für den es gemacht ist, sitzt an einem 1280-px-Desktop und hat auf 400 % gezoomt, weil er sonst nichts lesen kann.

```text
Desktop, 1280 × 1024 CSS-px, 400 % Zoom
────────────────────────────────────────
Effektiver Viewport:  320 × 256 CSS-px

┌────────────────┐  ← 320px. Das ist alles.
│  [LOGO]   [☰]  │  ← Header, 56px = 22 % (!)
├────────────────┤
│                │
│  Der Inhalt.   │  ← 200px übrig
│  Alles davon.  │
│                │
└────────────────┘
```

Und jetzt setz da einen sticky Header von 120 px hinein. Es bleiben 136 Pixel Inhalt.

### 2.4.11 Focus Not Obscured: sticky Header sind ein AA-Thema

Das ist die Neuerung, die viele noch nicht auf dem Schirm haben. [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) (englisch) ist **neu in WCAG 2.2 und Level AA**:

> „When a user interface component receives keyboard focus, the component is not **entirely** hidden due to author-created content."

Und das Understanding-Dokument nennt die Schuldigen **namentlich**: „Typical types of content that can overlap focused items are **sticky footers, sticky headers**, and non-modal dialogs."

Lies das Wort „entirely" genau, denn es entscheidet über den Schweregrad: Wenn ein fokussiertes Element **vollständig** unter deinem sticky Header verschwindet, ist das ein **AA-Verstoß**. Ist es nur **teilweise** verdeckt, erfüllst du 2.4.11 noch — dann greift erst [SC 2.4.12 (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html), Level AAA, das gar keine Verdeckung erlaubt.

In der Praxis ist das eine akademische Unterscheidung: Ein Tab-Fokus, der halb unter dem Header klemmt, ist für den Nutzer genauso unbrauchbar. Die Standardlösung ist zum Glück eine Zeile:

```css
html {
	/* Reserve the sticky header's height when scrolling to anchors or focus */
	scroll-padding-top: 4.5rem; /* must match the sticky header height */
}
```

Diese Zeile ist allerdings eine Wartungsfalle: Ändert jemand die Header-Höhe, bricht die Fokus-Sichtbarkeit lautlos. Führe die Höhe deshalb als **eine einzige Custom Property** und leite beides daraus ab:

```css
:root {
	--header-h: 4.5rem; /* 72px — the ONE place this number lives */
}

.site-header {
	position: sticky;
	top: 0;
	block-size: var(--header-h);
}

html {
	scroll-padding-top: var(--header-h);
}
```

### C34: Den sticky Header abschalten, wenn kein Platz ist

Für das Höhenproblem gibt es eine **offizielle W3C-Technique**, und sie ist erfreulich pragmatisch: [C34: Using media queries to un-fixing sticky headers / footers](https://www.w3.org/WAI/WCAG22/Techniques/css/C34) (englisch), gelistet als Advisory Technique zu 1.4.10.

W3C schreibt dort: Sticky-Bereiche „may block a big portion of the screen" bei Landscape-Orientierung oder Zoom — und: „Disabling, or un-fixing sticky regions, is an effective way to allow for enough available space."

Der offizielle Lösungsvorschlag koppelt die Klebrigkeit an die **verfügbare Höhe**, nicht an die Breite:

```css
/* Only stick when there is vertical room to spare */
@media (min-height: 480px) {
	.site-header {
		position: sticky;
		top: 0;
	}
}
```

**Ein Wort der Warnung zum Original:** Die W3C-Technique nutzt im zweiten Teil ihres Beispiels `min-device-width`/`max-device-width`. Diese Features sind in Media Queries Level 4 **als deprecated markiert** — und sie fragen den *Bildschirm* ab, nicht den *Viewport*. Damit greifen sie ausgerechnet dort **nicht**, wo 1.4.10 sie am dringendsten bräuchte: beim zoomenden Desktop-Nutzer, dessen Bildschirm groß bleibt, während sein Viewport schrumpft. Nimm stattdessen konsequent `height`-Queries — die messen genau das, worum es geht. Die im Schlusskapitel gezeigte Referenz-Implementierung macht das so.

Das ist die elegantere Antwort auf „Wie hoch darf ein sticky Header sein?" als jede Prozentzahl: **So hoch, wie er sein muss — und wenn kein Platz ist, ist er eben nicht sticky.**

### Skip-Link: Pflicht, und zwar wachsend

[SC 2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html) (Level A, englisch) verlangt einen Mechanismus, um wiederkehrende Blöcke zu überspringen. Die Logik ist bestechend einfach: **Je größer und verschachtelter dein Header, desto zwingender der Skip-Link.** Ein Tastaturnutzer, der sich auf jeder Unterseite durch 14 Navigationspunkte tabben muss, wird von deinem Header aktiv bestraft.

```html
<a class="skip-link" href="#main">Zum Inhalt springen</a>
```

```css
.skip-link {
	position: absolute;
	inset-inline-start: 1rem;
	inset-block-start: -100%;
	z-index: 100;
	padding: 0.75rem 1.25rem;
	background: var(--color-surface);
	transition: inset-block-start 150ms ease;
}

.skip-link:focus-visible {
	inset-block-start: 1rem;
}

@media (prefers-reduced-motion: reduce) {
	.skip-link {
		transition: none;
	}
}
```

### Slider und Bewegung

Wenn ein Slider im Header sein *muss*, gelten zwei harte Regeln.

**[SC 2.2.2 Pause, Stop, Hide](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html) (Level A, englisch)** — und hier die Nuance, die fast immer falsch wiedergegeben wird: Das Kriterium hat **zwei Teile**. Die berühmte Fünf-Sekunden-Schwelle gilt nur für den ersten (bewegende, blinkende, scrollende Inhalte). Der zweite Teil betrifft **automatisch aktualisierende Inhalte** — und **dafür gibt es keinen Fünf-Sekunden-Freibrief**.

Ein automatisch weiterschaltender Slider fällt unter *beide* Teile: als Bewegung (die Slide-Transition) und als Auto-Update (der Inhaltswechsel). Konsequenz: **Ein Auto-Rotate-Karussell braucht immer einen Pause-Mechanismus. Immer. Level A.**

**`prefers-reduced-motion`** ist seit Januar 2020 in allen Browsern verfügbar. MDN nennt als Zielgruppe ausdrücklich Menschen mit **vestibulären Störungen**, für die „animations involving scaling or panning large objects" Beschwerden auslösen können. Ein bildschirmfüllender, automatisch panender Hero-Slider ist exakt dieser Fall — nicht ein bisschen davon, sondern das Lehrbuchbeispiel.

```css
@media (prefers-reduced-motion: reduce) {
	.hero-slider {
		/* Do not just slow it down — stop it */
		animation: none;
		transition: none;
	}
}
```

Nicht „langsamer machen". Ausschalten.

## Teil 9: Performance — was der Header kostet

Der Header ist das Erste, was geladen wird. Er ist damit auch der Hauptverdächtige, wenn die [Core Web Vitals](https://www.jpkc.com/db/blog/core-web-vitals/) rot sind.

### Dein Hero-Bild *ist* dein LCP

Das ist keine Vermutung, das ist gemessen. Laut [Web Almanac 2024, Performance-Kapitel](https://almanac.httparchive.org/en/2024/performance) (englisch):

- **73,3 %** aller mobilen Seiten haben ein **Bild** als LCP-Element.
- Auf dem Desktop sind es **83,3 %**.

Wenn du ein Hero-Bild hast, ist es mit hoher Wahrscheinlichkeit das Element, an dem Google deine Ladezeit misst. Der Zielwert: **LCP ≤ 2,5 Sekunden** im 75. Perzentil.

Zwei Zahlen aus derselben Quelle zeigen, wie schlecht das im Feld gehandhabt wird:

- **9,5 %** aller mobilen Websites setzen `loading="lazy"` auf **ihr eigenes LCP-Bild**. Das ist der teuerste Ein-Wort-Fehler im Web. [web.dev](https://web.dev/articles/optimize-lcp) (englisch) ist eindeutig: „Never lazy-load your LCP image."
- Nur **15 %** setzen `fetchpriority="high"` darauf (immerhin: 2022 waren es 0,03 %).

Das Rezept ist banal:

```html
<img
	src="/assets/img/hero-1280.webp"
	srcset="
		/assets/img/hero-640.webp   640w,
		/assets/img/hero-1280.webp 1280w,
		/assets/img/hero-1920.webp 1920w,
		/assets/img/hero-2560.webp 2560w
	"
	sizes="(min-width: 80rem) 1280px, 100vw"
	width="1280"
	height="720"
	alt="Aussagekräftige Beschreibung des Bildinhalts"
	fetchpriority="high"
	decoding="async"
>
```

Kein `loading="lazy"`. `fetchpriority="high"`. `width` und `height` gesetzt (gegen CLS). Und: **`w`-Deskriptoren mit `sizes`, nicht `x`-Deskriptoren.** Der Unterschied ist wichtig — `x` beschreibt die Pixeldichte *des Bildes*, `w` seine Breite. Für ein Hero-Bild, dessen Anzeigebreite mit dem Viewport variiert, ist `w` das richtige Werkzeug ([web.dev: Descriptive syntax](https://web.dev/learn/images/descriptive/), englisch).

**Beachte das `sizes`-Attribut.** Es lautet bewusst *nicht* `100vw`. Das Bild sitzt in einem Container, der bei 80rem (1280 px) gedeckelt ist — genau wie in der Referenz-Implementierung in Teil 12. Wer hier trotzdem `100vw` schreibt, sagt dem Browser, das Bild sei viewportbreit, und der lädt auf einem 2560-px-Monitor prompt die größte Variante für einen 1280-px-Slot. Das ist derselbe Fehler in Grün: **`sizes` muss beschreiben, wie breit das Bild wirklich dargestellt wird** — sonst ist die ganze `srcset`-Mühe umsonst. Für einen echten Full-Bleed-Hero, der über die volle Breite läuft, ist `100vw` dagegen richtig — und dann gehören auch größere Varianten ins `srcset`.

### Der Mythos, an dem alle scheitern

Und jetzt der Punkt, der die meisten Performance-Diskussionen auf den Kopf stellt. Google selbst schreibt in [Common misconceptions about how to optimize LCP](https://web.dev/blog/common-misconceptions-lcp) (englisch):

> „**Image download time is almost never the bottleneck.**"

Konkret, und ich zitiere die Einschränkungen mit: Bei **der Mehrheit der Origins** mit schlechtem LCP entfallen **weniger als 10 %** ihrer **p75-LCP-Zeit** auf den eigentlichen Download des Bildes. Und: Die typische Seite mit schlechtem LCP wartet **fast viermal so lange darauf, den Download überhaupt zu starten**, wie sie dann zum Herunterladen braucht.

Das heißt: Die reflexhafte Empfehlung „komprimier das Hero-Bild stärker" ist **meistens die falsche Baustelle**. Das echte Problem heißt *Resource Load Delay* — der Browser findet das Bild zu spät. Und er findet es zu spät, wenn:

- es als CSS-`background-image` steckt (der Preload-Scanner sieht es nicht),
- es per JavaScript nachgeladen wird (Slider! Karussell-Bibliotheken!),
- es hinter einem render-blockierenden Stylesheet wartet,
- es `loading="lazy"` trägt.

**Das ist ein weiteres, oft übersehenes Argument gegen JS-Slider im Header:** Ein Karussell, das seine Bilder erst nach der Hydration lädt, verschiebt den LCP prinzipbedingt nach hinten. Nicht wegen der Dateigröße — wegen des Startzeitpunkts.

### CLS: die Sprungquellen im Header

[CLS](https://www.jpkc.com/db/blog/core-web-vitals/) soll bei ≤ 0,1 liegen. Die Header-typischen Verursacher sind eine kurze, aber gnadenlose Liste:

| Ursache | Symptom | Lösung |
| --- | --- | --- |
| Logo ohne `width`/`height` | Header springt beim Laden auf | Maße im HTML setzen, immer |
| Webfont-Swap in der Navigation | Nav-Zeile wird höher/niedriger | Metrisch angepasste Fallback-Schrift (`size-adjust`, `ascent-override`) — siehe unten |
| Sticky-Header per JS aktiviert | Inhalt springt nach der Hydration | Höhe in CSS reservieren, nicht in JS |
| Cookie-Banner im Dokumentfluss | Alles darunter rutscht | Als Overlay ausführen, nicht als Block |
| Hero-Bild ohne `aspect-ratio` | Hero klappt beim Laden auf | `width`/`height` oder `aspect-ratio` |
| Meta-Leiste, die erst nach Auth erscheint | Kompletter Header rutscht | Platz von Anfang an reservieren |

Der gemeinsame Nenner: **Reserviere den Platz, bevor du weißt, was hineinkommt.**

**Zum Webfont-Problem noch ein Wort**, weil hier oft ein Rat gegeben wird, der die Krankheit durch den Tod ersetzt: `font-display: optional` beseitigt den Layout-Sprung tatsächlich — aber nur, weil es **gar keine Swap-Phase** gibt. Lädt die Schrift nicht innerhalb von rund 100 ms, wird sie für diesen Seitenaufruf **überhaupt nicht angewendet**. Beim typischen Erstbesuch ohne Cache siehst du dann schlicht die Fallback-Schrift. Das ist keine Lösung des Webfont-Problems, das ist dessen Abschaffung.

Der saubere Weg ist die **metrisch angepasste Fallback-Schrift**: Du definierst eine lokale Systemschrift als `@font-face` und gleichst ihre Metriken per `size-adjust`, `ascent-override` und `descent-override` an die Webfont an. Dann belegt der Fallback exakt so viel Platz wie die echte Schrift — und der Tausch kostet keinen einzigen Pixel Layout-Sprung.

```css
@font-face {
	font-family: 'Fallback';
	src: local('Arial');
	/* Tuned so the fallback occupies the same box as the real font */
	size-adjust: 105%;
	ascent-override: 92%;
	descent-override: 24%;
}

body {
	font-family: 'MyWebfont', 'Fallback', sans-serif;
}
```

Die konkreten Prozentwerte musst du für deine Schrift ausmessen — sie sind kein Copy-Paste-Wert.

## Teil 10: Konversion — was die Evidenz wirklich hergibt

Hier trenne ich Belegtes von Behauptetem — und zwar auch dann, wenn das Belegte unbequem ist.

### Die Falz lebt (aber sie ist keine Mauer)

Die belastbarste Studie stammt von der Nielsen Norman Group: [Scrolling and Attention](https://www.nngroup.com/articles/scrolling-and-attention/) (englisch), 2018, **120 Teilnehmende, über 130.000 Blickfixationen** — erhoben an **1920×1080-Desktop-Bildschirmen**. Das ist eine wichtige Einschränkung, die ich mitnenne, weil ich die Zahlen gleich auch für Mobile heranziehe: Für Smartphones sind sie **nicht** gemessen. Der Aufmerksamkeitsgradient dürfte dort ähnlich wirken (die Falz existiert auch auf 844 px Höhe), aber belegt ist das nicht.

| Bereich | Anteil der Betrachtungszeit |
| --- | --- |
| Oberhalb der Falz | **57 %** |
| Erste zwei Bildschirmhöhen | **74 %** |
| Erste drei Bildschirmhöhen | **81 %** |
| Oberste 20 % der Seite | über 42 % |

Und die historische Einordnung: 2010 lagen noch **80 %** der Betrachtungszeit oberhalb der Falz. Der Effekt hat sich also **abgeschwächt, aber nicht aufgelöst**.

Damit sind **beide** Lager widerlegt:

- „Nutzer scrollen nicht" ist **falsch**. 81 % der Zeit in den ersten drei Bildschirmhöhen heißt: Sie scrollen. NN/g wörtlich: „people will scroll if they have a reason to do it."
- „The fold is dead" ist ebenfalls **falsch**. 57 % gegen 43 % ist kein toter Effekt, das ist ein massiver Aufmerksamkeitsgradient.

**Die Konsequenz für den Header ist direkt:** Jeder Pixel Header-Höhe drückt Inhalt aus dem 57-%-Bereich hinaus. Ein 160-px-Header verbraucht auf einem 800-px-Viewport ein Fünftel der wertvollsten Fläche der ganzen Seite — für Logo und Navigation, also für Dinge, die niemand gesucht hat. Kommt ein Hero über die volle Viewporthöhe dazu, liegt der erste *echte* Inhalt komplett unterhalb der Falz, im 43-%-Bereich.

### Slider: die ehrliche Zahlenlage

Ich könnte es mir einfach machen und die berühmte 1-%-Zahl zitieren. Aber sie ist falsch zitiert, und ich sage lieber, was wirklich in der Quelle steht.

Die Quelle ist Erik Runyon, [Carousel Interaction Stats](https://erikrunyon.com/2013/01/carousel-interaction-stats/) (englisch), Daten von 2012/13:

| Website | Klickrate aufs Karussell | Anteil erste Position |
| --- | --- | --- |
| nd.edu (die berühmte Zahl) | **~1 %** | 84 % |
| drei statische Karussells | 1,7–2,3 % | 48–62 % |
| ein **auto-rotierendes** Karussell | **8,8 %** | 40 % |

Lies die letzte Zeile. Ausgerechnet das *auto-rotierende* Karussell hatte die **höchste** Klickrate. Wer „Karussells konvertieren mit 1 %" schreibt, zitiert selektiv gegen die eigene Quelle. (Nebenbei: Die populäre Seite shouldiuseacarousel.com gibt die Erstslot-Quote mit 89 % an — die Primärquelle sagt 84 %. Die Zahl wurde schon bei der ersten Weitergabe verfälscht.)

**Was sich trotzdem belegen lässt** — und es reicht völlig:

Jakob Nielsen, [Auto-Forwarding Carousels Annoy Users](https://www.nngroup.com/articles/auto-forwarding/) (englisch), dokumentiert einen Test bei Siemens UK, bei dem eine Probandin ein prominentes 100-£-Rabattangebot **schlicht übersah**, weil das Karussell alle fünf Sekunden weiterschaltete. Ihr Zitat: „I didn't have time to read it. It keeps flashing too quickly."

Nielsen ergänzt: „Because it moves, users automatically assume that it might be an advertisement, which makes them more likely to ignore it." Und NN/g misst in [Designing Effective Carousels](https://www.nngroup.com/articles/designing-effective-carousels/) (englisch), dass animierte Werbung nur **27 % der Zeit** überhaupt angeschaut wird — Bannerblindheit trifft alles, was sich bewegt.

Dazu kommt die Barrierefreiheit. Jared Smith von WebAIM, zitiert auf shouldiuseacarousel.com: „Carousels pose accessibility issues for keyboard and screen reader users that simply cannot be adequately addressed by markup or hacks."

**Meine Position, so ehrlich wie die Datenlage hergibt:** Karussells sind nicht *nachweislich* Konversionskiller — die Zahlenlage dafür ist schwächer, als ihre Gegner behaupten. Aber sie sind **teuer**: Sie kosten LCP (JS-nachgeladene Bilder), sie kosten Barrierefreiheit (WCAG 2.2.2, Tastaturbedienung), sie kosten Aufmerksamkeit (Bannerblindheit) — und **die erste Position sammelt 40 bis 84 % aller Klicks ein**, alle übrigen Slides teilen sich den Rest. Dafür liefern sie einen Nutzen, den niemand belastbar messen kann.

Das ist kein Verbot. Das ist ein sehr schlechtes Geschäft.

Wenn er trotzdem sein muss: **maximal 5 Frames** (NN/g), **kein Auto-Rotate ohne Pause-Knopf** (WCAG 2.2.2 Level A), Bilder **nicht** per JS nachladen, Steuerelemente **innerhalb** des Karussells, und — der wichtigste Rat von NN/g — „**some people will only see the first frame or none at all**": Wichtige Inhalte müssen zusätzlich woanders stehen.

### Hamburger-Menü auf dem Desktop: hier ist die Evidenz eindeutig

Wenn ich in diesem Artikel eine einzige Empfehlung geben dürfte, wäre es diese. Die Zahlen stammen aus [Hamburger Menus and Hidden Navigation Hurt UX Metrics](https://www.nngroup.com/articles/hamburger-menus/) (englisch), NN/g 2016, **179 Teilnehmende, 6 Websites**:

| Metrik (Desktop) | Versteckt (nur Burger) | Sichtbar | Kombiniert |
| --- | --- | --- | --- |
| Nutzung der Navigation | 27 % | **48 %** | **50 %** |
| Zeit zur Aufgabenerfüllung | **mind. 39 % langsamer** | Referenz | Referenz |
| Auffindbarkeit von Inhalten | **über 20 % schlechter** | Referenz | Referenz |
| Empfundene Schwierigkeit | 21 % höher | Referenz | Referenz |

NN/gs Empfehlung ist ungewöhnlich direkt: „**Do not use hidden navigation (such as hamburger icons) in desktop user interfaces.** Instead display the top-level navigation options."

Und der Satz, der mir am meisten sagt: „**Discoverability is cut almost in half** by hiding a website's main navigation."

**Und auf Mobile?** Hier lohnt der genaue Blick, denn die Studie misst drei Varianten, nicht zwei. Mobil wurde die **versteckte** Navigation in 57 % der Fälle genutzt — die **kombinierte** aber in **86 %**. „Kombiniert" heißt: ein paar wichtige Punkte sichtbar, der Rest hinter dem Burger.

Das ist der eigentliche Rat, und er ist besser als „auf Mobile geht's halt nicht anders": **Auch auf 360 px musst du nicht alles verstecken.** Ein oder zwei tragende Ziele bleiben sichtbar (der primäre CTA, vielleicht „Kontakt"), der Rest wandert ins Menü. Der reine Burger ist auch mobil die schwächste der drei Optionen — er ist nur die bequemste.

**Auf dem Desktop ist er schlicht Ästhetik auf Kosten der Nutzer.** Wenn du 1400 px Platz hast und deine Navigation trotzdem versteckst, verschenkst du die Hälfte ihrer Auffindbarkeit für ein Icon.

### „7±2 Menüpunkte" ist ein Mythos

Zum Schluss noch eine Regel, die ich in fast jedem Design-Review höre. Jakob Nielsen selbst, in [Short-Term Memory and Web Usability](https://www.nngroup.com/articles/short-term-memory-and-web-usability/) (englisch):

> „It's a **common misconception** that limited short-term memory implies that menus should be similarly limited to 7 items. **It's fine to have longer menus** (if needed), because users don't have to memorize the full list of menu items."

Die Begründung ist sauber: Millers 7±2 beschreibt die Kapazität des **Arbeitsgedächtnisses** — Dinge, die man sich *merken* muss. Ein Menü muss man sich nicht merken, man **sieht** es. Menüs arbeiten mit *Wiedererkennung*, nicht mit *Erinnerung*.

Kürzere Menüs sind trotzdem besser — aber aus einem anderen Grund: **Scangeschwindigkeit**. Eine belastbare Maximalzahl gibt es nicht, und ich erfinde keine. Meine praktische Empfehlung von 3–7 Top-Level-Punkten ist eine Erfahrungsregel, keine Studie. Ich sage das dazu, weil andere es nicht tun.

## Teil 11: Der Anti-Pattern-Katalog

Die Sünden, die mir in Design-Abnahmen am häufigsten begegnen — jeweils mit der Fundstelle im Artikel:

| # | Anti-Pattern | Warum es schadet |
| --- | --- | --- |
| 1 | **Design braucht einen XXXL-Breakpoint** | Jenseits von 1920 CSS-px erreichst du noch rund 4 % deiner Besucher. Nicht mal ein MacBook Pro kommt über 1536. → Teil 4 |
| 2 | **Auf dem 32"-Monitor entworfen, nie kleiner geprüft** | Stichprobe von eins — und zwar aus der Hardware-Blase, in der Entwickler leben. → Teil 1 |
| 3 | **`100vh`-Hero** | Auf Mobile schlicht falsch berechnet, und ein „false floor". → Teil 3, 6 |
| 4 | **Sticky Header über 96 px** | Bei 400 % Zoom bleibt kaum Inhalt übrig. → Teil 6, 8 |
| 5 | **Sticky Header ohne `scroll-padding-top`** | Verschwindet der Tab-Fokus *vollständig* darunter: AA-Verstoß (SC 2.4.11). Teilweise verdeckt: AAA. Beides unbrauchbar. → Teil 8 |
| 6 | **Burger-Menü auf dem Desktop** | Mindestens 39 % langsamer, über 20 % schlechtere Auffindbarkeit. → Teil 10 |
| 7 | **Zwei gleichrangige CTAs** | Zwei Prioritäten sind keine Priorität. → Teil 5 |
| 8 | **Auto-rotierender Slider ohne Pause** | WCAG 2.2.2, Level A. Kein Ermessensspielraum. → Teil 8 |
| 9 | **Hero-Bild per JS/CSS-Background geladen** | Preload-Scanner findet es nicht → LCP kaputt. → Teil 9 |
| 10 | **`loading="lazy"` am LCP-Bild** | Der teuerste Ein-Wort-Fehler im Web. 9,5 % aller **mobilen** Seiten machen ihn. → Teil 9 |
| 11 | **Logo ohne `width`/`height`** | Direkte CLS-Quelle, in jedem einzelnen Seitenaufruf. → Teil 9 |
| 12 | **`font-size` in reinem `vw`** | W3C-Failure F94, bricht WCAG 1.4.4. → Teil 6 |
| 13 | **`sizes="100vw"` bei gedeckeltem Container** | Der Browser lädt die größte Bildvariante für einen kleinen Slot. → Teil 9 |
| 14 | **Meta-Leiste, weil „Platz ist"** | Jeder Pixel oben drückt Inhalt aus dem 57-%-Bereich. → Teil 10 |
| 15 | **Header wächst mit dem CMS mit** | Die Technik erlaubt mehr, als die Gestaltung verträgt. → Teil 4 |

## Teil 12: Ein Header, der die Regeln erfüllt

Zum Abschluss die Zusammenfassung als Code. Das ist kein Framework, sondern das Skelett — die Zahlen darin sind die aus Teil 6.

```css
:root {
	/* Single source of truth — everything else derives from this.
	   These are the TOP of the sticky ranges from part 6 (48–56 / 56–72),
	   because this header sticks. A static header may go higher. */
	--header-h: 3.5rem; /* 56px mobile */
	--content-max: 80rem; /* 1280px */
}

@media (min-width: 48rem) {
	:root {
		--header-h: 4.5rem; /* 72px desktop */
	}
}

/* --- Header ------------------------------------------------------ */

.site-header {
	block-size: var(--header-h);
	/* Full-bleed background, bounded content */
	background: var(--color-surface);
}

.site-header__inner {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: clamp(1rem, 3vw, 2.5rem);
	max-inline-size: var(--content-max);
	margin-inline: auto;
	padding-inline: clamp(1rem, 4vw, 3rem);
	block-size: 100%;
}

/* Only stick when there is vertical room to spare (W3C technique C34).
   Below 480px of viewport height — landscape phones, heavy zoom — the
   header is not worth its height, so it scrolls away like normal content.
   Note: height queries, not the deprecated device-width ones C34 uses. */
@media (height >= 480px) {
	.site-header {
		position: sticky;
		inset-block-start: 0;
	}

	/* Focus and anchors must clear the sticky header (WCAG 2.2 SC 2.4.11) */
	html {
		scroll-padding-block-start: var(--header-h);
	}
}

/* --- Navigation -------------------------------------------------- */

.nav__link {
	/* WCAG 2.5.8 requires 24px; Apple/Material say 44–48. Use the latter. */
	min-block-size: 2.75rem; /* 44px */
	display: inline-flex;
	align-items: center;
	padding-inline: 0.75rem;
	font-size: 1rem;
}

/* --- Hero -------------------------------------------------------- */

.hero {
	/* svh, not vh: guaranteed visible even with mobile toolbars out.
	   Capped at 60% so the next section always peeks above the fold. */
	min-block-size: 60svh;
	display: grid;
	align-content: center;
}

.hero__title {
	/* rem min/max keeps user zoom working (avoids W3C failure F94).
	   Max is exactly 2× min, as MDN requires for 200% scalability. */
	font-size: clamp(1.75rem, 4vw, 3.5rem);
	text-wrap: balance;
}
```

Und das Ergebnis, wie es der Nutzer sieht:

```text
 360px (Handy)              1280px (Laptop)                 2560px (WQHD)
┌────────────┐         ┌──────────────────────┐    ┌────────────────────────────────┐
│[Logo]  [☰] │  56px   │[Logo]  Nav…   [CTA]  │72px│      [Logo]  Nav…   [CTA]      │ 72px
├────────────┤         ├──────────────────────┤    ├────────────────────────────────┤
│            │         │                      │    │        │                │      │
│  H1        │  60svh  │   H1                 │    │  Rand  │   H1           │ Rand │
│  Teaser    │         │   Teaser             │    │        │   Teaser       │      │
│  [Aktion]  │         │   [Aktion]           │    │        │   [Aktion]     │      │
│            │         │                      │    │        │                │      │
├─ ─ ─ ─ ─ ─ ┤         ├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤    ├─ ─ ─ ─ ┼─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─┤
│▓ Inhalt ▓  │         │▓▓ Inhalt ▓▓          │    │        │▓▓ Inhalt ▓▓    │      │
└────────────┘         └──────────────────────┘    └────────────────────────────────┘
                                                    ↑ Der Platz wird zu RAND,
                                                      nicht zu Inhalt.
                                                      Kein XXXL-Breakpoint nötig.
```

Das ist der ganze Trick. Jenseits von ~1300 px wächst nicht der Inhalt, sondern der Rand. Deshalb braucht kein vernünftiges Design einen XXXL-Breakpoint — und deshalb ist ein Design, das einen *braucht*, kein vernünftiges Design.

## Prüf-Checkliste zum Mitnehmen

Zum Abhaken vor jeder Abnahme. **Nutze den Kopieren-Knopf oben rechts am Block** — du bekommst fertiges Markdown mit funktionierenden Ankreuzkästchen, das du direkt in dein Ticket, dein Pull-Request-Template, deine Notizen-App oder dein Abnahmeprotokoll einfügen kannst.

```markdown
# Header-Abnahme — Prüf-Checkliste

Quelle: https://www.jpkc.com/db/blog/header-groessen/

## Dimensionen
_(Empfehlungen aus dem Artikel, hergeleitet — keine Normen)_

- [ ] Header MOBIL  ≤ 64 px (sticky) bzw. ≤ 72 px (statisch)?
- [ ] Header DESKTOP ≤ 96 px (sticky) bzw. ≤ 120 px (statisch)?
- [ ] Hero ≤ 70 svh, mit sichtbarem Inhaltsstreifen darunter?
- [ ] Kein `100vh` / `100svh`-Hero ohne zwingenden Grund?
- [ ] Content-Container bei ≤ 1440 px gedeckelt (Framework-Korridor: 1280–1320)?
- [ ] Header-Hintergrund darf voll breit sein — der INHALT ist gedeckelt?
- [ ] Layout funktioniert bei 1280, 1024, 768, 440 und **320** CSS-px?
- [ ] Kein Breakpoint jenseits von 1536 px nötig?

## Barrierefreiheit
_(Kriterien-Nummern = echte WCAG-Anforderungen)_

- [ ] 400 % Zoom auf 1280 px: kein horizontales Scrollen? (WCAG 1.4.10, AA)
- [ ] Text auf 200 % vergrößerbar, ohne Verlust von Inhalt/Funktion? (1.4.4, AA)
- [ ] Header frisst bei starkem Zoom nicht den halben Viewport? _(eigene Herleitung)_
- [ ] Tab-Fokus verschwindet nicht unter dem sticky Header?
      `scroll-padding-top` = Header-Höhe gesetzt? (2.4.11, AA in WCAG 2.2)
- [ ] Alle Klickziele ≥ 24 px? (2.5.8, AA in WCAG 2.2)
- [ ] Icon-Buttons 44–48 px? (2.5.5 AAA / Apple 44 pt / Material 48 dp)
- [ ] Skip-Link vorhanden und bei Fokus sichtbar? (2.4.1, A)
- [ ] Sticky bei geringer Viewport-Höhe deaktiviert? (Technique C34)
- [ ] Bewegte Elemente pausierbar? (2.2.2, A)
- [ ] `prefers-reduced-motion` respektiert — Animation AUS, nicht nur langsamer?
- [ ] Keine Schriftgröße in reinem `vw` (W3C-Failure F94)?
      `clamp()`-Maximum ≥ 2 × Minimum?

## Performance
- [ ] Hero-Bild: KEIN `loading="lazy"`, dafür `fetchpriority="high"`?
- [ ] Hero-Bild im HTML — nicht per CSS-Background, nicht per JS/Slider?
- [ ] `srcset` mit `w`-Deskriptoren?
- [ ] `sizes` beschreibt die ECHTE Anzeigebreite (nicht blind `100vw`)?
- [ ] Logo und alle Header-Bilder mit `width`/`height`?
- [ ] Kein JS nötig, damit der Header seine Höhe bekommt?
- [ ] Webfont: metrisch angepasster Fallback statt Layout-Sprung?
- [ ] Cookie-Banner als Overlay — nicht im Dokumentfluss?

## Konversion
- [ ] Genau EIN primärer CTA?
- [ ] Navigation auf dem Desktop sichtbar — kein Burger?
- [ ] Auf Mobile: wenigstens ein tragendes Ziel sichtbar neben dem Burger?
- [ ] `<h1>` sagt, worum es geht — kein Claim ohne Aussage?
- [ ] Falls Slider: max. 5 Frames, kein Auto-Rotate ohne Pause-Knopf,
      Inhalte zusätzlich auch woanders erreichbar?

## Der Selbsttest, der alles auffliegen lässt
- [ ] Auf 320 px Breite geöffnet — und es funktioniert noch?
- [ ] Mit 400 % Zoom geöffnet — und der Header frisst nicht alles?
- [ ] Nur mit der Tastatur bedient — und der Fokus ist immer sichtbar?
```

Der letzte Block ist der wichtigste. **Diese drei Handgriffe dauern zusammen keine zwei Minuten und decken mehr auf als jedes Audit-Tool.** Wenn ein Design sie übersteht, ist es meistens auch sonst in Ordnung. Wenn nicht, weißt du sofort, wo du hinschauen musst.

## Fazit

Die Vermutung aus dem Einstieg war richtig — wenn auch aus einem anderen Grund als erwartet.

Der Grund ist nicht in erster Linie, dass zu wenige Menschen große Monitore besitzen. Der Grund ist, dass **große Monitore keine großen CSS-Viewports erzeugen.** Ein 4K-Panel liefert im Browser 1920 oder 2560 CSS-Pixel, je nach Skalierung — die vier Millionen Extra-Pixel gehen restlos in die Bildschärfe. Ein MacBook Pro 14" liefert 1512. Die Frage „Wie viele haben 4K?" ist deshalb die falsche. Die richtige lautet: „**Wie viele haben mehr als 1920 CSS-Pixel Breite?**" Und die Antwort aus den deutschen Zahlen: rund **7 % der Desktop-Besucher** — also etwa **4 % aller Besucher**.

**Ein Design, das echte XXXL-Breiten braucht, ist damit nicht ambitioniert. Es ist an 96 % seines Publikums vorbei gebaut.**

Dass solche Designs trotzdem entstehen, ist keine Böswilligkeit. Es ist eine **Stichprobe von eins**: Wir haben die guten Monitore. Die Steam-Umfrage zeigt, wie diese Hardware-Blase aussieht — gut ein Drittel der Gaming-PCs hat ein Panel jenseits von Full HD. Und selbst dieses Panel liefert im Browser keine entsprechende Fläche, sobald skaliert wird. Wer nur auf dem eigenen Gerät prüft, prüft die Blase — und sieht nicht einmal dort, was sein CSS wirklich bekommt.

Die Lösung ist am Ende erstaunlich unspektakulär. Sie heißt nicht „noch ein Breakpoint", sondern **`max-width`**. Jenseits von etwa 1300 Pixeln wird Platz zu Rand, nicht zu Inhalt. Genau das machen Bootstrap (1320 px) und Tailwind (`max-w-7xl`, 1280 px) seit Jahren vor. Sie haben nicht vergessen, einen `3xl`-Breakpoint einzubauen. Sie haben sich dagegen entschieden.

Und für alles darunter gilt eine noch einfachere Regel: **Jeder Pixel Header-Höhe wird dem Inhalt genommen** — genau dem Inhalt, der 57 % der Aufmerksamkeit bekommt, der bei 400 % Zoom um 200 Pixel Platz kämpft und der über Konversion entscheidet. Ein Header ist kein Gestaltungsraum. Er ist eine Steuer, die du auf jede einzelne Seite zahlst.

Zahle sie so niedrig wie möglich.

---

## Quellen und Datenstand

Alle Marktanteils- und Auflösungsdaten: **StatCounter GlobalStats, Erhebungsmonat Juni 2026** (Deutschland und weltweit). StatCounter misst Seitenaufrufe, nicht Personen, verwendet kein gewichtetes Panel und revidiert Werte bis zu 45 Tage lang — die Zahlen sind belastbare Größenordnungen, keine amtliche Statistik. Die **Steam-Hardware-Survey** (ebenfalls Juni 2026) misst *physische* Panel-Auflösungen und ist deshalb **nicht direkt** mit StatCounters CSS-Pixel-Werten vergleichbar; sie steht hier ausschließlich als Beleg für die Hardware-Ausstattung der Enthusiasten-Population.

Framework-Versionen zum Zeitpunkt der Recherche: **Bootstrap 5.3.8**, **Tailwind CSS 4.3.2**.

Kriterien-Nummern nach **WCAG 2.2**. Zur Rechtslage siehe Teil 8: Verbindlich ist in Deutschland derzeit EN 301 549 v3.2.1 mit **WCAG 2.1 AA** — die 2.2-Neuzugänge (2.4.11, 2.5.8) sind noch nicht in Kraft.

**Wo dieser Artikel eigene Herleitungen statt Belege verwendet, ist das jeweils gekennzeichnet** — insbesondere bei den Header-Höhen-Obergrenzen in Teil 6, den Element-Empfehlungen in Teil 5 und der Menüpunkt-Zahl in Teil 10. Es gibt weder eine WCAG-Vorgabe noch eine NN/g-Studie zur maximalen Header-Höhe. Wer dir eine Prozentzahl als „Standard" verkauft, hat sie sich ausgedacht — auch dann, wenn ich es bin.

Dieser Artikel hat vor der Veröffentlichung einen [adversarischen Faktentreue-Review](https://www.jpkc.com/db/blog/faktentreue-review/) durchlaufen: Jede überprüfbare Behauptung wurde mit dem Ziel geprüft, sie zu **widerlegen**. Mehrere Zahlen und zwei Schlussfolgerungen haben das nicht überlebt und wurden korrigiert.

Weiterführend im Blog: [Core Web Vitals & Performance](https://www.jpkc.com/db/blog/core-web-vitals/) für die Messmethodik hinter LCP und CLS, [Technical SEO](https://www.jpkc.com/db/blog/technical-seo/) für den technischen Gesamtrahmen.