1. 11

  2. 8

    Chose this article on the feature because he includes an actual example, though I’ll admit feeling schadenfreude at his lamentations that he has to care about performance when my browser regularly kills cpu and battery because of bad sites.

    1. 5

      From the article:

      Avoiding expensive CPU work is not a panacea; that some applications must do significant work in the background, including syncing data, reading delta streams, and massaging said data to determine whether or not to alert the user.

      WTF. These things aren’t expensive, especially at web-scale where you’re dealing with kilobytes of information, unless you’re being an unbelievable idiot about it.

      Lately I’ve been hoping one of the big browser vendors would announce they’re going to start immediately killing any tab that uses more than 1 second of CPU time. This change is amazing, I just wish they would make it operate on foreground tabs too.

      1. 1

        I totally agree here. Neither Slack nor Discord nor any Bitcoin chart website has to do any “processing” that’s a notable workload for any processor today. Heck, Javascript is fast. If yours is slow, it’s likely your own fault (or the fault of multi-megabyte framework you’re using).

      2. 3

        Gone are the days when you could count on timers to fire semi-reliably.

        Is it not a common opinion that relying on timers to fire reliably at all is not a good idea? Try making a game in the browser and you will quickly learn that relying on setInterval to call your main tick function doesn’t work out as you expect – instead, it’s better to use setTimeout, and then each time tick is called, you use a time delta to adjust how your render function operates. Can the same approach not be used for background work that needs to be time-synced?

        1. 2

          Well, someone seems worried about a Firefox comeback…

          1. 2

            I’ve been using https://github.com/deanoemcke/thegreatsuspender for a while to automatically suspend tabs I haven’t used recently. It made a noticeable impact on Chrome’s battery usage.

            1. 2

              I’ve had tabs open for several months thanks to The Great Suspender. My open tabs are my reading list now, no more hidden bookmarks or TODO list. If Chrome crashes and I lose it, NBD - it’s something I’m OK declaring bankruptcy on every now and then.

              1. 1

                I turn on the “Open my previous tabs” setting and also use a tab saving extension. I have still lost my tabs at some point, I think Chrome crashed while it was exiting? Anyway now about once a week I manually save my tabs as well via the extension and I’m happy with it.

            2. 2


              Anyway set{Interval,Timeout}() drops to 1hz on an inactive tab already and has for some time (FF, Chrome, Safari and IIRC both Edge and IE9+).

                1. 1

                  Thanks, fixed.

                  1. 1

                    Sorry about deleting it, I forgot about the merge story feature.

                    1. 2

                      It doesn’t appear to have broken anything, don’t worry about it. :)

                2. 1

                  Here’s the original proposal with a link to a design document. It looks like tabs that are playing audio are considered “foreground” for this purpose, so listening to audio/YouTube/etc. in another tab should still work, even if the player takes quite a bit of CPU.

                  Edit: From this comment it sounds like there will be additional exemptions as well, e.g. tabs with an active websocket connection will also be treated as foreground. That comment also clarifies that this is currently scheduled for Chrome 57 rather than 56 (i.e. in about 2 months, not 2 weeks).

                  1. 1

                    Oh, great, this reasonable improvement can be circumvented if you play an endless loop of silence.

                    1. 4

                      At least this will be visible in the UI (with a small speaker icon in the tab ui) so users can easily spot and block this.

                      Harmful behavior like this might also cause the chrome team to make playing audio an opt-in permission (which I’d actually like to see)