Front-end performance optimization is surprisingly lacking when it comes to web apps. We focus so much on shaving off 50 ms when it comes to server response time, but we're fine with a 7 second load time for front-end. It's very surprising that there isn't as much focus on front-end architecture performance.
Wait, are you replying to a guide on FE performance, completely ignoring the content, to say nothing is being said on FE performance and then promote your own stuff??
I'm not ignoring the content. I'm saying it's a big problem and there should be more focus on it. It's great that people are starting to pay more attention to it.
I removed my links although I think they're complementary to the article.
I know it is a chore, but since it seems to be unwelcome in your top level comment, do you mind posting the links here? I actually am interested in checking them out, and I bet I am not the only one.
In my experience, it's OK to have a (slightly) longer load time for content behind a login wall. I also spend extra effort caching whatever I can for return visits. Refreshing the page should give you an almost instant load time.
Yea, I've run user feedback sessions. Page loads never come up as a complaint (plenty of other things to complain about :P)
The goal was to keep an average of <3.0s for the first meaningful paint, after login. Before login, all pages were treated with the same respect you'd treat any marketing page; render what you can as fast as you can.
Back with AngularJS, when code-splitting and lazy-loading modules/controllers wasn't an option, you had to get creative. Since moving to Vue, initial page load has never been an issue.
Just for balance, the company behind the blog post is also a developer-ran performance monitoring service: https://www.debugbear.com/ (Disclosure: this person is not me, but I have used the service and I do know the person)
Well the main difference is, 50ms of processing time and memory usage on the server I'm paying AWS for, vs. 7 seconds of processing time and memory usage on the client machine the user brought to the party. The goals of performance engineering in the two spaces are different.
Sure, you are right that the goals are different. But good engineers respect the user. And that includes paying close and careful attention to client side performance. While you may not be directly paying for it, crappy performance there will cause users to bail on you - then you won't need to worry about how much the server is costing you.
Indeed, I think the notion that the user’s resources are “free” is deeply flawed. High load time, CPU usage, RAM usage, etc is merely tolerated, not accepted, by users depending on the value of your product, making whatever gains in productivity or reduction in expenses made by shoveling it all off onto the client more like a high interest loan than a freebie.
Good job. Just a minor nit: I assume most website these days have HTTP2 support. Otherwise considering the ROI I would work on that first so that should be optimization #1.
