In Chrome 108 wurden zwei neue Modi eingeführt: der Arbeitsspeicher-Sparmodus und der Energiesparmodus, mit denen Nutzer mehr Kontrolle darüber haben, wie Chrome ihre Systemressourcen nutzt.
Diese neuen Modi richten sich zwar hauptsächlich an die Nutzer, haben jedoch einige Auswirkungen, die für Webentwickler wichtig sind, da sie sich möglicherweise auf die Nutzererfahrung auf Ihrer Website auswirken können.
In diesem Beitrag erfahren Sie mehr über die möglichen Auswirkungen dieser neuen Modi und darüber, wie Webentwickler dafür sorgen können, dass sie die bestmögliche Nutzererfahrung bieten.
Arbeitsspeicher-Sparmodus
Wenn der Arbeitsspeicher-Sparmodus aktiviert ist, verwirft Chrome proaktiv Tabs, die seit einiger Zeit im Hintergrund nicht verwendet wurden. Dadurch wird Arbeitsspeicher für aktive Tabs und andere möglicherweise ausgeführte Anwendungen freigegeben. Nutzer können Chrome anweisen, Tabs für bestimmte Websites nicht zu verwerfen. Dies ist jedoch eine Nutzereinstellung, die Sie als Entwickler nicht beeinflussen können.
Wenn ein Tab verworfen wird, werden der Titel und das Favicon weiterhin in der Tableiste angezeigt, aber die Seite selbst ist nicht mehr verfügbar, genau so, als ob der Tab normal geschlossen worden wäre. Wenn der Nutzer diesen Tab noch einmal aufruft, wird die Seite automatisch neu geladen.
Bei reinen Inhaltsseiten hat das Verwerfen und Neuladen eines Tabs wahrscheinlich keine Auswirkungen auf die Nutzererfahrung. Bei umfangreichen, interaktiven Websites mit komplexen User Flows kann ein erneutes Laden mitten im Ablauf äußerst frustrierend sein, wenn die Website nicht in der Lage ist, die Seite an der Stelle wiederherzustellen, an der 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 der Fall ist, waren Webentwicklern vielleicht gar nicht bewusst, dass es passierte.
Ab Chrome 108 wird das Verwerfen von Tabs immer häufiger verwendet. Daher ist es wichtig, dass Websites mit solchen Vorfällen umgehen können.
Best Practices für das Verwerfen von Tabs
Das Verwerfen von Tabs stellt für Webentwickler keine neue Herausforderung dar. Es war immer möglich, dass Nutzende eine Seite entweder absichtlich oder versehentlich neu laden, bevor sie ihre Aufgabe ausführen. 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. Und das ist wichtig, da kein Ereignis ausgelöst wird, wenn ein Tab verworfen wird. Entwickler haben also keine Möglichkeit, darauf zu reagieren. Stattdessen müssen Entwickler sich darauf vorbereiten und sich im Voraus darauf vorbereiten.
Die besten Zeiten zum Speichern des Nutzerstatus sind:
- Regelmäßig, wenn sich der Status ändert.
- Immer dann, wenn ein Tab im Hintergrund ausgeführt wird (das Ereignis
visibilitychange).
Die schlechtesten Zeiten für das Speichern des Status sind:
- In einem
beforeunload-Ereignis-Callback - In einem
unload-Ereignis-Callback
Dies sind die schlechtesten Zeiten für das Speichern des Status, da diese Ereignisse völlig unzuverlässig sind und in vielen Situationen nicht ausgelöst werden, z. B. wenn ein Tab verworfen wird.
Im Diagramm zum Seitenlebenszyklus-Ereignis sehen Sie, welche Ereignisse voraussichtlich ausgelöst werden, wenn eine Seite verworfen wird. Wie Sie in diesem Diagramm sehen können, zu „verworfen“ ändern, ohne dass Ereignisse ausgelöst werden.
Jedes Mal, wenn sich eine Seite
im „verborgenen“ Bereich befindet, gibt es keine Garantie, dass andere Ereignisse ausgelöst werden, bevor die Seite entweder vom Browser verworfen oder vom Nutzer beendet wird. Deshalb ist es wichtig, alle nicht gespeicherten Nutzerstatus immer im visibilitychange-Ereignis zu speichern, da Sie sonst möglicherweise keine Gelegenheit dazu haben.
Der folgende Code stellt einige Beispiellogik für die Warteschlange dar, bei der der aktuelle Nutzerstatus immer dann beibehalten wird, wenn er sich ändert, oder sofort, wenn der Nutzer den Tab im Hintergrund abspielt 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, kann man nicht erkennen, dass ein Tab gleich verworfen wird. Es kann jedoch festgestellt werden, dass ein Tab verworfen wurde, nachdem ein Nutzer zu ihm zurückgekehrt ist und die Seite neu geladen wurde. In diesen Fällen ist das Attribut 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 durch das Verwerfen von Tabs erfolgte:
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.
Beachten Sie, dass es derzeit keine Möglichkeit gibt, das Verwerfen von Tabs mithilfe von Testtools wie Webdriver oder Puppeteer zu automatisieren. Da das Verwerfen und Wiederherstellen von Tabs jedoch fast mit dem Neuladen einer Seite identisch ist, funktioniert es wahrscheinlich auch beim Verwerfen/Wiederherstellen, wenn Sie testen, ob der Benutzerstatus nach einer Aktualisierung mitten in einem User Flow wiederhergestellt wird. 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, spart Chrome den Akku, da die Aktualisierungsrate des Displays reduziert wird. Dies beeinträchtigt das Scrollen, die Wiedergabequalität und die Framerate von Videos.
Im Allgemeinen müssen Entwickler nichts unternehmen, 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 Callbacks genau 16,67 Millisekunden vergangen sind, werden Ihre Animationen im Energiesparmodus doppelt so langsam ausgeführt.
Beachten Sie, dass es für Entwickler immer problematisch war, von einer Standardaktualisierungsrate von 60 Hz für alle Nutzer auszugehen, da dies auf vielen aktuellen Geräten nicht zutrifft.
Aktualisierungsrate im Displaynetzwerk 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.
Die besten Entwickler, die vorhandene APIs verwenden können, besteht darin, die Zeitstempel von aufeinanderfolgenden requestAnimationFrame()-Callbacks zu 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 durchführen, um das Ziel, den Energieverbrauch oder die Akkulaufzeit Ihrer Nutzer zu schonen, zunichte zu machen.
Website im Energiesparmodus testen
Wenn Sie Ihre Website im Energiesparmodus testen möchten, können Sie den Modus in den Chrome-Einstellungen aktivieren und so konfigurieren, dass er ausgeführt wird, wenn das Gerät vom Stromnetz getrennt ist.
Wenn Sie kein Gerät haben, das vom Stromnetz getrennt werden kann, können Sie den Modus auch manuell aktivieren. Gehen Sie dazu so vor:
- Aktivieren Sie das Flag
chrome://flags/#battery-saver-mode-available. - Rufe
chrome://discardsauf und klicke auf den Link Energiesparmodus aktivieren/deaktivieren. Wichtig:Die Markierung#battery-saver-mode-availablemuss aktiviert sein, damit der Link funktioniert.
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
Zwar handelt es sich bei den Modi „Arbeitsspeicher-Sparmodus“ und „Energiesparmodus“ in erster Linie um Funktionen für Nutzer. Sie haben jedoch Auswirkungen für Entwickler, da sie sich negativ auf den Besuch Ihrer Website auswirken können, wenn sie nicht ordnungsgemäß verwendet werden.
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.
Enthält Ihre Website jedoch eine der Methoden, die in diesem Post beschrieben werden, treten bei Ihren Nutzern wahrscheinlich Probleme auf, die sich bei Aktivierung dieser beiden Modi nur noch verstärken werden.
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.