This document is oriented on the objectives and usage of NextJs in possible future projects, I’ll also assess it’s implementation in our current App.
First we need some concepts explained:
1- A crawler enters your webiste,
2- Starts following hyperlinks, reading sitemaps (which lists the most important pages of a website), etc. to find new urls.
3- Crawlers then add these new URLs to the index wich then can be used by the search engines to fullfil search queries.
Client Side Rendering is the normal process in wich the render of the pages is done on the user’s browser. A single HTML file will be delivered to the client without any content (or with a loading screen) until you fetch all the JavaScript and let the browser compile everything before rendering the content.
The main issue of using Client Side Rendering in SEO terms, is that when the crawler enters the application page, it halts as it can’t see any hyperlink to follow because it hasn’t been rendered yet. Then it sends the page to the indexer for rendering and once it’s done, it extracts the hyperlinks to be later navigated. The problem then repeats as, once again, the crawler halts as the new page presents exactly the same situation slowing the whole process down.
With SSR (Server Side Rendering), the flow is the following:
1- A client does a request for a new page.
2- The server then resolves all the pages queries and data needs so it can returns a fully rendered html file to the client.
3- The client then shows an already rendered page wich cannot be used yet.
4- A new process takes places called “Hydratation” which loads Javascript and binds events with html elements, like buttons.
5- Now the web is fully loaded and actionable.
The main benefit of this process is that the crawler can see a fully rendered page and will not halt, as every single hyperlink is already provided wich is truly benefitial for the SEO and results in a better ranking position.
SSG (Static Site Generation) is another solution in which the whole website is rendered and snapshot is then saved on the server. This is great in SEO terms and performant wise, as the heavy work has already been done and the client side can enjoy of the results effortlessly. One big downside is that to use it’s benefits your website needs to work with static content or a database which doesn’t change too much, as with any change, you need to re render the whole website.
To fix this last problem, ISSG (Incremental Static Site Generation) solution provides the same benefits but it will, as it’s name sugests, incrementally generate a snapshop of your website. You may set a timer in which a new snapshot will be created and that suffies with your user’s needs.
NextJs uses both, the client and server side, some or all of the website will be rendered on the server side so the crawler can find the information (URL, metatags, content, etc) and therefore put it into search results.
You may render a page using SSR and then decide to continue rendering on the client as new request are made, or even just render it on the client without any SSR.
Another great benefit of NetxJs, is it’s possiblity of auto code splitting, as each page represents it’s own small Javascript bundle that has been created on the build step.
NextJs always had a great structure but with the 13 version it introduces a beta version of the new “App” directory.
To create a new page and provide routing and code splitting to your code, you just need to create a new folder inside the “app” directory inside the root folder of your application and provide a “page” file to it. Automatically this last file will represent the main component of your new page, but it doesn’t end there.
Normally the correct way of structuring your application would be:
1- Create a container component, which will have the responsability of fetching your data and serve as a layout to your page.
2- Create another component that would serve as the structure giver to your page’s hierarchy tree.
NextJs 13 introduces support to speed up the process and better organize your code, here I will copy from the NextJs documentation that already does an amazing job explaining what every new kind of file.
• page.js: A file used to define the unique UI of a route and make the path publicly accessible.
• layout.js: A file used to define UI that is shared across multiple pages. A layout accepts another layout or a page as its child. You can nest layouts to create nested routes.
• loading.js: An optional file used to create loading UI for a specific part of an app. It automatically wraps a page or child layout in a React Suspense Boundary, showing your loading component immediately on the first load and when navigating between sibling routes.
• error.js: An optional file used to isolate errors to specific parts of an app, show specific error information, and functionality to attempt to recover from the error. It automatically wraps a page or child layout in a React Error Boundary. Showing your error component whenever an error in a subtree is caught.
• template.js: An optional file, similar to layouts, but on navigation, a new instance of the component is mounted and the state is not shared. You can use templates for cases where you require this behavior, such as enter/exit animations.
• head.js: An optional file used to define the contents of the <head> tag for a given route.
• not-found.js: An optional file used to render UI when the notFound function in thrown within a route segment.
With just the inclusion of a new folder with a new “page” component, we can also create nested routes, for example:
Here we can access to:
/login
/register
/topics
/topics/item
It can be thought that SSR is a blessing but it can be really difficult to implement if your application has already been built with CSR or even if it uses hooks.
Let’s try to explain the problem with an example, in my application we use SWR (Stale While Revalidate), a Vercel’s library (the authors of NextJs) to fetch data which provides a great and easy to use API for it. You may thought that because we are using Vercel’s solution, it would be easy to migrate into SSR right ? well, it’s quite the contrary. SWR internally uses useRef, a React’s hook to make a reference to a certain html element and contain it’s value through the lifetime of the component, and as I said before, SSR doesn’t support hooks.
Hooks are the way we can control React’s component life cycle:
1- A componet is mounted.
2- It changes.
3- It is then destroyed when navigating to another url.
As SSR renders the page on the server, there’s no mounting part, so the hook is incomplete and it doesn’t work.
SSR works best for apps that are in need of SEO, if your app relates to a business wich main way of converting a user into a lead is the usage of a landing page, then maybe SSR is not the correct choice for you.
BUT SSR can be a great choice for your landing page so you can develop it faster and with SEO in mind.