Open Bug 1942649 Opened 18 days ago Updated 15 days ago

Throttling prevents loading gilbert web page

Categories

(DevTools :: Netmonitor, defect, P3)

defect

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.

Attached image image.png
Attached image image.png

300ms for 45kb (142kb transferred)
892ms for 37kb (37kb transferred)

Come up with a test page for throttling scenarios, and add tests.

Severity: -- → S3
Flags: needinfo?(jdescottes)
Priority: -- → P3

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/

Flags: needinfo?(jdescottes)
Attached image image.png

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.

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: