SSR vs SSG in Next.js – tutorial for CTOs and devs

Server-side rendering with Subsequent.js

SSR pages are generated upon every request. The logic behind SSR is executed solely on the server-side. It by no means runs within the browser.

How does Subsequent.js-based SSR work?

Should you export a perform referred to as getServerSideProps from a web page, Subsequent.js will pre-render this web page on every request utilizing the information returned by getServerSideProps.

The getServerSideProps technique is known as in two eventualities:

• when a consumer requests the web page instantly,
• or when a consumer requests the web page in a client-side transition by utilizing subsequent/hyperlink or subsequent/router.

The getServerSideProps perform at all times returns an object with one of many following properties:

• props – accommodates all the information required to render a web page.
• notFound – permits the web page to return a 404 standing and a 404 Web page.
• redirect – permits redirecting the consumer to inner and exterior assets.

Curiously, Subsequent.js claims that the whole code utilized in getServerSideProps needs to be eradicated from the consumer bundle so that you could create server-related and client-related code. It’s not at all times true. One fallacious import or dependency and the bundling won’t work as anticipated. The extra simple the construction of your software is, the better it’s to attain correct habits.

An implementation instance:

As you possibly can see, it’s fairly self-explanatory:

• you possibly can deal with a question parameter equivalent to a class
• if the class parameter doesn’t exist, you possibly can return a redirect object. Subsequent.js will redirect the consumer to a given vacation spot
• if the parameter exists, you possibly can proceed and make a name to an exterior API
• if the information from the exterior API is empty, you possibly can return a 404 web page
• in case you have any merchandise, you possibly can correctly render your web page with a listing of merchandise

When to make use of SSR?

SSR is beneficial for apps by which you need to pre-render often up to date knowledge from exterior sources. This system is particularly beneficial when the information can’t be statically generated earlier than a consumer request takes place, and on the similar time must be obtainable to engines like google.

Instance? A search outcomes web page or an e-commerce web site that features user-generated content material.

Professionals of SSR:

• the web page at all times accommodates up-to-date content material,
• if an error is thrown inside getServerSideProps, Subsequent.js will present an error web page routinely
• you may have entry to cookies, request headers, and URL question parameters
• you possibly can implement logic associated to the 404 web page, and redirects primarily based on consumer requests and knowledge

Cons of SSR:

• the web page is noticeably slower than a statically generated one as a result of some logic must be executed on each request (e.g. API name).
• a server-side rendered web page could be cached on CDNs solely by setting the cache-control header (it requires extra configuration).
• the Time to First Byte (TTFB – the time it takes a server to ship the primary byte of knowledge to a web page) metric will likely be larger than on a statically generated web page

Onto SSG!

Static website era with Subsequent.js

SSG-based pages are generated at a construct time. You may reuse (and reload) the entire web page on every request.

How does Subsequent.js-based SSG work?

Subsequent.js pre-renders pages utilizing static era, which amongst different issues implies that it doesn’t fetch any knowledge by default. If it’s good to generate a web page that features such knowledge, you may have two eventualities:

• if the web page content material depends upon exterior data, use getStaticProps technique solely,
• if web page paths rely on exterior knowledge – use the getStaticPaths technique along with getStaticProps.

The getStaticProps technique at all times runs on the server (versus the client-side). It collects web page knowledge for a given path. The tactic is known as in one in every of three instances:

• through the subsequent construct,
• within the background once you use revalidate,
• on-demand within the background when utilizing unstable_revalidate.

I’m going to go during the last two instances within the Incremental Static Regeneration part.

The getStaticProps technique at all times returns an object with one of many following properties:

• props – it accommodates all the information required to render a web page,
• notFound – permits the web page to return a 404 standing and a 404 Web page,
• redirect – permits redirecting the consumer to inner and exterior assets,
• revalidate – the time (in seconds) it takes for a web page regeneration to happen.

What is de facto necessary, the getStaticProps technique doesn’t have entry to incoming requests. Should you want entry to the request, think about using ‌some middleware moreover getStaticProps or think about SSR as a substitute. In improvement mode, getStaticProps is known as on each request for a greater developer expertise.

