CSS-Tricks für lange Tabellen: Sticky Header und Sticky Spalten

1. Warum lange Tabellen ohne sticky Header und Spalten schnell unlesbar werden

Eine Tabelle mit hunderten Zeilen verliert ihre Kopfzeile aus dem Blickfeld, sobald der Nutzer weiter nach unten scrollt, und damit auch die Information, welche Spalte welchen Wert enthält. Bei sehr breiten Tabellen mit horizontalem Scrollen passiert dasselbe mit der ersten Spalte, die meist den identifizierenden Wert einer Zeile trägt, etwa eine Bestellnummer oder einen Produktnamen: Ohne sie verliert jede Zahl weiter rechts ihren Bezug.

Beide Probleme lassen sich mit position: sticky lösen, ohne JavaScript, ohne eine zweite, künstlich synchronisierte Kopie der Kopfzeile und ohne die semantische Tabellenstruktur zu verlassen. Die Herausforderung liegt weniger im grundsätzlichen Einsatz von sticky, sondern in der Kombination aus beiden Achsen gleichzeitig, dem korrekten Scroll-Container und den Z-Index-Konflikten, die genau an der Überschneidung von fixierter Zeile und fixierter Spalte entstehen.

2. position: sticky für die Kopfzeile: Grundlagen und Voraussetzungen

position: sticky auf einer Kopfzeile funktioniert, indem top: 0 gesetzt wird und das Element innerhalb seines nächsten scrollenden Vorfahren so lange normal mitscrollt, bis es an dieser Position ankommt, und dann dort verharrt. Bei HTML-Tabellen wird die Eigenschaft typischerweise auf thead th gesetzt, wobei zu beachten ist, dass sticky auf thead selbst in manchen älteren Browser-Engines nicht zuverlässig funktioniert und die robustere Variante ist, die Eigenschaft auf die einzelnen th-Zellen zu setzen.

Voraussetzung für funktionierendes sticky ist außerdem, dass kein Vorfahre-Element overflow: hidden auf einer Achse setzt, die das sticky Element betreffen würde, und dass der scrollende Container selbst eine definierte Höhe mit overflow-y: auto hat. Fehlt eine dieser Voraussetzungen, verhält sich sticky optisch wie static, ohne dass ein offensichtlicher Fehler in der Konsole erscheint, was diesen Fehler in der Praxis besonders schwer zu debuggen macht.

.table-scroll {
  max-height: 480px;
  overflow-y: auto;
  overflow-x: auto;
}

thead th {
  position: sticky;
  top: 0;
  background-color: #0f172a;
  color: #fff;
  z-index: 2;
}

3. position: sticky für die erste Spalte: derselbe Trick, andere Achse

Derselbe Mechanismus funktioniert auf der horizontalen Achse für die erste Spalte, nur dass hier left: 0 statt top: 0 gesetzt wird und der relevante Scroll-Container horizontal scrollbar sein muss. Jede Zelle der ersten Spalte, also sowohl th als auch td, bekommt position: sticky; left: 0;, wodurch sie an ihrer linken Position verharrt, während der Rest der Zeile horizontal darunter wegscrollt.

Ein wichtiger Unterschied zur sticky Kopfzeile ist, dass die erste Spalte zwingend einen deckenden Hintergrund braucht, weil sie sonst durchsichtig über den nachfolgenden Spalten schwebt und deren Inhalt durchscheint, sobald horizontal gescrollt wird. Ohne expliziten background-color auf jeder sticky Zelle sieht die fixierte Spalte visuell verschoben oder überlagert aus, sobald Inhalte darunter vorbeiscrollen.

tbody td:first-child,
thead th:first-child {
  position: sticky;
  left: 0;
  background-color: #ffffff;
  z-index: 1;
}

thead th:first-child {
  background-color: #0f172a;
  color: #fff;
}

4. Sticky Header UND sticky erste Spalte gleichzeitig kombinieren

