What is web rendering? It is a process of generating HTML output which is ready to be rendered by web browser and viewable by user, this process can happen anywhere and anytime depending on your strategy.
There are couple strategies to pick where and when for rendering like server-side rendering (SSR), client-side rendering (CSR), static rendering, prerendering, and universal rendering.
Whenever user opens a website, the browser makes multiple requests to your server to get the content including HTML, CSS, JavaScript and other file assets. Whether the initial HTML page is fully viewable or blank, the user has to wait until client-side JavaScript is executed and event handlers have been attached to interact with the website.
Server-Side Rendering means generating the viewable HTML for a page on the server in response to navigation. This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response.
Client-side rendering means rendering pages directly in the browser using JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server.
Prerendering means you put a renderer between your server and user browser to pre-render a client-side application to capture its initial state as static HTML.
Static rendering means producing a separate HTML file for each URL ahead of time at build time, can be deployed to multiple CDNs to take advantage of edge-caching, are interactive without the need to execute much client-side JS.
Universal Rendering combines SSR and CSR via rehydration — data used for rendering on server also sent to browser to fully bootstrap JavaScript framework. Often referred to as Universal Rendering or SSR rehydration, this approach attempts to smooth over the trade-offs between Client-Side Rendering and Server Rendering by doing both.
Your chosen strategy can be pure or hybrid. This is a difficult decision to make and will put great impact on following dimensions:
Check out this post rendering on the web which has a handy infographic showing the server-client spectrum.
Above strategies are slightly different and has their pros and cons, before picking the one for your next project, answer following questions:
How desperately do you need SEO and sharing previews? Crawlers will struggle to understand your sites if meta tags and content dynamically generated from asynchronous JavaScript. Any strategies send fully viewable HTML on initial load will perform well on SEO and social.
How wide is spectrum of supported devices? JavaScript is expensive to process, any strategies scale by JavaScript size will struggle to run fast on slow devices. When you’re using a JavaScript on client side, even you can achieve perceived performance on fast contentful but still have to wait virtual DOM fully booted to interact.
Is your site highly interactive, dynamic or static content, private or public? SSR requires full page reloads so not good for interactivity, static rendering needs to rebuild every time content changes. If you are building an internal dashboard where an extra few hundred milliseconds on initial load doesn’t matter that much.
Can you tolerate high server cost? server-side and universal rendering requires web server to run and will consume a lot resources, client-side and static rendering can be deployed anywhere.
Who are you? server-side and universal rendering require steep learning curve because you have to worry both server and client at the same time. Are you willing to switch solution stacks over time?
There is a longstanding debate over the correct applications of server rendering versus client-side rendering, but it’s important to remember that you can opt to use server rendering for some pages and not others. Some sites have adopted hybrid rendering techniques with success.
There is no silver bullet solution to web rendering, keep learning and don’t afraid to pivot some strategies to see what works for you and what doesn’t.