The biggest culprit appears to be https://wired.disqus.com/embed.js which is called every 4-5ms, there are a few others on a 100ms timeout basis.

Adding Burak from Disqus.

https://www.wired.com/cns/services.min.js is also running every ms or so. It's hard to believe that this is desired behavior.

Are you sure it is us? I'm looking at this page with Firefox and I don't see any excessive calls to Disqus. I see a bazillion calls to https://capture.condenastdigital.com/track?_ts=... though and it is crawling Firefox to a halt too.

Also to reassure you, we don't reload embed.js periodically ever and we even try to detect it when people load it multiple times and quit early to avoid potential memory leaks and functionality issues.

Perhaps, we broke something or there is something behaving differently on Chrome (e.g. first party behavior leading to unexpected tight callbacks to a function in embed.js). 

I'll try to take a look at it in other browsers.

Alright. LMK if you need me to investigate more using Chrome or something else.

Looking at this with Firefox, I'm seeing frequent callbacks to the following function in disqus embed.js :

 t = function (a, b, c) {
    var d = function () {
      var e = a();
      return e ? void b(e)  : void setTimeout(d, c)
    };
    d()
  },


Where c is apparently undefined.


Burak: any idea why this would be called with an undefined c parameter? Could it be a misconfiguration on wired's part?


Conditions:
 Firefox 52, Windows, Developer tools opened, Responsive design enabled (with Viewport adjusted to 768x1024).
 
 Chrome 56, Windows, Devtools opened, Responsive design enabled (Nexus 5x settings).

Responded via private e-mail with a code sample.

Kenji, Burak, any updates here?

I looked at what Burak shared with me and couldn't quite figure out why the global variable used for driving the timeout wasn't initialized. I'm guessing that the issue is on Wired's side.

A setTimeout with an undefined timeout value doesn't sound healthy at all.
An intervention seems appropriate.

Strawman A: use a reasonable default if the timeout is undefined. Not quite sure how to define reasonable though :D Hmm, 250ms as in not too often but not too rare.

Strawman B: ignore setTimeout with an undefined timeout. This will break functionality but should also lead to a proper fix on whoever is at fault.

I'll see what I can do here. It is our responsibility as Disqus to be robust on pages that my be doing nasty things. It may also be a legit bug somewhere. I hope to get back to you today.

Oh god, there's a bug! Patch coming up.

That said I still can't reproduce the issue itself.

Okay I have a patch in place with a passing test so we should be able to get this live today around 10:30am PT.

Great, thanks!

Okay, the fix is deployed. Can you verify it on your end?

Ping :)

byk@: thanks, can confirm that disqus is now running on a much more reasonable 500ms timeout.

A few more remaining significant culprits for CPU usage:
1. First party Wired.com

a. https://www.wired.com/cns/services.min.js
Multiple* rAF callbacks per frame(!) to a function in services.min.js.
 
Apparently, does lazy loading of ads. Ideally, this ought to be done efficiently via Intersection Observer.

*: I'm guessing one callback per ad slot? :/

b. https://www.wired.com/assets/load?scripts=true&c=1&load%5B%5D=outbrain,blockadblock,jquery,wired,plugin-global-min,ads,wp-embed&ver=1490726470

On a rAF callback. 
Not sure what this does.


c. https://pixel.condenastdigital.com/sparrow.min.js
On a 30(?)ms timeout
Not sure what this does.


2. Third party
Parsely engaged time: https://d1z2jf7jlzjs58.cloudfront.net/code/ptrack-v0.8.0-engaged-time.js
on a 100ms timeout, track user engagement via a heartbeat.


For #1: IObs + outreach + ecosystem alignment program
For #2: we could consider designing efficient APIs for measuring user engagement and other analytics concerns, instead of this constant polling.

As for the Memory aspect, I'm not familiar with tooling. +haraken: can you recommend someone to take a look at how Wired.com ends up using 1GB+ memory?

+tasak +keishi Would you help analyze the 1GB+ memory issue?

Was someone able to reproduce the memory problem? Any tips?

I just tried on Linux 59.0.3055.0 and couldn't reproduce.

I am not able to reproduce this issue either.

So I and keishi@ took a look at the attached tracing file:
- ParseHTML events occurred 90 times: repeated "received data, parsed the data, executed v8, ran v8 gc..."
- Many different ad URLs were shown in the ParseHTML events.
- NetLOG said there were too many network connections.

I and keishi@ concluded that this issue was probably caused by the ad network used by Wired.com.
# We guess, probably this was a bug of the ad network.

Thanks for taking a look.
I also wasn't able to reproduce the memory issue.

It's gotta be a specific ad network that gets picked up under different conditions. Could someone in the US try to reproduce the issue?

Keishi / Tasak: assuming someone can repro, what would you need to understand the underlying cause? Can it be captured with a regular build?

In the trace file, ParseHTML slices contained frame id and url. And it seems to be that many iframes are loading ad related urls simultaneously. Examples are:
https://secure-lax.adnxs.com/ab
https://cdn3.doubleverify.com/bst2tv3.html
https://acdn.adnxs.com/ib/static/usersync/v3/async_usersync.html

I don't see a valid reason for this to happen so I suspect a bug in ad network JS. If someone can reproduce this, they should save the complete page and take a JS timeline profile so we can confirm.

I just tried opening the original URL on the computer where I first noticed it. The performance is still terrible (40% CPU spikes every 15 seconds or so as a new ad is loaded, then reducing to 10% in steady state, and with ~600 MB, but holding steady). But it's no longer egregious and growing.

That does imply it was something due to the ad network.

However, the problem in general is still pretty bad in the grand scheme of things--it's crazy to me that when a new ad is loaded it uses so much CPU.

Not really sure what to do here, given that the main issue was a specific ad which wasn't recorded, and which is no longer being loaded.

Tentatively marking as WontFix, please open a new bug if you se this error again. [Next time, we should try to record the ad, or at least note a specific link to it.]