Was Entwickler über den Arbeitsspeicher- und Energiesparmodus in Chrome wissen müssen

In Chrome 108 wurden zwei neue Modi eingeführt: Arbeitsspeicher-Sparmodus und Energiesparmodus. Damit können Nutzer besser steuern, wie Chrome ihre Systemressourcen nutzt.

Diese neuen Modi richten sich hauptsächlich an Nutzer. Sie haben jedoch einige Auswirkungen, die für Webentwickler relevant sein müssen, da sie die Nutzererfahrung auf Ihrer Website beeinträchtigen können.

In diesem Beitrag werden die möglichen Auswirkungen dieser neuen Modi behandelt und was Webentwickler tun können, damit sie das bestmögliche Nutzererlebnis bieten.

Arbeitsspeicher-Sparmodus

Wenn der Arbeitsspeicher-Sparmodus aktiviert ist, verwirft Chrome Tabs, die längere Zeit nicht im Hintergrund verwendet wurden. Dadurch wird Arbeitsspeicher für aktive Tabs und andere Anwendungen freigegeben, die möglicherweise ausgeführt werden. Nutzer können Chrome anweisen, Tabs für bestimmte Websites nicht zu verwerfen. Dies ist jedoch eine Nutzereinstellung und Sie als Entwickler können Sie nicht selbst steuern.

Wenn ein Tab verworfen wird, werden sein Titel und das Favicon weiterhin in der Tableiste angezeigt, die Seite selbst ist jedoch verschwunden, genau so, als ob der Tab normal geschlossen worden wäre. Ruft der Nutzer diesen Tab noch einmal auf, wird die Seite automatisch neu geladen.

Bei reinen Inhaltsseiten hat das Verwerfen und Aktualisieren eines Tabs wahrscheinlich keine Auswirkungen auf die Nutzerfreundlichkeit. Bei umfangreichen, interaktiven Websites mit komplexen Nutzerflüssen kann ein erneutes Laden in der Mitte dieses Vorgangs jedoch äußerst frustrierend sein, wenn die Website die Seite nicht genau an der Stelle wiederherstellen kann, an der der Nutzer aufgehört hat.

Das Verwerfen von Tabs zur Schonung des Arbeitsspeichers ist bei Chrome schon seit Jahren der Fall, aber nur in Situationen, in denen das System unter einer Auslastung des Arbeitsspeichers stand. Da dieses Szenario relativ selten ist, haben Webentwickler möglicherweise nicht gemerkt, dass das der Fall ist.

Ab Chrome 108 werden Tabs immer häufiger verworfen. Daher ist es wichtig, dass Websites solche Vorfälle problemlos bewältigen können.

Best Practices für das Verwerfen von Tabs

Das Verwerfen von Tabs ist für Webentwickler keine neue Herausforderung. Es war schon immer möglich, dass Nutzende eine Seite neu laden – entweder absichtlich oder versehentlich –, bevor sie ihre Aufgabe abgeschlossen hatten. Daher war es für Websites immer wichtig, den Nutzerstatus zu speichern, damit sie ihn wiederherstellen können, wenn der Nutzer die Website verlässt und später zurückkehrt.

Der wichtigste Aspekt ist nicht, ob der Nutzerstatus gespeichert werden soll, sondern wann er gespeichert werden soll. Das ist wichtig, da es kein Ereignis gibt, das ausgelöst wird, wenn ein Tab verworfen wird. Daher haben Entwickler keine Möglichkeit, darauf zu reagieren. Stattdessen müssen die Entwickler diese Möglichkeit voraussehen und sich im Voraus vorbereiten.

Die besten Zeiten zum Speichern des Nutzerstatus sind:

  • Regelmäßig, wenn sich der Status ändert.
  • Wenn ein Tab im Hintergrund ausgeführt wird (visibilitychange-Ereignis).

Die schlechtesten Zeiten zum Speichern von Status sind:

  • In einem beforeunload-Ereignis-Callback.
  • In einem unload-Ereignis-Callback.

Das ist die schlechteste Zeit für das Speichern von Status, da diese Ereignisse völlig unzuverlässig sind und in vielen Situationen nicht ausgelöst werden, auch wenn ein Tab verworfen wird.

Im Diagramm zu Seitenlebenszyklus-Ereignissen sehen Sie, welche Ereignisse voraussichtlich ausgelöst werden, wenn eine Seite verworfen wird. Wie Sie an diesem Diagramm sehen können, kann ein Tab vom Status „Ausgeblendet“ in den Status „Verworfen“ wechseln, ohne dass Ereignisse ausgelöst werden.

Status und Ereignisfluss der API zum Seitenlebenszyklus. Eine visuelle Darstellung des Status- und Ereignisflusses, der in diesem Dokument beschrieben wird.

Wenn eine Seite den Status „Verborgen“ hat, gibt es keine Garantie, dass andere Ereignisse ausgelöst werden, bevor die Seite entweder vom Browser verworfen oder vom Nutzer beendet wird. Daher ist es wichtig, nicht gespeicherte Nutzerstatus immer im visibilitychange-Ereignis zu speichern, da es sonst keine Chance gibt.

Im folgenden Code finden Sie eine Beispiellogik, mit der der aktuelle Nutzerstatus bei jeder Änderung oder sofort, wenn der Nutzer den Tab in den Hintergrund verlässt oder zu einer anderen Seite wechselt, in die Warteschlange gestellt werden:

let state = {};
let hasUnstoredState = false;

function storeState() {
  if (hasUnstoredState) {
    // Store `state` to localStorage or IndexedDB...
  }
  hasUnstoredState = false;
}

export function updateState(newState) {
  state = newState;
  hasUnstoredState = true;
  requestIdleCallback(storeState);
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    storeState();
  }
});

Erkennen, dass ein Tab verworfen wurde

Wie bereits erwähnt, kann nicht erkannt werden, dass ein Tab verworfen wird. Es ist jedoch möglich, dass ein Tab verworfen wurde, nachdem ein Nutzer zu ihm zurückkehrt und die Seite neu geladen wurde. In diesen Fällen ist die Eigenschaft document.wasDiscarded „true“.

if (document.wasDiscarded) {
  // The page was reloaded after a discard.
} else {
  // The page was not reloaded after a discard.
}

Wenn Sie wissen möchten, wie oft Ihre Nutzer solche Situationen erleben, können Sie Ihr Analysetool so konfigurieren, dass diese Informationen erfasst werden.

In Google Analytics können Sie beispielsweise einen benutzerdefinierten Ereignisparameter konfigurieren, mit dem Sie ermitteln können, welcher Prozentsatz der Seitenaufrufe über verworfene Tabs zustande gekommen ist:

gtag('config', 'G-XXXXXXXXXX', {
  was_discarded: document.wasDiscarded,
});

Anbieter von Analysen sollten erwägen, Ihrem Produkt diese Dimension standardmäßig hinzuzufügen.

Website im Arbeitsspeicher-Sparmodus testen

Sie können testen, wie eine Seite verworfen wird, indem Sie die Seite laden und dann chrome://discards in einem separaten Tab oder Fenster aufrufen.

Suchen Sie in der chrome://discards-Benutzeroberfläche den Tab, den Sie verwerfen möchten, und klicken Sie dann in der Spalte Aktionen auf Dringend löschen.

Screenshot der Benutzeroberfläche von chrome://discards mit der Position des Links zum Verwerfen von Tabs

Dadurch wird der Tab verworfen und Sie können ihn noch einmal aufrufen und überprüfen, ob die Seite im selben Zustand wie vor dem Verlassen aktualisiert wurde.

Derzeit gibt es keine Möglichkeit, das Verwerfen von Tabs über Testtools wie Webdriver oder Puppenteer zu automatisieren. Da das Verwerfen und Wiederherstellen von Tabs jedoch fast identisch mit dem Neuladen von Seiten ist, funktioniert die Wiederherstellung des Benutzerstatus mitten im User Flow wahrscheinlich auch beim Verwerfen/Wiederherstellen. Der Hauptunterschied zwischen den beiden ist, dass beforeunload-, pagehide- und unload-Ereignisse nicht ausgelöst werden, wenn ein Tab verworfen wird. Solange diese Ereignisse den Nutzerstatus nicht beibehalten, können Sie das Verwerfen/Wiederherstellungsverhalten testen.

Energiesparmodus

Wenn der Energiesparmodus aktiviert ist, reduziert Chrome den Akkuverbrauch, indem die Aktualisierungsrate des Displays verringert wird. Dies wirkt sich auf die Scroll- und Animationsqualität sowie die Framerates von Videos aus.

