Browser-Rendering: Vom Text zum Bild

Der gezeichnete Bildschirm ist keine Zauberei

Als ich zum ersten Mal mit der Frontend-Entwicklung (Vue.js) begann, dachte ich, der Browser sei nur ein „Frame zum Anzeigen von Code“. Es war natürlich, dass bei Verwendung von

ein Quadrat erschien und bei Verwendung von color: red rot wurde.

Meine Meinung änderte sich jedoch, als ich in der Praxis das Stottern der Animation oder das Ruckeln des Bildschirms beim Scrollen (Ruckeln) erlebte. „Warum läuft derselbe Code in Chrome reibungslos, stürzt jedoch im Internet Explorer (IE) ab?“ „Warum schießt meine CPU in die Höhe, wenn ich den Stil mit JavaScript nur ein wenig ändere?“

Es stellt sich heraus, dass der Browser nicht nur ein Bilderrahmen ist. Der Browser war ein riesiger „Maler“ und „Architekt“, der den von uns gesendeten Text (HTML/CSS) interpretierte, jedes Pixel mathematisch berechnete und ausdruckte.

Letztes Mal haben wir Daten sicher über holprige Netzwerkstraßen übermittelt. Öffnen wir dieses Mal das angekommene Datenfeld (Paket) und finden wir heraus, wie der Browser ein Bild zeichnet, das als Bildschirm bezeichnet wird. Dies ist die letzte Geschichte der Serie Re: Booting CS Basics.

Der Browser ist eine Baustelle, auf der Code gelesen, erstellt und gemalt wird.

Fracht angekommen, Montage beginnt

In unserer Weltanschauung „Digitales Logistikzentrum“ ist das Produkt (HTML-Datei) nun beim Kunden zu Hause (Browser) angekommen. Was jedoch ankam, war kein fertiges Produkt, sondern eine „Montageanleitung“. Das Arbeitsteam namens Browser Engine (Rendering Engine) liest dieses Handbuch und beginnt sofort mit der Montage. Dieser Prozess wird als Rendering-Pipeline bezeichnet.

Schritt 1: Blueprint-Analyse (Parsing & DOM-Baum)

Liest den zuerst eintreffenden HTML-Text und erstellt ein „Skelett“.

  • <html> ist die Wurzel (Root), <body> der Stamm, <div> die Äste…
  • Diese so entstandene Baumstruktur (Tree) nennt man DOM (Document Object Model). Sie ist zugleich die API, über die JavaScript später auf dieses Skelett zugreifen kann.

Schritt 2: Innenarchitektur (CSSOM-Baum)

Lesen Sie dann die CSS-Datei und erstellen Sie „Stilregeln“.

  • „Jedes div ist rot“, „Elemente mit der Klasse box sind 100px groß“
  • Das nennt man CSSOM (CSS Object Model).

Schritt 3: Erstellen Sie einen Arbeitsauftrag (Render Tree)

Jetzt kombinieren wir das Skelett (DOM) und das Design (CSSOM). Der wichtige Punkt hierbei ist, dass nur „Dinge, die tatsächlich auf dem Bildschirm erscheinen“ ausgewählt werden.

  • Und Elemente mit der Eigenschaft display: none? Da sie ohnehin nicht auf dem Bildschirm erscheinen, werden sie aus dem Renderbaum ausgeschlossen. (Sie nehmen auch keinen Platz ein.)
  • Und visibility: hidden? Solche Elemente sind zwar unsichtbar, nehmen aber Platz ein und werden deshalb in den Renderbaum aufgenommen.
Der Renderbaum ist eine endgültige Liste nur derjenigen, die wirklich gezeichnet werden können.

[Codeüberprüfung] Reflow und Repaint

Jetzt kommt der wirklich wichtige Schritt. Hier liegt der Schlüssel zur Leistungsoptimierung. Sobald der Renderbaum erstellt ist, führt der Browser zwei schwere Aufgaben aus.

  1. Layout / Reflow: Berechnet mathematisch, „wo und in welcher Größe“ jedes Element platziert wird. (Bauplanung)
  2. Paint / Repaint: Trägt an den berechneten Positionen tatsächlich „die Farbe auf“. (Malerarbeiten)

