Comparing different build options
Last updated
Last updated
Rangle.io
In its most basic form, SSG uses markdown and templates to generate pages of a website. This is similar to much of dynamic web programming – the main difference being that with SSG, the pages are generated and the content is bundled at build time.
When a website is built using SSG, the content is pre-rendered, and the site is hosted on a content delivery network (CDN). Static sites load quickly because pages are generated and bundled at build time, cached in multiple servers globally, and delivered by the CDN closest to each user.
In addition, a pre-rendered site with static code has a smaller attack surface, making it harder for hackers to find and exploit vulnerabilities. Since there is no dynamic code execution on the server side, it also eliminates the possibility of injection attacks, which is a common type of security vulnerability in dynamic websites.
Static site generators can also support the dynamic nature of a single-page application, making it a good choice for headless websites. By using APIs, a static site can still be built to interact with other back-end systems, such as Shopify Plus or other headless e-commerce platforms, enabling dynamic and interactive features that are expected of a modern website.
Some SSG websites also use frameworks like Next.js and Gatsby to add extra features and make the website more interactive. This makes the website work like a single-page application, where all the information is on one page, and updates as you scroll or click around.
With server-side rendering, a server-side application renders pages on-demand and sends fully rendered pages to the client. The HTML and page-specific CSS and JS are on a server, and the browser displays the content. The client initiates the SPA framework to make the site dynamic.
The distribution platform provides edge locations that move services closer to the end user to deliver faster experiences.
Incremental static regeneration is a mix of SSG and SSR and is especially advantageous for large sites where individual pages change often. The server builds a requested page and saves the generated static page for later use. Any users requesting a page that has already been requested will receive the cached static page. However, if the team maintaining the website wants to update any of these saved pages, they can revalidate any page, and the server will build the page anew when that page is next requested.
An application deployed with ISR benefits from the performance benefits of static generation, while also being able to selectively rebuild individual pages as they change, enabling very large sites to be updated quickly.
Here are the key factors to consider when evaluating which site builder is best suited to your needs:
Let's walk through the case of a medium-size e-commerce company replatforming a website with over a hundred pages and hundreds of thousands of monthly customers. Their development team is eager to tackle challenging issues, and they are looking for the right site builder to enhance their website's performance.
For e-commerce sites, SEO is extremely important for bringing customers to their websites. Good SEO performance depends on good Web Vitals like fast page load times; SSG and ISR deliver the fastest page load times.
Website performance is also critical for e-commerce businesses: reducing website load time by 100 ms boosts conversion rates by 8% and average order size by 9% for online retailers on average (Deloitte).
The significance of SEO and the high volume of concurrent requests for e-commerce sites narrow our options to either SSG or ISR.
Fast page rebuild could be really valuable for an e-commerce company. For example, products may promote the wrong price or incorrectly show a product is in-stock for a few minutes while a build is processing.
An ISR could save several minutes in build time when compared to an SSG. How would a few minutes' difference in page build speed impact their team's workflows and their customers?
How experienced are their developers? An SSG is the easiest to configure and may be preferable for teams with limited expertise or fewer resources that don't have the time to set up an ISR.
Personalization will require account authentication or analytics to understand who is viewing a page. When using SSG or ISR, a second loading step for data (after the initial page load) is required to determine whether personalized details should be displayed, thereby slowing page load time. For websites that require a lot of personalization and real-time updates, we'd recommend an SSR.
If they don't need personalization right away but want it in the future, we'd recommend starting with an ISR. This will get their teams comfortable with deploying and managing a server and provide the flexibility of switching to an SSR later. In our experience, it's easier to switch from ISR to SSR than from SSG to SSR due to how they're architected.
Trade-offs | SSG | SSR | ISR |
---|---|---|---|
Easiest to configure
✅
❌
❌
Simplest to host
✅
❌
❌
Best at handling many concurrent requests
✅
❌
✅
Fastest page load time
✅
❌
✅
Fastest page rebuild
❌
✅
✅
Up-to-date pages
❌
✅
✅
Able to personalize content for site visitors
❌
✅
❌