3 ms·

You can't beat serving useful data to the user on the first payload (base HTML), no matter how fast or clever client-side rendering gets.

CharlesW 8y ago
Are you arguing for or against SSR here? (Both would include base HTML, no?)
- antoncohen 8y ago
  A single page application (SPA) without server side rendering (SSR) doesn't serve "useful data to the user on the first payload". It serves an empty HTML shell with a script tag (or multiple tags) linking to the Javascript app bundle (or multiple bundles). If the app bundling doesn't break up the app into smaller bundles that are asynchronously loaded, the initial JS payload will probably be 10+ MB. At which point the browser needs to download the 10 MB of JS, execute it, and have the JS fill in the HTML with "useful data". So no, an SPA without SSR doesn't include useful data in the first payload.
  - scottmf 8y ago
    10mb of JS — Examples?
    - romed 8y ago
      I was going to say Slack but it "only" transferred 5MB.
    - antoncohen 8y ago
      10 MB could be an exaggeration on average, but not by a huge amount. Not even trying to find something crazy big, this is the first site I checked because I went to it earlier today and noticed it took a long time to load: https://help.salesforce.com/articleView?id=000232181&language=en_US&type=1 https://help.salesforce.com/articleView?id=000232181&languag... It is simple help article, but instead of serving the actual help article it spends about 2 seconds serving 4 MB of JS and rendering the article. After that I typed 'app.' into my URL bar and went to the first site that came up, that was 3.9 MB of JS on the login page. Numbers are for uncompressed JS, including the larger of the inline scripts.
    - pmlnr 8y ago
      https://petermolnar.net/the-three-facebooks/ https://petermolnar.net/the-three-facebooks/
    - s_kilk 8y ago
      For one example of JS-dumbfuckery, the Patreon embed button is served as a React app, with all of React bundled in dev-mode, weighing in at just over 2mb. All of that for a red rectangle with the word "Patreon" in the middle.
  - it_depends 8y ago
    There are patterns (prerendering, streaming (https://jakearchibald.com/2016/streams-ftw/#streaming-results https://jakearchibald.com/2016/streams-ftw/#streaming-result...), etc.) other than simply breaking up the JS app bundle into smaller pieces that can alleviate the traditional "SPA concerns" — hopefully you can just reduce its size overall. For other thoughts and ideas regarding SSR pros and cons, checkout this presentation given at Polymer Summit (http://www.youtube.com/watch?v=wYGoJ8R3nnM&t=5m35s http://www.youtube.com/watch?v=wYGoJ8R3nnM&t=5m35s).
  - epicide 8y ago
    If you are serving 10MB of JS, then you have a lot more optimizing to do way before you need to think about SSR.
  - pmontra 8y ago
    A Phoenix + React application I'm working on uses react-stdio to render React components server side and speed up page load time when users get to the site for the first time or reload the page in the browser for whatever reason. We ended up with a few hundred MB of RAM for Elixir and a few GB for the Node.js servers. Basically our machines are JavaScript application servers with a little bit of Elixir running in a corner. It feels so odd.
mzzter 8y ago
Agreed. Useful data in the first payload is what matters for a responsive experience. The kind of engineering team drives whether it is appropriately accomplished with view templates, rendered view frameworks, or some other HTML rendering technology that embeds preloaded data.
- deleted 8y ago
  [deleted]
- muthdra 8y ago
  Here's a pattern: since your Service Workers won't run the first time a user visits a page, you should send server-side rendered content to the user that also has a line that installs a Service Worker after the page is fully loaded from base HTML with useful data. The second time the user visits your page, the Service Worker will ideally be installed and will run, intercept the call and download your components separately, when they're needed, and save them on cache, as opposed to let the server render the components to base HTML. Third time forwards, components are loaded directly from cache and rendered by the Service Workers.
  - sebazzz 8y ago
    With a service worker you will often also cache the initial html, so it is then really all dependent on the speed of the code.
  - kinlan 8y ago
    This is exactly the pattern I use in https://github.com/PaulKinlan/webgde-deck https://github.com/PaulKinlan/webgde-deck and whilst is a little harder to mange it's incredibly fast https://webdev.topicdeck.com/ https://webdev.topicdeck.com/ is an example of it hosted.
    - mxstbr 8y ago
      FYI I'm getting "542: An error occured with your deployment" when clicking that link!

CharlesW 8y ago

Are you arguing for or against SSR here? (Both would include base HTML, no?)

antoncohen 8y ago
A single page application (SPA) without server side rendering (SSR) doesn't serve "useful data to the user on the first payload". It serves an empty HTML shell with a script tag (or multiple tags) linking to the Javascript app bundle (or multiple bundles). If the app bundling doesn't break up the app into smaller bundles that are asynchronously loaded, the initial JS payload will probably be 10+ MB. At which point the browser needs to download the 10 MB of JS, execute it, and have the JS fill in the HTML with "useful data". So no, an SPA without SSR doesn't include useful data in the first payload.
- scottmf 8y ago
  10mb of JS — Examples?
  - romed 8y ago
    I was going to say Slack but it "only" transferred 5MB.
  - antoncohen 8y ago
    10 MB could be an exaggeration on average, but not by a huge amount. Not even trying to find something crazy big, this is the first site I checked because I went to it earlier today and noticed it took a long time to load: https://help.salesforce.com/articleView?id=000232181&language=en_US&type=1 https://help.salesforce.com/articleView?id=000232181&languag... It is simple help article, but instead of serving the actual help article it spends about 2 seconds serving 4 MB of JS and rendering the article. After that I typed 'app.' into my URL bar and went to the first site that came up, that was 3.9 MB of JS on the login page. Numbers are for uncompressed JS, including the larger of the inline scripts.
  - pmlnr 8y ago
    https://petermolnar.net/the-three-facebooks/ https://petermolnar.net/the-three-facebooks/
  - s_kilk 8y ago
    For one example of JS-dumbfuckery, the Patreon embed button is served as a React app, with all of React bundled in dev-mode, weighing in at just over 2mb. All of that for a red rectangle with the word "Patreon" in the middle.
- it_depends 8y ago
  There are patterns (prerendering, streaming (https://jakearchibald.com/2016/streams-ftw/#streaming-results https://jakearchibald.com/2016/streams-ftw/#streaming-result...), etc.) other than simply breaking up the JS app bundle into smaller pieces that can alleviate the traditional "SPA concerns" — hopefully you can just reduce its size overall. For other thoughts and ideas regarding SSR pros and cons, checkout this presentation given at Polymer Summit (http://www.youtube.com/watch?v=wYGoJ8R3nnM&t=5m35s http://www.youtube.com/watch?v=wYGoJ8R3nnM&t=5m35s).
- epicide 8y ago
  If you are serving 10MB of JS, then you have a lot more optimizing to do way before you need to think about SSR.
- pmontra 8y ago
  A Phoenix + React application I'm working on uses react-stdio to render React components server side and speed up page load time when users get to the site for the first time or reload the page in the browser for whatever reason. We ended up with a few hundred MB of RAM for Elixir and a few GB for the Node.js servers. Basically our machines are JavaScript application servers with a little bit of Elixir running in a corner. It feels so odd.

mzzter 8y ago

Agreed. Useful data in the first payload is what matters for a responsive experience. The kind of engineering team drives whether it is appropriately accomplished with view templates, rendered view frameworks, or some other HTML rendering technology that embeds preloaded data.

deleted 8y ago
[deleted]
muthdra 8y ago
Here's a pattern: since your Service Workers won't run the first time a user visits a page, you should send server-side rendered content to the user that also has a line that installs a Service Worker after the page is fully loaded from base HTML with useful data. The second time the user visits your page, the Service Worker will ideally be installed and will run, intercept the call and download your components separately, when they're needed, and save them on cache, as opposed to let the server render the components to base HTML. Third time forwards, components are loaded directly from cache and rendered by the Service Workers.
- sebazzz 8y ago
  With a service worker you will often also cache the initial html, so it is then really all dependent on the speed of the code.
- kinlan 8y ago
  This is exactly the pattern I use in https://github.com/PaulKinlan/webgde-deck https://github.com/PaulKinlan/webgde-deck and whilst is a little harder to mange it's incredibly fast https://webdev.topicdeck.com/ https://webdev.topicdeck.com/ is an example of it hosted.
  - mxstbr 8y ago
    FYI I'm getting "542: An error occured with your deployment" when clicking that link!