Rendering-Leistung

Seiten sollten nicht nur schnell geladen werden, sondern auch reibungslos funktionieren; das Scrollen sollte so schnell wie eine Fingerbewegung sein, und Animationen und Interaktionen sollten so reibungslos wie Seide sein.

Derzeit beträgt die Bildschirmaktualisierungsrate der meisten Geräte 60 mal/ Sekunden. Wenn die Seite also eine Animation oder einen Farbverlaufseffekt enthält oder der Benutzer einen Bildlauf auf der Seite durchführt, muss die Geschwindigkeit, mit der der Browser jeden Frame der Animation oder Seite rendert, mit der Aktualisierungsrate des Gerätebildschirms übereinstimmen.

Die budgetierte Zeit für jeden Frame beträgt etwas mehr als 16 Millisekunden (1 Sekunde / 60 = 16,66 Millisekunden). Aber in Wirklichkeit muss der Browser einige Aufräumarbeiten erledigen, sodass die gesamte Arbeit innerhalb von 10 Millisekunden erledigt sein muss. Wenn dieses Budget nicht eingehalten werden kann, sinken die Frameraten und die Inhalte ruckeln auf dem Bildschirm. Dieses Phänomen wird oft als Jank (Jank) bezeichnet und wirkt sich negativ auf das Benutzererlebnis aus.

Es gibt fünf Hauptbereiche, die Sie bei Ihrer Arbeit kennen und beachten sollten. Dies sind die Teile, die die meiste Kontrolle haben und Schlüsselpunkte in der Pixel-zu-Bildschirm-Pipeline sind:

• JavaScript. Im Allgemeinen wird JavaScript verwendet, um einige visuelle Änderungen zu erzielen. Verwenden Sie beispielsweise die Animationsfunktion von jQuery, um eine Animation zu erstellen, einen Datensatz zu sortieren oder der Seite einige DOM-Elemente hinzuzufügen. Neben JavaScript gibt es noch andere gängige Methoden zum Erzielen visueller Änderungen, z. B. CSS-Animationen, Übergänge und die Webanimations-API.

• StilberechnungenSytle-Berechnungen. Dabei wird anhand passender Selektoren ermittelt, welche CSS-Regeln für welche Elemente gelten, z. B. .headline oder .nav > Sobald die Regeln bekannt sind, werden sie angewendet und die endgültigen Stile für jedes Element festgelegt werden berechnet.

• Layout. Nachdem bekannt ist, welche Regeln für ein Element gelten, kann der Browser damit beginnen, zu berechnen, wie viel Platz es einnehmen wird und welche Position es auf dem Bildschirm hat. Der Layoutmodus einer Webseite bedeutet, dass sich ein Element auf andere Elemente auswirken kann. Beispielsweise wirkt sich die Breite des -Elements im Allgemeinen auf die Breite seiner untergeordneten Elemente und Knoten überall im Baum aus Prozess kommt häufig vor.

• Zeichnen . Beim Zeichnen werden Pixel ausgefüllt. Dabei geht es um das Zeichnen von Text, Farben, Bildern, Rändern und Schatten, einschließlich aller sichtbaren Teile eines Elements. Das Zeichnen erfolgt normalerweise auf mehreren Oberflächen (oft als Ebenen bezeichnet).

• Synthetisieren. Da Teile der Seite möglicherweise auf mehreren Ebenen gezeichnet werden, müssen sie in der richtigen Reihenfolge auf dem Bildschirm gezeichnet werden, damit die Seite korrekt gerendert wird. Dies ist besonders wichtig für Elemente, die ein anderes Element überlappen, da ein Fehler dazu führen kann, dass ein Element falsch über einem anderen angezeigt wird.

Jeder Teil der Pipeline kann zu Verzögerungen führen. Daher ist es wichtig, genau zu wissen, welche Teile der Pipeline Ihr Code auslöst.

