PTAL. 

I tried to reproduce this on both an iPhone 5 and iPhone 7, but was unsuccessful. (I can test on other hardware if needed.) I am seeing very consistent speeds across Safari and Chrome.

stip@ can you run the fast.com speedtest on your WiFi that is exhibiting this problem with a WebView sample app (such as the following) in both WKWebView and Safari VC modes and post corresponding screenshots?

https://itunes.apple.com/us/app/webview-wkwebview-and-uiwebview-rendering/id928647773?mt=8

They all seem to run smoothly. Just for kicks I ran fast.com on dolphin and firefox for ios and they all seem to run at normal speeds.

One datapoint that might help: I did a test on www.dslreports.com/speedtest which splits out upload and download. It seems upload isn't affected, only download speeds are.

Deleted: UIWebView.PNG 50.0 KB

	UIWebView.PNG 50.0 KB View Download

Deleted: WKWebView.PNG 47.3 KB

	WKWebView.PNG 47.3 KB View Download

Deleted: SafariVC.PNG 47.3 KB

	SafariVC.PNG 47.3 KB View Download

Deleted: chrome_again.PNG 55.8 KB

	chrome_again.PNG 55.8 KB View Download

Thank you stip@ for the additional information.

mardini@, jasonkliu@ Are there any "Chrome Variations" partially enabled right now that could affect the network download speed. I can't reproduce this on my end, but it appears to only be affecting Chrome.

Not that I know of. 

Before we cast a wider net, I assume you checked with with Eugene already if he has an idea what could be happening here? This is just M58 and not M57?

Lindsay, could you please ask QA to reproduce this. 

mardini@:
This was reported against M57.

Eugene wasn't sure of the cause, but he did ask if we receive lots of callbacks during the test. It doesn't appear that we do, so I don't think this is caused by native code doing too much work and slowing down the test.

stip@, have you tried with a variety of WiFi networks? If not, is this a home or public network?

Tested on M57 on on iPhone 5s iOS 9.3.5, iPhone 6+ iOS 10.2
1. Google guest network (supports 5GHz devices) 
   11 Mbps, 26 Mbps
2. GoogleGuest-Legacy (2.4GHz devices)
   11 Mbps, 10 Mbps
3. GIN-3g
   97 Kbps, 23 Mbps
Please let me know if you need further testing.

shbarezer@ Can you confirm what the 2 numbers mean? Are these "upload, download"? And can you compare with Safari to determine if Chrome is the same or slower on these particular devices. Thank you

Ah, I see it is the 2 different devices, sorry didn't see that at first.

1. Fast.com estimates your current internet download speed. 
2. Same test running on Safari:
   Google guest: 17 Mbps, 35 Mbps
   GoogleGuest-Legacy: 19 Mbps, 10 Mbps
   GIN-3g: 92Kbps, 160 Kbps
In the fast network Chrome and Safari are about the same, in the slow network Chrome is faster. 

For #8, with GIN-3g: 
Should the second number be 23 kbps instead of 23 mbps?

Assuming I'm reading this correctly:

+-------------+---------------+------------------+--------------+-----------------+
|             | 5s/9.3.5, M57 | 5s/9.3.5, Safari | 6+/10.2, M57 | 6+/10.2, Safari |
+-------------+---------------+------------------+--------------+-----------------+
| GoogleGuest | 11 Mbps       | 17 Mbps          | 26 Mbps      | 35 Mbps         |
+-------------+---------------+------------------+--------------+-----------------+
| GG-Legacy   | 11 Mbps       | 19 Mbps          | 10 Mbps      | 10 Mbps         |
+-------------+---------------+------------------+--------------+-----------------+
| GIN-3g      | 97 Kbps       | 92 Kbps          | 23 Kbps      | 160 Kbps        |
+-------------+---------------+------------------+--------------+-----------------+

I ran this test GIN-3g again, and these are the values.
First attempt: 110 Kbps
Second attempt: 260 Kbps
Third attempt: 390 Kbps
 

That is correct.

It does only seem to be my home network, I don't see similar issues on the work network but I can verify tomorrow. Additionally, I briefly saw the speedtest bounce to 'normal' (15mbps speeds) on Chrome about an hour ago, but now it's back to kbps again.

If it helps, I'm using a CBN CH6640E as my home router, and my ISP is Kabel Deutschland.

