Open Bug 1110207 Opened 5 years ago Updated 2 months ago

[meta] [userstory] Network Throttling Control

Categories

(DevTools :: Responsive Design Mode, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: bgrins, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug, )

Details

(Keywords: DevAdvocacy, meta, Whiteboard: [multiviewport] [userstory][DevRel:P2])

User Story

User Story:

* As a web developer I want to test my application in slower network environments such that I can prepare my web application for running on a phone with only a 3g network.

Acceptance Criteria:

* A single option to change network speed affecting the current tab with the toolbox open, defaulting to 'online'
* A UI that offers a choice of a set of default speeds like:
** Online
** DSL
** LTE
** 3G
** 2G
** EDGE
** Offline
* For each speed, both upload, download, and latency are limited to the approximate values of the connection
* Not necessary to display the upload, download, and latency values directly to the user

Notes:

* This system is good for empathy building and working with application loading states however it doesn't address the real concerns developers will have which is comparing network load times as well as dissecting the rendering and load issues.
* A future user story should take on this aspect as well.
There is some discussion about this in Bug 1028905.  See Comments 11-15 on that bug.

> The use I can see for simulating a "slow network" is to improve perceived performance,
> like Brian said (e.g. a page shouldn't load social widgets before their main content!).
> This could be achieved by adding controllable random latency (not sure if throttling
> throughput is useful here).
>
> Then the network can be made "unreliable" to test a website's resilience in the face
> of bad conitions, e.g. by randomly dropping requests (with controllable probability).
There seems to be a lot of love for chrome's relatively blunt approach to this - applying a consistent delay percentage across all requests.

This is a weird feature to me, I doubt the utility is really the effective 'emulation' of a slower network, you're really only seeing a synthetic estimate of what the slowness might look like. The consistent delay is probably rare in real-world scenarios.

I think the real utility is simply slowing page load by some factor. So maybe we should do that.

There's a whole other level to this where some devlopers want a web proxy that applies a chaos monkey approach of randomizing speed and introducing failures. This might be out of scope for us, and might be better provided by purpose built tools. There are similar things for security ( for example ) like zap: https://code.google.com/p/zaproxy/
Duplicate of this bug: 1146864
Pasting from #1146864:

I'm using Firefox for web development. I'm working on a website's 'loading' states -- like when a web page is still fetching data from the server, and I want to communicate that visually to the user by e.g. an animation. To me as a web developer, it would be very useful to be able to throttle network speed to facilitate working on aspects like that. (Chromium's feature has turned out quite useful for me.)
Yup, echo-ing the previous comment here, I was testing loading screens, and my network connection was too quick to tell.

It'd also be nice for doing Service Worker testing to be able to throttle the connection so much, it has an offline state, without affecting other tabs or your overall network connetivity.
With the rise of JavaScript heavy applications, and lots of loading state on the client side, it would be very nice to test slow network. It doesn't even need to throttle network, a simple delay on responses would be nice.

Maybe one could do this through service workers while developing, but they are not enabled yet on Firefox.
But support through the developer tools would be much easier and user friendly.
Adding DevAdvocacy keyword; while this hasn't been a top-line request from developers at conferences, it almost always gets mentioned after a few minutes of conversation.

The use case is per the three comments above this: "slow me down to something approximating a moderately reliable EDGE or 3G connection so I can get a qualitative sense of what my page weight feels like in less well-connected contexts."
Keywords: DevAdvocacy
Whiteboard: [devtools-platform]
Over here on Chrome, we've definitely gotten enough positive feedback to validate our investment in the feature. It's good, and even though the simulation is very basic, it's a good ballpark.

> There's a whole other level to this where some developers want a web proxy that applies a chaos monkey approach of randomizing speed and introducing failures

Yeah, this is the current ask from developers and we're considering taking it on. It'll mostly just be scripting the presets we already have, but it may turn into multiple presets of severity like "Decent Chaos" and "Total Chaos".
I'll add a small +1 with a slightly different use-case.

I am from a country where 2G Internet and speeds around 64Kbps are not uncommon. I am developing a quite heavy webpage (which loads very large geojson map files). I am a Mozillian and therefore I used only firefox developer tools to check the website. I was serving it on localhost all the time while developing it and therefore 1 MB files would load in 4 milliseconds.

