Wat ontwikkelaars moeten weten over de geheugen- en energiebesparingsmodi van Chrome

Philip Walton

Chrome 108 introduceerde twee nieuwe modi, Memory Saver en Energy Saver , om gebruikers meer controle te geven over hoe Chrome hun systeembronnen gebruikt.

Hoewel deze nieuwe modi voornamelijk op de gebruiker gericht zijn, hebben ze wel enkele implicaties waarvan het belangrijk is dat webontwikkelaars zich ervan bewust zijn, omdat ze mogelijk van invloed kunnen zijn op de gebruikerservaring van uw site.

In dit bericht worden de mogelijke effecten van deze nieuwe modi besproken en wat webontwikkelaars kunnen doen om ervoor te zorgen dat ze de best mogelijke ervaring bieden.

Geheugenbesparingsmodus

Wanneer de Geheugenbesparingsmodus is ingeschakeld, verwijdert Chrome proactief tabbladen die al enige tijd op de achtergrond niet worden gebruikt. Dit maakt geheugen vrij voor actieve tabbladen en andere toepassingen die mogelijk actief zijn. Gebruikers kunnen Chrome opdracht geven tabbladen voor specifieke sites niet te verwijderen; Dit is echter een gebruikersvoorkeur en niet iets waar u als ontwikkelaar controle over heeft.

Wanneer een tabblad wordt weggegooid, verschijnen de titel en het favicon nog steeds in de tabbladstrook, maar de pagina zelf is verdwenen, precies alsof het tabblad normaal was gesloten. Als de gebruiker dat tabblad opnieuw bezoekt, wordt de pagina automatisch opnieuw geladen.

Voor puur inhoudspagina's heeft het weggooien en opnieuw laden van een tabblad waarschijnlijk geen invloed op de gebruikerservaring, maar voor rijke, interactieve sites met complexe gebruikersstromen kan het opnieuw laden in het midden van die stroom uiterst frustrerend zijn als de site niet in staat is de weergave te herstellen. pagina naar precies waar de gebruiker was gebleven.

Het weggooien van tabbladen om geheugen te besparen is iets wat Chrome al jaren doet, maar het werd alleen gedaan in situaties waarin het systeem onder geheugendruk stond. Gezien het relatief zeldzame voorkomen ervan, hebben webontwikkelaars zich misschien niet gerealiseerd dat dit gebeurde.

Vanaf Chrome 108 zal het weggooien van tabbladen steeds gebruikelijker worden, dus het is van cruciaal belang dat sites deze gevallen netjes kunnen afhandelen.

Best practices voor het omgaan met het weggooien van tabbladen

Het weggooien van tabbladen is geen nieuwe uitdaging voor webontwikkelaars. Het is altijd mogelijk geweest dat een gebruiker een pagina opnieuw laadde (opzettelijk of per ongeluk) voordat hij zijn taak had voltooid. Het is dus altijd belangrijk geweest dat sites de gebruikersstatus opslaan, zodat ze deze kunnen herstellen als de gebruiker weggaat en terugkomt.

De belangrijkste overweging is niet of de gebruikersstatus moet worden opgeslagen, maar wanneer deze moet worden opgeslagen. En dit is van cruciaal belang omdat er geen gebeurtenis plaatsvindt wanneer een tabblad wordt weggegooid, dus ontwikkelaars kunnen op geen enkele manier reageren op het feit dat dit gebeurt. In plaats daarvan moeten ontwikkelaars op deze mogelijkheid anticiperen en zich van tevoren voorbereiden.

De beste tijden om de gebruikersstatus op te slaan zijn:

• Periodiek als de toestand verandert.
• Wanneer een tabblad een achtergrond heeft (de visibilitychange ).

De slechtste tijden om de toestand op te slaan zijn:

• In een beforeunload gebeurtenis terugbellen.
• Bij een terugbelactie van een unload .

Dit zijn de slechtste tijden om de status op te slaan, omdat deze gebeurtenissen volledig onbetrouwbaar zijn en in veel situaties niet worden geactiveerd, ook niet wanneer een tabblad wordt weggegooid.

U kunt het gebeurtenisdiagram van de paginalevenscyclus raadplegen om te zien welke gebeurtenissen naar verwachting zullen worden geactiveerd als een pagina wordt verwijderd. Zoals u in dat diagram kunt zien, kan een tabblad van de status 'verborgen' naar de status 'weggegooid' gaan zonder dat er gebeurtenissen worden geactiveerd.

Elke keer dat de pagina zich in de 'verborgen' status bevindt, is er feitelijk geen garantie dat er andere gebeurtenissen worden geactiveerd voordat de pagina door de browser wordt verwijderd of door de gebruiker wordt beëindigd. Daarom is het belangrijk om altijd alle niet-opgeslagen gebeurtenissen op te slaan. gebruikersstatus in de visibilitychange , omdat u mogelijk geen nieuwe kans krijgt.

De volgende code schetst een voorbeeldlogica om in de wachtrij te blijven staan, waarbij de huidige gebruikersstatus behouden blijft telkens wanneer deze verandert, of onmiddellijk als de gebruiker het tabblad op de achtergrond zet of weg navigeert:

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();
  }
});

Detecteren dat een tabblad is weggegooid

Zoals eerder vermeld, is het niet mogelijk om te detecteren dat een tabblad op het punt staat te worden verwijderd, maar het is wel mogelijk om te detecteren dat een tabblad is verwijderd nadat een gebruiker ernaar terugkeert en de pagina opnieuw is geladen. In deze situaties is de eigenschap document.wasDiscarded waar.

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

Als u wilt begrijpen hoe vaak uw gebruikers dit soort situaties ervaren, kunt u uw analysetool configureren om deze informatie vast te leggen.

