Layout-Reflow ist einer der teuersten Vorgänge im Browser. Wenn man mit getBoundingClientRect() oder offsetHeight die Geometrie eines Elements abfragt, muss der Browser möglicherweise den gesamten Seitenbaum neu berechnen. Bei hunderten von Text-Elementen addiert sich dieser Overhead dramatisch. Pretext von Cheng Lou löst das radikal anders.
Das Problem: Forced Layout
Der Browser ist lazy. Er berechnet Layouts erst wenn er muss. Wenn JavaScript zwischen DOM-Mutationen und Layout-Queries wechselt, entsteht ein Muster das Performance-Experten "Forced Layout" oder "Layout Thrashing" nennen: Der Browser wird gezwungen, wieder und wieder komplett zu relayouten, bevor er irgendwas rendern kann.
Pretexts Ansatz: Prepare einmal, Layout immer
Das Design von Pretext ist konzeptuell elegant: Es teilt Text-Layout in zwei getrennte Phasen.
Phase 1: prepare()
Der prepare()-Schritt nutzt die Canvas-API einmalig um alle nötigen Font-Metriken zu sammeln. Die Canvas-Methode measureText() liefert präzise Informationen über Buchstabenbreiten, Kerning-Paare und Font-spezifische Masse. Diese werden gecacht. Kein DOM-Zugriff, kein Reflow. Dieser Schritt läuft einmal pro Font-Kombination.
Phase 2: layout()
Danach ist layout() reine Arithmetik. Gegeben: Text, verfügbare Breite, gecachte Font-Metriken. Gesucht: exakte Zeilenumbrüche, Zeilenhöhen, Gesamthöhe. Das sind Divisionen, Additionen, Vergleiche. Kein DOM, kein Canvas, kein Browser-API.
Warum Canvas statt DOM?
Die Canvas-API ist der einzige Browser-Mechanismus der präzise Font-Metriken liefert, ohne ein visuelles Layout auszulösen. CanvasRenderingContext2D.measureText() gibt ein TextMetrics-Objekt zurück mit Breite, Ascender, Descender und mehr. Der Canvas muss dafür nicht einmal im DOM sein, er kann vollständig off-screen bleiben.
Das ist die entscheidende Erkenntnis von Cheng Lou: Die Canvas-API wurde als Zeichen-Werkzeug konzipiert, ist aber als Mess-Werkzeug nutzbar. Mit dem richtigen Blickwinkel auf die Plattform verschwindet das Performance-Problem.
Grenzen und Tradeoffs
Pretext ist kein Allheilmittel. Der prepare()-Schritt kostet Zeit und muss bei neuen Font-Kombinationen wiederholt werden. Ausserdem müssen Entwickler selbst das Rendering übernehmen, sei es Canvas, SVG, WebGL oder DOM mit vorberechneten Positionen. Für einfache statische Webseiten ist das Overhead ohne Nutzen.
Für komplexe interaktive Anwendungen aber, für virtuelle Listen, für Echtzeit-Layout-Animationen, für Text-intensive Canvas-Anwendungen, ist die Investition klar lohnenswert. Die Editorial Engine Demo demonstriert 60fps Text-Reflow, der ohne Pretexts Ansatz schlicht nicht möglich wäre.
Fazit
Performance-Probleme löst man entweder durch schnellere Algorithmen oder indem man das Problem vollständig umgeht. Pretext geht den zweiten Weg. Es ist kein schnellerer DOM-Zugriff, es ist gar kein DOM-Zugriff mehr. Das ist die elegantere Lösung.