SSR and SSG are practically necessary for virtually anyone involved in the software development process: developers, designers, UX, quality assurance, testing, web analysis, SEO, copywriting, and content marketing…
However, there was a massive problem – Single Page Applications were ignored by the search engines. The HTML content rendered on the client-side was only available to search engines only after it was done in the browser, so automatic crawlers didn’t see any of it.
No SEO, no organic user traffic.
That’s where Next.js, SSR, and SSG come into play.
First of all, Next.js is extremely popular. It has over 88.4k stars and 2,2k contributors on Github. According to the State of Frontend 2022 report, 43.1% of developers use and love Next.js (second-best result after React), and over 33% want to learn it in the future (third-best after Svelte and Remix). The creator of Next are still upgrading and improving this solution, so you don’t have to worry about its maintenance and stability.
Next.js is a very versatile technology that provides various approaches to page rendering. Like every solution, it has its limitations, e.g. sharing static content in the production environment using Docker between multiple Next.js instances is not that easy.
SSR allows you to render JS code on the server during runtime and send indexable HTML to users and search engines alike. Next.js simplified server load, caching, and on-demand content, which in turn made applications more interactive and free of the developers’ time.
When do you use SSR with Next.js?
If your app needs to pre-render frequently updated data from external sources, server-side rendering should be your go-to solution. Especially when the data can’t be statically generated before a user request happens. What’s more, it makes your app “seen” by the search engines.
SSR makes sure that your website’s content is updated. You will also gain access to request headers, cookies, and URL query parameters. Next.js will show error pages in case of emergencies, and you can put forward 404-page logic and redirect according to users’ requests.
App example that will massively benefit from SSR is an online shop where users can design their t-shirts, posters, or other items using their own content (e.g. photographs).
Disadvantages of SSR
There aren’t many but you also need to be aware of the negative consequences. SSR website is only cached on CDNs by setting the cache-control header which needs additional configuration. In comparison to statically generated pages, the SSR website could be a bit slower (logic is executed on every request) and TTFB (Time to First Byte) metric will be higher.
Static Site Generation
The same definition as SSR applies here but with a major difference: HTML is generated during build time, not during runtime. You can reuse (and reload) the whole page on each request. Since the entire logic is executed at build time, your page will be much faster than SSR one.
When do you use SSG with Next.js?
Next.js provides On-demand Static Regeneration that allows for purging the static cache for a webpage if the content was updated by an external source (CMS, database). So only up-to-date data and no delays.
If you have to pre-render data, SSG is your technology of choice. Your data is available at build time, on every page with static content. Furthermore, it provide excellent SEO possibilities.
SSG improves performance with CDN caching, so no additional configuration is required. If your backend or data source is down – no worries – static pages are always online. There’s also less server load, since your backend serves only static files.
Sometimes when you work on a website you’d like to see what content it looks like before it’s published. Say no more! Another very useful advantage is the preview mode (the website is rendered at the request time).
App example that will massively benefit from SSG: blogs containing data from a headless CMS.
Disadvantages of SSR
Now for the cons. In comparison to SSR, SSG websites are much less interactive with little to no dynamic content because the website needs to be rebuilt and reloaded entirely every time a change is made. Also, no changes in content between deployments.
There’s no access to incoming requests which means no reading of cookies, request headers, or URL query parameters.
General benefits for your website
You can use adjust SSR and SSG solutions to your requirements, or combine them together. They work towards better usability, performance, and visibility of your content online.
Generally, if you need top-notch SEO and performance optimization – pick SSG.
If you frequently update your data and need great SEO – choose SSR instead.
Here’s a summary of all advantages that either SSG or SRR will bring to your projects:
- Better performance – websites work very fast
- Shorter loading time – you don’t want people to wait more than one second.
- Improved SEO – indexable websites gain more organic traffic from search engines.
- More visits equal more visitors/customers equals more potential profits.
- Better usability – users’ devices (especially mobile!) and internet connections aren’t overloaded with “heavy” websites.