In the beginning… there was server rendering. When a user typed a url in to their browser html was delivered to the browser as a whole document. When a user requested a new page after clicking a hyperlink, a new page was delivered with complete HTML including head, body and all frontend scripts that were necessary. When search engines had to spider the website it read the sitemap.xml and processed all pages each time receiving a new fully formed HTML document. This was great from an SEO perspective as the document rendered on the server contained all necessary elements to use for search engines.
Initial page load time of a website is a key factor in a users engagement level in a site and in this day of Gigabit network speeds even an extra second can come with negative revenue potential and user dissatisfaction. When a user first requests an un-cached single page application (SPA) all scripts must be loaded into the browser which causes a significant delay. Aside from CDN caching, workflow tools such as Webpack and Browserify have been developed to among other things allow a SPA to break up codebases into smaller pieces reducing the amount of code that must be transferred to a users computer before a site can function properly.
Another pitfall of SPA’s are the lessened ability of search engines to spider content; this can have a serious effect on a company’s bottom line.
Some other of the advantages to this technique are:
- the ability to share code between the client and server such as routing, validation etc.
- the ability to provide search engines with tailored seo information
React.js is one framework that is leading the way with a wide array of starter projects that integrate server rendering using Node.js. Ember.js has also been working on a similar strategy named FastBoot however it is still far from production-ready. There were also rumours of Angular.js 2 server side rendering support however implementation details are as yet vapourware.