
Page Lifecycle API - bootslebaron
https://developers.google.com/web/updates/2018/07/page-lifecycle-api
======
saidajigumi
This article is about Chrome's _implementation_ of the W3C Page Lifecycle
API[1]. In the long-term, this approach applies across all browsers, contrary
to the current HN title's implication that this is a Chrome-specific solution.

[1] [https://wicg.github.io/page-
lifecycle/spec.html](https://wicg.github.io/page-lifecycle/spec.html)

~~~
sctb
We've just updated the title from ‘Chrome’s solution to the “too many tabs”
memory problem’. There are many reasons not to editorialize titles when
submitting, and the likelihood of saying something misleading is one of them.

> _Otherwise please use the original title, unless it is misleading or
> linkbait. Don 't editorialize._

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
scrollaway
I don't think it's a bad edit. It would be better to have both, but "Page
Lifecycle API" doesn't actually tell you what that API is for --- it doesn't
even tell you it's a web browser API.

I think a better title would be: "Page Lifecycle API - A solution to the 'Too
Many Tabs' memory problem".

~~~
Fnoord
No.

"Page Lifecycle API" from "developers.google.com" gives a hint that the
article is written by Google and given "developers" is about an open source
(or open API at least) Google product, and presto in the first paragraph:
"[...] shipping in Chrome 68 [...]". The title is perfectly fine as it is.

------
philipwalton
Article author here. Most of the comments so far are talking about using lots
of tabs, but what I think is actually the most interesting part (or parts) of
the article hasn't been mentioned at all.

As I was doing my research for the article, I found a _lot_ of things that
really surprised me. And I feel pretty confident in saying that most web
developers aren't aware of these things either.

Here are my top four:

\- We shouldn't use the unload event. Ever.

\- The unload event often doesn't fire when closing tabs/app on mobile

\- The pagehide/pageshow events even exist (virtually no one I've talked to
knows what they do; most people think they're about page visibility).

\- In browsers that implement a page navigation cache, you can click a link to
navigate away and then navigate back with the back button, and all your JS
code is exactly as it was before you navigated.

To this last point. Try doing this in the console:

1\. Write a promise that resolves in a setTimeout after 5 seconds.

2\. After 1 second, click a link to navigate to a new page.

3\. Stay on that page for an hour.

4\. Click that back button.

5\. Your promise will resolve in 4 seconds!

~~~
CaliforniaKarl
You can see the last point in action on a number of places. I can think of two
sites in particular that pop up "You will be signed out in XX [decreasing
number] seconds unless you click 'Continue'." messages. I can come back to the
site's tab three hours later, and the countdown just started!

------
kbos87
“The Great Suspender” is a chrome extension that solves this very gracefully.
I came across it, showed a couple coworkers, and it spread like wildfire
inside my workplace, where everyone I work with spends their day split across
dozens of chrome tabs. I was wondering when this would become native to
chrome.

~~~
Hovertruck
This extension requests the following permissions:

\- "Read and change all your data on the websites you visit"

\- "Read and change your browsing history"

That's a lot of power to grant to a third party, especially on a work machine
where some of that data you're looking at may belong to your users.

~~~
reificator
I don't disagree, but I also don't know how you would build an extension like
that without those permissions.

How many applications are running on your work machine outside the browser,
with no warnings or significant[0] limitations?

[0]: [https://xkcd.com/1200/](https://xkcd.com/1200/)

------
scrollaway
Any sufficiently advanced web browser is indistinguishable from an operating
system.

~~~
zwkrt
You joke, but I've been thinking. Tabs were mind blowingly good UX when they
first came out, But with WebAssembly et al, are tabs still the right
abstraction?

~~~
mhink
This might be crazy, but... I think it would be kinda cool if tabs were a
Thing at the window-manager level. It’s sort of a reverse approach to solving
the Electron “problem”- instead of making web applications more like desktop
applications, make desktop applications (including browsers) work more
seamlessly together.

~~~
hoppelhase
That's what MS is trying to do with the "Sets" feature in Windows 10.

------
hnaccy
Don't know the details of how they handle this but going above 100 tabs in
Chrome proved to be too laggy and slow to be usable.

Meanwhile I've had 800+ tabs open in Firefox with no noticeable issues.

~~~
cabaalis
I've seen comments similar to this one often enough that I need to ask: What
is the use case for having that many tabs open, and how can you possibly
consume that much information?

~~~
istorical
If you're doing research and opening tons of articles, it's common that you
might want to go back into your browser history and reopen one of the last 50
things you might have opened but you might not remember the name of the page -
it's faster to hold command+shift (or control+shift on windows) and left-
bracket or right-bracket to page through tabs and glance at each tab for 2
seconds to see if it's the article you were trying to re-find as opposed to
opening up your history and clicking each, waiting for the tab to load,
realizing it's not that thing you looked at on Monday that you're looking for,
go back to history, check the next link, repeat.

In other words - this behavior is proof that there's room for improvement of
browser history UI.

~~~
hnaccy
>In other words - this behavior is proof that there's room for improvement of
browser history UI.

Definitely. Firefox's built-in history browsing UI is frankly horrible.
Norwell History Tools was better but is no longer supported.

~~~
petert_1
Have you ever used chrome's default history browsing UI, it's even worse.

------
xg15
> _If I can 't run asynchronous APIs in the frozen or terminated states, how
> can I save data to IndexedDB?

[In the future, we will add a commit() method to perform write-only
transactions that don't require callbacks. (assuming the IndexedDB database is
already open).]_

This seems like a strange design. So there is a callback specifically for
persisting data before freeze, but when it runs, the main persistance API
isn't actually available.

Wouldn't it have been possible to mark IndexedDB callbacks as "non-freezable
tasks" \- or allow a promise to be returned from the freeze callback? (Subject
to a timeout)

