So here are some additional comments on this issue. Plus two additional ways to replicate the issue. Attached are: a chrome extension; two videos displaying behavior. Apologies for the speed on the videos, they are about 2x regular speed.

Method 1 to replicate the issue:
1) Install "Test bug fix 808747" Chrome extension in developer mode.
2) Open up 10-15 tabs of Yahoo.com.
Expected behavior: Each tab reloads quickly, without lag.
What went wrong?: Tabs hang. Clicking on a tab suddenly makes it stop hanging.

Method 2 to replicate the issue:
1) Install "Super Auto Refresh" Chrome extension.
2) Browse to a complicated site, such as Yahoo.com.
3) Enable refresh for every 30 seconds.
4) Open up 10-15 tabs of Yahoo.com.
Expected behavior: Each tab reloads quickly, without lag.
What went wrong?: Tabs hang. Clicking on a tab suddenly makes it stop hanging.

Attachments:
Test bug fix 808747: Simple Chrome extension to replicate behavior.
Video 1: Using attached extension - Example behavior using an existing (sparingly used) profile.
Video 2: Using attached extension - Example behavior using a new profile.

Deleted: Test bug fix 808747.zip 1.7 KB

Test bug fix 808747.zip 1.7 KB Download

Deleted: Issue 808747-2.ogv 5.3 MB

	Issue 808747-2.ogv 5.3 MB View Download

Re-attaching Video 1

Deleted: Issue 808747-1.ogv 12.4 MB

	Issue 808747-1.ogv 12.4 MB View Download

Attached are two more videos. It looks like CPU usage may be the culprit. Open 20 tabs on http://localhost/, no issue. Open 20 tabs on https://yahoo.com, high cpu and tab lag.
Video #3: Running on Yahoo.com. 
Video #4: Running on localhost.

Deleted: Issue 808747-3.ogv 19.4 MB

Issue 808747-3.ogv 19.4 MB Download

Deleted: Issue 808747-4.ogv 4.2 MB

	Issue 808747-4.ogv 4.2 MB View Download

Note that the videos only play for about half of the video length but play at 2x speed. This is an issue with the video recorder (gtk-recordMyDesktop). That is, the second half of the videos are blank.

So the issue is this:

1) Create a large JavaScript extension. That is, script.js is at least a few megabytes. 
2) Allow the extension to load on a "complex" site, such as Yahoo.com.

Expected behavior: Prior to the latest Chrome update, this would run effectively.

What went wrong: With latest update, the extension's JavaScript code lags considerably.

Tried testing the issue on Win-10 using chrome reported version #64.0.3282.140 but unable to load the "Test bug fix 808747" extension due to the error as in the attached screen cast.

reporter@ - Could you please check the attached screen cast and please provide any other extension to test the issue from TE-end.

Thanks...!!

Deleted: 808747.webm 7.7 MB

	808747.webm 7.7 MB View Download

Oops - good catch

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Attached are two screenshots of the behavior. The screenshots are taken when replicating the behavior as noted below. Screenshots are of the Profiler which is running in the erroneous tab. Both screenshots display the same profile, but one screenshot has a higher zoom level.

Notes:
1) At 5000ms the tab leaves the previous page. As shown in the Profiler screenshot, the window becomes "blank".
2) At 45000ms, I switch back to the tab, in order to end the experiment.
3) At 45000ms, the tab then loads the content on the page, which is shown in the Profiler screenshot, when the page has a grey bar across it.
4) When the page loads at 45000ms, a timer on the page registers as starting at 0 seconds (page DOM and JavaScript does not realize it has been here for 45 seconds!).
4) Note that nearly 48 of the roughly 50 seconds that the tab is profiled, the tab is considered idle.
5) At roughly 12000ms a Chrome extension executes ("Chrome extension #1").
6) At roughly 17500ms another separate Chrome extension executes ("Chrome extension #2").
7) At roughly 26000ms, garbage collection is run twice (Major GC, DOM GC).

How to replicate:
1) Not all tabs show behavior.
2) Thus, find a tab exhibiting behavior.
3) Turn on Profiler via Chrome development tools.
4) Hit F5 on the tab and quickly switch to a different tab.

What happens:
The tab hangs indefinitely. Upon switching back to the tab, the tab loads the page. Regardless of how long the tab has been hanging, when the document on the page has loaded it sees itself as being loaded for "0" seconds (it was not loaded until switching to the tab).

Deleted: Screenshot from 2018-02-06 14-53-55.png 91.8 KB

	Screenshot from 2018-02-06 14-53-55.png 91.8 KB View Download

Deleted: Screenshot from 2018-02-06 14-53-10.png 75.5 KB

	Screenshot from 2018-02-06 14-53-10.png 75.5 KB View Download

Experimenting with using an SSD disk rather than SATA hdd for disk cache. Via command line: --disk-cache-dir=/location_of_ssd/. By the way, Chrome is also running with the tag: --allow-running-insecure-content.

