Verbesserung der Eingabe-Responsiveness bei Microsoft Edge


Das Internet wird immer interaktiver und Webseiten verlassen sich zunehmend auf JavaScript, wenn es um Kernfunktionalitäten wie Eingabe, Rendering, Layout und Composition geht. Da immer mehr dieser Kernfunktionalitäten clientseitig durchgeführt werden, ist es für Browser unerlässlich, dass sie Smart-Scheduling-Mechanismen benutzen, um JavaScript-Workloads effizient zu bearbeiten.

Mit EdgeHTML 15 und dem Windows 10 Creators Update hat Microsoft Edge einen großen Sprung nach vorne hinsichtlich der Disposition von JavaScript-Aufgaben erzielt. Das hat zu spürbaren Verbesserungen bei Benutzerfreundlichkeit, Responsiveness und der Leistung des modernen Web geführt. In diesem Beitrag erläutern wir einige der internen Funktionsweisen des EdgeHTML-Moduls und stellen dar, welch enorme Auswirkungen diese Verbesserungen auf die Leistung und wahrgenommene Schnelligkeit des Browsers gehabt haben.

Timer: Tod auf Raten
Wenn es um das Management von Aufgaben geht, ist das Internet erstaunlich komplex. Anstatt einen langen JavaScript-Vorgang auszuführen, tendieren die meisten Websites dazu, eine Reihe von kleinen bis mittelgroßen Vorgängen laufen zu lassen, die sich im Verlauf der Zeit aufsummieren: Ereignislistener, Timeouts, Zusagen und verschiedene andere asynchrone Aufgaben.

Selbst auf Seiten, auf denen scheinbar nicht viel passiert, geschehen in Wirklichkeit häufig viele Dinge unter der Oberfläche. Nachrichten- und Content-Websites, die sich auf Werbung, Analyse-Tracker und Scroll-Listener verlassen, dienen oft als gutes Beispiel hierfür. Hier ist eine Beispiel-Website, die manche der Probleme zeigt, die bei mangelhaft optimierten Sites häufig auftreten:

Während die Seite noch lädt und sogar lange nachdem sie „ruht“, geschieht im Hintergrund noch sehr viel. Eine Website wie diese kann Netzwerkanfragen nach zusätzlichen Ressourcen abschicken oder setTimeout aufrufen, um eine Aufgabe für den nächsten „Tick“ der Ereignisschleife in die Warteschlange einzureihen. Jeder dieser Rückrufe kann dann andere Zeitlimits oder Netzwerkanfragen disponieren, wodurch der Prozess wieder von vorne beginnt. Der Browser ist dafür verantwortlich, diese Aufgaben zu koordinieren und sicherzustellen, dass sie zusammen mit den Ereignislistenern, Zusagen und anderen Aktivitäten in Übereinstimmung mit der HTML5-Ereignisschleifenspezifizierung bearbeitet werden.

Kompliziert wird es bei den Eingabeaufgaben. Wie im Artikel „Scrolling on the Web“ dargestellt, bietet Microsoft Edge bereits jetzt eine klassenführende Bildlaufleistung, weil die große Mehrheit aller Geräte mit Bildlauffunktion (Scrolling) in einem Thread im Hintergrund bearbeitet werden können. Das bedeutet, dass diese Tätigkeiten nicht von Seiten beeinflusst werden, die viele JavaScript-Aufgaben disponieren. Der Bildlauf sollte in jedem Fall glatt und gleichmäßig sein, unabhängig davon, ob ein Mausrad, ein Touchpad oder ein Touchscreen benutzt wird.

Aufgrund von Hardwarebeschränkungen werden jedoch manche Bildlaufmethoden (wie z.B. Benutzung der Tastatur) noch immer über den Benutzeroberflächen-Thread bearbeitet. Dies gilt auch für viele andere Website-Interaktionen wie z. B. das Klicken auf Links oder die Eingabe in Formularfelder. Diese Eingabeereignisse müssen im selben Thread wie die die JavaScript-Ereignisschleife bearbeitet werden, was zu sehr unangenehmen Konsequenzen führen kann.