The getStaticPaths technique will solely run throughout a manufacturing construct. It won’t be referred to as throughout runtime. The technique have to be used along with getStaticProps. It can’t be used with getServerSideProps.

The getStaticPaths technique at all times returns an object with any of the next properties:

• paths – determines which paths needs to be pre-rendered at construct time,
• fallback – a boolean flag that determines how the app ought to behave in case the consumer desires to go to a web page that wasn’t listed within the paths array.

Subsequent.js has supplied On-demand Static Regeneration in model 12.1. It means that you may manually purge the static cache for a ‌web page if its content material has been up to date in an exterior supply (e.g. a CMS or database). The perform offers you the flexibility to at all times ship up-to-date knowledge with no delays and nonetheless maintain static era for a given web page.

An implementation instance:

The instance above implements the second of the 2 beforehand talked about eventualities – when paths rely on exterior knowledge:

• you implement the getStaticPaths technique to get a listing of weblog posts primarily based on a response from an exterior API,
• the getStaticPaths technique returns an array of paths, which will likely be pre-rendered at construct time,
• fallback: false returned by getStaticPaths implies that software will current a 404 web page for any web page not listed in paths,
• with the getStaticProps technique, you fetch the information for a single submit and return the information as web page props to a web page element.

When to make use of SSG?

SSG is beneficial to be used on any web page the place you need to pre-render knowledge. It may be generated earlier than a consumer request takes place. It implies that your knowledge is on the market at construct time, or in different phrases – on each web page the place you need to current static content material or present wonderful Web optimization capabilities. Examples of such pages embrace blogs or advertising and marketing websites that include knowledge from a headless CMS the content material of which isn’t up to date fairly often.

Professionals of SSG:

• you possibly can increase efficiency utilizing CDN caching with out plenty of additional configuration,
• your static web page is at all times on-line even when your backend or knowledge supply goes down,
• your web page is way sooner than a server-side rendered one as a result of the whole logic was executed at construct time
• your backend serves solely static recordsdata, which contributes to lowering the server load,
• you possibly can run your statically generated web page within the preview mode; the web page is then rendered at request time.

Cons of SSG:

• as a result of lack of entry to incoming requests, you can’t learn request headers, cookies, or URL question parameters,
• your content material can’t be modified between website deployments (with out ISR).

As you possibly can see, each SSR and SSG have their professionals and cons. That’s why you must also think about various options.

SSR and SSG alternate options

With all that mentioned and performed, one might suppose that SSR and SSG exhaust all the chances of shifting your workload to the server. However builders actually can’t assist themselves however innovate on a regular basis. Enter Incremental Static Regeneration!

Incremental Static Regeneration – what’s it?

Incremental Static Regeneration is without doubt one of the strongest options in Subsequent.js. It lets you use static era in a manner that doesn’t power you to rebuild your entire web page on ‌each reload.

Incremental Static Regeneration is an extension of static era. It affords a further property returned by getStaticProps. This property is known as revalidate and is counted in seconds. The revalidate property tells you ways usually Subsequent.js ought to regenerate static HTML for a given web page. The regeneration is triggered by a consumer request somewhat than each “X” seconds. That property needs to be configured primarily based on the character of knowledge you need to present on a given web page like weblog posts, merchandise, user-related knowledge, advertising and marketing content material.

ISR improves the scalability of net purposes. You may statically generate tons of of the most well-liked or newest posts at construct time and allow ISR for the remainder of the articles. As soon as a consumer makes a request to a web page not listed in getStaticPaths, Subsequent.js will server-render the web page for that consumer and statically generate the web page within the background. The following consumer will obtain statically generated content material. It’ll maintain the construct time brief, retaining all the advantages of SSG for each weblog submit. Think about how lengthy the construct can take if you wish to pre-render 10,000+ posts at construct time!

An implementation instance:

How does it work?