In Google Analytics kunt u bijvoorbeeld een aangepaste gebeurtenisparameter configureren waarmee u kunt bepalen welk percentage paginaweergaven voortkomt uit het weggooien van tabbladen:

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

Als u een analyseprovider bent, kunt u overwegen deze dimensie standaard aan uw product toe te voegen.

Test uw site in de Memory Saver-modus

U kunt testen hoe een pagina omgaat met het weggooien door de pagina te laden en vervolgens naar chrome://discards te gaan in een apart tabblad of venster.

Vanuit de chrome://discards -gebruikersinterface kunt u het tabblad dat u wilt verwijderen uit de lijst zoeken en vervolgens op Dringend weggooien klikken in de kolom Acties .

Hierdoor wordt het tabblad verwijderd, zodat u het opnieuw kunt bezoeken en kunt verifiëren dat de pagina opnieuw is geladen in dezelfde staat als toen u deze verliet.

Houd er rekening mee dat er momenteel geen manier is om het weggooien van tabbladen te automatiseren via testtools zoals webdriver of poppenspeler; Omdat het verwijderen en herstellen van tabbladen echter vrijwel identiek is aan het opnieuw laden van pagina's, zal het waarschijnlijk ook werken voor het weggooien/herstellen als u test of de gebruikersstatus is hersteld na opnieuw laden midden in een gebruikersstroom. Het belangrijkste verschil tussen de twee is dat de gebeurtenissen beforeunload , pagehide en unload niet worden geactiveerd wanneer een tabblad wordt verwijderd. Zolang u niet afhankelijk bent van deze gebeurtenissen om de gebruikersstatus te behouden, kunt u reloads gebruiken om het negeren te testen. / gedrag herstellen.

Energiespaarstand

Wanneer de Energiespaarstand is ingeschakeld, spaart Chrome de batterij door de vernieuwingsfrequentie van het scherm te verlagen, waardoor de scroll- en animatiegetrouwheid en de videoframesnelheden worden beïnvloed.

Over het algemeen hoeven ontwikkelaars niets te doen om de Energiespaarstand te ondersteunen. CSS- en JavaScript-API's voor animaties , transitions en requestAnimationFrame() worden automatisch aangepast aan elke wijziging in de vernieuwingsfrequentie van het scherm wanneer deze modus is ingeschakeld.

Het belangrijkste scenario waarin deze modus problematisch kan zijn, is als uw site op JavaScript gebaseerde animaties gebruikt die voor alle gebruikers een bepaalde vernieuwingsfrequentie aannemen.

Als uw site bijvoorbeeld requestAnimationFrame() lussen gebruikt en ervan uitgaat dat er precies 16,67 milliseconden zijn verstreken tussen callbacks, worden uw animaties twee keer zo langzaam uitgevoerd als de Energiespaarstand is ingeschakeld.

Houd er rekening mee dat het voor ontwikkelaars altijd problematisch is geweest om voor alle gebruikers uit te gaan van een standaard vernieuwingsfrequentie van 60 Hz, aangezien dit voor veel huidige apparaten niet het geval is.

Het meten van de vernieuwingsfrequentie van het scherm

Er is geen speciale web-API om de vernieuwingsfrequentie van het scherm te meten, en over het algemeen wordt het niet aanbevolen om dit met de huidige API's te proberen.

Het beste dat ontwikkelaars met bestaande API's kunnen doen, is het vergelijken van de tijdstempels tussen opeenvolgende requestAnimationFrame() -callbacks. Hoewel dit in de meeste gevallen werkt om de vernieuwingsfrequentie op een bepaald tijdstip te benaderen, laat het u niet weten wanneer de vernieuwingsfrequentie verandert. Om dat te doen zou u voortdurend een requestAnimationFrame() peiling moeten uitvoeren, wat het doel van het besparen van energie of de levensduur van de batterij voor uw gebruikers tenietdoet.

Uw site testen in de energiespaarstand

Eén manier om uw site in de Energiespaarstand te testen, is door de modus in de Chrome-instellingen in te schakelen en deze zo te configureren dat deze wordt uitgevoerd wanneer uw apparaat is losgekoppeld.

Als u niet over een apparaat beschikt dat kan worden losgekoppeld, kunt u de modus ook handmatig inschakelen door deze stappen te volgen:

1. Schakel de chrome://flags/#battery-saver-mode-available vlag in.
2. Ga naar chrome://discards en klik op de link Batterijbesparingsmodus schakelen ( belangrijk: de vlag #battery-saver-mode-available moet zijn ingeschakeld om de link te laten werken).

Eenmaal ingeschakeld, kunt u met uw site communiceren en controleren of alles er naar behoren uitziet: bijvoorbeeld of animaties en overgangen op de gewenste snelheid worden uitgevoerd.

Samenvatting

Hoewel de Memory Saver- en Energy Saver-modi van Chrome voornamelijk op de gebruiker gerichte functies zijn, hebben ze wel gevolgen voor ontwikkelaars, omdat ze de ervaring van het bezoeken van uw site negatief kunnen beïnvloeden als ze niet op de juiste manier worden afgehandeld.

Over het algemeen zijn deze nieuwe modi ontworpen met de bestaande best practices voor ontwikkelaars in gedachten. Als ontwikkelaars al lang bestaande best practices op internet volgen, zouden hun sites prima moeten blijven werken met deze nieuwe modi.

Als uw site echter een van de praktijken bevat die in dit bericht worden genoemd, is het waarschijnlijk dat uw gebruikers problemen ondervinden die alleen maar zullen toenemen als deze twee modi zijn ingeschakeld.

Zoals altijd is de beste manier om te bevestigen dat u een geweldige ervaring biedt, het testen van uw site met voorwaarden die overeenkomen met die van uw gebruikers.