As more companies embrace digital initiatives, businesses must work hard to not only find an audience for their site, but keep users engaged and interested. However, competing for clicks is becoming increasingly challenging, leaving little room for poor performance in speed and SEO and furthering the importance of social media in driving traffic and gaining conversions. That’s why tools like static site generation (SSG) and server-side rendering (SSR) are gaining (or in the case of SSR, regaining) popularity as a way to optimize performance, SEO, social media sharing, and other business drivers.
Learning about SSR and SSG and when to use them can help digital businesses weigh every possible option for enhancing the user experience and boosting their bottom line. This post will explain the basics of SSR and SSG, their pros and cons, and the various factors businesses should consider when determining how to render web pages.
What Are SSR and SSG?
SSR and SSG are rendering options for generating HTML before it’s delivered to a client’s browser, enabling users to see the page more quickly than they would during client-side rendering, where users see only a blank page while waiting for the browser to compile and render JavaScript. In addition to where the content is rendered, SSR and SSG differ from CSR in when, how, and what type of content is rendered.
- In SSR, a client requests content, dynamic HTML is pre-rendered on the server, and the page is delivered to the client’s browser.
- In SSG, static HTML is rendered at build time from templates and content provided by the developer, then delivered upon request by the client.
- In CSR, the client requests content and the server returns a blank HTML page to the client’s browser, which compiles and executes JavaScript and makes API calls.
Although CSR has been the most frequently used rendering method since the introduction of JavaScript frameworks, increasingly complex web pages with heavy use of dynamic content pulled from numerous APIs have resulted in longer and longer load times, frustrating users with increasingly high performance expectations. In addition, CSR can negatively impact search engine rankings and social media sharing—two risks many businesses cannot afford to take as they face stiff competition for in user engagement measured by pageviews.
How Does Rendering Impact Websites’ Bottom Line?
Driving Traffic
Making the right choice between SSR, SSG, and CSR can play a huge part in one of the biggest determinants of organic traffic: SEO rankings. Statistics cited in a 2017 Forbes blog post stated that the first page of search engine results can capture as much as 92% of web traffic, and only 15% of users will click on an ad or try a different search if they are unsatisfied with first page results. The algorithms that determine SEO rankings take into account not only the quality and relevance of content, but factors like speed, security, mobile friendliness, and most importantly, crawlability. If bots can’t crawl it, they can’t index it, and that means your site won’t appear in search results.
Unfortunately, crawlability can be hard to achieve with CSR. As Google Developers explains in “Rendering on the Web,” “Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work but often not without additional testing and leg-work.”
In addition, CSR doesn’t generate accurate link previews—a real problem for sites that rely on social media sharing to drive traffic. When links are shared on social media, a preview should appear with a picture and title to draw users into the site. These previews are generated by crawlers from social media sites that scan HTML for meta tags describing how the preview should look. However, with client-side rendering, a blank HTML file will be sent from the server, resulting in a generic preview that is the same for every page on the site or no preview at all, making the link less enticing to viewers.
User Interaction
Given the high expectations of today’s users, even small differences in page speed can have a big impact on user interaction. Deloitte’s 2020 report Milliseconds Make Millions found that a 0.1s improvement in mobile speed yielded improvements in conversions, bounce rates, customer engagement, and order size across multiple industries. Furthermore, it stated that slow sites made over 40% of e-commerce users less likely to make a purchase, and over 30% less likely to return to the site.
While the need for speed is obvious to most site owners, what constitutes page speed is a bit more complicated. Device type, user location, Internet connection, and network conditions all play a role in user-experienced speed, resulting in metrics that can vary significantly from user to user, especially when rendering is done on the client side. Furthermore, speed can actually be broken down into multiple subcategories that reflect not only how quickly users can view content, but the type of content they can view, whether they can interact with it, and the time it takes for server-side processes to initiate. These metrics include:
- TTFB, or Time to First Byte: the time between requesting a page and the first byte loaded by a server or other network resource.
- FP, or First Paint: the time it takes for any pixel to load on a user’s screen after requesting a webpage.
- FCP, or First Contentful Paint: the time it takes for any element of the page’s requested content to load on a user’s screen.
- TTI, or Time To Interactive: the time from when a page starts loading to when it can reliably react to user input.
Although client-side rendering has a fast TTFB, FCP and TTI can take a long time, a problem that is compounded for sites with a lot of dynamic content or API calls, and users with a poor Internet connection. As a result, mobile experiences will suffer and impatient users may navigate away from the web page before interacting with or even viewing the content they requested.
What Are the Pros and Cons of SSR and SSG?
Although CSR provides a fast TTFB and great flexibility for web applications, sites that rely on SEO, social media sharing, and mobile users for traffic may want to consider a different rendering method. Whether SSR or SSG is better for your site depends largely on the site’s specific requirements. As with every web technology, there are pros and cons to both methods.
SSR
Although SSR is an older rendering method than CSR, it has recently gained renewed popularity. In addition to being better for SEO and social media, SSR leverages the reliable Internet connection of the server to render most of the site’s content, resulting in a faster FCP, especially for users with poor connectivity. Content on server-rendered sites is also as up-to-date as possible, making SSR great for both dynamic sites and sites that refresh during user sessions, such as news sites.
The drawback of SSR is that rendering on the server can be expensive and resource-intensive. Dynamic HTML can’t be cached by static CDNs, resulting in longer trips to and from the server and a slower TTFB. Second load times—or the time it takes to load a new page in the same website—is also slower, since the server has to retrieve and compile PHP and deliver HTML for each new page. A new technique, universal rendering, avoids this problem with a combination of server-side and client-side rendering, but it requires JavaScript to be rendered in the browser after HTML is delivered, meaning that users with poor connectivity may experience a long wait between when content is visible and when it’s interactive.
Pros of SSR:
- Social media friendly.
- SEO friendly.
- Fast FCP and FP.
- Up-to-date content.
Cons of SSR:
- Slow TTFB.
- Server-intensive workloads.
- Can’t be cached by traditional CDNs.
- Navigating across a site is slow without universal rendering.
- TTI is longer than FTP with universal rendering.
SSG
Static site generation is another alternative to CSR that may seem like a return to older development methods, but recent improvements to SSGs are making them an increasingly popular option. While updating statically generated sites was once a cumbersome task, automation has significantly eased this maintenance burden. New tools like NextJS and GatsbyJS allow developers to add more client-rich functionality to sites, and today’s wide variety of SSGs support many different languages and frameworks. And generating at build time produces incredibly fast load times, making SSGs ideal for keeping up with the high performance expectations of today’s users. Finally, SSGs don’t rely on databases, improving their security and allowing them to live entirely on CDNs for massive scalability during performance spikes.
Although there are clear advantages to SSG, rendering at build time does present some problems. It isn’t a good choice for personalized sites, since content is generated before users request it. Depending on how a site caches and purges content, it may not always be up to date. Finally, individual HTML files must be generated for every URL on a site with each site build, so a site with thousands of pages will have very slow build speeds, making SSG an impractical choice.
Pros of SSG:
- Fast load times.
- Secure.
- Social media friendly.
- SEO friendly.
- Mobile friendly.
- Scalability.
Cons of SSG:
- Problematic for sites with many pages.
- No personalization.
- Content may be stale.
Understanding SSR and SSG in Edge Computing
Changes in user behavior and development techniques have renewed interest in Server-Side Rendering (SSR) and Static Site Generation (SSG) as alternatives to client-side rendering. Each approach comes with trade-offs, but leveraging edge computing can help mitigate some of the challenges associated with SSR and SSG.
For SSR, server-intensive workloads can be reduced by using edge functions to pre-render pages at the nearest edge node before delivering them to the requesting client. This approach improves response times and reduces the load on origin servers. Additionally, the capabilities of Edge Cache enable dynamic caching, allowing frequently accessed content to be delivered more efficiently, leading to faster load times.
With SSG, caching static content at the edge improves both performance and scalability. By storing pre-generated pages closer to users, latency is reduced, and delivery speeds are enhanced. Flexible caching and purging options ensure that content remains up to date while maintaining the benefits of edge distribution.
Integrating these techniques into an edge computing environment allows developers to optimize rendering strategies for speed, efficiency, and cost-effectiveness, adapting to modern web performance demands.