Nicht jeder Frame durchläuft immer jeden Teil der Pipeline. Unabhängig davon, ob Sie JavaScript, CSS oder Webanimationen verwenden, gibt es normalerweise drei Möglichkeiten, die Pipeline für einen bestimmten Frame auszuführen:

1 > Zeichnen > Synthese

Wenn Sie das „Layout“-Attribut eines Elements ändern, d. h. die geometrischen Eigenschaften des Elements (wie Breite, Höhe, usw.), dann muss der Browser alle anderen Elemente überprüfen und dann automatisch „die Seite umfließen“ lassen. Alle betroffenen Teile müssen neu lackiert werden und die endgültig lackierten Elemente müssen zusammengesetzt werden.

2. JS/CSS > Compositing

Textfarbe oder -schatten usw.), d. h. Eigenschaften, die sich nicht auf das Layout der Seite auswirken, überspringt der Browser das Layout, führt aber dennoch das Zeichnen aus.

Wenn Sie eine Eigenschaft ändern, die weder Relayout noch Repaint erfordert, erfolgt nur Compositing durchgeführt. Dieser letzte Ansatz verursacht den geringsten Overhead und eignet sich am besten für stark beanspruchte Punkte im Anwendungslebenszyklus, wie z. B. Animationen oder Scrollen.

Leistung ist die Kunst, die Ausführung zu vermeiden

JavaScript-Ausführung optimieren

JavaScript-Leistungsanalyse kann als eine Kunst bezeichnet werden, da der von Ihnen geschriebene JavaScript-Code nichts mit dem Code zu tun hat, der tatsächlich ausgeführt wird. Moderne Browser nutzen JIT-Compiler und eine Vielzahl von Optimierungen und Tricks, um eine möglichst schnelle Ausführung zu erreichen, was die Dynamik des Codes stark verändert.

Einige Dinge, die Ihrer Anwendung helfen, JavaScript gut auszuführen:

• Vermeiden Sie für Animationseffekte die Verwendung von setTimeout oder setInterval und verwenden Sie requestAnimationFrame.

• Verschieben Sie lang laufendes JavaScript vom Hauptthread in einen Web Worker.

• Verwenden Sie kleine Aufgaben, um DOM-Änderungen über mehrere Frames hinweg durchzuführen.

• Verwenden Sie die Zeitleiste und den JavaScript-Profiler von Chrome DevTools, um die Auswirkungen von JavaScript zu bewerten.

