Above the Fold: was der Begriff 2026 bei Bildschirmen von 360 bis 3440 Pixel noch bedeutet

Der Begriff stammt aus dem Zeitungsgeschäft. Tageszeitungen lagen am Kiosk gefaltet aus, sichtbar war nur die obere Hälfte der Titelseite. Schlagzeile und Foto in diesem oberen Bereich, above the fold, entschieden, ob jemand die Zeitung kaufte oder weiterging.

Als sich professionelles Webdesign Ende der Neunziger etablierte, übertrug man diese Logik direkt auf Bildschirme. Ein Nutzer öffnet eine Seite und sieht zunächst nur einen Ausschnitt, der Rest bleibt verborgen, bis gescrollt wird. Frühe Usability-Studien aus dieser Zeit, mit Monitoren, die meist 800x600 oder 1024x768 Pixel maßen, zeigten, dass ein großer Teil der Nutzer gar nicht scrollte. Die praktische Schlussfolgerung war einfach: Was wichtig ist, muss ohne Scrollen sichtbar sein.

Diese Regel wurde über mehr als ein Jahrzehnt zum Designdogma. Überschrift, Call-to-Action, Kontaktformular und Wertversprechen quetschten sich in die ersten 600 bis 800 Pixel Höhe, teils auf Kosten der visuellen Klarheit, aus Angst, Nutzer ohne Scroll-Bereitschaft zu verlieren.

Aus dieser Angst entstand ein eigener kleiner Werkzeugmarkt. Heatmap-Anbieter wie Crazy Egg oder Hotjar bauten ihr erstes Verkaufsargument fast ausschließlich um die Frage herum, wie viele Nutzer eine Seite überhaupt scrollen und wie weit. Agenturen präsentierten Kunden Screenshots mit einer roten Linie bei 600 oder 800 Pixel, mit dem Hinweis, alles darunter werde kaum gesehen. Diese Praxis war unter den damaligen technischen Bedingungen, mit wenigen verbreiteten Bildschirmgrößen, nicht unbegründet. Das Problem entstand erst später, als sich diese eine rote Linie als feste Regel verselbstständigte, obwohl sich die Geräte darunter längst vervielfacht hatten.

Mit Core Web Vitals änderte sich der Bezugsrahmen. In der offiziellen Dokumentation zum Largest Contentful Paint taucht der Begriff Above the Fold nicht auf, geprüft: Die web.dev-Seite zu LCP erwähnt ihn nicht. Google spricht stattdessen vom Viewport, dem tatsächlich sichtbaren Bereich auf jedem Gerät und in jeder Sitzung. LCP misst, wie lange das größte Element in diesem Viewport braucht, um zu rendern, sei es ein Bild, ein Textblock oder ein Video. Ragt ein Element über den Viewport hinaus oder wird es abgeschnitten, zählt dieser Teil nicht zur Elementgröße, geprüft laut web.dev-Dokumentation.

Der Unterschied ist fein, aber wichtig. Above the Fold ging in den Nullerjahren von einem festen Wert aus, einer gedachten Linie bei einer bestimmten Pixelhöhe, gleich für alle Besucher. LCP macht diese Annahme nicht: Die Messung erfolgt pro echter Sitzung, mit dem realen Viewport jedes einzelnen Nutzers. Es gibt keine einzelne Falzlinie, die Google bewertet, sondern so viele Viewports wie es Kombinationen aus Gerät, Ausrichtung und Zoomstufe unter den Besuchern einer Seite gibt.

Anders gesagt: Das ursprüngliche Konzept löste ein Problem der visuellen Hierarchie mit einer festen Regel. Core Web Vitals löst ein Performance-Problem mit einer dynamischen Messung. Beides zählt, aber beides ist nicht austauschbar, und wer es verwechselt, trifft falsche Designentscheidungen.

