5 ms·

Why do you think slow web apps are slow?

maccard 4y ago
Poor/no architecture. On the client side - requiring multiple API calls that take tens of ms to respond,doing them serially, trying to mask this with loading transitions that take up to a second that are hit multiple times during common use. On the server side, a pile of microservices that are designed around team responsibility, with requests that require requests that require requests to respond to common API calls. The desire to write the backend in JS causes a very low perf ceiling on a single instance which means a medium sized web app needs a dns lookup, load balancer hit plus reverse proxy in place for (m)any of the API calls, even if they're internal/trusted. These apps are tested and benchmarked on the highest performance professional computing devices on local networks with gigabit connections, and then deployed to 5-10 year old computers running on 10Mb connections shared between 4 people. The servers are deployed to a large number of low cost cloud instances running on a virtualization layer inside a virtualization layer on "enterprise grade" (read: slow) hardware with real world disk and network speeds that are orders of magnitude slower than what is used for testing. Pick any/all of the above!
- baisq 4y ago
  You are saying that web apps are slow because of the server, when we all have seen web apps that are laggy even when showing animations when you hover over elements. Users with slow CPUs exist!
  - Jorge1o1 4y ago
    >laggy even when showing animations Yes, often because those web apps use a javascript like popmotion instead of just plain css transitions. Or some dev writes an onScroll or onHover function with zero debouncing.
  - maccard 4y ago
    No, I'm saying that web apps are slow because there is no thought put into the architecture of the application, and the structure of the app likely matches the structure of the team, not the design of someone who considered holisticly how it would work.
- muxator 4y ago
  It's comforting reading this. Too often web aps are developed thinking about ease of development/developer convenience alone, on fast hw, with fast and reliable network. If those same developers used a 10 years old PC and a semicrappy 4g netwrk I bet the overall quality of the products that comes out would be ten times better.
  - maccard 4y ago
    I don't think that extreme is true either. I work in games and we have access to workstation hardware even though most of our players will inevitably end up playing on substantially lower end hardware. We set performance targets for subsystems, have thorough profiling available, and regularly _test_ on consumer hardware to gain the above metrics and work with them. That can be (and often is) done.
    - solardev 4y ago
      I think game devs are on the opposite side of the spectrum from web devs when it comes to performance testing, though. PC gaming has always been performance-driven, and performance variability/customization has been part of the end-user experience since the first 3dfx cards and graphics settings screen (and before that too). Web... until recently it wasn't really a consideration for users or devs, because everything was just basic HTML and CSS and it was big images or videos that was the problem. Then, within like a decade, suddenly all these JS-heavy frameworks took over and everyone jumped on board, and connectivity has struggled to keep pace. Web developers (the humans) too struggled to keep up, with everyone having to relearn the framework du jour every year or two, with all the optimization techniques of the previous generations thrown out or made irrelevant by new frameworks & browser optimizations. I've never met a web dev who seriously even considered performance beyond some superficial metrics -- I've never seen anyone use the profiler in Chrome or their IDE at all -- much less knew what to do about it even if they did. It's just not really a thing, at least in the small to med business space. Maybe if you're working in big tech or framework development that's different, but otherwise, performance is near the bottom of considerations for web dev. Which is why we have articles like this every once in a while... it's actually newsworthy when people go "hey, JS is slow again, here's technique #33 million to speed it up", to which most of us will go "oh, that's nice, but I can't replace my whole stack just for one speedup, and besides, this new thing is going to be obsolete by September anyway."
onion2k 4y ago
Mostly due to developers writing code that synchronously waits for network requests to complete before updating the DOM. The user clicks, then nothing happens while the app sends a request, and app only updates the DOM after the request completes. It's that 'nothing happens' step that makes things feel slow. They do other things like rerendering part of the app every time any part of the state changes rather than limiting the updates to just the bit that matters to that component too, so the app is doing a ton of unnecessary work (React helps here; it ignores state updates that don't change anything). There's a lot of problems in web apps that make them feel slow, but they mostly distill down to developers following some bad practises that are easily avoidable. Web apps that are slow because they're maxing out what the framework is capable of are very, very rare. Making a faster framework won't fix the ones that are just coded badly. Making a more intelligent framework might.
- maccard 4y ago
  > The user clicks, then nothing happens while the app sends a request, and app only updates the DOM after the request completes I've not seen this too often frankly - that tends to result in a "hung" state for a UI where the app appears to not respond. The most frequent issue I've seen is long transition animations (500+ms) to mask network calls, even when they're not necessary. > Making a faster framework won't fix the ones that are just coded badly. Making a more intelligent framework might. This x1000

