3 ms·

If a website that is rendered in the browser using a JS framework adds SSR, does that mean that the client-side JS code will be delayed (not render-blocking) so

If a website that is rendered in the browser using a JS framework adds SSR, does that mean that the client-side JS code will be delayed (not render-blocking) so that the first render can happen? How does that work?

danielskogly 6y ago
If I understand you correctly, then the answer is no. As strogonoff mentions in his comment[0], most of the frameworks that provide helpers to enable SSR also provides a way to "rehydrate" in the client side. React has to ways of rendering the app to a string, where one of them outputs html that can be used as the basis for rehydration[1], while the other one[2] drops any extra DOM attributes that the former adds. [0] https://news.ycombinator.com/item?id=23446779 https://news.ycombinator.com/item?id=23446779 [1] https://reactjs.org/docs/react-dom-server.html#rendertostring https://reactjs.org/docs/react-dom-server.html#rendertostrin... [2] https://reactjs.org/docs/react-dom-server.html#rendertostaticmarkup https://reactjs.org/docs/react-dom-server.html#rendertostati...
- SimeVidas 6y ago
  The thing that I don’t understand is, how can the browser render the SSR content if the JS bundle is render-blocking? Doesn’t the JS bundle prevent anything from rendering until all its JS has been executed?
  - danielskogly 6y ago
    It's only render-blocking if put before the content! You can actually see this if you load up the demo[0] and reload the page. For some reason, I've made the mistake of putting the script-tag for the JS bundle _after_ the main content but _before_ the footer. The footer is also rendered on the server, but you'll see - especially if you throttle your connection - that the main app will appear instantly, but the footer ("Try without javascript :)", etc.) won't appear until the JS has finished loading. This is why today it's common to put script-tags for external JS at the end of the body-tag. [0]https://todo-react-redux-noscript.herokuapp.com/ https://todo-react-redux-noscript.herokuapp.com/
    - SimeVidas 6y ago
      Thanks. That explains it. I wasn’t sure if <script> at the end of <body> blocks rendering of the preceding content. Apparently not.

danielskogly 6y ago

If I understand you correctly, then the answer is no. As strogonoff mentions in his comment[0], most of the frameworks that provide helpers to enable SSR also provides a way to "rehydrate" in the client side. React has to ways of rendering the app to a string, where one of them outputs html that can be used as the basis for rehydration[1], while the other one[2] drops any extra DOM attributes that the former adds. [0] https://news.ycombinator.com/item?id=23446779 https://news.ycombinator.com/item?id=23446779 [1] https://reactjs.org/docs/react-dom-server.html#rendertostring https://reactjs.org/docs/react-dom-server.html#rendertostrin... [2] https://reactjs.org/docs/react-dom-server.html#rendertostaticmarkup https://reactjs.org/docs/react-dom-server.html#rendertostati...

SimeVidas 6y ago
The thing that I don’t understand is, how can the browser render the SSR content if the JS bundle is render-blocking? Doesn’t the JS bundle prevent anything from rendering until all its JS has been executed?
- danielskogly 6y ago
  It's only render-blocking if put before the content! You can actually see this if you load up the demo[0] and reload the page. For some reason, I've made the mistake of putting the script-tag for the JS bundle _after_ the main content but _before_ the footer. The footer is also rendered on the server, but you'll see - especially if you throttle your connection - that the main app will appear instantly, but the footer ("Try without javascript :)", etc.) won't appear until the JS has finished loading. This is why today it's common to put script-tags for external JS at the end of the body-tag. [0]https://todo-react-redux-noscript.herokuapp.com/ https://todo-react-redux-noscript.herokuapp.com/
  - SimeVidas 6y ago
    Thanks. That explains it. I wasn’t sure if <script> at the end of <body> blocks rendering of the preceding content. Apparently not.