In Chrome 108 wurden zwei neue Modi eingeführt: der Arbeitsspeicher-Sparmodus und der Energiesparmodus. Damit haben Nutzer mehr Kontrolle darüber, wie Chrome ihre Systemressourcen nutzt.
Diese neuen Modi sind zwar in erster Linie für Nutzer gedacht, haben aber einige Auswirkungen, die Webentwickler kennen sollten, da sie sich potenziell auf die Nutzerfreundlichkeit Ihrer Website auswirken können.
In diesem Beitrag werden die potenziellen Auswirkungen dieser neuen Modi und die Möglichkeiten von Webentwicklern beschrieben, die Nutzerfreundlichkeit zu optimieren.
Arbeitsspeicher-Sparmodus
Wenn der Arbeitsspeicher-Sparmodus aktiviert ist, werden in Chrome proaktiv Tabs geschlossen, die im Hintergrund schon länger nicht mehr verwendet wurden. Dadurch wird Arbeitsspeicher für aktive Tabs und andere möglicherweise laufende Anwendungen freigegeben. Nutzer können Chrome anweisen, Tabs für bestimmte Websites nicht zu schließen. Dies ist jedoch eine Nutzereinstellung, die Sie als Entwickler nicht steuern können.
Wenn ein Tab gelöscht wird, werden sein Titel und sein Favicon weiterhin im Tab-Bereich angezeigt, die Seite selbst ist jedoch nicht mehr zu sehen, genau so, als wäre der Tab normal geschlossen worden. Wenn der Nutzer diesen Tab noch einmal aufruft, wird die Seite automatisch neu geladen.
Bei reinen Inhaltsseiten hat das Löschen und Neuladen eines Tabs wahrscheinlich keine Auswirkungen auf die Nutzerfreundlichkeit. Bei interaktiven Websites mit komplexen Nutzerflüssen kann ein Neuladen in der Mitte des Nutzerflusses jedoch extrem frustrierend sein, wenn die Website die Seite nicht genau dort wiederherstellen kann, wo der Nutzer aufgehört hat.
Chrome arbeitet schon seit Jahren daran, Tabs zu verwerfen, um Arbeitsspeicher zu sparen, aber nur in Situationen, in denen das System unter Speicherauslastung stand. Da dies relativ selten vorkommt, haben Webentwickler das Problem möglicherweise nicht bemerkt.
Ab Chrome 108 werden Tabs häufiger geschlossen. Daher ist es wichtig, dass Websites mit diesen Vorfällen reibungslos umgehen können.
Best Practices für die Behandlung von geschlossenen Tabs
Das Schließen von Tabs ist für Webentwickler keine neue Herausforderung. Es war schon immer möglich, dass Nutzer eine Seite – entweder absichtlich oder versehentlich – neu laden, bevor sie ihre Aufgabe abgeschlossen haben. Daher war es immer wichtig, dass Websites den Nutzerstatus speichern, damit sie ihn wiederherstellen können, wenn der Nutzer die Website verlässt und wieder zurückkehrt.
Die wichtigste Überlegung ist nicht, ob der Nutzerstatus gespeichert werden soll, sondern wann. Das ist wichtig, weil kein Ereignis ausgelöst wird, wenn ein Tab geschlossen wird. Entwickler können also nicht darauf reagieren. Stattdessen müssen Entwickler diese Möglichkeit antizipieren und sich im Voraus darauf vorbereiten.
Die besten Zeiten zum Speichern des Nutzerstatus sind:
- Regelmäßig, wenn sich der Status ändert.
- Jedes Mal, wenn ein Tab im Hintergrund geöffnet ist (
visibilitychange-Ereignis).
Die schlechtesten Zeiten für das Speichern des Status sind:
- In einem
beforeunload-Ereignis-Callback. - In einem
unload-Ereignis-Callback.
Das ist der schlechteste Zeitpunkt, um den Status zu speichern, da diese Ereignisse völlig unzuverlässig sind und in vielen Situationen nicht ausgelöst werden, z. B. wenn ein Tab verworfen wird.
Im Ereignisdiagramm für den Seitenlebenszyklus sehen Sie, welche Ereignisse ausgelöst werden, wenn eine Seite verworfen wird. Wie Sie diesem Diagramm entnehmen können, kann ein Tab vom Status „Ausgeblendet“ in den Status „Verworfen“ übergehen, ohne dass Ereignisse ausgelöst werden.
Wenn die Seite den Status „ausgeblendet“ hat, ist nicht garantiert, dass andere Ereignisse ausgelöst werden, bevor die Seite vom Browser verworfen oder vom Nutzer geschlossen wird. Daher ist es wichtig, den nicht gespeicherten Nutzerstatus immer im Ereignis visibilitychange zu speichern, da Sie möglicherweise keine weitere Chance dazu erhalten.
Im folgenden Code wird eine Beispiellogik beschrieben, mit der der aktuelle Nutzerstatus jedes Mal in die Warteschlange gestellt wird, wenn er sich ändert, oder sofort, wenn der Nutzer den Tab minimiert oder die Seite verlässt:
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, ist es nicht möglich zu erkennen, dass ein Tab gerade geschlossen wird. Es ist jedoch möglich zu erkennen, dass ein Tab geschlossen wurde, nachdem ein Nutzer zu ihm zurückgekehrt ist und die Seite neu geladen wurde. In diesen Fällen hat die Property document.wasDiscarded den Wert „wahr“.
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 in solche Situationen geraten, 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 aufgrund von geschlossenen Tabs erfolgt ist:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Anbieter von Analysetools können diese Dimension standardmäßig Ihrem Produkt hinzufügen.
Website im Arbeitsspeicher-Sparmodus testen
Du kannst testen, wie eine Seite mit dem Verwerfen umgeht, indem du die Seite lädst und dann chrome://discards in einem separaten Tab oder Fenster aufrufst.
In der chrome://discards-Benutzeroberfläche finden Sie den Tab, den Sie verwerfen möchten, und klicken dann in der Spalte Aktionen auf Dringendes Verwerfen.
Dadurch wird der Tab verworfen und Sie können ihn noch einmal aufrufen und überprüfen, ob die Seite in den gleichen Status wie beim Verlassen geladen wurde.
Derzeit gibt es keine Möglichkeit, das Schließen von Tabs über Testtools wie Webdriver oder Puppeteer zu automatisieren. Da das Schließen und Wiederherstellen von Tabs jedoch fast identisch mit dem Aktualisieren von Seiten ist, funktioniert der Test, ob der Nutzerstatus nach einem Aktualisieren in der Mitte eines Nutzerflusses wiederhergestellt wird, wahrscheinlich auch für das Schließen und Wiederherstellen von Tabs. Der Hauptunterschied zwischen den beiden besteht darin, dass die Ereignisse beforeunload, pagehide und unload nicht ausgelöst werden, wenn ein Tab verworfen wird. Solange Sie sich also nicht darauf verlassen, dass diese Ereignisse den Nutzerstatus beibehalten, können Sie mithilfe von Neuladevorgängen das Verwerfen/Wiederherstellen-Verhalten testen.
Energiesparmodus
Wenn der Energiesparmodus aktiviert ist, reduziert Chrome den Akkuverbrauch, indem die Displayaktualisierungsrate verringert wird. Das wirkt sich auf die Scroll- und Animationsqualität sowie auf die Video-Framerates 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() passen sich automatisch an jede Änderung der Aktualisierungsrate der Anzeige an, wenn dieser Modus aktiviert ist.
Dieser Modus könnte in der Regel problematisch sein, wenn auf Ihrer Website JavaScript-basierte Animationen verwendet werden, bei denen davon ausgegangen wird, dass alle Nutzer eine bestimmte Aktualisierungsrate verwenden.
Wenn Ihre Website beispielsweise requestAnimationFrame()-Schleifen verwendet und davon ausgeht, dass zwischen den Rückrufen genau 16,67 Millisekunden vergehen, laufen Ihre Animationen doppelt so langsam, wenn der Energiesparmodus aktiviert ist.
Es war immer problematisch, für alle Nutzer eine Standardaktualisierungsrate von 60 Hz anzunehmen, da dies für viele aktuelle Geräte nicht zutrifft.
Displayaktualisierungsrate messen
Es gibt keine dedizierte Web-API zur Messung der Aktualisierungsrate der Anzeige. Im Allgemeinen wird es nicht empfohlen, dies mit aktuellen APIs zu versuchen.
Entwickler können mit vorhandenen APIs am besten die Zeitstempel zwischen aufeinanderfolgenden requestAnimationFrame()-Callbacks vergleichen. Obwohl damit in den meisten Fällen die ungefähre Aktualisierungsrate zu einem bestimmten Zeitpunkt ermittelt werden kann, werden Sie dadurch nicht darüber informiert, wenn sich die Aktualisierungsrate ändert. Dazu müssten Sie ständig eine requestAnimationFrame()-Umfrage ausführen, was dem Ziel, den Energieverbrauch oder die Akkulaufzeit für Ihre Nutzer zu schonen, zuwiderläuft.
Website im Energiesparmodus testen
Sie können Ihre Website im Energiesparmodus testen, indem Sie den Modus in den Chrome-Einstellungen aktivieren und so konfigurieren, dass er ausgeführt wird, wenn Ihr Gerät nicht angeschlossen ist.
Wenn Sie kein Gerät haben, das Sie vom Stromnetz trennen können, können Sie den Modus auch manuell aktivieren. Gehen Sie dazu so vor:
- Aktivieren Sie das Flag
chrome://flags/#battery-saver-mode-available. - Rufen Sie
chrome://discardsauf und klicken Sie auf den Link Energiesparmodus aktivieren/deaktivieren. Wichtig:Das Flag#battery-saver-mode-availablemuss aktiviert sein, damit der Link funktioniert.
Danach können Sie mit Ihrer Website interagieren und prüfen, ob alles wie gewünscht aussieht, z. B. ob Animationen und Übergänge mit der gewünschten Geschwindigkeit ablaufen.
Zusammenfassung
Der Arbeitsspeicher-Sparmodus und der Energiesparmodus von Chrome sind zwar in erster Linie Funktionen für Nutzer, sie haben aber auch Auswirkungen auf Entwickler, da sie sich bei unsachgemäßer Verwendung negativ auf die Nutzung Ihrer Website auswirken können.
Im Allgemeinen wurden diese neuen Modi unter Berücksichtigung der bestehenden Best Practices für Entwickler entwickelt. Wenn Entwickler seit Langem die Best Practices für das Web befolgen, sollten ihre Websites auch weiterhin mit diesen neuen Modi funktionieren.
Wenn Ihre Website jedoch eine der in diesem Beitrag genannten Praktiken enthält, treten bei Ihren Nutzern wahrscheinlich Probleme auf, die sich durch die Aktivierung dieser beiden Modi nur verschlimmern.
Die beste Möglichkeit, die Nutzerfreundlichkeit zu überprüfen, besteht wie immer darin, Ihre Website mit Bedingungen zu testen, die mit denen Ihrer Nutzer übereinstimmen.