Das ist die eigentlich interessante Frage, wichtiger als die reine Definition. Hat ein Smartphone einen Viewport von 360 Pixel Breite und ein Ultrawide-Monitor 3440 Pixel, ist "der sichtbare Bereich ohne Scrollen" für zwei Personen, die dieselbe URL zur gleichen Minute besuchen, eine radikal andere Zahl. Ergibt es überhaupt noch Sinn, für eine einzige Schnittlinie zu designen?

Die Marktanteilsdaten zu Bildschirmauflösungen bestätigen das recht eindeutig: Im Juli 2026 lag die weltweit meistgenutzte Auflösung, 1920x1080, bei gerade einmal 10,13 Prozent des globalen Traffics, geprüft, Statcounter Global Stats, Daten Juli 2026, aktualisiert am 07.08.2026. Der Rest verteilt sich auf Dutzende mobile Viewport-Breiten, von 360x800 bis 414x896, jede davon nur mit einstelligen Anteilen. Eine dominante Auflösung gibt es seit Jahren nicht mehr; die Fragmentierung ist so breit, dass ein exakter Pixelwert als Falzgrenze in der Praxis willkürlich ist.

Dabei geht es nicht nur um die Breite. Above the Fold war ursprünglich vor allem eine Frage der Höhe, wie weit ein Nutzer scrollen muss, bis er scrollt. Auch diese Höhe schwankt heute erheblich: Ein Smartphone im Hochformat zeigt oft nur 600 bis 700 Pixel Höhe, bevor Browserleiste und Betriebssystem-Elemente den nutzbaren Bereich weiter verkleinern, und dieser Bereich ändert sich sogar innerhalb derselben Sitzung, wenn beim Scrollen die Adressleiste ein- oder ausblendet. Ein Desktop-Fenster in voller Höhe zeigt dagegen leicht 900 bis 1000 Pixel. Wer above the fold nur über die Breite denkt, übersieht die Hälfte des eigentlichen Problems.

Das heißt allerdings nicht, dass das dahinterliegende Prinzip tot ist. Eine Eyetracking-Studie des Nielsen Norman Group mit Daten aus 2018 fand heraus, dass Nutzer 57 Prozent ihrer Betrachtungszeit auf den oberen Seitenbereich verwendeten, gegenüber 80 Prozent in einer vergleichbaren Studie aus 2010, geprüft, nngroup.com, Studie von 2018. Zu beachten ist, dass diese Daten über sieben Jahre alt sind und keine methodisch vergleichbare, aktuellere Wiederholung gefunden wurde, daher werden sie mit dieser Einschränkung zitiert. Dieselbe Studie zeigte, dass sich 74 Prozent der Betrachtungszeit auf die ersten zwei Bildschirmfüllungen konzentrierten, und dass das Muster eines scharfen Aufmerksamkeitsabfalls nach diesem Bereich 2018 genauso auftrat wie 2010, nur weiter unten verschoben.

Die vernünftige Lesart dieser beiden Datenpunkte zusammen lautet: Als feste Pixellinie hält Above the Fold der Analyse 2026 nicht stand. Als Prinzip, dass weiter oben platzierter Inhalt systematisch mehr Aufmerksamkeit bekommt als scrollpflichtiger, stimmt es weiterhin, nur ist der Schnitt keine scharfe Grenze mehr, sondern ein abfallender Aufmerksamkeitsverlauf, der je nach Gerät variiert. Die Frage "Was passt in die ersten 700 Pixel?" durch "Was sieht jedes reale Segment meiner Zielgruppe zuerst, und lädt das schnell?" zu ersetzen, ist der Perspektivwechsel, den sowohl Verhaltensdaten als auch Performance-Metriken nahelegen.

Die praktische Konsequenz ist nicht, die Idee visueller Hierarchie aufzugeben, sondern sie nicht mehr als Pixelmaß, sondern als Priorisierungsentscheidung je Zielgruppensegment zu behandeln.