> _For code that needs to work today, however, developers have two options:

\- Use Session Storage [...]

\- Use IndexedDB from your service worker [...]_

I guess session storage is technically a workaround - but it seems odd, as
almost everywhere else you get the recommendation to use IndexedDB instead.

I guess a strategy could be to simply dump all your unsaved data into session
storage on freeze, and then "properly" load it into IndexedDB on the next load
or unfreeze. Still, this seems complicated and subject to problems if your
data exceeds the maximum storage size.

------
indentit
Am I the only one concerned that this seems to give web pages more ways to
track your activity? How long you had the page visible but not focused for,
how long it was hidden for etc. So a web site could display an advertisement
video and it would automatically pause if I'm doing something else to force me
to sit through it to continue using the site etc.

------
saagarjha
Looks a lot like the lifecycle of an Android or iOS app–it's a good thing that
websites can now be prepared to be forcefully unloaded in the background since
it builds in resilience and reduces wasteful use of resources in the
background.

~~~
megaman22
Most websites shouldn't care, because they should be static html, and the
dumping them to disk and reloading them shouldn't make a whit of difference.

The rest should probably be an actual application.

------
mschuster91
Semi-OT: I'm one of these guys with ~200 tabs open spread over 5 different
Chrome user profiles (work plus one session per Twitter account, as I can't
stand Tweetdeck or any other app). Once an hour some tab, usually it's Twitter
or a specific newspaper, will run amok in the background and run up to 100%
CPU usage until I manage to launch the Chrome Task Manager and kill the
offending tab (group, sometimes).

Is there any way to force Chrome to totally inactivate all tabs in the
background, with a whitelist option so Youtube and friends can run?

~~~
detaro
I think that's pretty much what "the great suspender" does:
[https://chrome.google.com/webstore/detail/the-great-
suspende...](https://chrome.google.com/webstore/detail/the-great-
suspender/klbibkeccnjlkjkiokjodocebajanakg)

------
deagle50
Meanwhile, we're still waiting for the "too many tabs" UI problem to be
addressed. The had a hidden side tabs option that looked promising but got rid
of it.

~~~
ant6n
For starters, wie need search among open tabs and windows

~~~
yjftsjthsd-h
In Firefox, go to the location bar and type in "% foo" and it will search for
foo in open tabs (the space is required). I have no idea why this isn't
documented better; it's a lifesaver.

------
theabacus
I thought the strategy was always to to create a bunch of threads so it’s very
opaque what chrome is actually using.

That is to say, I’ve only seen chrome get worse in this regard.

~~~
alyandon
I had to recently increase my user noproc ulimit because Chrome was spawning
so many background threads that it was hitting the limit and causing all my
applications to crash/behave strangely. On a system with (only) 4GB of ram,
Chrome is such a resource hog that it is almost unusable without Tab
Suspender.

~~~
kingbirdy
Why not use a more lightweight browser then?

~~~
alyandon
I generally use Firefox as my main browser. However, I've been leaning on
Chrome while the whole post-XUL extension apocalypse settles down and session
managers in Firefox are back on par to what they were prior to the switch to
web extensions.

~~~
newscracker
I very much miss Session Manager (from Mozdev) on newer Firefox releases. The
WebExtensions based session management extensions are still not as rich or as
reliable as that one. So on machines I control, I use an older version of
Firefox so that I can rely on Session Manager and a few other extensions from
the XUL world.

Firefox 52.x ESR, which does work with XUL extensions, would remain a
supported choice until September 2018 (a couple of more months from now).
After that, there wouldn't be a Mozilla supported browser that's not
exclusively WebExtensions based, AFAIK.

------
greggman
the left half isn't talking to the right.

the webassembly / webgpu / webvr people are trying to bring multi gigabyte
games to the web and the page lifecycle people are trying to make it so every
time you put that.tab in the back you have to wait several minutes for the
data to reload.

------
rasz
This is terrible, just suspend, and dump to disk if you need more memory, this
should be transparent to websites.

or, you know, start optimizing. Opera 12 used to render websites using 5-10MB,
same websites took 50-100MB in Chrome.

~~~
gsnedders
> This is terrible, just suspend, and dump to disk if you need more memory,
> this should be transparent to websites.

How do you transparently suspend a site that has a setInterval(foo, 1000)
running?

~~~
rasz
Same way you suspend a laptop, dump whole state to disk.

------
IshKebab
Oh god. They didn't learn anything from Android's lifecycle insanity then.

------
dmitriid
It's the umpteenth "standard" to be pushed by Chrome in early draft form only
to ship it a few days or a few weeks after publication.

~~~
philipwalton
This isn't true. The proposal was discussed many times in the WebPerf working
group and went through a TAG review before shipping.

Microsoft made a public statement of support for the API, and Firefox
engineers were actively involved in many of the design and implementation
discussions.

You can read more details in the Intent to Ship thread here:
[https://groups.google.com/a/chromium.org/d/msg/Blink-
dev/Na7...](https://groups.google.com/a/chromium.org/d/msg/Blink-
dev/Na7aTFJOpWs/_tpdtav8CAAJ)