Blockierung der Eingabe: Der „Ist diese Seite kaputt?“-Effekt
Das haben Sie wahrscheinlich bereits am eigenen Leib erlebt: Sie laden eine Seite, die Inhalte werden angezeigt, und Sie denken sich, dass Sie bereits mit der Seite interagieren können. Wenn Sie jedoch versuchen, auf einen Link zu klicken, vergehen mehrere Sekunden, bevor irgendetwas geschieht. Oder Sie versuchen, den Bildlauf mit den Pfeiltasten der Tastatur zu steuern, aber die Seite ruckelt langsam vor sich hin oder bewegt sich überhaupt nicht.

In früheren Versionen von Microsoft Edge geschah dies häufig auf Seiten, die viele setTimeouts oder andere Rückrufe in die Warteschlange einreihen. Dies lag daran, dass unser Dispositionssystem Eingaben nicht höher priorisierte als gewöhnliche JavaScript-Aufgaben, so dass alle disponierten Timeouts im Haupt-Thread bearbeitet werden mussten, bevor Eingaben angenommen werden konnten.

Ab EdgeHTML 15 erlaubt Microsoft Edge es Eingabeereignissen jetzt, sich vor JavaScript-Tätigkeiten „vorzudrängeln“, wobei ein als Eingabepriorisierung bezeichneter Ansatz benutzt wird. Dank dieser neuen Dispositionstechnik können Eingabeereignisse jetzt quasi sofort behandelt werden, selbst dann, wenn auf der Seite ein großer Rückstau von setTimeout-Vorgängen aufgelaufen ist.

Die Verbesserungen sind bei manchen Seiten verblüffend. Von Windows Insidern haben wir gehört, dass die Leistungssteigerung bei Microsoft Edge wie „Tag und Nacht“ sei, vor allem dank der neuen Möglichkeiten, sofort den Bildlauf nutzen und auf Links klicken zu können. Man braucht nicht mehr frustrierend lange Sekunden abwarten, bis eine stark JavaScript-lastige Seite endlich fertig geladen hat.

So verrichtet die nachstehende „News-Site“ z. B. mehrere Sekunden Arbeit am Benutzeroberflächen-Thread, während sie lädt. Wenn Sie während des Ladevorgangs versuchen, auf den ersten Link zu klicken, könnte die Navigation blockiert sein, weil Eingaben mit der Maus nicht priorisiert werden.

Ab EdgeHTML 15 priorisiert Microsoft Edge jedoch das Klickereignis höher als andere Aufgaben, sodass die nächste Seite fast ohne Verzögerung lädt:

Hier sehen Sie ein weiteres Beispiel für die Verbesserung beim Bildlauf: Diese Seite führt analog zur News-Beispielsite mehrere setTimeouts im Hintergrund aus, was beim Bildlauf mittels Tastatur zu Störungen führen kann:

Ab EdgeHTML 15 lässt sich der Bildlauf weiterhin mit der Tastatur steuern, sogar während setTimeouts bearbeitet werden. Damit wird eine häufige Ursache von blockierten oder langsamen Bildläufen auf hochaktiven Websites adressiert.

Der Benutzer hat Vorrang
Um zu verstehen, wie EdgeHTML 15 im Hintergrund vorgeht, um diese Leistungsverbesserung zu erzielen, hilft ein kleine Veranschaulichung. In Wirklichkeit ist die Umsetzung natürlich etwas komplizierter, aber zum besseren Verständnis vereinfachen wir die Dinge in diesem Beispiel.

Mithilfe einiger Bilder von Rachel Nabors können wir uns die Art und Weise, wie Aufgaben auf einer Website bearbeitet werden, als Leute vorstellen, die vor einem beliebten Nachtklub auf Einlass warten. Die Schlange erstreckt sich um den ganzen Block, und am Eingang steht der Türsteher und lässt nur einen Gast auf einmal durch.