I should also note that this isn't just fast.com, basically all websites are affected (google properties, twitter, wikipedia, etc) and all load normally in Safari.

Okay one more experiment that may narrow down where the issue is. I set up a network-local speed test. First I set up https://github.com/maruel/serve-dir to host files off my laptop.

In the first test, the laptop and phone were both connected to the router as in a normal wifi network. In this case, Chrome loaded a 146kb image in about 10 seconds (I used a stopwatch to time it) while Safari loaded effectively instantly.

In the second test, I set up the laptop to broadcast its own network, bypassing the router entirely. In this configuration Chrome was able to repeatedly download the file instantaneously.

So my guess is that somehow iOS Chrome (and only iOS Chrome) is interacting poorly with my router. Which is a very weird problem to have...

stip@, do you see the same problem with Test WKWebView app?:
https://itunes.apple.com/gb/app/webview-wkwebview-uiwebview/id928647773?mt=8

eugenebut: see comment #3

jasonkliu@ Dolfin and Firefox are not necessarily the same as stock WKWebView. User Agent sniffing could be an issue here.

Eugene: comment 3 answers your question. yes, it was run in stock WKWebView (see images), and it performs much better than Chrome. 

Sorry, apparently I'm blind. Those screenshots are very interesting and show that stock WKWebView is slower than Safari. But router can not see the user agent and discriminate the app based on a user agent, so there is probably something wrong with Chrome app.

Do we know that User Agent couldn't be part of the cause? I think it is at least one of the easier items to test, even if just to validate that the issue is elsewhere.

stip@ could you get Chrome's user agent from your phone (using a site like whatsmyua.com will work). Then try to use this User Agent on your desktop/laptop from Safari or Chrome (provided your computer has wireless support). I can give more details or just search around for various ways to test/change UA in your browser. I don't think it's likely that this will result in slow speeds, but if it does, we can tie it to the user agent.

Also, have you tried desktop chrome via wifi versus another browser to see if there is something about Chrome in general going on?

One more question, is this reproducible from an Incognito tab? (To try to test with a request that may look a bit different to the router.)

An easy way is to use this Chrome extension and select "Chrome for iPhone":
https://chrome.google.com/webstore/detail/user-agent-switcher-for-g/ffhkkpnppgnfaobgihpdblnhmmbodake

It uses CriOS/27.0.1453.10 but I don't think that would matter.

full UA:
Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_4 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/27.0.1453.10 Mobile/10B350 Safari/8536.25

+ Robert

I saw some AppStore reviews that might be related to this today (attached).
Robert: any user feedback about this issue or on the product discussion forums?

Deleted: Screen Shot 2017-03-25 at 08.29.52.png 26.5 KB

	Screen Shot 2017-03-25 at 08.29.52.png 26.5 KB View Download

Deleted: Screen Shot 2017-03-25 at 08.28.23.png 45.3 KB

	Screen Shot 2017-03-25 at 08.28.23.png 45.3 KB View Download

Deleted: Screen Shot 2017-03-25 at 08.29.27.png 54.7 KB

	Screen Shot 2017-03-25 at 08.29.27.png 54.7 KB View Download

Obviously comment #25 refers to M57 Stable.

Per Sharon's measurements on Wi-Fy, Chrome is somewhat slower than Safari (11 Mbps vs. 19 Mbps). And from user feedback it sounds like this is M57 regression. Sharon, could you please try bisecting the build.

Yes, we see increase in user feedback and I've sent the link to feedback through email. Thanks. 

I have tested on M57 iPhone SE iOS 9.3.5:
These are the results of the first fast.com test after an installation of the app.

Safari: (GG 30Mbps;GL 12 Mbps; Gin3g X)
Good build: 57.0.2987.94 Rev# 0409810a54af (GG 29Mbps;GL 32 Mbps; Gin3g 180Kbps)
Bad build: 57.0.2987.95 Rev# 738ec999bea6 (GG 9.8Mbps;GL 16 Mbps; Gin3g 54Kbps)

Having said that I see different download speed every-time I run fast.com after running it at least once.

Please let me know if there is anything else.

After discussing with eugenebut@ the results we decided to run one more test:
Run fast.com on GG network 5 times (killing the app after every try)