You fetch a listing of posts to pre-render in getStaticPaths the identical manner you do for SSG. The distinction is that the fallback worth is about to blocking. It implies that when the consumer visits a web page that isn’t statically generated but, Subsequent.js will return content material after server-rendering is finished for that individual web page. SSG will likely be performed within the background for the customers that observe.

In getStaticProps, there’s a new property tasked with returning an object referred to as revalidate. It’s counted in seconds so Subsequent.js will pre-render the web page when a request comes, however at most as soon as per 10 seconds. When a web page is visited simply as soon as per day, revalidation triggers as soon as per day.

When are you able to think about ISR?

• Once you need to refresh the content material with out having to rebuild the whole website.
• When you may have tons of of pages that you need to pre-render however you don’t want to spend hours on constructing an app.
• Once you need to statically generate pages that will likely be created quickly – for instance by content material editors. Once they create a brand new weblog submit, you don’t want to need to rebuild your app to generate a newly created web page.

CSR or Shopper-Aspect Rendering

Shopper-side rendering primarily based on client-side knowledge fetching is one other various. In contrast to within the case of working with server-side rendering API, knowledge fetching could be performed on a web page or element stage. 

Shopper-side knowledge fetching can have an effect on the efficiency of your software and the loading pace of your pages negatively. That’s as a result of knowledge fetching is finished when the element or web page is mounted and the information isn’t cached.

When are you able to think about CSR?

• when your acquisition technique doesn’t prioritize Web optimization,
• once you don’t must pre-render your knowledge,
• when the content material of your pages wants frequent updating,
• when the web page content material is said to logged consumer knowledge.

Once you do resolve to make use of SSR or SSG, do you have to at all times implement it utilizing Subsequent.js?

Why Subsequent.js for SSR and SSG?

Subsequent.js is a robust answer that provides plenty of totally different approaches to rendering your pages. Because it covers so many strategies, you possibly can simply modify it to your necessities. You should utilize totally different rendering methods and even mix them collectively.

How to determine which method is the most effective? Listed here are a few useful inquiries to ask your self:

• Do you want each wonderful Web optimization and efficiency? SSG is the way in which to go.
• Do you want Web optimization and the flexibility to often replace your knowledge? Use SSR.
• Do you require often up to date knowledge however Web optimization and efficiency will not be a precedence? CSR is a good choice.
• Do you may have hundreds of pages that require frequent updating of content material? ISR is value contemplating.

There are a number of combos of the eventualities above. Discovering the most effective stability requires an intensive evaluation of your challenge.

One more reason for selecting Subsequent.js is easy, and but crucial – Subsequent.js is extraordinarily in style. It has over 83,000+ stars on Github (greater than another alternate options) and a giant group. Moreover, the Vercel firm works within the background, making certain steady improvement and upkeep of the Subsequent.js framework. Mixed, you may have a steady, vibrant setting that’s right here to remain.

After all, as with each framework, Subsequent.js has its disadvantages. For instance, it’s not that simple to share static content material between a number of Subsequent.js cases within the manufacturing setting utilizing Docker. Nonetheless, the flexibleness of Subsequent.js makes it comparatively simple to search out options within the occasion of adjusting necessities within the challenge. Most certainly you gained’t must migrate to a different answer or framework to get issues performed.

Subsequent.js alternate options

There are a selection of different instruments that your can use for each server-side rendering and static website era.

Gatsby

Gatsby is a quick and versatile framework and static website generator that makes constructing web sites with any CMS or API very nice. Gatsby is used for constructing web sites that generate static HTML at construct time. Subsequently, the code could be saved on CDNs and distributed to all your customers internationally. Gatsby combines the most effective components of React and GraphQL so it’s fairly a deal with for builders. Since model 4, Gatsby helps SSR, which makes the framework much more highly effective. Over 52,000 GitHub stars are a testomony to Gatsby’s reputation.

Remix

Remix is a full-stack net framework that allows you to concentrate on the consumer interface. It delivers a quick and slick consumer expertise. 

