A simple jspm + Babel + React repository to test performance of loading many JS files in Chrome on Mac OS X. Times are measured with Date.now()-PerformanceTiming.fetchStart.
JSPM with DevTools open causes ~20ms extra load time per JS file. A simple JS XHR performance test saw a 1 to 2.5ms increase with DevTools open, implying that there is something else SystemJS is doing that is triggering a significant performance hit in DevTools.
Feedback and replications are welcome.
I've tested numerous times now and consistently getting the below figures. Interestingly, the "Disable cache" option in DevTools Network tab does not have a noticeable impact on load times. Cache is verified by the "(from cache)" in the Size column.
Load time ranges from the simple jspm app (in the jspm folder):
DevTools not open
DevTools open to Elements tab
DevTools open to Network tab
Caddy was tested and the numbers fell within the above ranges. Browsersync was tested and was 30-200ms slower than the above ranges.
Web server commands (run from the public dir):
go run serve.gowago -http :8420 -h2 :8421caddybrowser-sync start --serverIn response to issue #1, I added an XHR test. This makes 165 iterative (not parallel) XHR requests for a 5KB JS payload. Nothing is done with the JS file. Average times:
Just having DevTools open imposes a significant performance hit when loading many JS files with SystemJS. Initially, I thought this was the XHR requests (in this case 165), but the XHR test points to the issue being elsewhere.
HTTP2 actually resulted in slightly slower times. I hypothesize that the overhead of TLS costs more than the benefit of using a single connection when talking to localhost. This test would need to be replicated over the Internet to verify this.