SPA: server-side rendering, do you really need it?
Let's talk about SPA and server-side rendering: in the background of the frontend development world since forever, but with good perspectives for the future.
At 20tab we develop web applications in Python using Django, which suits both the back-end part and the frontend one very well.
However, over the last few years, thanks to AJAX technology and to the success of new front-end development tools, web pages have become increasingly complex, thus favouring the creation of applications which don’t need a page refresh at the end of every new request: we are talking about Single Page Applications, often abbreviated as SPA.
What is a SPA?
An SPA is a website which the user can interact dynamically with by modifying the page he/she is visiting without having to ask the server for the entire rendering of a new page.
This approach allows the user to have a surfing experience similar to that of desktop applications: hence the name web application.
Below follows a list of the most used libraries and frameworks for SPA development.
- React (120k stars, 21k forks, 1200 contributors)
- Vue (44,5k stars, 11,5 forks, 800 contributors)
- Angular (125k stars, 18k forks, 253 contributors)
Number of websites developed
Pros and cons of a SPA
- It is much faster and performing than a traditional website because many resources are only loaded once while surfing.
- It is easy to debug since it is possible to monitor its web operations, examine the DOM nodes and the data associated to them with modern browsers.
- From a microservices-oriented development perspective, developers can use, for instance, the back-end codebase to develop mobile applications as well as other associated products.
- It can exploit the cache of clients effectively, so as to be able to work offline too.
- If not optimised, the first page load may be slow with 3G connections and similar, especially in very complex applications.
- It may be less safe than traditional sites. Because of an insufficient control of inputs, an attacker could exploit vulnerabilities such as cross-site scripting (XSS).
- It is not easy to perform SEO optimizations.
How is the first page served?
Here is an example of showing how a web application is served to the client:
The page contains the essential tags in the <head> section.
Conversely, there is often a node without any content with an associated ID in the <body>. The file generated by a SPA (bundle.js) creates the page content dynamically, by exploiting that very element.
However, this could be a problem if one of the strengths of our application has to be related to indexation on search engines. Let’s analyse Google in particular.
This leads to two phases of indexation:
TIP - Here you have a useful link to help you check how the search engine processes a web application before indexing it: https://search.google.com/test/mobile-friendly
Google has also recently announced an update to Chromium, the rendering engine used by crawlers to scan websites.
"Today, we are happy to announce that Googlebot now runs the latest Chromium rendering engine (74 at the time of this post) when rendering pages for Search.” - 7 May 2019
Link to the article: https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html
Before analysing server-side rendering, let’s briefly see an example that could be defined as hybrid.
In order to ensure that the pages of our application can be shared on social media - which, unlike Google, do not perform the second rendering cycle - certain template systems (such as Handlebars, Twig, etc…) are often used so as to serve the meta of the page server-side.
At 20tab we have used this kind of approach for a few projects, one in particular one: Pasupi - Food delivery finder, a search engine for home-delivery restaurants and pubs.
Isolation between back-end (Python/Django) and front-end (React) made it easy for us to develop the application, which is compatible with android and iOS and has been developed with React Native and the back-end APIs.
SPA server-side rendering
- The first page load is faster.
- Essential for SEO. Google can index client-side SPAs well too, but other search engines might not be able to do it.
- It is one of the most complex architectures that a front-end developer could ever build.
- The development complexity increases exponentially according to the complexity of the application to be created.
- The integration of all the external libraries, such as styled-components or redux, radically changes with SSR.
The development and maintenance cost of an isomorphic application (SPA + SSR) can be really high and does not always gives the expected results.
In addition, server side rendering has always been overshadowed in the world of front-end development and has never received the right push from companies dealing with the development of libraries or frameworks.
As for what concerns the SEO part, search engines are becoming increasingly updated and are going in the direction of single page applications.
I will leave you with a tweet from Dan Abramov, one of the developers working on the React team, that gives us high hopes for the future support of server-side rendering.