Modern Web Development Concepts

SSR, SSG, ISR, and CSR—if these sound like obscure government agency abbreviations instead of web rendering technologies, we’re here to clarify some of the confusion.

SSR, SSG, ISR, and CSR are actually the four main techniques used for rendering web pages. While they might seem like alphabet soup to some, they're fundamental concepts in the realm of modern web development.

SSR: Server-Side Rendering

Server-Side Rendering (SSR) is a rendering technique where web pages are generated on the server on demand and then sent to the client's browser. In simpler terms, imagine you're hungry and decide to order a pizza.

With SSR, the pizza is fully cooked in the kitchen (server) and then delivered to your doorstep (browser) ready to eat, rather than the chef bringing all the ingredients over to your house and cooking them in your kitchen. Sure the latter might get to your house faster, but you’re going to be waiting and using your own resources to contribute to the preparation of the final product.

Here's how SSR works: when a user requests a web page, the server fetches the necessary data, processes it, and generates an HTML document dynamically. Once the HTML content is ready, it's sent to the client's browser, where it's displayed to the end user.

For example, imagine visiting a news site built with SSR. When you click on a news, the server retrieves the article's content, assembles it into HTML format, and sends it to your browser. This means that you see the full article immediately, without having to wait for annoying client-side processing.

Pros:

• Improved initial load time

• Better SEO

• Content is accessible even if JavaScript is disabled, allowing for wider browser compatibility

Cons:

• Increased server resource usage

• More round trips to the server

• Limited client-side interactivity

Best practices when working with SSR

• Optimize server response time: Optimize database queries, retrieve only the minimum amount of required data via API calls, and efficiently leverage server-side rendering frameworks (e.g., by devouring the latest content available in our academy!) to minimize page generation time.

• Optimize Google's Core Web Vitals: Monitor key performance and user experience metrics such as First Contentful Paint (FCP), Interaction To Next Paint (INP), and Cumulative Layout Shift (CLS) to identify areas for optimization with tools like Google Lighthouse.

• Add SEO metadata to your pages: Ensure that your server-rendered content is fully accessible to search engine crawlers and that each page has the appropriate metadata according to SEO best practices.

• Consider server-side caching: Adopt caching mechanisms at the server or database level with tools like Redis to save time when receiving requests for already rendered pages.

• Monitor and optimize server performance: Avoid server overloads by keeping an eye on server-side rendering performance metrics through application monitoring systems. 

• Build 404 and 500 error pages: Implement robust error handling mechanisms and fallback strategies to gracefully handle rendering failures and server-side errors.

SSG: Static Site Generation

Static Site Generation (SSG) involves pre-building all website pages at build time, rather than generating them dynamically on each request. 

Think of SSG as a nice dinner party where you have already prepared all the dishes in advance to have more time to have fun with your friends during the event (or maybe you bought something pre-packaged because you’re lazy ). When your guests arrive (website visitors), they can browse the tables (static site) and see all the dishes (web pages) laid out neatly. Quite efficient, isn't it? You don't even need a cook (server) to cook the dishes (generate content) on the spot.

For example, a blog based on SSG would have its blog post pages compiled into HTML files during the build process. If you visit that blog, you’ll receive pre-rendered HTML pages instead of having to wait for on-demand server-side rendering.

Pros:

• High focus on speed and performance

• Increased security

• No need for a complex web server

Cons:

• Limited interactivity

• Longer build times

• Content updates require new builds

Best practices when working with SSG

• Use CDN for content delivery: Distribute your pre-rendered pages closer to end-users by uploading them to a CDN, reducing latency and page load times across geographically dispersed locations.

• Optimize build times: Streamline your static site generation process to minimize build times, ensuring quick updates and deployments.

• Prefer lightweight frameworks: Consider frameworks and libraries that don’t take up much space, as no one loves to wait for their device to download and load a web page.

• Structure your site for UX and SEO: Design the site structure to facilitate navigation by users and crawling by search engines, maximizing both user experience and visibility. Discover more.

Static Sites

