SSR vs SSG in Subsequent.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?

In the event you export a operate known 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 known as in two eventualities:

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

The getServerSideProps operate 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 person to inner and exterior sources.

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

An implementation instance:

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

• you possibly can deal with a question parameter comparable to a class
• if the class parameter doesn’t exist, you possibly can return a redirect object. Subsequent.js will redirect the person 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 an inventory of merchandise

When to make use of SSR?

SSR is advisable for apps during which it’s a must to pre-render ceaselessly up to date knowledge from exterior sources. This method is particularly advisable when the information can’t be statically generated earlier than a person request takes place, and on the similar time must be accessible to serps.

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

Execs 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 robotically
• you’ve entry to cookies, request headers, and URL question parameters
• you possibly can implement logic associated to the 404 web page, and redirects based mostly on person 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 probably be increased than on a statically generated web page

Onto SSG!

Static website technology with Subsequent.js

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

How does Subsequent.js-based SSG work?

Subsequent.js pre-renders pages utilizing static technology, which amongst different issues implies that it doesn’t fetch any knowledge by default. If it is advisable generate a web page that features such knowledge, you’ve two eventualities:

• if the web page content material depends upon exterior data, use getStaticProps technique solely,
• if web page paths depend upon 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 strategy 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 over the past 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 person to inner and exterior sources,
• revalidate – the time (in seconds) it takes for a web page regeneration to happen.

What is absolutely vital, the getStaticProps technique doesn’t have entry to incoming requests. In the event you want entry to the request, think about using ‌some middleware in addition to getStaticProps or take into account SSR as an alternative. In growth mode, getStaticProps known as on each request for a greater developer expertise.

The getStaticPaths technique will solely run throughout a manufacturing construct. It won’t be known as throughout runtime. The technique should 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 person desires to go to a web page that wasn’t listed within the paths array.

Subsequent.js has offered On-demand Static Regeneration in model 12.1. It means that you would be able to 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 operate offers you the power to at all times ship up-to-date knowledge with no delays and nonetheless preserve static technology for a given web page.

An implementation instance:

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

• you implement the getStaticPaths technique to get an inventory of weblog posts based mostly on a response from an exterior API,
• the getStaticPaths technique returns an array of paths, which will probably 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 publish and return the information as web page props to a web page part.

When to make use of SSG?

SSG is advisable to be used on any web page the place it’s a must to pre-render knowledge. It may be generated earlier than a person request takes place. It implies that your knowledge is out there at construct time, or in different phrases – on each web page the place you wish to current static content material or present glorious Search engine optimization capabilities. Examples of such pages embody blogs or advertising websites that include knowledge from a headless CMS the content material of which isn’t up to date fairly often.

Execs of SSG:

• you possibly can enhance efficiency utilizing CDN caching with out a number 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 far sooner than a server-side rendered one as a result of all the logic was executed at construct time
• your backend serves solely static information, which contributes to reducing 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 take into account different options.

SSR and SSG alternate options

With all that stated and executed, one may suppose that SSR and SSG exhaust all the probabilities 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 likely one of the strongest options in Subsequent.js. It allows you to use static technology in a manner that doesn’t pressure you to rebuild your entire web page on ‌each reload.

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

ISR improves the scalability of net functions. You possibly can statically generate lots of of the preferred or newest posts at construct time and allow ISR for the remainder of the articles. As soon as a person makes a request to a web page not listed in getStaticPaths, Subsequent.js will server-render the web page for that person and statically generate the web page within the background. The following person will obtain statically generated content material. It’ll preserve the construct time quick, retaining all the advantages of SSG for each weblog publish. 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 an inventory of posts to pre-render in getStaticPaths the identical manner you do for SSG. The distinction is that the fallback worth is ready to blocking. It implies that when the person 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 probably be executed within the background for the customers that observe.

In getStaticProps, there’s a new property tasked with returning an object known 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 take into account ISR?

• If you wish to refresh the content material with out having to rebuild all the website.
• When you’ve lots of of pages that it’s a must to pre-render however you don’t want to spend hours on constructing an app.
• If you wish to statically generate pages that will probably be created quickly – for instance by content material editors. Once they create a brand new weblog publish, you don’t want to need to rebuild your app to generate a newly created web page.

CSR or Consumer-Facet Rendering

Consumer-side rendering based mostly on client-side knowledge fetching is one other different. Not like within the case of working with server-side rendering API, knowledge fetching could be executed on a web page or part degree. 

Consumer-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 part or web page is mounted and the information just isn’t cached.

When are you able to take into account CSR?

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

If you do determine 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 gives a number of completely different approaches to rendering your pages. Because it covers so many methods, you possibly can simply alter it to your necessities. You should use completely different rendering methods and even mix them collectively.

How to determine which strategy is the very best? Listed here are a few useful inquiries to ask your self:

• Do you want each glorious Search engine optimization and efficiency? SSG is the best way to go.
• Do you want Search engine optimization and the power to ceaselessly replace your knowledge? Use SSR.
• Do you require ceaselessly up to date knowledge however Search engine optimization and efficiency will not be a precedence? CSR is a good selection.
• Do you’ve 1000’s 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 very best steadiness requires a radical evaluation of your mission.

Another excuse for selecting Subsequent.js is simple, and but essential – Subsequent.js is extraordinarily common. It has over 83,000+ stars on Github (greater than another alternate options) and an enormous group. Moreover, the Vercel firm works within the background, guaranteeing steady growth and upkeep of the Subsequent.js framework. Mixed, you’ve a secure, vibrant setting that’s right here to remain.

In fact, as with each framework, Subsequent.js has its disadvantages. For instance, it’s not that straightforward to share static content material between a number of Subsequent.js cases within the manufacturing setting utilizing Docker. Nonetheless, the pliability of Subsequent.js makes it comparatively straightforward to search out options within the occasion of fixing necessities within the mission. Most probably you gained’t have to migrate to a different answer or framework to get issues executed.

Subsequent.js alternate options

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

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 your whole customers the world over. Gatsby combines the very best 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 permits you to concentrate on the person interface. It delivers a quick and slick person expertise. 

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

Hexo

Hexo is a Node.js-powered instrument 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 information in a matter of seconds. It has over 34,000 stars on GitHub.

Hugo

The Hugo mission 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 advice once we discuss net growth!?).

As you may need guessed from its identify, Hugo is written in Go. This is likely one of the causes behind its acknowledged power – 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 technology instrument. It contains fast builds, limitless content material sorts, Search engine optimization, analytics, i18n help with Polyglot, in addition to JSON and AMP codecs.

What is going to the longer term convey?

For the reason that roadmap for Subsequent.js just isn’t publicly accessible (excluding milestones), it’s not that straightforward to foretell what it’ll seem like sooner or later. However there may be at the very least one characteristic that’s actually value mentioning.

React Server Elements

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

Briefly, server elements and their logic will probably 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 elements can include baby elements of the consumer. These elements could be absolutely interactive and hydrated within the browser.

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

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

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

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

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

SSR/SSG to enhance and future-proof your software

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

• SSR and SSG are methods that developed organically to reply to 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 when it comes to 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 embody a number of alternatives to fetch knowledge from the consumer.
• Subsequent.js affords an answer to a number of the SSG points with Incremental Static Regeneration. In fact, this answer comes with its personal package deal of professionals and cons. The latter embody points with caching and debugging.

When you have any expertise with software program growth, both as a dev or enterprise particular person, you positively understand that there are not any one-size-fits-all options. The extra complicated and revolutionary your software is the extra fact that thought holds. The identical factor goes for SSR and SSG.