Performance metrics for web apps
blog.superhuman.com
blog.superhuman.com
Summary:
1. Use performance.now(), which has 0.1ms resolution and is monotonic, instead of new Date() which has 1ms resolution and can decrease if machine time changes
2. Check for document.hidden and the 'visibilitychange' event
3. Use event.timeStamp for start time (when measuring responsiveness to an event)
4. Use the parameter that requestAnimationFrame() passes to callbacks to include time running framework code
5. You can nest requestAnimationFrame() to include Layout and Paint time, but that limits precision to 16ms so they didn't
6. Instead of percentiles, count % of events under a target like 100ms, it's more user-centric: instead of "how fast/slow is my app" it tells you "how often do users experience slowness"
7. Chart the counts at multiple targets in an percent stacked area chart
One weird thing to me about items 5 and 6—why not both? Why not have a chart including and a chart excluding Layout and Paint time, so you know if you're doing bad CSS or something that's introducing an expensive repaint? Why not have a stacked line chart with percentiles alongside the percent stacked area chart?
Not so much anymore.
MDN says: “The timestamp is not actually high-resolution. To mitigate security threats such as Spectre, browsers currently round the results to varying degrees. (Firefox started rounding to 1 millisecond in Firefox 60.) Some browsers may also slightly randomize the timestamp. The precision may improve again in future releases; browser developers are still investigating these timing attacks and how best to mitigate them.”
Also, performance.now (and the date methods) have their precision hamstrung in some browsers for privacy and Spectre mitigation.
Of course, for perf use the dedicated APIs. Just don’t expect microsecond resolution to be accurate.
Also he lost me at don’t measure layout and paint. That’s like the #1 reason why UI is slow. Layout and paint is a very compute intensive task. Deffo you should measure both but you can get huge gains by optimizing how many dom nodes browser has to deal with so layout and paint is efficient.
V8 won’t bat an eye to go through a million items in an array and do a filter map operation on them. Rendering a million things in a browser is a different ball game.
I’ve spent many years of my life optimizing UI perf. I have to give the Chrome devtools team massive kudos for building a great performance analyzing tool.
Be careful skipping this! It is trivially easy to regress layout perf with CSS property changes and if you’re not instrumenting layout you might not catch it. I’ve personally fixed 300ms P90 regressions from thrashing layout on a button click.
The editor boots itself up using less bandwidth than the Apple homepage (last time we checked).
Compared to our executable predecessor it even boots up faster after first run.
We’ve focussed a lot on making it performant and get emails from customers telling us they forget they are using a web app.
Web apps don’t have to be “slow as fudge”!
To answer your question, it depends on the type of response time you're asking. If you mean simply button click event fire type responses, then yes native app development is superior. But like I stated if you wa t your app to be truly write once run anywhere, JS web apps are the way to go.....these days at least.
That being said, I only had one go at React and another brief stint with Android app development. I found them both to be complete messes. Maybe I'm so used to my last job doing C# Winforms, but I haven't found a more comfortable experience.
Also I mostly use mail via IMAP using the iOS mail app, in which case the web client is entirely irrelevant.
They should either lock access to the account until you buy a new subscription (which seems obvious, just hold the account hostage), or lock the account forever if they don't want to store/recv messages for inactive accounts.
Every email startup should learn from this.