Kategorieseiten mit hunderten Kacheln, Landingpages mit einem Dutzend Sektionen, Dokumentationsstrecken mit tausenden Zeilen: Auf solchen Seiten leistet der Browser Arbeit, die kein Mensch je zu sehen bekommt. Er berechnet Stile, bestimmt Positionen und zeichnet Inhalte, die vier Bildschirmhöhen unterhalb des Sichtfensters liegen. Die CSS-Eigenschaft content-visibility setzt genau hier an: Sie erlaubt dem Browser, das Rendering ganzer Teilbäume zu überspringen, solange sie für die Nutzung nicht relevant sind. Im Demo der Chrome-Dokumentation sank die Rendering-Zeit beim ersten Laden dadurch von 232 Millisekunden auf 30 Millisekunden (web.dev). Dieser Artikel erklärt die Mechanik dahinter, die vier Containment-Typen, die richtige Platzhalterhöhe gegen neue Layout-Sprünge – und die Stellen, an denen die Eigenschaft besser nichts zu suchen hat.
Warum lange Seiten Rendering-Arbeit verschwenden
Ein Browser baut jede Seite in klar getrennten Etappen auf: Er berechnet für jedes Element den zutreffenden Stil (Style), ermittelt Position und Größe jeder Box (Layout), füllt Pixel (Paint) und setzt die Ebenen zusammen (Composite). Der entscheidende Punkt: Diese Etappen laufen standardmäßig über das gesamte Dokument – auch über den Teil, der erst nach fünf Sekunden Scrollen erreichbar wäre. Bei einer Seite mit sechs gleichwertigen Sektionen, von denen anderthalb ins erste Bild passen, fällt so ein Vielfaches der eigentlich nötigen Arbeit an.
Diese Arbeit landet auf dem Main-Thread – demselben Strang, der auch Eingaben verarbeitet. Deshalb schlägt verschwendete Rendering-Arbeit doppelt zu: Sie verzögert den ersten sichtbaren Inhalt und macht die Seite in den ersten Sekunden träge. Wie groß der Unterschied zwischen leistungsstarker und schwacher Hardware ausfällt, zeigen die Felddaten deutlich. Der HTTP Archive Web Almanac 2025 weist aus, dass 62 Prozent der Seiten mobil einen guten LCP-Wert erreichen, am Desktop dagegen 74 Prozent (HTTP Archive Web Almanac 2025). Bei der Interaktionsmetrik INP ist der Abstand noch auffälliger: 77 Prozent gute Werte mobil gegenüber 97 Prozent am Desktop (HTTP Archive Web Almanac 2025).
Insgesamt erreichen laut derselben Auswertung 48 Prozent der mobilen und 56 Prozent der Desktop-Websites durchgängig gute Core Web Vitals (HTTP Archive Web Almanac 2025); mobil ist der Wert von 36 Prozent im Jahr 2023 über 44 Prozent im Jahr 2024 auf die aktuellen 48 Prozent gestiegen (HTTP Archive Web Almanac 2025). Der Abstand zwischen Desktop und Mobilgerät entsteht nicht durch langsamere Leitungen allein, sondern vor allem durch die deutlich knappere CPU-Leistung günstiger Geräte. Genau dort wirkt jede eingesparte Style- und Layout-Berechnung am stärksten – ein Kernthema der Optimierung für mobile Endgeräte.
Rendering ist nicht Laden
Was content-visibility dem Browser erlaubt
Die Eigenschaft kennt drei Werte. visible ist der Ausgangszustand und ändert nichts. hidden überspringt den Inhalt unabhängig davon, wo er sich befindet, und hält den Rendering-Zustand zwischengespeichert – nützlich für Tab-Panels oder Ansichten in Single-Page-Anwendungen, die später zurückkehren. auto ist der interessante Fall: Das Element erhält dauerhaft Layout-, Stil- und Paint-Containment und überspringt seinen Inhalt zusätzlich dann, wenn es für die Nutzung nicht relevant ist (MDN Web Docs).
/* Wiederholungs-Sektionen unterhalb des Sichtfensters */
.produkt-reihe,
.faq-block,
.artikel-abschnitt {
content-visibility: auto;
contain-intrinsic-size: auto 480px;
}
/* Vorgehaltene, aber nicht sichtbare Ansicht (z. B. Tab-Panel) */
.tab-panel[data-inaktiv] {
content-visibility: hidden;
}Der Effekt ist im Demo der Chrome-Dokumentation gut dokumentiert: Bei einem langen Reise-Blog fiel die Rendering-Zeit des ersten Ladevorgangs von 232 Millisekunden auf 30 Millisekunden (web.dev). Als Faustregel nennt dieselbe Quelle eine Reduktion von 50 Prozent oder mehr der Rendering-Kosten beim Laden für Seiten mit viel Inhalt unterhalb des Sichtfensters (web.dev). Für den Sonderfall content-visibility: hidden berichten Facebook-Entwickler laut derselben Dokumentation von einer Verbesserung der Navigationszeit von bis zu 250 Millisekunden beim Zurückspringen auf zwischengespeicherte Ansichten (web.dev).
| Aspekt | visible | auto | hidden |
|---|---|---|---|
| Rendering des Inhalts | durchgehend | nur wenn relevant für die Nutzung | übersprungen |
| Containment | keines | Layout, Stil, Paint (plus Größe, wenn übersprungen) | Layout, Stil, Paint, Größe |
| Seitensuche (Strg+F) | findet Inhalt | findet Inhalt | findet Inhalt nicht |
| Tab-Reihenfolge und Fokus | normal | normal | ausgenommen |
| Typischer Einsatz | Standard | lange Seiten mit Wiederholungs-Sektionen | vorgehaltene Ansichten, Tab-Panels |
Wann ein Element als relevant gilt, ist präzise definiert. Nach der Spezifikation trifft das zu, wenn seine Paint-Containment-Box den Viewport schneidet, wenn das Element oder sein Inhalt fokussiert ist, wenn es oder sein Inhalt ausgewählt ist oder wenn es in der Top-Layer liegt (W3C, CSS Containment Module Level 2). Browser arbeiten dabei zusätzlich mit einem Sicherheitsrand: Als Viewport gilt der sichtbare Bereich zuzüglich eines vom Browser gewählten Randes von rund 50 Prozent der Viewport-Abmessungen (MDN Web Docs). Dadurch wird der Inhalt bereits vorbereitet, bevor er tatsächlich ins Bild scrollt.
Ein Element gilt als relevant für die Nutzung, wenn es auf dem Bildschirm liegt, wenn es oder sein Inhalt fokussiert ist, wenn es oder sein Inhalt ausgewählt ist oder wenn es in der Top-Layer platziert wurde.
Die vier Containment-Typen und was sie zusichern
content-visibility ist kein isolierter Kniff, sondern die bequeme Oberfläche über einem älteren Mechanismus: der CSS-Eigenschaft contain. Containment ist eine Zusage der Autorin an den Browser – ein Versprechen, dass bestimmte Wechselwirkungen zwischen einem Element und dem Rest des Dokuments ausgeschlossen sind. Erst dieses Versprechen erlaubt es dem Browser, Arbeit auszulassen, ohne ein falsches Ergebnis zu riskieren. Die Eigenschaft contain ist seit März 2022 browserübergreifend verfügbar (MDN Web Docs).
layout
Das Innenleben des Elements bildet einen unabhängigen Formatierungskontext. Nichts von außen beeinflusst das Layout im Inneren und umgekehrt (MDN Web Docs). Der Browser muss bei einer Änderung im Inneren nur diese Box neu berechnen.
paint
Die Nachfahren zeichnen zu keinem Zeitpunkt außerhalb der Box-Grenzen; Überstehendes wird an der Border-Box beschnitten (MDN Web Docs). Liegt die Box außerhalb des Bildes, kann der Browser den gesamten Inhalt beim Zeichnen auslassen.
size
Die Größe der Box lässt sich bestimmen, ohne die Kinder anzusehen (W3C, CSS Containment Module Level 2). Ohne eine Angabe über contain-intrinsic-size fällt die Box dabei allerdings auf null zusammen.
style
Eigenschaften mit Fernwirkung – etwa CSS-Zähler und Quotes – bleiben auf den Teilbaum begrenzt (MDN Web Docs). Der Browser muss eine Änderung im Inneren nicht bis in andere Dokumentteile verfolgen.
Für die Praxis gibt es zwei Kurzformen: contain: content steht für Layout, Paint und Stil, contain: strict ergänzt zusätzlich das Größen-Containment (MDN Web Docs). content-visibility: auto entspricht im Grunde contain: content plus der Fähigkeit, das Zeichnen und die Treffererkennung auszulassen, sobald das Element nicht relevant ist. Wichtig zu wissen: Layout- und Paint-Containment machen das Element zum umschließenden Block für absolut und fest positionierte Nachfahren und erzeugen einen eigenen Stacking-Kontext (MDN Web Docs). Wer Containment einschaltet, verändert also mehr als nur die Rendering-Reihenfolge.
Containment ist ein Versprechen, kein Wunsch
contain-intrinsic-size: Platzhalter ohne neue Layout-Sprünge
Sobald ein Element seinen Inhalt überspringt, erhält es zusätzlich Größen-Containment – der Browser bestimmt seine Höhe also, ohne die Kinder anzusehen. Ohne weitere Angabe ist das Ergebnis eine Box mit der Höhe null (MDN Web Docs). Die Folgen sind unangenehm und leicht zu erkennen: Die Seite wird beim Laden kurz sehr kurz, die Scrollleiste springt beim Scrollen, und Anker-Navigation landet an der falschen Stelle. Genau deshalb gehört zu jedem content-visibility: auto eine Platzhalterhöhe.
/* Feste Schätzung: gleichartige Sektionen mit bekannter Höhe */
.produkt-reihe {
content-visibility: auto;
contain-intrinsic-size: 420px;
}
/* Gemerkte Größe: unterschiedlich hohe Sektionen */
.artikel-abschnitt {
content-visibility: auto;
contain-intrinsic-size: auto 480px;
}Die zweite Variante ist in den meisten Fällen die bessere. Mit dem Schlüsselwort auto vor der Länge merkt sich der Browser die zuletzt tatsächlich gerenderte Größe und verwendet diese anstelle der Schätzung, sobald das Element seinen Inhalt wieder überspringt (MDN Web Docs). Die angegebene Länge wirkt dann nur noch als Startwert für den ersten Durchlauf. Für lange Listen und endlos nachladende Seiten verbessert sich die Schätzung dadurch von selbst, je weiter der Nutzer scrollt. Die Eigenschaft contain-intrinsic-size ist seit September 2023 browserübergreifend verfügbar (MDN Web Docs).
Schlechte Schätzung erzeugt genau das Problem, das man vermeiden wollte
Abgrenzung: Lazy Loading, Code-Splitting und Containment
In Audits taucht regelmäßig die Annahme auf, Lazy Loading und content-visibility seien dasselbe in Grün. Das ist ein Missverständnis mit teuren Folgen, weil dann die falsche Maßnahme gegen ein Symptom gestellt wird. Die drei Techniken greifen an drei verschiedenen Kostenarten an und ersetzen einander nicht.
| Technik | Was wird gespart | Wirkt auf | Typischer Auslöser im Audit |
|---|---|---|---|
| Lazy Loading (Bilder, iframes) | Netzwerkanfragen und Bytes | Datenvolumen, Verbindungsauslastung | viele Bilder unterhalb des Sichtfensters |
| Code-Splitting | Parsen und Ausführen von JavaScript | Main-Thread-Blockade, INP | großes Bundle, lange Tasks |
| content-visibility | Style-, Layout- und Paint-Arbeit | Rendering-Zeit, erster Frame | lange Seite, viele Sektionen, hohe Knotenzahl |
| contain-intrinsic-size | Fehlende Höhe übersprungener Boxen | Scrollhöhe, Layout-Stabilität | springende Scrollleiste, verschobene Anker |
Am deutlichsten wird der Unterschied bei einer Seite, die bereits sauber Lazy Loading und Code-Splitting einsetzt und trotzdem träge wirkt: Die Bytes sind knapp, das Skript ist aufgeteilt – aber das Markup selbst ist lang, und der Browser muss trotzdem jede Kachel layouten. Umgekehrt hilft content-visibility wenig, wenn die eigentliche Bremse die Serverantwortzeit ist; dann sind Maßnahmen wie 103 Early Hints zur Nutzung der Serverdenkzeit die passendere Antwort. Welche Kostenart dominiert, entscheidet die Messung, nicht die Gewohnheit – der Ausgangspunkt jeder strukturierten Performance-Analyse.
Eng verwandt ist der Blick auf die reine Knotenzahl. Ein überfüllter Baum verteuert jede Style- und Layout-Berechnung, unabhängig von Containment; die Verschlankung des Document Object Model und der Einsatz von content-visibility ergänzen sich deshalb. Containment senkt die Kosten der Arbeit, die anfällt; eine kleinere Seite senkt die Menge der Arbeit selbst.
Scrollleiste, Seitensuche und Sprunganker
Der wichtigste Unterschied zwischen content-visibility: auto und klassischem Verstecken liegt in der Auffindbarkeit. Übersprungener Inhalt bleibt im Document Object Model und im Accessibility-Baum; er bleibt fokussierbar, selektierbar, in der regulären Tab-Reihenfolge und für die Seitensuche erreichbar (MDN Web Docs). Damit lässt sich Rendering-Arbeit sparen, ohne die Zugänglichkeit einzuschränken – ein entscheidender Unterschied zu display: none oder visibility: hidden.
- Seitensuche mit Strg+F findet Treffer in übersprungenen Sektionen und scrollt dorthin
- Tab-Navigation erreicht Links und Formularfelder in übersprungenen Bereichen
- Textauswahl über mehrere Sektionen hinweg funktioniert unverändert
- Screenreader lesen die Inhalte, weil sie im Accessibility-Baum verbleiben
- Fokus oder Auswahl machen ein Element sofort relevant und lösen das Rendering aus
Anders verhält sich content-visibility: hidden: Hier ist der Inhalt für Seitensuche, Tab-Reihenfolge und Auswahl nicht erreichbar, ähnlich wie bei display: none (MDN Web Docs). Für aufklappbare Bereiche, die auffindbar bleiben sollen, gibt es dafür ein passendes HTML-Gegenstück. Ein Element mit dem Attributwert until-found ist zunächst verborgen, bleibt aber für die Seitensuche und für Fragment-Navigation erreichbar; findet der Browser einen Treffer, löst er ein beforematch-Ereignis aus, entfernt das Attribut und scrollt zur Stelle (MDN Web Docs).
<section class="faq-antwort" hidden="until-found" id="versand">
<p>Diese Antwort bleibt für die Seitensuche auffindbar,
obwohl sie eingeklappt ist.</p>
</section>Sprunganker sauber halten
content-visibility: auto Ziel einer Ankernavigation sind, lohnt ein zweiter Blick auf die Sprungziele. Solange die Platzhalterhöhe grob stimmt, landet der Sprung an der richtigen Stelle; weicht sie stark ab, verschiebt sich das Ziel beim Rendern. Ein realistischer contain-intrinsic-size-Wert und ein passender scroll-margin-top unter einer klebenden Kopfzeile lösen die allermeisten dieser Fälle.Anti-Pattern: wo content-visibility schadet
Die Eigenschaft ist billig zu schreiben und teuer falsch einzusetzen. Ein pauschaler Selektor über alle Sektionen bringt in der Regel weniger als eine handvoll gezielter Regeln – und produziert Nebenwirkungen, die erst im Feld auffallen. Die folgenden Muster tauchen in Audits regelmäßig auf und sollten vermieden werden.
- Hero- und LCP-Container: Der Bereich im ersten Bild wird ohnehin gerendert. Containment bringt dort keinen Vorteil, kann den LCP-Kandidaten aber verzögern oder – bei falscher Platzhalterhöhe – verschieben.
- Pauschale Selektoren über den gesamten DOM: Regeln auf
*,divoder jedessectionerzeugen tausende Containment-Boxen. Die Buchführung darüber kostet selbst Zeit und kann die Rendering-Bilanz verschlechtern. - Elemente mit klebender Positionierung im Kontext: Layout- und Paint-Containment erzeugen einen neuen umschließenden Block und Stacking-Kontext. Ein
position: sticky-Element innerhalb einer solchen Box klebt danach an der Box, nicht am Viewport. - Container mit bewusst überstehendem Inhalt: Dropdowns, Tooltips, Schlagschatten oder überlappende Bildkanten werden durch Paint-Containment an der Border-Box beschnitten.
- Kurze Seiten ohne Inhalt unterhalb des Sichtfensters: Wenn fast alles im ersten Bild liegt, gibt es keine Arbeit zu überspringen. Der Aufwand steht dann in keinem Verhältnis zum Effekt.
- Sektionen ohne verlässliche Höhenschätzung: Ohne
contain-intrinsic-sizebeziehungsweise ohne denauto-Zusatz tauscht man Rendering-Zeit gegen springende Scrollleisten und instabiles Layout ein.
Selektiv schlägt flächendeckend
Richtig messen: Rendering-Zeit statt Score-Vergleich
Der häufigste Fehler bei der Bewertung ist der Blick auf eine einzelne zusammengefasste Kennzahl. Ein Performance-Score ist ein gewichteter Mittelwert mehrerer Metriken; er reagiert auf Netzwerk-Schwankungen, Drosselungseinstellungen und Zufall. Eine Änderung, die zwei Punkte kostet oder bringt, sagt über eingesparte Rendering-Arbeit wenig aus. Wer content-visibility bewerten will, misst die Arbeit selbst – und zwar im Performance-Panel der Entwicklerwerkzeuge.
- Referenzlauf aufzeichnen: identische Seite, identische Drosselung (CPU-Drosselung um Faktor 4 bis 6 für ein realistisches Mobilbild), Cache im gleichen Zustand.
- Im Zusammenfassungsbereich die Summen für Rendering und Painting ablesen – das sind die Posten, die Containment direkt beeinflusst.
- Die Einträge
Recalculate StyleundLayouteinzeln betrachten: Anzahl der betroffenen Elemente und Dauer je Vorgang sind aussagekräftiger als die Gesamtsumme. - Regel setzen, Lauf wiederholen, Differenz notieren – dieselbe Seite, dieselben Bedingungen, mindestens drei Läufe je Variante wegen der Streuung.
- Gegenprobe auf Stabilität: Scrollleiste beobachten, Anker anspringen, Seitensuche testen, Sticky-Elemente und überstehende Inhalte prüfen.
- Nach dem Ausrollen die Felddaten beobachten, denn das Labor bildet die Gerätevielfalt der echten Nutzung nur begrenzt ab.
Diese Reihenfolge verhindert die typische Fehlinterpretation, bei der eine Maßnahme wegen eines schwankenden Scores verworfen oder gefeiert wird. Wie sich Laborwerte und Felddaten zueinander verhalten, behandelt der Beitrag zu Real User Monitoring gegenüber CrUX-Felddaten; wie ein Bericht strukturiert gelesen und priorisiert wird, zeigt der Leitfaden zum Lighthouse-Bericht. Für eine methodisch saubere Ausgangsmessung nutzen wir das Lighthouse-Audit mit Performance-Report.
Warum die Wirkung auf schwachen Mobilgeräten am größten ist
Style- und Layout-Berechnung ist reine CPU-Arbeit. Ein aktuelles Notebook erledigt sie so schnell, dass eine Ersparnis von 200 Millisekunden Rendering-Zeit im Labor kaum auffällt. Auf einem Mittelklasse-Telefon mit deutlich niedrigerer Single-Core-Leistung wird aus derselben Arbeit ein Vielfaches. Genau deshalb ist der Unterschied zwischen Labor und Feld bei Rendering-Maßnahmen besonders groß – und genau deshalb schlägt der Effekt in den mobilen Felddaten stärker durch als in jedem Desktop-Test.
Die Zahlen des HTTP Archive Web Almanac 2025 stützen das: Beim INP liegt der Anteil guter Werte mobil bei 77 Prozent gegenüber 97 Prozent am Desktop; der Abstand ist von 23 Prozentpunkten im Jahr 2024 auf 20 Prozentpunkte im Jahr 2025 geschrumpft, bleibt aber deutlich (HTTP Archive Web Almanac 2025). Beim LCP stehen mobil 62 Prozent guter Werte 74 Prozent am Desktop gegenüber, und der Anteil schlechter Erlebnisse ist mobil mit 13 Prozent gegenüber 7 Prozent fast doppelt so hoch (HTTP Archive Web Almanac 2025).
Das Zusammenspiel mit den Core Web Vitals
Vorgehen: messen, selektiv einsetzen, im Feld kontrollieren
In Projekten hat sich ein dreistufiges Vorgehen bewährt, das ohne Umbau der Vorlagen auskommt. Zuerst die Bestandsaufnahme: Welche Vorlagen sind lang genug, dass sich das Überspringen lohnt? In der Regel sind das Kategorie- und Suchergebnisseiten, lange Landingpages, Dokumentations- und Wissensstrecken sowie Blog-Übersichten. Dann die Messung der Rendering- und Painting-Summen je Vorlage unter Drosselung. Erst danach der selektive Einsatz auf den Wiederholungs-Sektionen, begleitet von einer visuellen Kontrolle.
Ein typisches Muster aus der Praxis: Eine Kategorieseite mit 96 Kacheln in vier Reihenblöcken weist unter vierfacher CPU-Drosselung rund 410 Millisekunden Rendering- und Painting-Arbeit beim ersten Laden aus. Nach dem Setzen von content-visibility: auto mit contain-intrinsic-size: auto 460px auf die Reihenblöcke unterhalb des Sichtfensters fällt der Wert auf rund 190 Millisekunden, ohne dass eine Kachel entfernt oder eine Funktion beschnitten wird (Projekterfahrung). Die Scrollhöhe bleibt stabil, weil die Platzhalterhöhe aus dem Median der gerenderten Reihenhöhe abgeleitet wurde. Solche Ausgangslagen begegnen uns quer durch Vorlagen und Branchen, unter anderem in der Shopware-Performance-Optimierung.
- Wiederholungs-Sektionen identifizieren, statt Regeln über den gesamten DOM zu streuen
- Hero- und LCP-Container ausdrücklich ausnehmen
- Platzhalterhöhe je Sektionstyp aus gemessenen Höhen ableiten,
auto-Zusatz bevorzugen - Sticky-Elemente, Dropdowns, Tooltips und überstehende Bildkanten gegenprüfen
- Seitensuche, Tab-Reihenfolge und Ankernavigation nach der Änderung testen
- Rendering- und Painting-Summen vor und nach der Änderung unter identischer Drosselung vergleichen
- Feldwerte für LCP, INP und CLS über mehrere Wochen beobachten, bevor die Regel ausgeweitet wird
Ein letzter Punkt betrifft die Dauerhaftigkeit. Vorlagen wachsen, Sektionen werden verschoben, neue Module kommen hinzu – und eine einmal passende Platzhalterhöhe stimmt nach einem Redesign womöglich nicht mehr. Deshalb gehört die Kontrolle der Rendering-Summen in dieselbe Routine wie die Überwachung der Bundle-Größe. Wer zusätzlich die Kosten eingebundener Drittsysteme im Blick behält – etwa den Einfluss von Consent-Bannern auf den LCP –, hält die Rendering-Bilanz einer langen Seite über Releases hinweg stabil.
Wir analysieren lange Katalog-, Listen- und Landingpage-Vorlagen auf ihre tatsächliche Rendering-Last, setzen content-visibility und Containment gezielt dort ein, wo sie wirken, sichern die Platzhalterhöhen gegen neue Layout-Sprünge ab und kontrollieren das Ergebnis in den Felddaten. Einen Überblick über das gesamte Leistungsbild gibt die Seite zu unseren Performance-Leistungen; für die konkrete Umsetzung am Frontend führt der Weg über die Frontend-Optimierung mit Analyse, Umsetzung und Nachmessung.
Quellen und Studien
auto erhält das Element Layout-, Stil- und Paint-Containment und überspringt Style-, Layout- und Paint-Arbeit, wenn es außerhalb des sichtbaren Bereichs liegt (MDN Web Docs). Im Demo der Chrome-Dokumentation sank die Rendering-Zeit beim ersten Laden dadurch von 232 auf 30 Millisekunden (web.dev).contain-intrinsic-size liefert eine Platzhalterhöhe; die Schreibweise mit vorangestelltem auto lässt den Browser die zuletzt gerenderte Größe merken und verbessert die Schätzung im Verlauf des Scrollens von selbst.content-visibility: auto ja. Der übersprungene Inhalt bleibt im Document Object Model und im Accessibility-Baum, bleibt fokussierbar, selektierbar, in der Tab-Reihenfolge und für die Seitensuche erreichbar (MDN Web Docs). Bei content-visibility: hidden gilt das nicht – dort verhält sich der Inhalt ähnlich wie bei display: none. Für eingeklappte, aber auffindbare Bereiche eignet sich das HTML-Attribut mit dem Wert until-found.position: sticky am Viewport kleben soll oder in denen Inhalte bewusst über die Kante ragen, da Layout- und Paint-Containment einen neuen umschließenden Block bilden und den Überstand beschneiden.Recalculate Style und Layout vor und nach der Änderung vergleichen – unter identischer CPU-Drosselung und über mehrere Läufe. Anschließend gehört die Bestätigung in die Felddaten, weil sich der Effekt auf leistungsschwächeren Mobilgeräten deutlicher zeigt als im Labor.