Wenn auf dem Bildschirm visuelle Änderungen vorgenommen werden, ist es am besten, Vorgänge am Anfang des Frames auszuführen . Die einzige Möglichkeit, sicherzustellen, dass JavaScript am Anfang eines Frames ausgeführt wird, ist die Verwendung von requestAnimationFrame.

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame. */function updateScreen(time) {  // Make visual updates here.}
requestAnimationFrame(updateScreen);

Ein Framework oder Beispiel kann setTimeout oder setInterval verwenden, um visuelle Änderungen wie Animationen durchzuführen, aber das Problem bei diesem Ansatz besteht darin, dass die Callback-Funktion an einem bestimmten Punkt aufgerufen wird Der Frame Der Lauf befindet sich möglicherweise direkt am Ende des Frames, was häufig dazu führt, dass wir Frames auslassen, was zu Verzögerungen führt. (Das Ausführen von JS wie Composite nimmt Zeit in Anspruch und blockiert Aktualisierungen der Benutzeroberfläche.)

Tatsächlich ist das aktuelle Standardanimationsverhalten von jQuery die Verwendung von setTimeout. Es wird dringend empfohlen, einen Patch für die Verwendung von requestAnimationFrame durchzuführen.

JavaScript wird im Hauptthread des Browsers ausgeführt, zusammen mit Stilberechnungen, Layout und in vielen Fällen Zeichnungen. Wenn JavaScript zu lange ausgeführt wird, blockiert es diese andere Arbeit, was möglicherweise zu ausgelassenen Frames führt.

Überlegen Sie also gut, wann und wie lange Ihr JavaScript ausgeführt wird. Wenn Sie beispielsweise eine Animation wie Scrollen ausführen, ist es am besten, eine Möglichkeit zu finden, das JavaScript im Bereich von 3-4 ms zu halten. Alles darüber hinaus kann zu viel Zeit in Anspruch nehmen. Wenn Sie frei sind, müssen Sie sich nicht so viele Gedanken über die Zeit machen.

In vielen Fällen ist es möglich, reine Rechenarbeit auf einen Web Worker zu verlagern, der z. B. keinen DOM-Zugriff, keine Datenmanipulation oder Durchquerung (wie Sortieren oder Suchen) erfordert, was in der Regel gut geeignet ist Dieses Modell, Laden und Modellieren. Das Gleiche gilt für die Generierung.

var dataSortWorker = new Worker("sort-worker.js?1.1.11");
dataSortWorker.postMesssage(dataToSort);// The main thread is now free to continue working on other things...dataSortWorker.addEventListener('message', function(evt) {   var sortedData = evt.data;   // Update data on screen...});

Nicht alle Jobs sind für dieses Modell geeignet: Web Worker haben keinen DOM-Zugriff. Wenn der Vorgang im Hauptthread ausgeführt werden muss, sollten Sie einen Batch-Ansatz in Betracht ziehen, der die große Aufgabe in kleinere Aufgaben aufteilt, die jeweils nicht länger als ein paar Millisekunden dauern und innerhalb des requestAnimationFrame-Handlers für jeden Frame ausgeführt werden.

var taskList = breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);function processTaskList(taskStartTime) {  var taskFinishTime;  do {// Assume the next task is pushed onto a stack.var nextTask = taskList.pop();// Process nextTask.    processTask(nextTask);// Go again if there’s enough time to do the next task.taskFinishTime = window.performance.now();
  } while (taskFinishTime - taskStartTime < 3);  if (taskList.length > 0)
    requestAnimationFrame(processTaskList);
}

Dieser Ansatz hat Konsequenzen für UX und UI. Sie müssen einen Fortschritts- oder Aktivitätsindikator verwenden, um sicherzustellen, dass der Benutzer weiß, dass die Aufgabe verarbeitet wird. Diese Methode bindet unter keinen Umständen den Haupt-Thread der Anwendung und hilft dem Haupt-Thread, stets schnell auf Benutzerinteraktionen zu reagieren.

Bewerten Sie beim Evaluieren eines Frameworks, einer Bibliothek oder Ihres eigenen Codes unbedingt den Overhead, der durch die Ausführung von JavaScript-Code auf Frame-für-Frame-Basis entsteht. Dies ist besonders wichtig, wenn leistungskritische Animationsarbeiten wie Transformationen oder Scrolls ausgeführt werden.

Der beste Weg, den JavaScript-Overhead und die Leistung zu messen, ist die Verwendung von Chrome DevTools. Normalerweise erhalten Sie einen einfachen Datensatz wie diesen:

Der Hauptabschnitt enthält ein Flammendiagramm der JavaScript-Aufrufe, sodass Sie genau analysieren können, welche Funktionen wie lange aufgerufen wurden

Wenn Sie JavaScript mit langer Laufzeit finden, können Sie den JavaScript-Analysator oben auf der DevTools-Benutzeroberfläche aktivieren:

In Auf diese Weise ist die Profilerstellung für JavaScript mit einem Mehraufwand verbunden. Aktivieren Sie sie daher nur, wenn Sie ein tieferes Verständnis der JavaScript-Laufzeitfunktionen wünschen. Wenn dieses Kontrollkästchen aktiviert ist, können Sie jetzt dasselbe tun und erhalten weitere Informationen darüber, welche Funktionen in JavaScript aufgerufen werden:

Mit diesen Informationen können Sie die Auswirkungen bewerten von JavaScript auf die Anwendungsleistung und beginnen, Hotspots zu identifizieren und zu korrigieren, bei denen die Ausführung von Funktionen zu lange dauert. Wie bereits erwähnt, sollten Sie versuchen, lang laufendes JavaScript zu entfernen. Wenn dies nicht möglich ist, verschieben Sie es in einen Web Worker, um den Hauptthread für die Ausführung anderer Aufgaben freizugeben.

