Is client-side webpage rendering faster?



  • Short answer: no

    Long answer:

    I did an experiment with some very simple Go code to see whether rendering a page on the client when it was requested (Discourse) would be faster than rendering it on the server and sending it to the client (all other forum software).

    TimelineRawData-20150628T185752.json.bz2 (165.5 KB) TimelineRawData-20150628T185817.json.bz2 (131.8 KB)

    Here are two timelines for a user clicking on a link. Don't worry, I'll get to the exact numbers later. The first one is with JavaScript disabled and the second has JavaScript enabled. They both have adblock enabled, which should give the client-side version an advantage as it doesn't need to run the adblock initialization code after it finishes rendering.

    Now for the numbers. On the server-rendered version, the click event starts at T+1.412244. The browser returns control to the user at T+1.412654, 0.410ms after the user clicked. The HTML is parsed starting at T+1.423816, which means networking and server code took a total of 11.162ms. DOMContentLoaded is fired at T+1.449724, which is a total of 37.480ms after the user clicked the link.

    The client-rendered version has the click event start at T+1.270391. DOMContentLoaded is fired at T+1.318807, 48.416ms later. The browser returns control to the user at T+1.318986. Yes, I put those in the right order. The click event lasts longer than the entire network connection to the server did.

    But wait! The server only took 11ms! You'd have to live within 2079 miles of the server to get a response that quickly!

    Well, no matter what, you have to talk to the server. If you don't have anything dynamic on the page, you're better off using a static page that is preloaded by an HTML5 cache manifest. Discourse does multiple HTTP requests per "page" load. Is that ever going to be faster than rendering the HTML on the server and sending it to the client?

    Yet another instance of a solution looking for a problem.


  • I survived the hour long Uno hand

    @ben_lubar said:

    Is that ever going to be faster than rendering the HTML on the server and sending it to the client?

    When I asked the javascript guys at work, they said it was faster because the client only has to render one page while the server would have to render a page per visitor. Somehow I doubt their logic, but that's what they said.



  • Does the server not have to render the data that the client requests in order to have enough data to generate the page? Do you run your website on a dhromebook?


  • I survived the hour long Uno hand

    Our home page makes 48 requests before it's done loading, so I'm going to say yes.

    Nothing happens on the home page, there's just a fuckton of third party scripts.


  • :belt_onion:

    Can I throw the bullshit 🎌 here? That explanation makes no sense....



  • If your page's main body and script satisfy all the criteria for proxy/cache to work, yes it will enhance performance because the web server will just emit the static compressed stream to clients. The difference is only in the relevent JSON/XML data.

    Also, when there is user action a server-side page will have to render the whole page again, but those using client-side scripts will just need the relevent data, plus it only need to update relevent part of the page, so it is more likely to be more efficient (not always, say when there need to be page redirect the workload will be similar to server side version).



  • @cheong said:

    If your page's main body and script satisfy all the criteria for proxy/cache to work, yes it will enhance performance because the web server will just emit the static compressed stream to clients. The difference is only in the relevent JSON/XML data.

    however, that doesn't apply here because Discourse stuffs several things that would otherwise require a round-trip into the page payload.


Log in to reply