Poor/no architecture. On the client side - requiring multiple API calls that take tens of ms to respond,doing them serially, trying to mask this with loading transitions that take up to a second that are hit multiple times during common use. On the server side, a pile of microservices that are designed around team responsibility, with requests that require requests that require requests to respond to common API calls. The desire to write the backend in JS causes a very low perf ceiling on a single instance which means a medium sized web app needs a dns lookup, load balancer hit plus reverse proxy in place for (m)any of the API calls, even if they're internal/trusted. These apps are tested and benchmarked on the highest performance professional computing devices on local networks with gigabit connections, and then deployed to 5-10 year old computers running on 10Mb connections shared between 4 people. The servers are deployed to a large number of low cost cloud instances running on a virtualization layer inside a virtualization layer on "enterprise grade" (read: slow) hardware with real world disk and network speeds that are orders of magnitude slower than what is used for testing. Pick any/all of the above!

baisq 4y ago
You are saying that web apps are slow because of the server, when we all have seen web apps that are laggy even when showing animations when you hover over elements. Users with slow CPUs exist!
- Jorge1o1 4y ago
  >laggy even when showing animations Yes, often because those web apps use a javascript like popmotion instead of just plain css transitions. Or some dev writes an onScroll or onHover function with zero debouncing.
- maccard 4y ago
  No, I'm saying that web apps are slow because there is no thought put into the architecture of the application, and the structure of the app likely matches the structure of the team, not the design of someone who considered holisticly how it would work.
muxator 4y ago
It's comforting reading this. Too often web aps are developed thinking about ease of development/developer convenience alone, on fast hw, with fast and reliable network. If those same developers used a 10 years old PC and a semicrappy 4g netwrk I bet the overall quality of the products that comes out would be ten times better.
- maccard 4y ago
  I don't think that extreme is true either. I work in games and we have access to workstation hardware even though most of our players will inevitably end up playing on substantially lower end hardware. We set performance targets for subsystems, have thorough profiling available, and regularly _test_ on consumer hardware to gain the above metrics and work with them. That can be (and often is) done.
  - solardev 4y ago
    I think game devs are on the opposite side of the spectrum from web devs when it comes to performance testing, though. PC gaming has always been performance-driven, and performance variability/customization has been part of the end-user experience since the first 3dfx cards and graphics settings screen (and before that too). Web... until recently it wasn't really a consideration for users or devs, because everything was just basic HTML and CSS and it was big images or videos that was the problem. Then, within like a decade, suddenly all these JS-heavy frameworks took over and everyone jumped on board, and connectivity has struggled to keep pace. Web developers (the humans) too struggled to keep up, with everyone having to relearn the framework du jour every year or two, with all the optimization techniques of the previous generations thrown out or made irrelevant by new frameworks & browser optimizations. I've never met a web dev who seriously even considered performance beyond some superficial metrics -- I've never seen anyone use the profiler in Chrome or their IDE at all -- much less knew what to do about it even if they did. It's just not really a thing, at least in the small to med business space. Maybe if you're working in big tech or framework development that's different, but otherwise, performance is near the bottom of considerations for web dev. Which is why we have articles like this every once in a while... it's actually newsworthy when people go "hey, JS is slow again, here's technique #33 million to speed it up", to which most of us will go "oh, that's nice, but I can't replace my whole stack just for one speedup, and besides, this new thing is going to be obsolete by September anyway."

onion2k 4y ago

Mostly due to developers writing code that synchronously waits for network requests to complete before updating the DOM. The user clicks, then nothing happens while the app sends a request, and app only updates the DOM after the request completes. It's that 'nothing happens' step that makes things feel slow. They do other things like rerendering part of the app every time any part of the state changes rather than limiting the updates to just the bit that matters to that component too, so the app is doing a ton of unnecessary work (React helps here; it ignores state updates that don't change anything). There's a lot of problems in web apps that make them feel slow, but they mostly distill down to developers following some bad practises that are easily avoidable. Web apps that are slow because they're maxing out what the framework is capable of are very, very rare. Making a faster framework won't fix the ones that are just coded badly. Making a more intelligent framework might.

maccard 4y ago
> The user clicks, then nothing happens while the app sends a request, and app only updates the DOM after the request completes I've not seen this too often frankly - that tends to result in a "hung" state for a UI where the app appears to not respond. The most frequent issue I've seen is long transition animations (500+ms) to mask network calls, even when they're not necessary. > Making a faster framework won't fix the ones that are just coded badly. Making a more intelligent framework might. This x1000