Es könnte cool sein zu wissen, dass der Browser eine Version einer Funktion 100-mal schneller ausführt als eine andere, z. B. das Anfordern des OffsetTop von Ein Element als die Berechnung von getBoundingClientRect() ist schnell, aber die Häufigkeit, mit der Sie eine solche Funktion pro Frame aufrufen, ist fast immer sehr gering. Daher ist es oft vergebliche Mühe, sich auf diesen Aspekt der JavaScript-Leistung zu konzentrieren. Normalerweise sparen Sie nur ein paar Zehntel einer Millisekunde.

Wenn Sie ein Spiel oder eine rechenintensive Anwendung entwickeln, stellen Sie möglicherweise eine Ausnahme von diesem Leitfaden dar, da Sie normalerweise viele Berechnungen in einem einzigen Rahmen unterbringen. In diesem Fall sind verschiedene Methoden sehr nützlich.

Kurz gesagt: Verwenden Sie Mikrooptimierungen mit Vorsicht, da sie oft nicht auf die Art der App abgestimmt sind, die Sie erstellen. Gemäß der 2/8-Regel beginnen Sie mit der Optimierung zuerst am Engpass.

Einschränken des Umfangs und der Komplexität von Stilberechnungen

Ändern des DOM durch Hinzufügen und Entfernen von Elementen, Ändern von Attributen, Klassen oder durch Animationen führt dazu, dass der Browser die Berechnungen neu startet Elementstile und in vielen Fällen auch Layouts (d. h. automatischer Umfluss) der Seite oder eines Teils einer Seite. Dieser Vorgang wird als berechneter Stil bezeichnet Berechnung.

Der erste Teil der Berechnung eines Stils besteht darin, einen Satz passender Selektoren zu erstellen. Dabei handelt es sich im Wesentlichen darum, dass der Browser herausfindet, welche Klassen, Pseudoselektoren und IDs auf ein bestimmtes Element angewendet werden sollen.

Im zweiten Teil geht es darum, alle Stilregeln aus dem passenden Selektor abzurufen und den endgültigen Stil für dieses Element herauszufinden. In Blink (der Rendering-Engine für Chrome und Opera) ist der Overhead dieser Prozesse, zumindest im Moment, ungefähr gleich:

Ungefähr 50 % der früheren Zeit Die Berechnung des berechneten Stils für ein Element wird verwendet, um Selektoren abzugleichen, während die andere Hälfte der Zeit damit verbracht wird, einen RenderStyle (berechnete Stildarstellung) aus den Übereinstimmungsregeln zu erstellen.

• Reduzieren Sie die Selektorkomplexität; verwenden Sie einen klassenzentrierten Ansatz wie die BEM-Spezifikation (Block-Element_Modifer).

• Reduziert die Anzahl der Elemente, deren Stile berechnet werden müssen.

Im einfachsten Fall gibt es in CSS nur eine Klasse von Elementen:

.title {
/*styles */
}

Allerdings as As the Das Projekt wächst, möglicherweise wird komplexeres CSS erstellt und der endgültige Selektor sieht möglicherweise so aus:

.box:nth-last-child(-n+1) .title {
/* Styles */
}

Um zu wissen, ob ein Stil angewendet werden muss, muss der Browser tatsächlich fragen: „Ist dies ein Element mit Klassentitel, dessen übergeordnetes Element genau das negative N-te untergeordnete Element plus 1 Element ist.“ mit Klassenbox?“ Die Berechnung dieses Ergebnisses kann je nach verwendetem Selektor und entsprechendem Browser erhebliche Zeit in Anspruch nehmen. Ein bestimmter Selektor kann in eine Klasse geändert werden:

.final-box-title {
/* Styles */
}

