High-level proposal doc https://docs.google.com/document/d/1VnlO_yV-mDjj9Gi2KjK0HGKOUGKOIS1Jvbt_PeQmOlE/edit#

Intent to Implement
https://groups.google.com/a/chromium.org/d/topic/blink-dev/iS0Szd-GD7E/discussion

v0 design doc
https://docs.google.com/a/chromium.org/document/d/1mf3pMcl4mvi8ew0h0KVAMVATQipNV3ERSp9WrtlPGrU/edit?usp=sharing

may be blocked on 734165, or find another way to go without depending on it.

No please. I don't want this. I would like to have my tabs load at the same speed.

Do you have any real use case that was badly affected by this feature?

We gather data for months from the real world use cases, and data says that this experiment have positive impacts for the most cases.

Foreground page loading speed is of course improved, but actually even background page loading have good impacts. E.g., in the most case, when users pick up a background tab, the background tag already finished loading. Otherwise, the newly activated tab can finish unfinished loading faster than without this throttling.

This is slowing down the editing interface in Squarespace very harshly.

The warning messages themselves are annoying.

This policy triggers for a page with 1 stylesheet, 1 module, and 1 image totalling no more than 20kB, so it surely applies to 99.9% of all pages which exist.
It's a false/nuisance alarm which means nothing more than "you opened a link in a new tab".

c18:
Do you know how the site implements the editing interface? This throttling should not be triggered if the tab is actively used. If you are seeing a frame is throttled even if the page is foregrounded, something is wrong, and that means the frame is throttled not only for loading, but even for JavaScript executions and so on.

c19:
Thank you for considerable feedback. I aggressively show the messages in the initial release because it's better than silent when people feel something is wrong after the Chrome update. I will incrementally update the condition to show the message.

https://bugs.chromium.org/p/chromium/issues/detail?id=883294 is the first update.

Probably my second update is to show a console warning when
 - A request was throttled on background.
AND
 - When a page is brought to the foregrounded, throttled requests are still in the queue.

I don't see anything specifying what these limits actually are. I don't even know if it's a formula or a fixed number, or whether it's based on the number of resources or memory.

Also, are the parameters settable?

 Issue 898005  has been merged into this issue.

In response to Comment 16: "Do you have any real use case that was badly affected by this feature?"

I've run into a problem in local web development due to this feature. I frequently work in my code editor and allow the browser to auto-reload using a watch task. Since the browser is not focused, the per-frame limit is reached. As a result, (pre-)fetching is prevented until I focus the browser, meaning I'm unable to see what's occurring in the site I'm developing.

I set the "Enable Resource Load Throttling" flag to disabled, but understand that this option to disable will soon be removed. The console message itself isn't an issue (in fact it's helpful), but not being able to disable the throttling would be pretty disruptive to the development workflow.

Perhaps throttling could be disabled for tabs where Chrome Devtools is open?

Update: I'm still experiencing the issue after disabling "Enable Resource Load Throttling" in flags. Additionally, on fetch timeout, an error is thrown, requiring a full reload.

Is there any other way to disable Background Tab Resource Load Throttling?

Just to make sure I'm posting this on the correct thread, the console message that explains the behavior is pasted below.

"Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details"

> Since the browser is not focused
Do you mean your page under development is in a background tab, or just means Chrome' window is not focused because you are working in the editor?
If the page is in a foreground tab, resource loading should be free from throttling regardless of the Chrome Window's focus.

Also, if you set chrome://flags/#enable-resource-load-scheduler Disabled, it should disable the throttling completely. So if you still see it, something is wrong. I mean that console message should be shown only when the flag is Default or Enabled. Are you sure it happens even after setting it Disabled, and relaunching Chrome?

If you can attach a minimized repro set, it would help.

Also the Milestone should be updated to be M-69 that rolls out the feature by default over our field trial infrastructure.

Also I'd note that m69 had an issue that could break loading in a specific case, https://bugs.chromium.org/p/chromium/issues/detail?id=891940

I'm running into an issue with this and DevTools in Chrome 70.0.3538.77

DevTools is undocked and it seems having the DevTools window obscure the browser window triggers the throttling which is far from ideal in this use-case

Seeing multiple instances of this message in the console

Active resource loading counts reached to a per-frame limit while the tab is in background. Network requests will be delayed until a previous loading finishes, or the tab is foregrounded. See https://www.chromestatus.com/feature/5527160148197376 for more details

As an update to #31

It only happens when the DevTools window complete covers the browser window, if the browser window is partially visible then the warning doesn't appear (and presumable throttling doesn't happen)

Hi,

I'm having some issues with my PWA in standalone mode where Chrome doesn't completely load the required resources. It either hangs on the PWA's splash screen or it does get past that but doesn't run my scripts.

The best way to reproduce this issue is for me to force close Chrome, then start the PWA. Unfortunately, that prevents me from getting a look at the network tab because that only records things when the dev window is open - and I can't open the window via device inspector before chrome runs again.

I had a look in the Sources tab and it revealed an empty index.html and some missing scripts.

There was another issue in a previous version of Chrome where the window.prompt() wouldn't fire in PWA standalone mode on phones (it weirdly did work on tablets) because Chrome thought the window/tab was in the background:
https://bugs.chromium.org/p/chromium/issues/detail?id=875595

Is it possible that something similar is happening here?

Reg #32
+altimin@: Is it possible that hidden frames are in throttled state?

Reg #33
I do not think your issues are related to this feature.
Can you try it with chrome://flags/#enable-resource-load-scheduler being Disabled?

@#c34 I tried disabling it and haven't seen the issue since then (3~4 days).. that said, reproducing it is kind of hit-and-miss so I'll keep it like this for a while, then turn it back on and see if the issue returns, then report back.

