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

commit 621a73dfd5f9ef0928664e43b7c788eba981bb96
Author: Makoto Shimazu <shimazu@chromium.org>
Date: Thu May 17 10:35:49 2018

Don't arm watcher in WebDataConsumerHandleImpl until it's fully read

WebDataConsumerHandle::DidGetReadable is expected to be called when it "stops to
wait for data". However, WebDataConsumerHandleImpl::DidGetReadable is called
when it's "ready to be read". It caused excessive calls of DidGetReadable and
results CPU hogging during streaming the data.

Bug:  843811 
Change-Id: I213f4b5cb7004b4ae21aaedda229a7bc16d0c68b
Reviewed-on: https://chromium-review.googlesource.com/1062985
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Makoto Shimazu <shimazu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559483}
[modify] https://crrev.com/621a73dfd5f9ef0928664e43b7c788eba981bb96/content/renderer/loader/web_data_consumer_handle_impl.cc
[modify] https://crrev.com/621a73dfd5f9ef0928664e43b7c788eba981bb96/content/renderer/loader/web_data_consumer_handle_impl_unittest.cc

This bug would affect more when the resource is loaded from slower network since it keeps to take CPU resource during the response is streamed.
If the response was in the HTTP cache, the duration would be smaller and this would have less effect.
That might explain why we saw a stopped service worker made things much slower even after it's started up.

No, c#2 was wrong.
It happens when *faster* network *slower* consumer (page). If page is blocked on a script with fast network, it's likely to happen.