4 ms·

It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophi

It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.

abritinthebay 9y ago
5 seconds per request?? What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses). Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.
qaq 9y ago
did you ever consider that you might not be doing something right ?
- dustingetz 9y ago
  Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ http://hyperfiddle.net/ As I said, our app is sophisticated
  - setr 9y ago
    Why in the world would you take over scrolling like that Is this how you get your kicks?
    - dfee 9y ago
      I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.
      - dustingetz 9y ago
        What is the scroll bug exactly, or are you referring to the perf problems?
        dfee 9y ago
        No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.
        dustingetz 9y ago
        wow, thanks
        setr 9y ago
        On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
        dustingetz 9y ago
        ah its just a flexbox css bug, thanks for the report
        deleted 9y ago
        [deleted]
  - ricardobeat 9y ago
    What is the slowest part? Doesn’t look that complicated visually.
  - happy_rust44 9y ago
    what exactly are the bottlenecks? Done some profiling or benchmarks across your codebase? You say blocking node thread and how exactly are you using threads in node? Maybe resource contention is the actual blocking instead of your ssr pipeline. Lots of variables to look for but it still won't match 5 seconds unless you're doing something very wrong. Anyways there's always a choice for writing hot code in a performant language if you know one...
batmansmk 9y ago
50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.
- dustingetz 9y ago
  our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
  - abritinthebay 9y ago

abritinthebay 9y ago

5 seconds per request?? What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses). Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.

qaq 9y ago

did you ever consider that you might not be doing something right ?

dustingetz 9y ago
Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ http://hyperfiddle.net/ As I said, our app is sophisticated
- setr 9y ago
  Why in the world would you take over scrolling like that Is this how you get your kicks?
  - dfee 9y ago
    I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.
    - dustingetz 9y ago
      What is the scroll bug exactly, or are you referring to the perf problems?
      - dfee 9y ago
        No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.
        dustingetz 9y ago
        wow, thanks
      - setr 9y ago
        On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
        dustingetz 9y ago
        ah its just a flexbox css bug, thanks for the report
        deleted 9y ago
        [deleted]
- ricardobeat 9y ago
  What is the slowest part? Doesn’t look that complicated visually.
- happy_rust44 9y ago
  what exactly are the bottlenecks? Done some profiling or benchmarks across your codebase? You say blocking node thread and how exactly are you using threads in node? Maybe resource contention is the actual blocking instead of your ssr pipeline. Lots of variables to look for but it still won't match 5 seconds unless you're doing something very wrong. Anyways there's always a choice for writing hot code in a performant language if you know one...

batmansmk 9y ago

50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.

dustingetz 9y ago
our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
- abritinthebay 9y ago