Hi,
I think I have a related issue in gmail tab. Gmail stops working showing error 007# and chrome console shows:
Active resource loading counts reached to a per-frame limit while the tab is in background. Network requests will be delayed until a previous loading finishes, or the tab is foregrounded. See https://www.chromestatus.com/feature/5527160148197376 for more details

#37, did you ensure that the issue still happened even if the flag is changed to Disabled? (See #34) The console message is shown very often, but it does not change any behavior. It just informs that loading went slowly while the tab was in background. When you see the message in DevTools, there is no limit because the tab is already in foreground.

Feedback sent 8:30 am EST

[first line/title] Maybe the cause? https://bugs.chromium.org/p/chromium/issues/detail?id=723233 

https://www.tide-forecast.com/locations/Longboat-Key/tides/latest

This URL is bookmarked > 3 finger click or 2 > open in a new tab.

It is supposed to show a red dot for the time of day in the tide chart.

When first opening > the dot does not show. Click on bookmark again > second time opening works.
Same can be achieved by refreshing the page.

BTW, this happens for mail.google.com. SOMETIMES.
First open does not populate all the labels.
I usually open a new tab > type m > https://mail.google.com/mail/u/0/#inbox

It started happening in Beta 70 and continues in Dev 72

Google Chrome	71.0.3578.27 (Official Build) beta (64-bit)
Revision	d7850e07856a010c464bc7ea52e4ee10ca5965ce-refs/branch-heads/3578@{#361}
Platform	11151.17.0 (Official Build) beta-channel caroline
Firmware Version	Google_Caroline.7820.384.0

Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See <URL> for more details
latest:4 Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details
container.html:8 Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details
container.html:8 Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details
container.html:8 Active resource loading counts reached a per-frame limit while the tab was in background. Network requests will be delayed until a previous loading finishes, or the tab is brought to the foreground. See https://www.chromestatus.com/feature/5527160148197376 for more details

This seems to be the part that does not work on first try:
or the tab is brought to the foreground

Sometimes ctrl + R works, sometimes not
ctrl + shift + R works
New tab > open URL again works

Previous feedback sent for the Gmail labels not loading.

Beta 71 feedback sent.

[first line/title] Failure to load labels in Gmail. Caroline Beta 71
Nov 2, 2018 7:55 am EDT

Some newer emails have labels. There are 5 in my attached screenshot.

In the screenshot included with this feedback there are 8.

1. open an email > while the email was open > label appeared

2. open another > label was not added > close email > label appeared in the list

This also happened in at least the last 2 Betas 70.0.3538.69 and 70.0.3538.69 [edit] 70.0.3538.76 (clipboard failure)

Previous feedback Oct 23 
Gmail labels do not always show.

Not sure if this crash report has anything to do with it.
Uploaded Crash Report ID c471bc8f0309e582 (Local Crash ID: ChromeOS_ARC)
Crash report uploaded on Thursday, November 1, 2018 at 7:37:23 AM

Google Chrome	71.0.3578.27 (Official Build) beta (64-bit)
Revision	d7850e07856a010c464bc7ea52e4ee10ca5965ce-refs/branch-heads/3578@{#361}
Platform	11151.17.0 (Official Build) beta-channel caroline
Firmware Version	Google_Caroline.7820.384.0
Customization ID	SAMSUNG-CAROLINE
ARC	5090785
JavaScript	V8 7.1.302.11
Flash	31.0.0.135 /opt/google/chrome/pepper/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; CrOS x86_64 11151.17.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.27 Safari/537.36

All the emails in this screenshot below the first 5 should have the same labels.

Deleted: Screenshot 2018-11-02 at 7.34.28 AM.png 346 KB

	Screenshot 2018-11-02 at 7.34.28 AM.png 346 KB View Download

I heard that gmail issues are not related to this feature, and another team works on a fix.

For all other reporters, please consider to check if your issue happens even with hrome://flags/#enable-resource-load-scheduler Disabled before reporting new issues in this thread. Many scheduling/throttling/lifecycle related changes were made around recent stable releases, and in most cases, this is not a right thread to report your issue (though only this feature is easily found by console warnings)

I slightly modified https://www.chromestatus.com/feature/5527160148197376 so that users can find a way to identify if the issue is caused by this feature.

I started experiencing this issue after a chrome update this week. The problem is in debugging a angularjs webpack application with VSCode using chrome. The problem I am having is with browsersync page refresh after a file is changed and my console in the IDE is filled with hundreds of these warnings. To resolve this issue I edited the VSCode launch.json config settings for property "runtimeArgs" and add the value "--enable-resource-load-scheduler=false" to suppress the message spam.

Re#43
Thank you for the tip. We will fix too many warnings issue in m72, but until it is rolled out, it would be a workaround. Also, filtering out info level messages would work if you do not use info level messages for your developments.

console message change will come; https://chromium-review.googlesource.com/c/chromium/src/+/1333587

It shows console message only when the request is stacked in the throttling queue beyond an expected timeout period.

I am seeing "page unresponsvie" while loading drive.google.com (see crbug.com/912176)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/07c5ec358e2051a725af0475e401e06c6066480d

commit 07c5ec358e2051a725af0475e401e06c6066480d
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Wed Jan 23 07:51:43 2019

ResourceLoadScheduler: Show console info only when it's informative

Current console info messages are not informative because it's shown so
often, almost every time when the frame runs in background.

With this patch, the message is shown only if the top request in the
queue hasn't been sent in the last 1 minute when the frame is brought
to the foreground.

Bug: 723233
Change-Id: I6fe15b3f6928701e2858cadd0d7eb9e5c64327c6
Reviewed-on: https://chromium-review.googlesource.com/c/1333587
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#625123}