Zunächst lohnt sich ein Blick auf die eigenen echten Daten, bevor man etwas annimmt: Google Search Console und der Core-Web-Vitals-Bericht segmentieren die Performance nach Gerät, und Analytics-Tools zeigen, welcher Traffic-Anteil von Mobilgeräten, Tablets oder Desktops kommt und mit welchen vorherrschenden Bildschirmbreiten. Ein Design auf Basis eines 1440-Pixel-Mockups ohne diesen Blick auf die Daten heißt, für einen Bruchteil der echten Zielgruppe blind zu gestalten.

Zweitens sollte das LCP-Element jeder wichtigen Vorlage, Startseite, Produktseite, Artikel, explizit identifiziert und optimiert werden: welches Bild, welche Überschrift oder welcher Block ist in jedem Breakpoint der Kandidat für das größte Element, und lädt es unter realen mobilen Netzbedingungen schnell, nicht nur im Laborumfeld mit Glasfaser.

Drittens löst gut gemachtes responsives Design einen guten Teil des Problems bereits: Statt einer festen Höhe, die auf jeder Bildschirmgröße passen muss, definiert man eine Inhaltshierarchie, Überschrift, Wertversprechen, primärer Call-to-Action, die sich flexibel an den verfügbaren Platz anpasst, statt auf kleinen Bildschirmen erzwungen gestaucht zu werden.

Schließlich bleiben Heatmaps und A/B-Tests die verlässlichste Methode, um zu wissen, was ein bestimmtes Nutzersegment tatsächlich sieht, statt es aus einem einzigen Design abzuleiten. Eine geräteweise segmentierte Heatmap zeigt, wo die Aufmerksamkeit in der Praxis liegt, nicht in der Theorie, und ein A/B-Test prüft, ob das Verschieben eines Elements über oder unter eine bestimmte Position das Verhalten wirklich verändert.

Sinnvoll ist außerdem, das Design auf echten Geräten zu testen und nicht nur in Browser-Emulatoren. Ein Emulator simuliert eine Bildschirmbreite, aber selten die tatsächliche Ladegeschwindigkeit im Mobilfunknetz, die Bedienung mit dem Daumen oder das Verhalten von Browserleisten, die sich beim Scrollen ein- und ausblenden. Wer Design- und SEO-Entscheidungen an einem einzigen Referenzgerät festmacht, egal ob das ein iPhone in der Schublade des Designers oder ein 27-Zoll-Monitor im Büro ist, überträgt genau den Fehler der frühen 2000er Jahre in eine neue technische Umgebung.

• Echte Geräte- und Viewport-Daten aus Google Search Console und der eigenen Analytics-Lösung prüfen, bevor man eine Standardbildschirmgröße annimmt.
• Die Inhaltshierarchie (Überschrift, Wertversprechen, Call-to-Action) flexibel definieren, nicht als feste Pixelblöcke.
• Das LCP-Element jeder wichtigen Vorlage identifizieren und optimieren, inklusive Ladezeit unter realen mobilen Netzbedingungen.
• Das Design in mehreren echten Viewport-Breiten testen, nicht nur auf dem Bildschirm des Designers.
• Heatmaps und A/B-Tests geräteweise segmentiert einsetzen, um zu prüfen, welcher Inhalt wirklich Aufmerksamkeit bekommt.

• Eine feste Pixelhöhe als Falzlinie definieren und den gesamten wichtigen Inhalt darauf zwängen, ohne zu beachten, dass diese Linie je nach Gerät variiert.
• Visuelle Klarheit für zu viele Elemente, Überschrift, Unterzeile, Formular, Banner, Menü, im ersten Bereich opfern.
• LCP mit allem, was above the fold liegt, verwechseln: LCP misst ein konkretes Element, nicht den gesamten Bereich.
• Nur an einem Desktop-Mockup mit 1440 Pixel gestalten und testen, ohne zu prüfen, wie derselbe Inhalt bei 360 Pixel oder auf einem Ultrawide-Monitor wirkt.
• Eine Annahme darüber, was der Nutzer zuerst sieht, für bare Münze nehmen, ohne sie mit Heatmap- oder Analytics-Daten abzugleichen.