In Remix, there are solely two rendering modes – you should use SSR at runtime and CSR at runtime. Remix makes use of React to construct consumer interfaces. It accommodates nested routes, which implies that you may run a number of routes on a single view with none loading states. Remix has develop into in style in the previous few months. The group is rising quick. It has over 14,000 GitHub stars.

Hexo

Hexo is a Node.js-powered device that belongs to the SSG class. It’s quick, easy and highly effective. It’s marketed primarily as a weblog framework. It parses your posts with Markdown or one other render engine, producing static recordsdata in a matter of seconds. It has over 34,000 stars on GitHub.

Hugo

The Hugo challenge began again in 2013, but it surely’s nonetheless going robust with some notable adopters together with the Smashing Journal or Cloudflare (isn’t that fairly a suggestion after we discuss net improvement!?).

As you may need guessed from its title, Hugo is written in Go. This is without doubt one of the causes behind its acknowledged energy – pace. Hugo calls itself the world’s quickest framework for constructing web sites. Functionally, it’s a competitor to Gatsby and a correct static website era device. It contains fast builds, limitless content material varieties, Web optimization, analytics, i18n help with Polyglot, in addition to JSON and AMP codecs.

What’s going to the long run deliver?

For the reason that roadmap for Subsequent.js isn’t publicly obtainable (excluding milestones), it’s not that simple to foretell what it can appear like sooner or later. However there may be at the very least one function that’s actually value mentioning.

React Server Parts

React 18 launched the React Server Parts. It doesn’t sound so thrilling at first look, but it surely will get higher! Let’s begin with the docs.

Briefly, server parts and their logic will likely be executed solely on the server. They won’t be topic to the hydration course of. In consequence, you’ll ship freshly generated static items of HTML. Naturally, server parts can include baby parts of the consumer. These parts could be absolutely interactive and hydrated within the browser.

To grasp the sensible implications, let’s fall again on the docs once more.

Regardless of being within the alpha model, server parts already help a few of Subsequent.js APIs, together with subsequent/hyperlink, subsequent/picture, and subsequent/doc. They’ve entry to the router as nicely. It’s injected into the element by the router prop.

Server parts are stateless, so you can’t use React Hooks as useContext, useState, useReducer, or useEffect inside these parts. Moreover, options equivalent to i18n (internationalization) or subsequent/head will not be supported but.

For my part, server parts can probably change the way in which the Subsequent.js framework is used. They might change conventional SSR. Their advantages embrace sending much less JavaScript to the browser (fewer kilobytes to obtain) and limiting the hydration course of to consumer parts. Each ought to enhance consumer expertise by bettering net efficiency, particularly the Time To First Byte and First Enter Delay metrics.

All of it sounds nice in concept, however I’m nonetheless going to do correct trials and resolve about them. I’m going to concentrate to the way in which they affect consumer expertise, net efficiency, and current Subsequent.js workflows. One factor is for certain – React Server Parts are going to make some noise within the Subsequent.js group!

SSR/SSG to enhance and future-proof your software

And that’s it! After all, there may be much more to be mentioned about SSR vr SSG. Nevertheless, this could offer you a strong understanding of the way it works to make each your software and your corporation extra environment friendly. You understand that:

• SSR and SSG are strategies that advanced organically to answer actual points that companies confronted with the efficiency, usability, and visibility of their content material.
• SSR improves all of those metrics with out compromising your net software in any manner.
• SSG affords much more by way of metrics enchancment, but it surely’s not viable in lots of eventualities – the necessity to rebuild your web site each time the information modifications upon web page request limits its use instances to pages that don’t embrace plenty of alternatives to fetch knowledge from the consumer.
• Subsequent.js affords an answer to a number of the SSG points with Incremental Static Regeneration. After all, this answer comes with its personal package deal of professionals and cons. The latter embrace points with caching and debugging.

If in case you have any expertise with software program improvement, both as a dev or enterprise particular person, you undoubtedly notice that there aren’t any one-size-fits-all options. The extra advanced and revolutionary your software is the extra reality that thought holds. The identical factor goes for SSR and SSG.