+-------------+---------------+------------------+
|             | SE/9.3.5, M57 | SE/9.3.5, Safari | 
+-------------+---------------+------------------+
| #1          | 30 Mbps       |  24 Mbps         | 
+-------------+---------------+------------------+
| #2          | 41 Mbps       |  32 Mbps         | 
+-------------+---------------+------------------+
| #3          | 37 Mbps       |  41 Mbps         | 
+-------------+---------------+------------------+
| #4          | 25 Mbps       |  30 Mbps         | 
+-------------+---------------+------------------+
| #5          | 46 Mbps       |  35 Mbps         | 
+-------------+---------------+------------------+

Hey Sharon, do we know the build from which this regression got introduced?

It is very hard to pinpoint the exact build, because the runs speed keeps changing. 

After some research it looks like Chrome did introduce throttling for background tabs in M57.  crbug.com/650594  Much of this appears to be implemented in Blink. However, some would affect iOS, such as this:
https://codereview.chromium.org/2130493002

When we use WebThreadImpl::IOThreadRun (this looks like it happens whenever something is sent to run on WebThread::IO), part of the throttling code is called. This is not to say it is throttling, but the call stack ends up in NetworkThrottleManagerImpl::CreateThrottle in net/base/network_throttle_manager_impl.cc and priority always appears to be set to LOWEST for my local tests.

To be clear, I'm not sure that this is having an impact on iOS, but wanted to point it out.

