4 ms·

Do you have some good examples of how this "real world" perf if tested? I often write micro benchmarks to see if something is faster one way or another. I ofte

Do you have some good examples of how this "real world" perf if tested? I often write micro benchmarks to see if something is faster one way or another. I often find one browser or another to be 3x to 10x faster in a certain micro benchmark. A big issue is, most websites don't need perf AFAICT. Of the sites I use regularly (HN, Stack Overflow, GMail, Gdocs, GSheets, Facebook, Messenger, Slack, Reddit, github, maybe only gsheets and gdocs need any real perf. The place where perf is needed is things like three.js, playcanvas, babylon.js, unity -> html, etc... And on those AFAIK, Chrome almost always wins, probably, because it's GPU support is multi-process

IainIreland 5y ago
There's no magic answer here. We track various metrics (page load time, responsiveness, gc pause time, and so on) in telemetry. (You can poke around at telemetry.mozilla.org.) We have some page load benchmarks that load a recorded copy of various pages and track how long it takes to load. Sometimes capturing a profile of a particular site can help. Of the big JS benchmarks, we've found Speedometer to be the least bad, because there was at least an effort to mimic actual websites. Microbenchmarks are tricky because it's very easy to measure something other than what you intend: differences in inlining heuristics, say. In the long run, I expect performance-critical websites to migrate to webassembly.
meheleventyone 5y ago
I have to second this, we have a JS based game engine and Firefox is very much noticeably slower than Safari and Chrome in terms of JS performance. I agree with Iain below that in the long run this will mean moving more code to wasm so hopefully the tooling there improves. Right now all it does is move users of performance critical web-first software away from Firefox. Although I’d note that performance is utterly important for normal applications as well. Being noticeably snappy and prompt is great for UX.

IainIreland 5y ago

There's no magic answer here. We track various metrics (page load time, responsiveness, gc pause time, and so on) in telemetry. (You can poke around at telemetry.mozilla.org.) We have some page load benchmarks that load a recorded copy of various pages and track how long it takes to load. Sometimes capturing a profile of a particular site can help. Of the big JS benchmarks, we've found Speedometer to be the least bad, because there was at least an effort to mimic actual websites. Microbenchmarks are tricky because it's very easy to measure something other than what you intend: differences in inlining heuristics, say. In the long run, I expect performance-critical websites to migrate to webassembly.

meheleventyone 5y ago

I have to second this, we have a JS based game engine and Firefox is very much noticeably slower than Safari and Chrome in terms of JS performance. I agree with Iain below that in the long run this will mean moving more code to wasm so hopefully the tooling there improves. Right now all it does is move users of performance critical web-first software away from Firefox. Although I’d note that performance is utterly important for normal applications as well. Being noticeably snappy and prompt is great for UX.