Confirmed on both a MBP and a MacPro, although the CPU usage is in the 10-20% range. On my MBP, the page uses 1.6% CPU even when not the active tab.

Forgot to mention: I think (but am not certain) that the tab takes more CPU after it has been open for some time. I noticed this site when trying to figure out why my machine was hot: another user account had this tab open. CPU usage went down after I switched to that account and reloaded the page. The following day, CPU usage was back up to 100% for the tab. There were multiple sleep/wake cycles during this time. Just mentioning it in case it's somehow relevant.

I let the page run for a while on both Chrome and Safari. Safari had about half of Chrome's CPU usage.

Recorded the site for future replay, in case it changes. Confirmed that the saved site still exhibits same problems.

Deleted: puppy_training.zip 1.8 MB

puppy_training.zip 1.8 MB Download

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

commit 9c3c0a38de1c83ac9e6a9f683bad1291e12e2885
Author: erikchen <erikchen@chromium.org>
Date: Wed Aug 31 16:31:07 2016

Add a new benchmark for cpu power measurements on steady state sites.

The site in question is known to have high CPU usage, even though there appears
to be no visual changes to the site.

BUG= 640398 ,  638365 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq

Review-Url: https://codereview.chromium.org/2271793003
Cr-Commit-Position: refs/heads/master@{#415654}

[modify] https://crrev.com/9c3c0a38de1c83ac9e6a9f683bad1291e12e2885/tools/perf/benchmarks/power.py
[add] https://crrev.com/9c3c0a38de1c83ac9e6a9f683bad1291e12e2885/tools/perf/page_sets/data/idle_after_loading_stories.json
[add] https://crrev.com/9c3c0a38de1c83ac9e6a9f683bad1291e12e2885/tools/perf/page_sets/data/idle_after_loading_stories_001.wpr.sha1
[add] https://crrev.com/9c3c0a38de1c83ac9e6a9f683bad1291e12e2885/tools/perf/page_sets/idle_after_loading_stories.py

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

commit 6380c710d7ee2d6739e563d2957fc7475d663f70
Author: rnephew <rnephew@chromium.org>
Date: Thu Sep 01 01:17:59 2016

[BattOr] Add mac BattOr test for steady state cases.

BUG= 640398 ,  638365 ,  639308 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq

Review-Url: https://codereview.chromium.org/2301653002
Cr-Commit-Position: refs/heads/master@{#415832}

[modify] https://crrev.com/6380c710d7ee2d6739e563d2957fc7475d663f70/tools/perf/benchmarks/battor.py
[modify] https://crrev.com/6380c710d7ee2d6739e563d2957fc7475d663f70/tools/perf/page_sets/idle_after_loading_stories.py

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

commit 6380c710d7ee2d6739e563d2957fc7475d663f70
Author: rnephew <rnephew@chromium.org>
Date: Thu Sep 01 01:17:59 2016

[BattOr] Add mac BattOr test for steady state cases.

BUG= 640398 ,  638365 ,  639308 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq

Review-Url: https://codereview.chromium.org/2301653002
Cr-Commit-Position: refs/heads/master@{#415832}

[modify] https://crrev.com/6380c710d7ee2d6739e563d2957fc7475d663f70/tools/perf/benchmarks/battor.py
[modify] https://crrev.com/6380c710d7ee2d6739e563d2957fc7475d663f70/tools/perf/page_sets/idle_after_loading_stories.py

+shrike

erikchen@ - have you had a chance to look into this? I'm just wondering what Chrome or JavaScript tracing show to be the issue.

Not yet, but it's on the list.

There's nothing to be done for this bug. The excessive CPU usage is caused by ads which do not load deterministically under WPR. There's no way to guarantee the same ads play in Safari and Chrome, which also means there's no way to determine what we should be fixing [if anything] in Chrome.

When I open the live site in both Chrome and Safari, sometimes Chrome uses more CPU, sometimes Safari uses more CPU. 

Sorry, but I don't think further investigation into this issue is worthwhile. See https://docs.google.com/document/d/1YVO9FGRBF1RUsedU28H6P8lt9bDpOci0vi0CLSkFih8/edit#heading=h.yifmz8ib67c8 for more details.