(I'm also looking for anything suspicious around "CONNECTION_WIFI".)

Claude, I think from comment #30 it looks like there are no differences between Safari and Chrome on Google Guest network. Even if this bug is a regression, we still can not reproduce the problem locally. I will try running some tests when I'm at home on 2 different routers.

Alright, Thanks Eugene!

Tried with Starbucks WiFi, and got pretty consistent results from Chrome 57 and Safari (~30 Mbps across 5 runs).

I've been experiencing this issue for the past week or so using latest iOS on iPhone 6S with latest Chrome app. Safari does not exhibit the same problem.

My router is a German made Fritz!Box 7490.

Switching to 4G then back to Wifi appears to have resolved this for me at least temporarily.

Thank you jamiepaulburchell@ for the information. Have you seen this issue on other WiFi networks or only on your home router?

Per the comment in the forum that mentions this only affects their 5GHz network, I tried disabling 5GHz on my home router to force my phone to 2.4, but I still wasn't able to reproduce the problem on my network.

Forum post: https://productforums.google.com/forum/#!topic/chrome/yWe5B7VQW5I;context-place=topicsearchin/chrome/wifi

On my home network (mix of 5Ghz and 2.4) I get 12Mbps in Chrome and 20+ in Safari.

This is repeatable. The router is an AirportExtreme with an AirPort Express extending the network. 

In comment 40 I tried this 4 times in a row and got 12Mbps. Just tried it again and got 66Mbps in Chrome. Trying again got 20. 

Something appears to get "stuck" and doesn't perform as well. Note that while I was getting 12 in Chrome, I was easily getting 20+ in Safari. The runs were done right after each other. 

My takeaway: there is a tremendous amount of variability in the results, but Safari is always approx 10Mbps higher. 

I believe the results from pinkerton@ point to either a separate issue or the problem slowly degrades until the extremely poor speeds as described in the initial report are seen.

The initial reports describe speeds at 200 times worse in Chrome than Safari. I don't believe we have been able to reproduce that yet.

Since wifi speeds vary based on so many factors, I don't think we should consider anything to be a reproduction of this issue unless we are seeing kbps in the speed test results or very close to it.

I think I see the same results as Pinkerton with my Comcast's router. Will try bisecting and reverting https://codereview.chromium.org/2130493002

For completeness, I should add I'm on Comcast, with the cable modem hooked to my AirportExtreme providing wifi, and a separate hub off the AE for hardwired devices. Nothing besides the AE is connected directly to the cable modem. 

Thanks Eugene for trying that.

mardini@, can we have someone familiar with Reading List chime in? It looks like that was the most probable feature in M57 that could have had an impact on this if it wasn't impacted by the throttling code.

+noyau and wychen for ReadingList and DOMDistiller comments.

Curious what the DOMDistiller could be doing to fast.com, but we should check!!

Adding fast.com stats for reference

Deleted: IMG_5361.PNG 62.4 KB

	IMG_5361.PNG 62.4 KB View Download

Deleted: IMG_5362.PNG 63.7 KB

	IMG_5362.PNG 63.7 KB View Download

jamiepaulburchell@ have you tried to reproduce this on any other WiFi network other than your home network? Is is only reproducible there?

I don't currently have access to another network.

I turned of 5Ghz and the issue remained. I turned it back on and turned off the 2.4Ghz and the problem was resolved.

If new entries are added to Reading List, they would be processed in a queue to load and distill. This could affect the network performance. In this particular case, I don't see Reading List mentioned, so probably unrelated.

I'm not using the Reading List facility.

When I enabled 2.4 and 5GHz frequencies again the problem went away. I turned off Wifi on the phone, turned back on and still the problem was gone.

Restarted my phone, tried fast.com again in Chrome and problem returned. Fine again in Safari.

OK, so I just connected to a public BT Wifi (UK) hotspot. Although internet access is behind a paywall, I am able to browse BT's pages and sites while connected. Access and page rendering was extremely slow in Chrome, Safari was as I would expect. Therefore this does not seem to be related to my router. My physical location did not change while testing.

Thank you jamiepaulburchell@ for the information. Can you clarify what you mean by the problem went away when you "enabled 2.4 and 5GHz frequencies again"?

My router has support for Wifi on both 2.4GHz and 5GHz frequencies and I am able to disable one or both frequencies from the router's Web UI.

Re comment 39, you suggest the forum post states this is an issue for 5GHz networks. This is the opposite to what is stated:

"5GHz network on the same router does not have this issue (Chrome works fine over the 5GHz network). "

This matches what I am seeing; when I disabled 2.4Ghz and forced 5GHz the issue went away.

I can not install M56 from our storage (probably because of expired certificate), but I found a better clue than bisecting. Test WKWebView app consistently gives better results than Chrome and Safari. michaeldo@, did you try testing with test WKWebView app? It may be the case that WKWebView navigation callbacks affect the performance.

eugenebut@ I looked into the callbacks initially and nothing seemed to be called enough to cause problems during the load of an actual page. See Comment #7 where I allude to this.

Maybe this clue does point out that if the app is doing "anything", it will slow down the network speed.

What kind of speed differences are you seeing in your comparisons, are they significant (100x or greater)?

I had 40 Mbps with WKWebView app and 12-16 with Chrome.

+ Olivier to comment on #46. 

 

An easy way to test if this is related to Reading List is to delete all Reading List items, then kill Chrome and Relaunch.
If the problem persist, it is not Reading List.

It may also be the new sync framework (USS) that shipped with M57. 
Are you signed in?

Not using Reading List, not signed in 

Srikanth found that turning off "Physical Web" in Experimental Settings fixes performance problem. Matt, do you know if it is possible to turn off Physical Web in Chrome for iOS from the server side?

stip@, could you please try testing Chrome download speed with Bluetooth turned off. 

Sorry for the absence (been traveling a bit).

I just experienced this problem on a different network (in California, no less). Turning off bluetooth fixes it.

Deleted: bluetooth_1.PNG 54.1 KB

	bluetooth_1.PNG 54.1 KB View Download

Deleted: no_bluetooth_1.PNG 49.9 KB

	no_bluetooth_1.PNG 49.9 KB View Download

Deleted: bluetooth_2.PNG 48.8 KB

	bluetooth_2.PNG 48.8 KB View Download

Deleted: no_bluetooth_2.PNG 52.4 KB

	no_bluetooth_2.PNG 52.4 KB View Download

I turned off physical web in chrome://flags (I had to restart chrome for it to stick). Looks like the issue is gone for now, but I suspect it will take a few days of testing to verify it went away. Thanks!

Turning off Bluetooth completely fixed it for me. Hopefully this can be fixed in a future update. 

eugenebut@: Yes, it can be turned off server-side.

Confirming what others already suspect: physical web enabled use of Bluetooth scanning when Chrome is in the foreground only, in m57.  BLE usage can indeed affect the radio performance of WiFi, but we did not expect this extreme result.

This feature is behind a flag, which I will disable server-side right now.

Thanks for the confirmations! 
I'll try to do a final confirmation from here in the office (of turning off the feature and seeing the mbps bounce back) even though we know repro isn't working well in office so it might not be possible. But given the confirmations we have above, I would like to turn this feature off on stable and beta channels server side ASAP -and start a postmortem. Thank you.

FWIW, I tried to reproduce in Paris Office and could not (I always have a 80Mbps).
Are there other conditions than having PW enabled?

Hi Olivier,
We have not been able to repro on office wifi so far. It's probably going to be observable if you try from your house :)
Thanks,

I have also not yet reproduced, but I am still going to proceed with disable so we can explore calmly.

Perhaps related to number of nearby beacons?  Or duration Chrome is in Foreground?  Perhaps related to specific iOS products (looks like stip used iPhone SE)?

Maybe the severity is based on WiFi channel? I would hope this interference isn't built into one of the hardware configurations, but maybe we should test this to ensure?

Per https://support.apple.com/en-us/HT201542
"Certain displays can emit harmonic interference, especially in the 2.4GHz band between channels 11 and 14."
"Try changing your access point to use 5 GHz or a lower 2.4 GHz channel."

jamiepaulburchell@, if your 2.4 GHz wifi is between channels 11 and 14, can you test using a lower channel?

I used a RFDuino to generate 100 beacons.
Immediate effect is to crash Chrome on my Android, but I did not see any speed issue.

The displayed URLs in chrome://physical-web and omnibox seem quite unpredictable too.

Update: I have disabled PW via finch for Stable & Beta.

stip@, craig.stokes@ we expect that performance bug was fixed and would appreciate if you could retest it with Bluetooth turned on. Thanks a lot for your help!

Addition to comment #77: server change may take some time to propagate and will require  app restart.

michaeldo@ my 2.4Ghz channel is set to auto/channel 1. It always seems to be this channel.

I did notice the problem went away when I disabled Bluetooth and some other services, but I was then annoyingly unable to reproduce after switching back on even after restarting the phone. The last few times I've tried and the issue has gone.

jamiepaulburchell@ thanks for the followup about your channel.

It is likely you can't see the problem anymore due to comments 69 & 76. The problem has been "fixed" for now because we disabled the feature which was using Bluetooth within Chrome.

It sounds like jamiepaulburchell was unable to reproduce even before I made this switch.

You can confirm if PW has already been disabled on your device by checking for the existence of Settings->Privacy->Physical Web option.  I suspect your device may still not have the new finch setting, though it should within a day.

If you could check this, it will help me better understand the consistency of this issue.  Thanks!

Hmm, I don't appear to have this option yet.

Thanks for confirming, this means you have already have the feature removed.

mmocny@, can someone from Physical Web take ownership of this bug to investigate in more depth?

I went to chrome://flags and turned Physical Web back on, also confirmed was enabled in settings. Connected to 2.4Ghz Wifi with Bluetooth enabled and after restarting Chrome still am unable to reproduce. I guess the unpredictability could be a result of Wifi congestion.

Please link the bug that will track this feature on/off by default in M59 to this bug as well. Thank you!

Filed  issue 707885  to track us disabling PW by default in m59, to make sure this doesn't accidentally creep back in.  This is a simple revert which will be done promptly.

Filed  issue 707886  to track our primary hypothesis for the cause of this issue.  That bug (at least) will block the re-introduction of PW feature into iOS.

This bug, I believe, can be closed since it is no longer a release blocker for m58, now that the PW finch experiment is disabled.  However, I will leave it open while we write up a post-mortem to share, and to give some time to verify PW was the only cause (since there is some unpredictability here).

I have decreased priority of this to reflect the new status.

I found it notorious to reproduce deterministically. It would always eventually happen, but I couldn't find a particular set of circumstances to trigger it.

It seemed to happen more often when my Sonos (which is connected via wifi) was playing, but not every time.

I've attached the network data from my laptop (which is connected to the same network and has better diagnostic information).

It may also be helpful to know that my iPhone is normally connected to a Pebble Time Round (first edition), which is a BLE device.

Deleted: Screen Shot 2017-04-04 at 12.34.08 AM.png 32.3 KB

	Screen Shot 2017-04-04 at 12.34.08 AM.png 32.3 KB View Download

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

Removed merge label.

Post-mortem, as promised: https://docs.google.com/a/google.com/document/d/1Npn-YeH9u3MHeVpzuPSAy9J0RXz85KjKKlwwrYO63yQ

Marking Verified since this is no longer repro.