7 ms·

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 tim

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.

ChrisCinelli 7y ago
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.
FailMore 7y ago
Just for balance, the company behind the blog post is also a developer-ran performance monitoring service: https://www.debugbear.com/ https://www.debugbear.com/ (Disclosure: this person is not me, but I have used the service and I do know the person)
thrower123 7y ago
It's so much easier to profile and optimize backend requests and the tooling is so much better. So many fewer moving parts to corral.
duhi88 7y ago
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.
- deleted 7y ago
  [deleted]
- mattmanser 7y ago
  I wonder if you've actually talked to any users, or this is just your personal opinion. I hate load times for apps, especially as I know it should be instant and all sites I architecture load instantly.
  - duhi88 7y ago
    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.
jiofih 7y ago
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??
- jmeyer2k 7y ago
  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.
  - filoleg 7y ago
    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.
    - jmeyer2k 7y ago
      Sure! I wrote an article about front-end optimization here: https://blog.pagecheck.app/2020/01/22/5-optimizations-to-make-your-page-run-faster/ https://blog.pagecheck.app/2020/01/22/5-optimizations-to-mak... I'm building a front-end site monitoring tool here: https://pagecheck.app https://pagecheck.app
      - doque 7y ago
        Great looking app, giving it a try now.
jameshart 7y ago
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.
- duckfruit 7y ago
  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.
  - kitsunesoba 7y ago
    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.
mekster 7y ago
Because average devs don't care about anything but the CPU spike on their servers.

ChrisCinelli 7y ago

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.

FailMore 7y ago

Just for balance, the company behind the blog post is also a developer-ran performance monitoring service: https://www.debugbear.com/ https://www.debugbear.com/ (Disclosure: this person is not me, but I have used the service and I do know the person)

thrower123 7y ago

It's so much easier to profile and optimize backend requests and the tooling is so much better. So many fewer moving parts to corral.

duhi88 7y ago

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.

deleted 7y ago
[deleted]
mattmanser 7y ago
I wonder if you've actually talked to any users, or this is just your personal opinion. I hate load times for apps, especially as I know it should be instant and all sites I architecture load instantly.
- duhi88 7y ago
  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.

jiofih 7y ago

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??

jmeyer2k 7y ago
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.
- filoleg 7y ago
  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.
  - jmeyer2k 7y ago
    Sure! I wrote an article about front-end optimization here: https://blog.pagecheck.app/2020/01/22/5-optimizations-to-make-your-page-run-faster/ https://blog.pagecheck.app/2020/01/22/5-optimizations-to-mak... I'm building a front-end site monitoring tool here: https://pagecheck.app https://pagecheck.app
    - doque 7y ago
      Great looking app, giving it a try now.

jameshart 7y ago

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.

duckfruit 7y ago
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.
- kitsunesoba 7y ago
  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.

mekster 7y ago

Because average devs don't care about anything but the CPU spike on their servers.