Lassen Sie uns den Kostenunterschied mit dem Code spüren.

const box = document.getElementById('box');

// Case 1: Code, der Layout (Reflow) ausloest (teuer!)
// Wenn Groesse oder Position sich aendert, muessen umliegende Elemente neu berechnet werden.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Code, der nur Paint (Repaint) ausloest (vergleichsweise guenstig)
// Position bleibt gleich, nur die Farbe aendert sich. Keine Neuberechnung, nur Neuzeichnen.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Analyse:

  • Änderung von width: Das ist ein Umbau, der die Größe des Gebäudes verändert. Das Nachbargebäude wird verschoben, und dessen Nachbar ebenfalls. Der Browser muss alles noch einmal komplett durchrechnen. (Reflow wird ausgelöst -> Hauptursache für Leistungseinbußen)
  • Änderung von color: Die Größe des Gebäudes bleibt, wie sie ist; nur der Anstrich wird erneuert. Es muss nichts berechnet werden. (Repaint wird ausgelöst -> schnell)

In der Praxis treten die meisten Fälle von „stotternder Animation“ auf, weil Layouteigenschaften wie width, left und top in Echtzeit berührt werden. In diesem Fall ist eine Technik erforderlich, um die Layoutberechnung mithilfe von Eigenschaften wie transform.

zu überspringen

Praktische Ratschläge: Schikanieren Sie Ihren Browser nicht

Ich wusste das nicht, als ich auf dem College war, also habe ich das DOM zufällig mit JavaScript manipuliert. Indem ich die Anweisung for durchging, änderte ich die Größe und den Stil jedes Elements. Aus der Sicht des Browsers ist es, als würde man gefoltert, indem man ein Gebäude Dutzende Male pro Sekunde zerstört und wieder aufbaut.

Tipps zur Sicherstellung der Leistung:

  1. DOM-Änderungen bündeln und auf einmal ausführen: Ändern Sie Stile nicht einzeln, sondern legen Sie vorab eine class an und ändern Sie nur ein einziges Mal den className.
  2. Animationen der GPU überlassen: Verwenden Sie statt left und top lieber transform: translate(). Dann wird der Layoutschritt übersprungen, und die GPU übernimmt die Verarbeitung.
  3. Der Unterschied beim Ausblenden: Unterscheiden Sie bewusst zwischen display: none (nicht im Renderbaum), wenn ein Element ganz verschwinden soll, und visibility: hidden (im Renderbaum enthalten), wenn nur sein Platz frei bleiben soll.
Das Ändern der Position (Reflow) ist ein viel teurerer Vorgang als das Ändern der Farbe (Repaint).

Zum Ende von Serie 1: Mein CS neu gestartet

Mit diesem Artikel ist die [Re: Booting] CS Basics-Reihe zu Ende gegangen.

Wir gingen zusammen auf eine lange Reise.

  1. Sprache (Language): Der von Menschen geschriebene Code wurde in Maschinensprache übersetzt (Build),
  2. Speicher (Memory): bezog die Zimmer namens Stack und Heap,
  3. Prozess (OS): teilte sich mithilfe der Schattendoppelgänger-Technik namens Threads die CPU,
  4. Netzwerk (Network): wurde in Pakete zerlegt und legte holprige Straßen zurück
  5. Rendering: und erschien schließlich vor unseren Augen, als er auf den Maler namens Browser traf.

Anfangs war es nur Wissen, das ich auswendig lernte, um einen Job zu bekommen. Nachdem ich jedoch in der Praxis auf Fehler gestoßen war und noch einmal hinschaute, war CS (Computertechnik) kein toter Buchstabe, sondern eine solide Grundlage, die meinen Code stützte.

Die Fundamentarbeiten sind nun abgeschlossen. Es ist Zeit, Ihr eigenes Schloss auf festem Boden zu bauen. In der nächsten Serie [Monolith Builder] werde ich die Erstellung von Webanwendungen mit Spring Boot und Vue.js behandeln, die ich in der Praxis erlebt habe. Bitte freuen Sie sich auf den Prozess der Umsetzung der „Theorie“ in die „Praxis“.

Schreibe einen Kommentar