Throttling prevents loading gilbert web page
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: ochameau, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(5 files)
Setting throttling to DSL, when it works, make the following page very slow to load:
https://www.gibert.com/sao/index/index/
But, it also quickly break and prevents loading the page entirely.
STR:
- load the page once without RDM to workaround the "human checking" thing first
- open RDM and disable any responsive feature, only enable DSL throttling
- reload
- reload again if the page worked
Note the "X" instead of the reload icon and the "Waiting for..." or "Reading from..." text in bottom left.
Reporter | ||
Updated•18 days ago
|
Reporter | ||
Comment 1•18 days ago
|
||
Reporter | ||
Comment 2•18 days ago
|
||
300ms for 45kb (142kb transferred)
892ms for 37kb (37kb transferred)
Comment 3•16 days ago
|
||
Come up with a test page for throttling scenarios, and add tests.
Comment 4•15 days ago
|
||
Here is a zipped HAR recording of a load of https://www.gibert.com/sao/index/index/ with DSL throttling.
It was generated from DevTools, but I believe it gives a better representation of what happens, when viewed on http://www.softwareishard.com/har/viewer/
Comment 5•15 days ago
|
||
Let's look at what happens early during the load:
- first the index loads in 700ms for 42kB (which is reported as waiting time, I guess it's actually a mix of backend time + network time)
- then we have in parallel 30 requests starting, including one for the react-bundle file (45kb 300ms in Alex's comment), for a total of 2.5 MB which takes ~10s to finish. Overall this seems to match the throttling profile, but the parallelisation of requests might still be a bit weird
- then we have 12 other requests starting after this first batch, for a total of 100 kB, taking 1 second
- and after that we have other requests which should have a significant receiving time (eg legacy-build.min.js more than 50k, should be at least 200ms) but only show some waiting time?
I think part of the issue is that the netmonitor makes it hard to understand when a request is waiting because another request/connection is already capping the download rate, but the behavior also seems a bit unrealistic.
Comment 6•15 days ago
|
||
Finally here is another HAR, created this time from Chrome, for the same scenario and profile.
The total load time is similar (~12s) and the overall progression is also similar but we can see that requests finish more organically than with Firefox.
Description
•