In principle, the idea of stopping a script/tab in the background from taking over the browser is a good one.

In practice, however, a blanket algorithm that just goes "hey, then NOBODY in the background gets to run" is stupid. Baby-bathwater, or Sesame Street's story of banning all words that begin with the letter 'P', or whatever metaphor you want to use, it is all the same.

When it works, to stop aggressive advertisements, it is fine. But hey, many of us just use ABP to get rid of a lot of them (btw, pages with ABP detectors: when ABP tells me that it blocked 57 scripts or images on your site, that tells me you've too much advertising and no, I'm not going to read your article with it off).

When it doesn't work is when it works too well because it works when you don't want it to.

I have 3 use-cases, two very similar, where the throttling has halted my workflow.

Blogs: I have Feedly as my RSS reader for following blogs. Some site's RSS feeds don't include the whole article, but rather require you to click to read them later, and they open in a new tab. Because it takes time to load the article, the images, the framework of the page, and the advertisements, and the page won't render until all of them are in (classic Table layout may be gone, but the effects remain: until all images are loaded and scripts run, it doesn't render the text).

I don't want to sit through that. So I go back to feedly to click to the next article, and if it is a blog entry I repeat.

Before? no problem. I've been living this lifestyle for years, through 4 different RSS readers.

Today? At least 2 of the sites I visit regularly won't render. Their scripts detect a timeout in loading the content and initializing, and so render instead an error page. This forces me to reload, and to have to WATCH... IT... SLOWLY... LOAD... THE... CONTENT... LIKE... IT... WAS... 1998... AND... I'M... STILL........ ON...... 2800... BAUD...
because if I background the tab, the error page renders when I finally come back to it.

This is especially necessary for me when I'm on public WIFIs that already are throttling throughput, or there's no wifi so I'm hotspotting off my cell phone's 4G.


Webapps: Service Workers and PWAs aren't the norm yet, especially for desktop-based web applications. Today's webapps can be large, often implemented in javascript-heavy frameworks like Angular, Sproutcore/Ember, React, even Google's on Polymer.

Those scripts take time to load and execute, no matter how compressed they are. Some web applications are just huge. This is not a bad thing. Customers know what to expect in the initial load in exchange for all the features.

Web applications, even after the scripts run, tend to load a lot of JSON data as well, all of which requires parsing and conversion into Javascript objects (or more complex objects for MVC frameworks like Ember and Knockout).

That takes time.

That is something I would fire off in a tab, and let it run in the background while I keep reading my blogs or answer questions and comments on my issue tracker.

Today, I come back to my webapp 10 minutes later and find it hasn't even finished initializing the code, nevermind actually running all of the fetches of the initial data load.

Even server-side rendering in react isn't going to help because it still needs to send down the code and the raw data, even though it has at least given you a 'first page' pre-rendered. You're still stuck waiting.

And just like the blog entries, you have to WATCH IT run or else it doesn't.

Client Polling: Some web apps have client-side based polling of the server, because the server framework is too well established to attempt to add server-push or webworker code. They would use setTimeout or setInterval. Now, there's no guarantee that the timeouts actually run on time, since the presumption by Chrome is that setTimeout is only being used for animation and who needs that if it is off the screen. An app may take the seeming lack of a reply as a case of "the server broke down" rather than "the client is running at 1% of what it should be running as", should they have a monitor of their polling system trying to determine if there's no result or if the server simply didn't reply because of a network disconnect (still more common than people like to admit).

So yeah, the throttling has its use cases, but so does NOT throttling background tabs.

So can you turn it off? It looks like it.

  • Go to "chrome://flags"
  • Search for "Throttle expensive background timers"
  • Set it to 'Disable'

So that's what I'm doing until Chrome decides to improve their algorithm to figure out what is and isn't an abusive script in a background tab. And even this doesn't always seem to work (TweetDeck didn't init for me properly when I had it in the background), because even without JS throttling, it is also garbage-collecting the DOM state and only storing the 'last html', which means flipping back to the tab still requires it to suddenly redraw everything from its last known state...which is, of course, not the state the data might actually be in anymore.

Some scripts aren't abusing CPU: they are the very scripts we WANT to run. The web is more, much more, than just buzzfeed articles and porn sites with 58 advertisements...

...and for a company that has been driving the web application standards for the last 10 years, and have the primary platform people use for them, Google should know about that.