Loading un-cached, un-built local page 3x slower than chrome


#1

I’m loading a fairly heavy section of my site in development, so all served locally, all unbuilt javascript. In total 468requests, about 8mb, most of them js files. I have dev tools open and caching disabled. Every full refresh to run new code is ~1.28 minutes as reported by firefox. Chrome reports ~30.5s, which is the difference between a slightly trying wait where I can stay focused, and getting distracted because I’ve been waiting so long.

I’d love to be using firefox, I hate having to use chrome, but this is pretty much unusable when the alternative is so much faster.

Please let me know if there are any metrics or debugging info I can provide that would be useful. Oh also 57.0b6 developer edition on Ubuntu 14.04.


(Harald Kirschner) #2

Thank you Jesse for the detailed report and sorry that the tools get in your way. This sees a great stress test for the tools; how did you end up with such a massive project :sweat_smile:.

As you probably can’t share the environment for us to benchmark, would you be able to record a performance profile using the tools from https://perf-html.io/? We have detailed instructions on MDN.

We also filed some issues 1 regarding page load perf and patches for the worst offenders already landed in Debugger and Console. You could help us check if the issue persists on Nightly.

The coming months we’ll be heads down on more performance work, so it would be of massive help to see more reports with performance profiles (from Nightly, but we’ll do our best with DevEd reports). Thanks for your help so far!


(Julian Descottes) #3

I have a similar issue with ~300 scripts served from localhost for a side project. I logged the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1366693

When I tested, I realized that if I opened DevTools without visiting the Inspector or the Network tab, the load time was more acceptable. Could you check if a specific tool seems to be responsible for the performance hit you see (see the details in the bug I linked to if you are not sure how to test this).

Thanks!


(Mike Ratcliffe) #4

We use mutation events in the Inspector and that is known to be very slow. If it is slowing things down to this extent then we should look if there is a way to optimize things.

Maybe we could use React’s diffing algorithm to rebuild the HTML tree each time but that would make it difficult to preserve DOM events.

I am working on optimizing things at the moment so after I finish with the net panel I should take a look at the inspector.