Now, with Jamstack becoming a norm for most modern websites, web pages have become increasingly complex and offer richer user experiences. Server-side rendering involves creating pages on the fly when a request arrives on the server. This takes time and slows down the response time.

Enter Static Sites and Static Site Generators. They allow the creation of pre-generated pages at build time, serving up pre-built HTML, CSS, and JS files, and offering better security, performance, and SEO opportunities.

What is a Static Site?

A static site consists of a collection of prebuilt HTML documents, CSS styles, and JavaScript files. When a client makes a request for one of the pages in a static site, the hosting servers directly return the pre-built HTML documents associated with the given URL.

Thus, the hosting delivers the website files to visitors' browsers exactly as they appear on the server. Then the user's browser renders the pages and executes the JavaScript scripts on the client.

This mechanism greatly reduces server response times. The reason is that, unlike dynamic sites, there is no need for retrieving data from a database and generating pages on the fly. Instead, everything is static and already embedded in HTML pages saved on the hosting server disk or memory. In other words, serving a static website requires no server-side processing or connection to a database.

If you want to update such a site, you must regenerate individual pages to update their content. This may require a new deploy. While this process can be cumbersome on large sites, static sites tend to provide faster navigation times and better technical SEO metrics.

Why use a Static Site Generator?

As you can imagine, managing a static site takes a lot of effort. For example, suppose you want to update a section of the template shared across all pages. To do so, you would have to manually change each individual HTML document the site consists of. In a large project, that is simply not possible. Here is why you should use instead a static site generator system.

A static site generator, usually abbreviated to SSG, is a software tool to generate static websites. In detail, it automates the process of converting pages written in markup languages like Markdown or programming languages like JavaScript into a collection of HTML, CSS, and JavaScript files that make up a static site.

The main benefits introduced by static site generators are:

• Streamlined development process: An advanced SSG technology lets code your static site with popular technologies such as React, Vue, and Angular. In addition, it usually provides simplified route management. This helps you organize your page components into a directory structure that will reflect the structure of the output website.

• Support for templates and UI libraries: To define the layout and structure of a site, SSGs use an approach based on templates. For instance, Next.js offers in-depth layout templating features. These templates typically include reusable components like headers, footers, navigation menus, and others. If you opt for a JavaScript static site generator, you also have access to all the packages in the npm ecosystem and well-known UI component libraries such as Bootstrap, Ant Design, and Material-UI.

• Simplified page generation: When you run the build command in the static site generator, the application parses the source files. For each page, it retrieves the required data via queries or API calls, embeds it in the page's HTML document, and produces the rest of the necessary CSS and JavaScript files. So, it generates static HTML files applying any formatting, styling, or other transformations specified in the templates.

• Optimized output files: The collection of static HTML, CSS, JavaScript, and asset files produced by the static site generators are typically compressed, minimized, and optimized for the Web. This helps the user save network resources to retrieve them and client resources to render them.

• Easy deployment: Once the static site has been generated, you can deploy the produced files to any web server, CDN (Content Delivery Network), or static site hosting service. Advanced static site generators like Next.js also have a built-in web server to serve static files directly. 

Examples of SSGs

That being said, there's several options to choose from when building out static sites. Some of the most commonly found examples are:

• Next.js: A Node static site generator that allows you to write static sites in React. As of this writing, it is one of the most widely used web technologies in the world, with a market share of 16.6%.

• Astro: A fresh technology that combines decades of proven performance best practices with the DX improvements of web components. It allows you to use your favorite JavaScript frameworks like Vue.js or React when building a static site.

• Nuxt: A web framework for developing static web applications using Vue.js. It supports both static site generation and server-side rendering. In both cases, you only need to write web pages and Nuxt will do the rest. Find out how to build a blog in Nuxt.

• SvelteKit: A framework for building static web applications, with a seamless development experience, and flexible file system-based routing. Follow our tutorial on how to build a blog in SvelteKit.

You can find the list of the other open-source static website generators on the official Jamstack site.

ISR: Incremental Static Regeneration

