Hmm FrameHostMsg_ContextMenu is using 950ms on the browser *main* thread. That would definitely cause everything to go wonky --- chrome is only as fast as its browsermain can go.

I think there's a couple things here:

1. There might be chrome side bugs here causing excessive CPU usage. Someone needs to dig into these traces to understand if there are bugs we need to fix.

2. Re: loading spinner UI, I filed issue 695714 to track considering changing how the spinner works.

3. We have a close to shipping intervention where we throttle background tabs to 1% CPU wall time. That should make this experience considerably better from a CPU perspective (#expensive-background-timer-throttling in about:flags). It will take the background tabs longer to load, but they shouldn't jank up your computer and the baseline when they settle should be low. There's some caveats the limit the efficancy of the v1 of this feature, but we have plans to work through those over time.

altimin: Can you confirm that enabling the time-based task throttling mostly addresses the CPU usage issue? If it doesn't, I'd like to understand why.

I wonder if the background renderers are getting backgrounded properly? As long as their priorities are correct, the OS should make sure they won't jank up the foreground tab (modulo browser-side funny business).

There are a number of things going wrong here:

1. Heavy pages using a lot of CPU.
2. We do not throttle timers for first 10 seconds in the background.
3. We do not throttle loading tasks and there are a lot of them.

So while budget-based timer throttling is going to help, it won't solve the problem completely. I have an approximate plan in my head about next steps here.

I do notice that the browser-side cpu is pretty swamped just from all the requests coming in from the tabs. Kinuko and I were talking the other day about the need for proper prioritization of IPC etc, and maybe this is a strong example of why we need it.

Re: c#4, OS-level renderer backgrounding is an experiment right now on macOS.

Interesting. I see the tabs sending really lots of resource loading requests (in addition to other requests), competing browser-side cpu and network resources fiercely with other tabs.

Regarding the chromium side bugs, I have a few observations:
1. If you do the repro steps in the original post in safari, scrolling isn't janky at all.
2. It's not just politico. Go to https://www.google.com/search?q=morning+melatonin and open the first four links in a background tabs. The search page becomes pretty unscrollable. Again, there's not perceivable degradation of user experience in Safari for this case.

I suspect the main reason that Safari stays responsive is that each background tab goes in its own process, whereas Chrome puts them all in the same process. If we're going to do that, then we need to invest in making it so that we do better CPU coordination between the tabs.

Throttling background tabs to 1% is a good initial improvement there. Long-term, Global Resource Coordinator might be a better solution that keeps background tab loading fast without degrading foreground tabs. In the meantime, should we consider tweaking our process logic?

Should this be higher than P3 given how bad the user experience is compared to at least one other browser and that opening tabs in the background isn't really a rare use case.

Ignore my last comment. I was actually just seeing another instance of issue 698556. If run in an incognito window, the experience is reasonably close to Safari. If I run in incognito with ghostery enabled, it's awful (e.g. >10 second janks trying to scroll foreground tab).

komoroske: I suggest you try your original repro steps in an incognito window. I'd guess one of your extensions is killing your perf. I filed issue 698556 to track that problem.

Available, but no owner or component? Please find a component, as no one will ever find this without one.