Still seeing the behavior with --disk-cache-dir. Will try --use_virtualized_gl_contexts=0 next.

Could you try again with --disable-background-timer-throttling? If this makes the problem go away, then I think this intended behavior: in order to reduce power consumption, Chrome allocates a CPU time budget for background tabs. If they exceed it, some tasks (e.g., timers) on the background tab will be delayed to reduce their CPU cost. If a page reloads constantly this can make it take a longer time to finish.

As per comment#15 adding label Needs-Feedback and requesting reporter to try accordingly and mention its behaviour.

Thanks!

Here is a possible solution! (Sorry, have not yet tried --disable-background-timer-throttling.)

For quite some time (for at least one or more years, up until this bug became apparent in January) I had been running Chrome with a certain command line switch, which happens to be (--use_virtualized_gl_contexts=0). But this was always from the command line. After a system upgrade in January, Fedora's bash history was removed. It took from then until just a few days ago to realize there was a missing switch I had been using to start Chrome (--use_virtualized_gl_contexts=0). (It has been so long using this switch that the exact reason for why I first began using it has become a bit hard to remember. But thinking back now, it may have had sometime to do with video card issues, wherein the temporary solution back then--before finding use_virtualized_gl_contexts=0--was to use chrome://gpu-clean command every so often. Actually, yes, the previous issue--and reason for using this switch--was laggy pan/zoom behavior in an iframed window of Google Maps.) At least temporarily, using the switch (--use_virtualized_gl_contexts=0) appears to solve the issue. (Also tried was removing Chrome's cache via chrome://settings, which at the time of removal was above 300 megabytes.) Recently, the issue has appeared on a Windows machine (will report back on troubleshooting this).

One other thing: There is now an issue where an entire window of tabs will suddenly die. Although the tab will not display the "bones" tab icon, every tab in a given entire window of tabs will turn dark grey (similar to the background color of a pdf in Chrome). Closing the offending window and re-opening it with CTRL+SHIFT+T restarts the window/tabs.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Confirmed: Issue occurs on Windows machine.

Confirmed: Command line argument (--use_virtualized_gl_contexts=0) fixes the issue.

Note: In both cases (in Linux and Windows environment), Chrome is also running with --allow-running-insecure-content arugment.

Will check back in with Windows version / Windows Chrome version.

Just had a troubleshooting session with the Windows machine. Command line argument (--use_virtualized_gl_contexts=0) was not working. Browser tabs were very slow or completely stalled. Tried: Cleared the browser image cache (700 MiB). Did not appear to help. Finally, tried loading in the browser the URL: (chrome://gpuclean). This is the URL which, a long time ago, was useful in dealing with this speed issue in Chrome when seeing significant lag using Google Maps (mentioned previously, Comment 17). Also tried (chrome://gpuclean) on the Linux machine recently, although at the time it seems as though it had not helped. (Was it the solution for the Linux machine?) After chrome://gpuclean (which was after cleaning the cache to no effect) the Windows machine is running smoothly.

@Reporter: It is understood from your comment#19 and #21 that the issue seems to be resolved, Could you please let us know if we can close this issue.

Thanks!

The fix for the Windows machine is in fact to disable the cache altogether via two command line arguments: (--disk-cache-size=0 --media-cache-size=0) !!!
	
Does this mean the issue is "fixed"? Or is it just ignoring some underlying issue? Is it fixed if some major part of the program (the media cache is major, correct?) has to be disabled in order to run? That part of the program - the media cache - is definitely not fixed if it is not even present as a feature.

To recap on the Linux machine: The fix for the Linux machine in fact appears to also be related to altering the cache. The command-line argument used is (--disk-cache-dir=/location/of/ssd/drive), whereas typically on this machine (Fedora) the disk cache is (probably) loaded in .config (a regular disk drive) !!! That is, moving the disk cache to an SSD drive. But in any case, in the future it may be wise to disable the cache altogether (following the lead of the Windows machine)!

Personally speaking, it feels that this issue is not resolved, that by passing command-line arguments to solve the issue is simply bypassing some underlying problem. But of course it's up to the authors of this software (Chrome) as to whether or not they want to consider this issue to be resolved.

Nonetheless, thanks so much for your help thus far!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

To make an analogy:

Pretend that your oven is not working. Let's pretend the issue is that it will not turn on. So a technician comes over and diagnoses the problem. They find out how to get the oven to turn back on--voilà! All set. It turns out that all that is necessary to get the inside of the stove "working again" is to disable the stovetop burners. Okay. Great. But then half of the stove does not work. Of course this is not half of the program, just a little slice of it. But the point seems to remain.

@Reporter: Please try to test this issue on latest chrome stable# 66.0.3359.170 and let us know if the issue still persists, you can download latest chrome stable from the URL: https://www.chromium.org/getting-involved/dev-channel.

Thanks!

As there isn't any info/Feedback from reporter since long time, hence closing this issue and marking it as Won't Fix.

@Reporter: Please feel free to file a new one if the issue still persists.

Thanks!