Incremental Static Regeneration (ISR) is an advanced technique to update specific parts of a statically generated site without having to rebuild the entire thing. 

Consider your site as a bustling city, constantly evolving and expanding. ISR is like having a team of urban planners continuously updating and improving your city without disrupting its daily life. It's like renovating one building in the city while the rest of the metropolis remains untouched. Italian umarels would love that! (elderly Italians love to stare at construction sites).

When a user requests some web page content—if it’s been a while since its last update—ISR springs into action to swiftly regenerate the page with fresh data and return it to the client. What an innovative way of keeping your site fresh and relevant!

For example, consider a platform where service prices change frequently. With ISR, only the service pages needing updates are regenerated, ensuring you always see up-to-date prices information.

Pros:

• On-demand updates

• High scalability

• A mix between SSR and SSG

Cons:

• Difficult to implement

• Hard to find the right regeneration criteria

• Increased complexity

Best practices when working with ISR

• Focus on critical paths and sections: Get the most out of ISR by prioritizing the pages or sections of your website that require frequent updates or personalized content.

• Optimize revalidation intervals: Fine-tune the revalidation intervals for ISR to balance between serving fresh content and minimizing server load, considering factors like content volatility and user traffic patterns.

• Implement content fallback strategies: Establish fallback mechanisms to serve stale content during regeneration periods, ensuring a smooth user experience even when fresh data is unavailable.

• Set cache control headers: Configure cache control headers to instruct clients on how to locally cache ISR responses to avoid triggering regenerations with unnecessary requests.

CSR: Client Side Rendering

Client-Side Rendering (CSR) is a web development approach where the rendering of web pages occurs dynamically on the user's device rather than on the server. 

Assume the Web is an interactive canvas. You can think of CSR as the artist who sketches the details directly on your screen . Now, imagine walking into an art gallery where each painting is blank upon arrival. As you approach a painting, the details gradually emerge, meticulously crafted by the artist right before your eyes. Similarly, in CSR, the webpage arrives as a blank canvas, and your browser uses JavaScript to fetch data and construct the visual elements on the fly.

For instance, consider a Single Page Application (SPA) that relies on CSR, such as a social media platform. If you visit it—instead of receiving fully rendered pages from the server—your browser receives empty pages with involving a JavaScript bundle. The browser executes the JS code, dynamically generates the DOM, and retrieves new content as you navigate the app.

Pros:

• Enhanced interactivity

• Improved reactivity

• Rich UI

• Resources can be requested onlt when they need to be rendered

Cons:

• Resource-intensive rendering tasks that take time 

• SEO challenges

• Requires JavaScript enabled

Best practices when working with CSR

• Minimize bundle size: Improve load times and reduce bandwidth consumption by optimizing the size of client-side bundles with tree shaking, code minification, and code splitting in small chunks.

• Implement lazy loading: Defer the loading of non-essential resources until they’re needed, reducing initial page load times and conserving bandwidth.

• Cache assets strategically: Leverage browser caching to cache static assets and API responses like a boss.

• Optimize client-server communication: Streamline client-server communication by minimizing unnecessary requests and compressing JSON data payloads.

• Ensure browser compatibility: Test your application across different browsers and devices to ensure consistent performance, responsiveness, and functionality.

SSR vs SSG vs ISR vs CSR

Thought of SSR, SSG, ISR, and CSR as mutually exclusive rendering approaches? Think again!In reality, all four rendering methods can be employed together, each on different areas of the same site:

• Server-Side Rendering (SSR): Pages in the e-commerce section of the site.

• Incremental Static Regeneration (ISR): Pages in the blog section of the site. 

• Static-Site Generation (SSG): Home page, landing pages, terms and conditions page, and privacy policy page.

• Client-Side Rendering (CSR): Back-office SPA platform.

Moreover, even within a server-generated page, certain sections may require client-side rendering and JavaScript execution. Thus, the landscape of page rendering is far more diverse than you may have thought!

Confront the four different rendering approaches explored here in the final SSR vs SSG vs ISR vs CSR summary table below.