In der Implementierung vor dem Creators Update musste jeder in derselben Schlange anstehen: JavaScript-Timer, Layout- und Style-Updates sowie Eingabeereignisse. Schlimmer noch: Da JavaScript-Timer ihre eigenen Timer in Warteschlangen einreihen konnten, konnten diese sich vor andere Ereignisse vordrängeln, wenn der ursprüngliche Timer so lange brauchte, dass er noch nicht fertig war, wenn schon der nächste Timer zur Ausführung eingeteilt war.

Im Beispiel des Clubs wäre dies so, als würde ein besonders rücksichtsloser Gast seinen Freund anrufen, um ihm zu sagen: „Keine Sorge, ich halte den Platz in der Schlange für dich frei. Ich werde dem Türsteher einfach sagen, dass du schon unterwegs bist!“ Zu allem Überfluss würde es der Türsteher dem Gast erlauben, die gesamte Warteschlange aufzuhalten, während alle anderen darauf warten, dass der Freund auftaucht! Währenddessen muss das arme Eingabeereignis am Ende der Schlange warten.

Im Rahmen des Creators Update wurde dieses Schema jedoch komplett überarbeitet. Anstatt dass eine einzige Warteschlange dazu dient, alle Ereignisse zu bearbeiten, gibt es jetzt für Eingabeereignisse eine priorisierte Warteschlange. Im Beispiel wäre dies so, als würde der Club eine besondere VIP-Schlange einführen, die es hochkarätigen Gästen erlaubt, vor dem rücksichtslosen Gast, der seinen Freund anruft, in den Club gelassen zu werden.

Dies ist ein viel besseres System, weil Eingabeereignisse grundsätzlich höhere Priorität genießen sollten als irgendwelche anderen Vorgänge auf einer Webseite. Letztendlich ist der Benutzer der Herrscher über den Browser, und was auch immer die Website erreichen will, zählt weniger als das, was der Benutzer tun möchte. Selbst wenn eine Website sehr damit beschäftigt ist, JavaScript-Timer auszuführen, sollte jeglicher Eingabe von der Maus oder Tastatur des Benutzers die höchste Prioritätsstufe zugewiesen werden.

Priorisierung der Browser-Benutzeroberfläche gegenüber Webinhalten
Abgesehen von der „Überholspur“ für Benutzereingaben bei Webseiten wurde im Rahmen des Creators Updates eine weitere besondere Warteschlange für Eingaben in der Browser-Benutzeroberfläche selbst eingeführt.

Sie können sich vorstellen, wie eine problematische Webseite einen Browser lahmlegen kann, wenn Eingaben zwischen der Webseite und dem Browser-Frame geteilt werden – d.h. die URL-Leiste, Registerkarten, der Button „Favoriten“ usw. Bei manchen Webinhalten war genau dies vor dem Creators Update der Fall. Inzwischen geht Microsoft Edge jedoch intelligenter damit um, Browser-UI-Eingaben separat von Eingaben durch Webseiten zu handhaben.

In diesem Beispiel benutzen wir crashmybrowser.com, eine wunderbare Website, die genau das tut, was man von ihr erwartet. Bei einem der Tests dieser Website haben wie eine „Gabelungsbombe“ erstellt, bei der ein Timeout zwei weitere Timeouts verursacht, die wiederum jeweils zwei zusätzliche Timeouts hervorbringen, und so weiter und so fort, bis die Webseite komplett abstürzt. Vor dem Creators Update konnten derartige gnadenlose JavaScript-Übergriffe Benutzer daran hindern, die Registerkarte zu schließen oder eine neue zu öffnen, da Eingaben über die Benutzeroberfläche des Browsers nicht getrennt von anderen Eingabetypen behandelt wurden.

