Slower Network presets are also causing slower Waiting TTFB
Reported by
ine...@gmail.com,
Jun 6 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: 1. Open DevTools Network tab. 2. Open any website. Could be google.com Check the "Waiting (TTFB)" for the first request. I get ~143ms 3. Change Network Preset (throttling) to Fast 3g. Reload the page. "Waiting (TTFB)" gets worse. ~570ms now. 4. Change Network Preset (throttling) to Slow 3g. Reload the page. "Waiting (TTFB)" gets worse. ~2.2s now. What is the expected behavior? Waiting TTFB, since it's dependent on the server, shouldn't change depending on Network preset. What went wrong? I discovered this while testing Lighthouse Audit. On Chrome DevTools even google.com gets a performance grade of 65. If you run Lighthouse on the command line (node), the performance score goes up to 77. Firefox also has throttling, and the Waiting time doesn't change on different network speeds. Did this work before? N/A Chrome version: 66.0.3359.181 Channel: stable OS Version: OS X 10.13.4 Flash Version:
,
Jun 7 2018
Able to reproduce this issue on reported version, on latest stable and latest cnary using Mac 10.13.3, Windows 10 and Ubuntu 17.10. Observing Waiting TTFB as around 150ms, when fast 3g observed around 520ms and when slow 3g observed around 2.0ms. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged. Thanks!
,
Jun 11 2018
phulce@, do you know if this is expected behavior, or a bug in the throttling?
,
Jun 11 2018
1) This is expected by the definition of TTFB. TTFB will always include network latency. As throttling introduces additional latency, you expect TTFB to increase as well. 2) @inerte are you sure you were comparing the same version of LH? I just ran canary and latest CLI (lighthouse@next) and got exact same perf score for google.com.
,
Jun 11 2018
2) @phulce I got different numbers running Chrome stable and lighthouse (not @next). I downloaded Canary and lighthouse@next and here's more: Chrome stable, 4 runs: 73, 63, 67, 71 lighthouse (--version 2.9.4), 4 runs: 77, 78, 78, 77 Chrome Canary (Simulated Fast 3G), 4 runs: 91, 91, 92, 92 Chrome Canary (Applied Fast 3G): 91 lighthouse@vnext (--version 3.0.0-beta.0), 4 runs: 87, 85, 85, 86 1) I see your point about network latency. https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing-explanation says TTFB "includes 1 round trip of latency". I still thought there was a problem because 2s seemed excessive, and lighthouse produces different numbers. Looking again at my new numbers I don't think there's a bug on Chrome desktop Network presets, as the only clear thing is that I get different numbers from Lighthouse on the DevTools and command line. But this could be caused by different default settings on both tools or something else altogether. Thanks for your time anyway, I appreciate the quick triage!
,
Jun 11 2018
Hmm, yeah not sure what's up with that CLI vs. Chrome difference then other than potential settings/URL-redirect mismatch. There might be a slight edge to DevTools Lighthouse for having a Chrome instance that's been running for awhile as opposed to a cold start from the CLI, but it shouldn't be large. If you ever figure it out and find a bug, we'd be happy to hear about it over at https://github.com/GoogleChrome/lighthouse/issues/new/choose :) |
||||
►
Sign in to add a comment |
||||
Comment 1 by krajshree@chromium.org
, Jun 7 2018