New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 672946 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Loading pages on slow networks is a poor experience

Project Member Reported by mdw@chromium.org, Dec 9 2016

Issue description

Application Version (from "Chrome Settings > About Chrome"): 56.0.2924.18
Android Build Number (from "Android Settings > About Phone/Tablet"): LXI22.50-62
Device: Moto E

Steps to reproduce:

1) Put the device on a slow network (e.g., GIN-2gpoor)
2) Try to load any page.

Observed behavior: 

All the user sees is a blank screen with a static loading bar stuck at about 10% for a very long time (30 seconds or more).

Expected behavior: 

We need to drastically rethink the loading experience when Chrome is on a slow network. Even if the user has Flywheel enabled and will eventually get a Preview page, the period of time that elapses before *any* content is shown can be quite long.

Some ideas (though there may be others)...

- After a short (~4-5 sec) timeout with no network activity, acknowledge that the network is slow and suggest another action (e.g., offline content, load later, etc.)

- Animate the loading bar to make it clear that something is happening. Other browsers (e.g., UC Browser) "pulse" the loading bar instead of having it be a static blue line.

- Revise timeout thresholds on slow networks to, e.g., retry requests more quickly when it's likely that the connection is stalled.

See internal doc for more details on experiment:
https://docs.google.com/a/google.com/document/d/19ctmz25Dd4FsCUeFJeaIhWGBTENcVo5_KD626fRE4DM/edit?usp=sharing
 
Cc: k...@chromium.org
+ Kingston who owns the experiment for our new loading bar
Side note - I'm open to exploring a snackbar (like UC Does) on slow connections. You can see a mock for that here: https://docs.google.com/presentation/d/1jrXKzfOfQmNVG4PaHq6NXULfkALo-ANRNBcDsM--JV8/edit#slide=id.g1342d780a2_0_1482
Hmm, thought we do have the animated progress bar when there is no progress.
The animated progress bar work has been .. in progress since early 2015. The updated version with indeterminate progress is a 1% experiment currently. Kingston is working on pulling out evidence that this improves the experience in the stats.

Comment 5 by k...@chromium.org, Dec 9 2016

Yep, right now the main issue is that early stats are suggesting that page load is not any different, but page load times have increased by ~0.5% for median and 2% for slower page loads. Therefore, we'd have to weight it carefully.
Components: -Internals>Network UI>Browser>Navigation
Net triager here. This seems more like UI than networking, changing components.

Comment 7 by k...@chromium.org, Dec 16 2016

@Matt - does the page eventually load or does it just stay at 10% forever (or at least for a very long time without anything happening)?

We have a separate bug tracking the indeterminate progress bar: https://bugs.chromium.org/p/chromium/issues/detail?id=609627

Comment 8 by bengr@chromium.org, Dec 22 2016

Status: Assigned (was: Untriaged)
Another idea:
- Don't visually navigate away until there is something to paint.


Retrying requests is something we've been discussing and want to do.

Comment 9 by bengr@chromium.org, Feb 9 2017

Cc: aposner@chromium.org bbergher@chromium.org
Status: WontFix (was: Assigned)
Closing this as it is/will be replaced with specific features to improve the loading experience.

Sign in to add a comment