Entwickler haben möglicherweise Probleme mit dem Namen der Klasse, aber für Browser ist die Aufgabe viel einfacher. Um zu wissen, ob das Element das letzte Element seines Typs war, musste der Browser in der vorherigen Version zunächst alles über die anderen Elemente wissen und wissen, ob alle darauf folgenden Elemente das N-te letzte untergeordnete Element sein würden, was schneller war als einfaches Matching Klassenselektoren für Elemente sind viel teurer.

Beim Generieren des Renderbaums muss für jedes DOM-Element der passende Selektor in allen Stilregeln gefunden werden und die entsprechenden Stilregeln müssen zusammengeführt werden.
Der CSS-Selektor wird von rechts nach links analysiert, sodass sich der öffentliche Stil auf dem übergeordneten Knoten des CSSOM-Baums befindet und der spezifischere Stil (der Selektor ist spezifischer) auf dem untergeordneten Knoten und dem Knoten liegt Verzweigungen und Durchlaufzeiten werden sich kaum ändern. Wenn Sie CSS-Regeln mit der Links-nach-Rechts-Methode lesen, werden die meisten Regeln bis zum Ende als nicht übereinstimmend befunden, und bei Verwendung der Rechts-nach-Links-Methode wird viel unnötige Arbeit geleistet. Solange Sie feststellen, dass der Selektor ganz rechts nicht übereinstimmt. Wenn eine Übereinstimmung vorliegt, verwerfen Sie diese direkt, um viele ungültige Übereinstimmungen zu vermeiden.

Ein weiterer Leistungsaspekt: ​​Der Arbeitsaufwand, der berechnet werden muss, wenn sich ein Element ändert, ist ein wichtigerer Faktor für viele Style-Updates.

Im Allgemeinen sind die Kosten für die Berechnung des berechneten Stils im ungünstigsten Fall Elemente ist die Anzahl der Elemente multipliziert mit der Selektoranzahl, weil Um dies zu sehen, muss jedes Element mindestens einmal anhand jeder Stilregel überprüft werden wenn es übereinstimmt.

Hinweis: Früher galt: Wenn Sie eine Klasse (zum Beispiel) am Body-Element geändert haben, mussten alle untergeordneten Elemente der Seite ihre berechneten Stile neu berechnen. Jetzt ist es etwas anders: Für Elemente, deren Stile bei Änderungen neu berechnet werden, verwalten einige Browser einen kleinen Satz Regeln, die für jedes dieser Elemente einzigartig sind. Dies bedeutet, dass abhängig von der Position des Elements im Baum und den spezifischen Eigenschaften, die geändert wurden, das Element nicht unbedingt neu berechnet werden muss.

Stilberechnungen können oft auf eine kleine Anzahl von Zielelementen ausgerichtet sein, anstatt die gesamte Seite ungültig zu machen. Bei modernen Browsern ist dies oft weniger problematisch, da Browser nicht unbedingt alle Elemente überprüfen müssen, auf die sich eine Änderung auswirken könnte. Andererseits sind ältere Browser nicht unbedingt für solche Aufgaben optimiert. Die Anzahl der als ungültig deklarierten Elemente sollte so weit wie möglich reduziert werden.

// Schedule our function to run at the start of the frame.requestAnimationFrame(logBoxHeight);function logBoxHeight() {  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
}

function logBoxHeight() {
  box.classList.add('super-big');    //样式更改后，浏览器必须先应用新的样式（重绘）之后才能获取当前的值，有时是多做无用功
  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
}

function logBoxHeight() {  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
  box.classList.add('super-big');
}

function resizeAllParagraphsToMatchBlockWidth() {  // Puts the browser into a read-write-read-write cycle.
  for (var i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = box.offsetWidth + 'px';
  }
}

// Read.var width = box.offsetWidth;function resizeAllParagraphsToMatchBlockWidth() {  for (var i = 0; i < paragraphs.length; i++) {// Now write.paragraphs[i].style.width = width + 'px';
  }
}

Das obige ist der detaillierte Inhalt vonOptimierung der Browser-Rendering-Leistung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!