Werden beide Techniken kombiniert, entsteht die Zelle oben links, also der Schnittpunkt aus fixierter Kopfzeile und fixierter erster Spalte, an der beide sticky-Regeln gleichzeitig gelten. Diese eine Zelle braucht deshalb sowohl top: 0 als auch left: 0 und muss zusätzlich über einen höheren z-index verfügen als die übrigen sticky Elemente, weil sie sowohl über der restlichen Kopfzeile als auch über der restlichen ersten Spalte sichtbar bleiben muss.

In der Praxis definiert man diese Ecke am besten als eigene, spezifischere Selektor-Regel, etwa thead th:first-child, statt sich auf die Kombination der beiden allgemeineren Regeln zu verlassen. So bleibt explizit klar, dass diese eine Zelle einen Sonderfall darstellt, und die Reihenfolge der CSS-Regeln im Stylesheet spielt für die korrekte Darstellung keine Rolle mehr.

/* Sticky header row */
thead th {
  position: sticky;
  top: 0;
  z-index: 2;
  background-color: #0f172a;
  color: #fff;
}

/* Sticky first column */
tbody td:first-child,
thead th:first-child {
  position: sticky;
  left: 0;
  z-index: 1;
  background-color: #ffffff;
}

/* Top-left corner: sticky on BOTH axes, needs the highest z-index */
thead th:first-child {
  z-index: 3;
  background-color: #0f172a;
  color: #fff;
}

5. Der Z-Index-Fallstrick an der Überschneidung von Zeile und Spalte

Der klassische Fallstrick entsteht, wenn die drei betroffenen Ebenen, normale Kopfzeile, normale erste Spalte und die gemeinsame Ecke, keine klar gestaffelten Z-Index-Werte bekommen. Ohne diese Staffelung überlagert beim Scrollen mal die Kopfzeile die erste Spalte und mal umgekehrt, je nachdem, welches Element im DOM später steht und welchen Stacking Context der Browser zuletzt aktualisiert hat, was zu einem sichtbar flackernden oder inkonsistenten Ergebnis führt.

Die zuverlässige Lösung ist eine bewusste, dokumentierte Rangfolge: die gemeinsame Ecke bekommt den höchsten Wert, die Kopfzeile den zweithöchsten, die erste Spalte den niedrigsten der drei sticky Ebenen, und alle übrigen Tabelleninhalte bleiben ohne expliziten z-index. Diese Rangfolge sollte in einem Kommentar im Stylesheet festgehalten werden, weil sie sich sonst bei künftigen Änderungen leicht unbeabsichtigt verschiebt.

/* z-index ranking for sticky table cells, from lowest to highest:
   1 = sticky first column
   2 = sticky header row
   3 = sticky top-left corner cell
   Do not change this order without checking all three overlaps. */
tbody td:first-child { z-index: 1; }
thead th { z-index: 2; }
thead th:first-child { z-index: 3; }

6. Stacking Contexts verstehen: warum z-index manchmal einfach nicht wirkt

Manchmal wirkt ein gesetzter z-index trotz korrekter Werte nicht wie erwartet, und die Ursache liegt fast immer in einem übergeordneten Stacking Context. Jedes Element, das etwa transform, filter, opacity kleiner als 1 oder selbst position mit einem z-index-Wert gesetzt hat, eröffnet einen neuen Stacking Context, innerhalb dessen alle z-index-Werte der Kind-Elemente nur relativ zueinander gelten, nicht relativ zum gesamten Dokument.

Für sticky Tabellen bedeutet das konkret: Wenn ein Wrapper-Element um die Tabelle versehentlich eine dieser Eigenschaften trägt, etwa weil eine Karten-Komponente standardmäßig transform für Hover-Effekte nutzt, können die intern korrekt gestaffelten z-index-Werte der sticky Zellen nicht mehr über Elemente außerhalb dieses Wrappers hinausragen. Die Fehlersuche sollte deshalb immer bei den Vorfahren beginnen, nicht nur bei der Tabelle selbst.

