Browser-Rendering: Vom Text zum Bild

📖 10min read

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“.

Schritt 2: Innenarchitektur (CSSOM-Baum)

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

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.

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.

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:

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:

Das Ändern der Position (Reflow) ist ein viel teurerer Vorgang als das Ändern der Farbe (Repaint).

Abschlussserie 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.

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