Im Allgemeinen müssen Entwickler nichts tun, um den Energiesparmodus zu unterstützen. CSS- und JavaScript-APIs für Animationen, Übergänge und requestAnimationFrame() werden automatisch an jede Änderung der Display-Aktualisierungsrate angepasst, wenn dieser Modus aktiviert ist.

Dieser Modus könnte vor allem dann problematisch sein, wenn auf Ihrer Website JavaScript-basierte Animationen verwendet werden, die von einer bestimmten Aktualisierungsrate für alle Nutzer ausgehen.

Wenn Ihre Website beispielsweise requestAnimationFrame()-Schleifen verwendet und davon ausgeht, dass zwischen den Callbacks genau 16,67 Millisekunden vergangen sind, werden die Animationen bei aktiviertem Energiesparmodus doppelt so langsam ausgeführt.

Für Entwickler war es schon immer problematisch, von einer Standardaktualisierungsrate von 60 Hz für alle Nutzer auszugehen, da dies auf viele aktuelle Geräte nicht zutrifft.

Aktualisierungsrate des Displays messen

Es gibt keine spezielle Web-API zum Messen der Aktualisierungsrate der Anzeige. Im Allgemeinen ist es nicht empfehlenswert, dies mit aktuellen APIs zu tun.

Entwickler können mit vorhandenen APIs am besten die Zeitstempel zwischen aufeinanderfolgenden requestAnimationFrame()-Callbacks vergleichen. In den meisten Fällen lässt sich so die ungefähre Aktualisierungsrate zu einem bestimmten Zeitpunkt ermitteln. Sie erfahren jedoch nicht, wann sich die Aktualisierungsrate ändert. Dafür müsstest du ständig eine requestAnimationFrame()-Umfrage durchführen, um das Ziel zu vermeiden, Energie oder Akkulaufzeit zu sparen.

Website im Energiesparmodus testen

Eine Möglichkeit, Ihre Website im Energiesparmodus zu testen, besteht darin, den Modus in den Chrome-Einstellungen zu aktivieren und ihn so zu konfigurieren, dass er ausgeführt wird, wenn das Gerät vom Stromnetz getrennt ist.

Wenn du kein Gerät hast, das vom Stromnetz getrennt werden kann, kannst du den Modus auch manuell aktivieren. Gehe dazu folgendermaßen vor:

  1. Aktivieren Sie das Flag chrome://flags/#battery-saver-mode-available.
  2. Rufen Sie chrome://discards auf und klicken Sie auf den Link Energiesparmodus aktivieren/deaktivieren. Wichtig:Das Flag #battery-saver-mode-available muss aktiviert sein, damit der Link funktioniert.

Screenshot der Benutzeroberfläche von chrome://discards mit der Position des Links zum Aktivieren des Energiesparmodus

Nach der Aktivierung können Sie mit Ihrer Website interagieren und überprüfen, ob alles so aussieht, wie es sollte, z. B. ob Animationen und Übergänge mit der gewünschten Geschwindigkeit ausgeführt werden.

Zusammenfassung

Die Funktionen des Arbeitsspeicher-Sparmodus und des Energiesparmodus von Chrome sind zwar hauptsächlich für Nutzer gedacht, aber sie haben Auswirkungen für Entwickler, da sie sich negativ auf die Nutzerfreundlichkeit Ihrer Website auswirken können, wenn sie nicht ordnungsgemäß verarbeitet werden.

Diese neuen Modi wurden im Allgemeinen unter Berücksichtigung bestehender Best Practices für Entwickler entwickelt. Wenn Entwickler sich seit Langem an den Best Practices für das Web orientieren, sollten ihre Websites auch weiterhin mit diesen neuen Modi einwandfrei funktionieren.

Wenn deine Website jedoch eine der in diesem Beitrag genannten Vorgehensweisen beinhaltet, treten bei deinen Nutzern wahrscheinlich Probleme auf, die sich durch die Aktivierung dieser beiden Modi nur erhöhen.

Wie immer können Sie sicherstellen, dass Sie eine positive Erfahrung bieten, indem Sie Ihre Website unter Bedingungen testen, die denen Ihrer Nutzer entsprechen.