7. Performance bei sehr langen Tabellen: was sticky wirklich kostet

position: sticky selbst ist performant, weil der Browser die Positionierung während des Layouts berechnet und beim eigentlichen Scrollen nur noch das Compositing aktualisieren muss, ohne für jeden Scroll-Frame ein komplettes Reflow auszulösen. Der eigentliche Performance-Engpass bei sehr langen Tabellen mit tausenden Zeilen liegt fast nie am sticky-Mechanismus selbst, sondern daran, dass der Browser jede einzelne Zeile im DOM vorhält und für jede sticky Zelle einen eigenen Compositing-Layer verwalten muss.

Bei Tabellen mit mehreren tausend Zeilen lohnt es sich deshalb weniger, an den sticky Regeln selbst zu optimieren, sondern eher, Virtualisierung einzusetzen, also nur die im sichtbaren Bereich befindlichen Zeilen tatsächlich zu rendern und den Rest durch Platzhalter-Höhe zu ersetzen. Für die meisten praktischen Anwendungsfälle mit einigen hundert Zeilen reicht reines CSS sticky jedoch völlig aus, ohne dass Virtualisierung überhaupt nötig wird.

8. Der richtige Scroll-Container: overflow, table-layout und Breiten-Fallstricke

Der Scroll-Container, der overflow: auto trägt, muss exakt der nächste scrollende Vorfahre der sticky Elemente sein, denn sticky bezieht sich immer auf diesen Container, nicht auf den Viewport, sobald ein solcher Vorfahre mit definiertem overflow existiert. Wird die Tabelle stattdessen direkt im normalen Seitenfluss ohne eigenen Scroll-Container gerendert, bezieht sich sticky automatisch auf den gesamten Viewport, was für sehr lange Seiten mit vielen anderen Inhalten oft ein unerwünschtes Verhalten ist.

Zusätzlich sollte table-layout: fixed zusammen mit explizit gesetzten Spaltenbreiten erwogen werden, weil der Browser bei table-layout: auto die endgültigen Spaltenbreiten erst nach dem Einlesen des gesamten Tabelleninhalts berechnet, was bei sehr langen Tabellen zu spürbaren Verzögerungen und zu einem sichtbaren Neuberechnen der sticky Spaltenbreite während des Ladens führen kann.

.table-scroll {
  max-height: 480px;
  overflow: auto;
}

table {
  table-layout: fixed;
  border-collapse: separate;
  border-spacing: 0;
  width: 100%;
}

th:first-child,
td:first-child {
  width: 180px;
}

9. Checkliste für robuste Sticky-Tabellen

Eine robuste Sticky-Tabelle braucht am Ende vier zusammenhängende Bausteine: einen klar definierten Scroll-Container mit overflow: auto und fester Höhe, deckende Hintergrundfarben auf jeder sticky Zelle, eine dokumentierte Z-Index-Rangfolge für die drei betroffenen Ebenen, und die Vermeidung von Stacking-Context-erzeugenden Eigenschaften auf Vorfahren, die versehentlich die interne Rangfolge durchbrechen könnten.

Werden diese vier Punkte von Anfang an berücksichtigt, lässt sich eine lange, breite Tabelle mit sticky Header und sticky erster Spalte allein mit CSS umsetzen, ohne JavaScript-Bibliotheken für virtualisiertes Scrollen oder eine künstlich synchronisierte zweite Kopfzeile. Erst bei mehreren tausend Zeilen wird eine zusätzliche Virtualisierungsstrategie relevant, für die überwiegende Mehrheit praktischer Tabellen reicht der reine CSS-Ansatz vollständig aus.

10. Zusammenfassung

11. FAQ: Sticky Header und Spalten in langen Tabellen: Das Wichtigste auf einen Blick