Once I was done developing I pushed it to a server and tried it on my mobile phone a few minutes later. That's when I realize how horribly slow the downloading is and how I'd not put a "loading..." gif or spinner in the website.

I also wanted to test how the website appears on chrome and when I opened the developer tools in Chromium, lo and behold! There's a network speed throttler right in front of my eyes.

I've to switch to Chrome, for developing this app at least. This feature is very much about accessibility and decentralization on the Web for a large number of Internet users. If geographically local (many a times inexperienced, like me) developers can't build useful websites for slow Internet users, they'll forever be consuming websites built by large corporations with well paid developers who know everything about optimization, caching, and creating beautiful UX. 

tl;dr - this feature helps beginner developers in slow Internet countries even in a very crude form like chromium's.
After talking with the Necko team, I believe it is possible for DevTools to craft a crude version of this in JS by using setNewListener from nsITraceableChannel craft a throttled channel that wraps the original.

They expressed various concerns about how rough such an approach would be, since it could buffer lots of data in memory, affect network parallelism unrealistically, etc.  But, I think it's still valuable to explore this JS approach, since it may be give a rough but workable version of this feature fairly easily.

The network monitor server side is already wrapping channels in this way, so that could be an appropriate hook to use for this.
User Story: (updated)
Component: Developer Tools → Developer Tools: Responsive Mode
Flags: qe-verify-
Summary: Provide a way to simulate a slow network from developer tools → [userstory] Network Throttling Control
Whiteboard: [devtools-platform] → [multiviewport] [userstory]
Depends on: 1239925
User Story: (updated)
User Story: (updated)
Depends on: 1244227
Depends on: 1156659
Duplicate of this bug: 1010781
Whiteboard: [multiviewport] [userstory] → [multiviewport] [userstory][DevRel:P2]
Depends on: 1283445
Depends on: 1283453
:clarkbw, should we borrow the throttling profiles as they exist in Google Chrome today?  Do we have any data to suggest different values and / or profiles are relevant today?
Flags: needinfo?(clarkbw)
No more data than before.

So our current list is this:

** Online
** DSL
** LTE
** 3G
** 2G
** EDGE
** Offline

I saw Chrome has some Good / Regular options for 2G, 3G and GPRS instead of EDGE.  Using GPRS instead of EDGE is fine with me.  And I wonder if we should use 4G/LTE instead of just LTE.  Otherwise I didn't see anything else of value.
Flags: needinfo?(clarkbw) → needinfo?(jryans)
(In reply to Bryan Clark (DevTools PM) [@clarkbw] from comment #13)
> No more data than before.
> 
> So our current list is this:
> 
> ** Online
> ** DSL
> ** LTE
> ** 3G
> ** 2G
> ** EDGE
> ** Offline
> 
> I saw Chrome has some Good / Regular options for 2G, 3G and GPRS instead of
> EDGE.  Using GPRS instead of EDGE is fine with me.  And I wonder if we
> should use 4G/LTE instead of just LTE.  Otherwise I didn't see anything else
> of value.

Okay.  Any thoughts on what to use as the bandwidth and latency values for each of the profiles?  Chrome exposes their values in the UI, so we could reuse those, or come up with our own.  I am not sure how we'd really judge the values to be "correct" since actual phone bandwidth and latency is highly dependent on many variables, different carriers deploy different features of each spec, etc.
Flags: needinfo?(jryans) → needinfo?(clarkbw)
I think it would be simplest for developers if we shared the same values.  Like you said, there's no way to be correct here so we might as well be consistent.
Flags: needinfo?(clarkbw)
+1. If we're going to use identical labels, we should use identical values.

Otherwise, we risk unfavorable, naive comparisons. "Firefox on 2G loads the page so much slower than Chrome on 2G!"
Depends on: 1312672
Depends on: 1312740
Depends on: 1317745
Product: Firefox → DevTools
Severity: normal → enhancement
Keywords: meta
Priority: -- → P3
Summary: [userstory] Network Throttling Control → [meta] [userstory] Network Throttling Control
You need to log in before you can comment on or make changes to this bug.