Im Creators Update wurden jedoch Eingaben über die Benutzeroberfläche des Browsers besonders priorisiert, sodass Benutzer „ungehorsame“ Registerkarten schließen können, ohne darauf warten zu müssen, dass sie wieder reagieren. Hierbei gilt zu beachten: Solche Eingaben werden sogar noch früher behandelt als die Eingaben des Benutzers auf der Website. So würden z. B. im Fall einer Endlosschleife (ein weiteres lustiges Beispiel auf crashmybrowser.com) Eingaben auf der Website selbst nie behandelt; trotzdem sollten Eingaben in der Benutzeroberfläche des Browsers befolgt werden, ganz unabhängig davon, was gerade auf der Webseite geschieht.

Im Beispiel unseres ganz im Trend liegenden Clubs könnte man die besondere Behandlung von Eingaben auf der Benutzeroberfläche des Browsers mit einem geheimen Seiteneingang vergleichen, der nur Bandmitgliedern und ihrem Gefolge offensteht. Obwohl also VIPs bevorzugt behandelt werden, ist die Band noch wichtiger und sollte schnell in den Künstlerbereich gelangen können.

Echte Benutzer sehen die Verbesserungen der Responsiveness
Um die Auswirkungen dieser Änderungen auf die Responsiveness bei Webinhalten zu sehen, können wir aggregierte Telemetriedaten von EdgeHTML 15 Windows Insider-Geräten betrachten und dabei die Builds vom November (vor der Implementierung der Eingabepriorisierung) mit denen vom März (nach der Einführung) vergleichen. Bei den Interaktionen unterscheiden wir bei der Responsiveness grob „hervorragende“ (great) Sessions (1000ms).

Wie sich in dem Diagramm oben erkennen lässt, hat Microsoft Edge den Anteil der „hervorragenden“ Sitzungen von 88,71 % auf 95,53 % gesteigert, während der Anteil „schlechter“ Sitzungen von 5,68 % auf 3 % sank und der Anteil der „furchtbaren“ Sitzungen von 5,61 % auf 1,46 % zurückging.

Dies bestätigt, dass Microsoft Edge-Benutzer die Vorteile der Eingabepriorisierung direkt erfahren können. Auf den meisten Websites erleben die Benutzer hervorragende Sessions. Wenn eine Website jedoch schlecht ist, kann die Erfahrung furchtbar sein. Aggregierte Windows-Telemetrie zeigt eindeutig, dass die Verbesserungen bei der Eingabepriorisierung im Rahmen des Creators Update die Anzahl der weniger guten Sessions bei schweren Websites erheblich verringert haben.

Fazit
All diese Änderungen bei der Eingabe verfolgen einen einzigen Zweck, nämlich dem Benutzer die Kontrolle über seine Browsererfahrung zu geben. Unabhängig davon, was eine Website gerade anstellt, sollte der Benutzer mit dem Browser interagieren, die Registerkarten verwalten, Inhalte per Bildlauf ansehen und so schnell wie gewünscht zu neuen Seiten navigieren können. Dank dieser Verbesserungen im Creators Update werden Benutzer von Microsoft Edge einen schnelleren, flüssigeren und reaktionsfreudigeren Browser genießen können.

Wie Bret Victor es formulierte: „Creators brauchen eine unmittelbare Verbindung zu dem, was sie gerade erschaffen.“ Dies gilt nicht nur für „Creators“, sondern auch für Websurfer: Wenn sie auf der Tastatur oder mit der Maus etwas antippen, sollte die Webseite sofort reagieren. Eine solche Responsiveness trägt dazu bei, die immersiven Aspekte des Internets aufrechtzuerhalten, und schafft eine starke empfundene Verbindung zwischen dem Benutzer und seinem Browser. Sofortiges Feedback ist nicht nur für den kreativen Fluss unerlässlich, sondern auch für reibungsloses Surfen im Internet. Durch das Creators Update hat Microsoft Edge einen großen Schritt auf dem Weg zur Realisierung dieser Vision getan.

Comments (0)

Skip to main content