But like with any technology, there are pitfalls that you can fall into when you're writing React code if you're not careful.

In this article, we will discuss these common mistakes and I'll provide you with best practices to avoid them. This will help you keep your React projects efficient, maintainable, and scalable.

1. Mistakes in Key Props Usage

One of the most common mistakes when using React involves the key prop. There are several scenarios where key props are used, with lists being the most common.

The key prop is crucial because it helps React track which items have changed, been added, or removed. If they are not correctly set, React's diffing algorithm can become inefficient, leading to performance issues and bugs.

Best Practice: Always pass a stable and unique key for the items in a list. If possible, use unique IDs from your data instead of array indices as keys.

const ItemList = ({ items }) => (
  <ul>
    {items.map(item => (
      <li key={item.id}>{item.name}</li>
    ))}
  </ul>
);

In the above code snippet, each item in the list has a key with item.id. This ensures that every list item is uniquely identifiable, helping React render more efficiently and reduce unnecessary renders.

For more tips on optimizing performance, check out this article on caching in React.

2. Ignoring the Virtual DOM

Some developers mistakenly believe that the role of the Virtual DOM means they need to update the DOM themselves. This goes against how React works and can result in unpredictability and bugs.

What is the Virtual DOM?

For those new to React, the Virtual DOM is an in-memory representation of the real DOM. It allows React to update the UI efficiently by minimizing direct manipulations of the actual DOM. React compares the new Virtual DOM with the previous one and updates only the necessary parts of the real DOM.

Developers might assume they need to synchronize the Virtual DOM with the real DOM due to experiences with other libraries or frameworks.

Best Practice: Always let React handle the DOM. If you must interact directly with the DOM, use refs.

const ItemList = ({ items }) => (
  <ul>
    {items.map(item => (
      <li key={item.id}>{item.name}</li>
    ))}
  </ul>
);

Explanation:

Using a unique identifier from the data, such as item.id, ensures that each key is unique and stable. This allows React to efficiently determine which items have changed, been added, or removed. It helps React's reconciliation algorithm to update the UI efficiently and prevents bugs related to item reordering or deletion.

3. Overusing State

State management is crucial in React, but excessive state usage can make a component complex and difficult to maintain. Any change in state triggers a re-render, which can be expensive if not handled properly.

Best Practice: Minimize the use of state and lift state only when necessary. For global state, use contexts or state management libraries like Redux.

import React, { useState } from 'react';

const MyComponent = () => {
  const [count, setCount] = useState(0);
  const [name, setName] = useState(''); // Additional state

  const handleIncrement = () => setCount(count + 1);
  const handleNameChange = (e) => setName(e.target.value);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleIncrement}>Increment</button>
      <input
        type="text"
        value={name}
        onChange={handleNameChange}
        placeholder="Enter name"
      />
    </div>
  );
};

In the above example, the useState hook is used to maintain a simple count state. When the button is pressed, it displays and increments the count, demonstrating a very basic use of state.

4. Forgetting to Clean Up Effects

When using the useEffect hook, it is essential to clean up side effects to prevent memory leaks and other unintended behaviors. Side effects might include setting up subscriptions, timers, or event listeners that need to be cleared when the component unmounts or when the effect dependencies change.

Best Practice: Always return a cleanup function from your effect when setting up side effects that need to be cleared.

Example without Cleanup:

const Timer = () => {
  const [time, setTime] = React.useState(0);

  React.useEffect(() => {
    const intervalId = setInterval(() => {
      setTime(prevTime => prevTime + 1);
    }, 1000);
    // No cleanup function provided here
  }, []);

  return <div>Time: {time}s</div>;
};

In the example above, a timer is set up with setInterval, but no cleanup function is provided to clear the interval when the component unmounts. This can lead to memory leaks.

Correct: Cleanup with useEffect:

const Timer = () => {
  const [time, setTime] = React.useState(0);

  React.useEffect(() => {
    const intervalId = setInterval(() => {
      setTime(prevTime => prevTime + 1);
    }, 1000);

    // Cleanup function to clear the interval
    return () => clearInterval(intervalId);
  }, []);

  return <div>Time: {time}s</div>;
};

In this corrected example, a cleanup function is provided to clear the interval when the component unmounts, preventing potential memory leaks.

5. Ignoring Performance

A React application can encounter serious performance issues, such as excessive re-renders and heavy calculations during render.

Best Practice: Memoize components and values using React.memo, useMemo, and useCallback for improved performance.

const MemoizedComponent = React.memo(({ data }) => {
  return <div>{data}</div>;
});

This example uses React.memo to memoize a functional component, preventing it from re-rendering unnecessarily when the data prop hasn't changed.

6. Overusing the Context API

The Context API is very handy for passing data through your component tree without prop drilling. But it's often overused, leading to performance issues.

Best Practice: Avoid using context for frequently changing values. Mainly use it for static values or rare updates.

const ThemeContext = React.createContext('light');

const ThemedComponent = () => {
  const theme = useContext(ThemeContext);
  return <div className={theme}>Themed Component</div>;
};

In the above example, ThemeContext is initialized with the default value 'light'. The ThemedComponent uses the useContext hook to get the actual value of the theme.

7. Not Handling Errors Properly

One important feature of React is error boundaries. They catch and handle errors in the component tree. Without them, unhandled errors may eventually crash the entire application.

Best Practice: Implement error boundaries using componentDidCatch or ErrorBoundary components.

const UserProfile = ({ userId }) => {
  const [user, setUser] = React.useState(null);
  const [error, setError] = React.useState(null);

  React.useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(response => {
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        return response.json();
      })
      .then(data => setUser(data))
      .catch(err => setError(err.message));
  }, [userId]);

  if (error) {
    return <div>Error: {error}</div>;
  }

  if (!user) {
    return <div>Loading...</div>;
  }

  return <div>{user.name}</div>;
};

By adding error handling, we catch any issues with the API request and display an appropriate error message.

This approach improves the robustness of the component, providing users with feedback in case of an error and ensuring the application remains functional even when unexpected issues occur.

8. Failing to Keep Components Pure

React components should always be pure functions of their props. Impure components depend on external states and side effects, making the system unpredictable.

Best Practice: Ensure that your components are pure and that their output depends entirely on their props.

const MyComponent = ({ name }) => {
  return <div>{name}</div>;
};

This functional component is pure because it only depends on the name prop to render its output.

9. Not Using React Developer Tools

React Developer Tools is a simple yet essential extension for debugging and optimizing the performance of a React application. Development can become more complicated if you don't use this helpful toolkit.

Best Practice: Install and use React Developer Tools regularly to inspect component hierarchies, state, and props.

10. Ignoring SEO Best Practices

SEO is an important aspect of any web application, and this holds true for React applications as well. Many developers overlook SEO, leading to poor search engine rankings and reduced visibility.

Here are some of the most common React SEO mistakes:

Wondering how to implement the React SEO Best Practices? Good news, I made a follow up video:

Best Practices: If video is not your thing, here are the key points to remember:

• Always render your content server-side: Google has publicly stated to avoid Client-Side Rendering (CSR).

• Ensure unique URLs for different pages: Since React is a Single Page Application (SPA), always render different URLs for different pages. For example, if you have 5 landing pages, make sure you render 5 unique URLs.

• Ensure unique metadata for each page: As a bonus tip, use React Helmet to ensure every single page has unique metadata.

• Internally link your website: Surprisingly, many developers completely ignore this. Make sure to add internal links to improve navigation and SEO.

Conclusion

In conclusion, avoiding these common React mistakes can greatly improve the performance and maintainability of your applications.

If you're interested in learning more about my work or need help with React or Next.js development, check out hirenext.dev. Alternatively you can keep up with my blog OhMyCrawl.

In this article, I'll explain why CMSs exist, the problems they help solve, and I'll also offer helpful guidance in choosing the right CMS for your needs.

What is a CMS?

You can think of a CMS as an extremely user-friendly database for your website’s content.

A CMS provides an intuitive interface that allows website owners and content creators to manage a website's content without requiring advanced technical skills.

As an example, think about it from the perspective of someone who wants to own a blog, but doesn’t know anything about web development. It would be very difficult, if not impossible, for this person to modify the source code of the web site in order to add a new article to the blog.

This is where a CMS comes in. The CMS is linked to the owner’s website, and the site has built in code that pulls data from the CMS and automatically publishes this data on the site. In this example, the data could be a new blog article and image.

Headless CMS vs Traditional CMS

You may have heard the term “headless CMS” floating around, and wondered what that was all about. Nowadays, CMSs come in two flavors; a traditional CMS, and a headless CMS. Let’s take a look at a few definitions to get a better grasp of each:

What is a Traditional CMS?

A traditional CMS is a complete website management system that not only stores your content in a user-friendly database, but also offers a front end, usually a WYSIWYG style editor to build out your actual web page.

The front-end UI designer and backend storage system are unified in one intuitive interface. Wordpress is a famous example of a traditional CMS.

What is a Headless CMS?

A headless CMS is similar to the traditional CMS, but without the front-end WYSIWYG editor to build your site. If you think of your actual webpage as the “head”, and your content as the “body”, then this starts to make sense.

A headless CMS is totally independent of your site’s design, and you can typically use any framework of choice and connect it to the headless CMS. The headless CMS acts similar to a backend database, but is tailor-made for handling typically used website content like images and rich text.

When Do I Need a CMS?

Before concerning yourself with choosing the right CMS for your needs, it is essential to understand whether you actually need one. CMSs are designed to streamline the process of creating, editing, and managing digital content, primarily for websites.

If you’re wondering whether you should consider a CMS, ask yourself the following questions:

1. Does the website require frequent content updates, such as articles or product listings?

2. Will there be multiple content authors collaborating on the website's content?

3. Does the website require flexible content structuring and organization to accommodate future changes?

If you answered yes to one of these questions, there’s a good chance that your project would benefit from the features offered by a good CMS.

CMS Integration and Compatibility

It’s important to consider ease of integration with your chosen system or framework. You may be considering adding some functionality to your site such as an e-commerce system or customer relationship management (CRM) software. Or you may just be starting a new project from scratch.

Either way, it is crucial to ensure that the CMS you select can seamlessly integrate with these systems.

Most frameworks, such as Next.js, Gatsby or Astro, will offer a list of official CMS plugins that streamline the process of integration. Of course, a CMS can be added to any project without an official plugin by utilizing the API from your CMS of choice, and coding everything manually.

But it’s usually wise to look for a CMS that is supported by your framework, as it takes much of the heavy lifting out of the equation and allows you to focus on other pressing concerns.

For example my blog has a list of the best CMS for Next.js to choose from. Most frameworks have a number of CMSs that are compatible and created by 3rd party developers.

When searching for a CMS with seamless integration and compatibility, look to your framework’s official docs for guidance, which should tell you what public libraries are available.

CMS Features to Consider

When evaluating CMS options, do some research and testing rather than going for the first option that pops up. While the specific requirements may vary depending on your project, here are some fundamental features to look for:

1. User-Friendliness: The CMS should have an intuitive and user-friendly interface, enabling non-technical users to manage and update content easily.

2. Content Organization: Effective content organization is crucial for a CMS. Look for features such as categorization, tagging, and metadata management to ensure your content is easily searchable and conveniently organized.

3. SEO Optimization: Ensure the CMS supports essential SEO features, such as image optimization, full-featured rich text editors, and friendly URLs.

Common CMS Pitfalls

There are a few potential pitfalls you should consider, because utilizing a CMS doesn’t always live up to expectations. Here are a few common challenges:

1. Overwhelming Complexity: This may seem oxymoronic, considering my earlier statement that CMSs are supposed to simplify things. But everyone is different, and one CMS may not suit your taste as much as the next person. It’s a good idea to create an account and take a look around, maybe even create some content, just to get a feel for whether the CMS is right for you.

2. Hidden Costs: Many CMSs claim they are free. But almost all of them begin charging when you reach a certain threshold of traffic or storage capacity. It’s important that you do your research, and ensure that you’re considering whether your project will venture into the realm of “paid service” sooner than you expected.

3. Limited Support and Documentation: When encountering issues or needing assistance, reliable support and comprehensive documentation is paramount. Ensure that the CMS you choose has an active community, official support channels, and extensive documentation or user guides. This support network can be invaluable in troubleshooting problems and learning how to make the most of the CMS's features.

Conclusion

Choosing the right CMS is an important decision that can impact your website's performance, scalability, and ease of management. By understanding the purpose of a CMS and evaluating your specific needs, you can make an informed decision that aligns with your goals.

Ultimately, a CMS should empower you to efficiently create, manage, and update content, allowing you to focus on delivering a compelling user experience. At the end of the day, meaningful content is the goal, and a CMS should be a helpful hand that guides you through the process.

Hope you enjoyed the post. If you want to learn more about CMSs and SEO in general checkout OhMyCrawl. If you want to follow along with one of my side projects, checkout my latest site Trust In Geeks to follow my journey.

As with any tool or programming methodology, caching plays a huge role when it comes to optimizing React applications.

Caching in React typically goes by the term memoization. It's used to improve performance by reducing the amount of times a component renders due to state or prop mutations.

React provides two APIs for caching: useMemo and useCallback. useCallback is a hook that memoizes a function, while useMemo is a hook that memoizes a value. These two hooks are often used in conjunction with the Context API to further improve efficiency.

Here’s a basic list of topics we’ll be covering in this article:

1. React caching default behavior.

2. The useMemo hook.

3. The useCallback hook.

In order to follow along, you'll need a decent understanding of React and stateful components.

Default Caching Behavior in React

By default, React uses a technique called “shallow comparison” to determine whether a component should be re-rendered. This basically means that if the props or state of a component haven’t changed, React will assume that the output of the component hasn’t changed either and won’t re-render it.

While this default caching behavior is very effective by itself, it isn’t always enough to optimize complex components that require advanced state management.

In order to achieve more control over your component’s caching and rendering behavior, React offers the useMemo and useCallback hooks.

Caching in React with the useMemo Hook

useMemo is useful when you need to do an expensive computation to retrieve a value, and you want to ensure that the computation is only performed when necessary. By memoizing the value using useMemo, you can ensure that the value is only computed when its dependencies change.

In a React component, you may have multiple properties that make up your state. If a piece of state changes that has nothing to do with our expensive value, why recompute it if it hasn’t changed?

Here’s an example code block reflecting a basic useMemo implementation:

react
import React, { useState, useMemo } from 'react';
function Example() {
const [txt, setTxt] = useState(“Some text”);
const [a, setA] = useState(0);
const [b, setB] = useState(0);
const sum = useMemo(() => {
console.log('Computing sum...');
return a + b;
}, [a, b]);
return (
<div>
<p>Text: {txt}</p>
<p>a: {a}</p>
<p>b: {b}</p>
<p>sum: {sum}</p>
<button onClick={() => setTxt(“New Text!”)}>Set Text</button>
<button onClick={() => setA(a + 1)}>Increment a</button>
<button onClick={() => setB(b + 1)}>Increment b</button>
</div>
);
}

In our Example component above, assume the sum() function performs an expensive computation. If the txt state is updated, React is going to re-render our component, but because we memoized the returned value of sum, this function will not run again at this time.

The only time the sum() function will run is if either the a or b state has been mutated (changed). This is an excellent improvement upon the default behavior, which will rerun this method upon each re-render.

Caching in React with the useCallback Hook

useCallback is useful when you need to pass a function as a prop to a child component, and you want to ensure that the function reference does not change unnecessarily. By memoizing the function using useCallback, you can ensure that the function reference remains the same as long as its dependencies do not change.

Without getting too heavy into JavaScript function references, let’s just take a look at how they can affect the rendering of your React app. When a function reference changes, any child components that receive the function as a prop will re-render, even if the function logic itself has not changed.

This is because, as we already mentioned, React does a shallow comparison of prop values to determine whether a component should re-render, and a new function reference will always be considered a different value than the previous one.

In other words, the simple act of redeclaring a function (even the same exact function), causes the reference to change, and will cause the child component that receives the function as a prop to unnecessarily re-render.

Here’s an example code block reflecting a basic useCallback implementation:

react
import React, { useState, useCallback } from 'react';
function ChildComponent({ onClick }) {
console.log('ChildComponent is rendered');
return (
<button onClick={onClick}>Click me</button>
);
}
function Example() {
const [count, setCount] = useState(0);
const [txt, setTxt] = useState(“Some text…”);
const incrementCount = useCallback(() => {
setCount(prevCount => prevCount + 1);
}, [setCount]);
return (
<div>
<p>Text: {txt}</p>
<p>Count: {count}</p>
<button onClick={setTxt}>Set Text</button>
<button onClick={setCount}>Increment</button>
<ChildComponent onClick={incrementCount} />
</div>
);
}

As you can see in the above example, we pass the incrementCount method instead of the setCount method to the child component. This is because incrementCount is memoized, and when we run our setTxt method, it won’t cause the child component to unnecessarily re-render.

The only way our child component will re-render in this example is if the setCount method runs, because we passed it as a dependency parameter to our useCallback memoization.

Conclusion

Caching is an important technique for optimizing React applications. By reducing unnecessary re-renders, caching can help to improve the performance and efficiency of your application.

React provides a default caching behavior by using a virtual DOM to compare changes in state and props, and only updating components after a shallow comparison reflects changes. This is a great optimization technique that’s sufficient in many scenarios, but sometimes more fine-grained control is desired.

The useMemo and useCallback hooks were created to achieve this fine-grained control.

useMemo is used to memoize the results of a function call, and is useful when the function is expensive to compute and the result does not change often.

useCallback is used to memoize the actual reference of a function rather than the returned value, and is used when the function is passed as a prop to child components that might cause unnecessary re-renders.

Want to learn more? To learn more check out the OhMyCrawl Blog for more programming tips for SEO.

Here's what we'll cover in this guide:

1. What is server side rendering? What are its pros and cons when compared to other rendering methods such as Client Site Rendering (CSR)?

2. How do you know if a site is rendered using SSR?

3. How to use SSR, and things to keep in mind when choosing an SSR framework.

4. How to leverage SSR to improve performance.

We’ll cover each of these items in depth, so that by the end of this tutorial you have a firm grasp of server side rendering and how it fits into the ever-changing world of web development.

We should also look at two key terms we’ll be using throughout, and what they mean:

1. HTML – Hyper Text Markup Language. HTML isn’t technically code, it’s simply a markup language that structures your content on a web page.

2. DOM – Document Object Model. The DOM is an actual model of your HTML, made up of objects. It has an API interface which allows you to modify it, and in-turn modify the HTML.

It’s important to understand the difference between HTML and the DOM. When you're reading through documentation it's easy to become confused and misinterpret the two.

What is Server Side Rendering (SSR)?

SSR is when you render your website's HTML on the server. This is as opposed to Client Side Rendering (CSR) when your website renders HTML in the browser by manipulating the DOM with JavaScript.

How to Check For SSR

There are certain times when you'll want to check whether a site is using server side rendering. For instance, both developers and SEO professionals often need this information to help troubleshoot and optimize technical SEO issues.

We'll discuss a few techniques commonly used to determine this.

Check the page source

An easy way to determine if a site is using SSR is to view the page source.

If the HTML code is complete with all the content, including the main body, images, text, and so on, the site is likely using SSR.

On the other hand, if the HTML code is bare-bones, then it requires JavaScript to render the content. In this case, it's probably not using server side rendering.

The first step is to right click in Chrome or your favorite web browser:

Right click 'view page source'

Once you are viewing the source code, you'll be able to easily search for content elements, for example you'll bee able to find <p> , <h1>, and so on.

If you can see them here, more then likely they are rendering server side:

Anything you see here is rendering sever side

Check Google Cache

An easy way to determine if your content is rendering server side is to check the Google Cache.

Simply type in the URL you want to inspect like this with the site: operator into Google.

For example below I typed in site:[https://www.freecodecamp.org/news/](https://www.freecodecamp.org/news/) then selected 'Cached':

type in your URL into Google, then select 'Cached'

Generally speaking, anything you can visually see is server side rendering. If it's rendering with Javascript, more than likely you won't be able to see it:

Anything you see here most likely renders Serverside

Bonus Tip: Disable JavaScript

You can also test if a site is using SSR by disabling JavaScript on your browser. If the website's content is still visible without JavaScript, it is likely using SSR. If the website appears blank, it is not using SSR.

In this example here, we can clearly see Airbnb is not leveraging server side rendering on their homepage:

And here's a pretty good visual representation if you don’t quite get the concept yet:

SSR vs CSR

Let's break down the different processes in client side and server side rendering, followed by the advantages and disadvantages of each one.

How SSR Works

1. An HTTP request is made to the server.

2. The server receives the request, and processes all (or most of) the necessary code right then and there.

3. The end result is a fully formed and easily consumed HTML page that can be sent to the client’s browser via the server’s response.

This is a fairly simple concept on the surface, but things can get pretty complicated when considering how to include interactive components on the client that require JavaScript. We’ll touch on that later – first let’s check out what happens when you request a CSR web app.

How CSR Works

1. An HTTP request is made to the server.

2. The server receives the request, and responds by sending an empty HTML shell to the client along with a bunch of bundled JavaScript.

3. The client receives the empty HTML shell, and proceeds to process all of the JavaScript.

4. The JavaScript modifies the DOM extensively, which renders the final HTML for the end user.

To put this in simplified language, client side rendering is when your website or web app renders into HTML in the browser by processing JavaScript, rather than on the server using whatever the backend framework of choice is.

Next we’ll take a look at the strengths and weaknesses of each style of rendering.

Benefits of SSR

The main benefit of server side rendering is page load speed. Page load speed is an important metric for user experience, and subsequently an important aspect of technical SEO. Google wants to consume pages fast, too.

When a page is rendered into HTML on the server, all of the heavy-lifting is taken care of. For this reason, when the response makes it to the client’s browser, there isn’t much work left for the browser to display the page. It’s ready to go upon delivery.

Drawbacks of SSR

There are plenty of reasons why most JavaScript frameworks have decided to include SSR as a rendering option in their frameworks. But there are a few drawbacks to SSR

Designers want pages to be interactive, and when a page is rendered into pure HTML for the client, it leaves a pretty bland user experience. So how do we make these pages interactive while preserving all the great benefits of server side rendering?

The answer is an added layer of complexity that goes by many names, but it’s most commonly known as code-splitting and hydration.

Code Splitting and Hydration

In order for a page to be interactive, we need JavaScript to be sent to the client. SSR frameworks such as Next.js and Astro allow us to build an HTML only page on the server that can be sent to the client fast, while allowing for specific bundles of JavaScript to be sent to the client after the initial HTML has loaded.

In the React world, this process is known as hydration. The code is split into manageable chunks that can then be requested on an as needed basis and injected, or hydrated, into the client page to add interactivity and functionality.

You may be wondering why this is a “drawback.” Well, the idea itself isn’t the drawback, it’s the technical challenge that comes along with it. Isomorphic React and other technologies that are used to accomplish this goal are notoriously complex, and it takes intimate knowledge of a framework to program these sites efficiently.

Benefits of CSR

The benefits of client side rendering are essentially the polar opposite of server side rendering. We have excellent availability for interactive functionality, as the entire HTML page is built using JavaScript on the client. In fact, the entire CSR framework is often sent to the client in a purely client side rendering environment.

For this reason, once the page is initially loaded everything is very responsive for the end user. That’s because everything, including the code for all other pages, is loaded along with the initial page load.

From a developer’s standpoint, client side rendering is a great experience. The complexity of sharing the workload with the server is non-existent, and we can focus on building reusable interactive components that make for a streamlined development process.

Drawbacks of CSR

Soon after the explosion of CSR frameworks, SEO specialists started to realize that Google and other search engines don’t do a good job indexing these pages. The synopsis was clear: pure CSR sucks for SEO.

Initial page load speed is the main drawback here. When using CSR, the page is initially sent to the client as an empty HTML shell with no content. This empty husk is often what Google and other search engines see, which isn’t desirable for obvious reasons.

The JavaScript will build the page pretty quickly, but in practice most search engines still have trouble indexing the content after the DOM manipulation has completed and the HTML is rendered.

In the worst case scenario, the load time of a poorly built client side rendering app can even begin to negatively affect user experience, which is the ultimate blunder.

When to Use SSR vs CSR

Based on what we’ve learned so far, it should be no surprise that server side rendering is a great choice when initial page load is a priority and technical SEO is important. But that’s not the only driving factor behind this consideration.

When a site has a ton of dynamic and frequently changing data, server side rendering allows developers to share the workload of retrieving content.

When using a purely client side rendering app for data intensive sites, it requires many calls from the client to the server to fetch the data. This can lead to pages becoming bogged down and slow to load, which can result in a poor user experience.

Server side rendering addresses this issue by allowing the server to pre-fetch and pre-render the necessary data before sending it to the client.

Remember, most server side rendering implementations aren’t purely SSR, they just get the heavy stuff out of the way. Developers still have the option to send specific, small bundles of JavaScript after the fact that add interactivity and even data fetching, in essence sharing the data fetching load with the server.

How to Leverage SSR for Your Project

Unless you’re trying to build a framework of your own, SSR isn’t something you want to implement from scratch. Luckily, there are many frameworks and libraries that can help you leverage SSR in your project.

One popular option is Next.js for SEO, a React framework that provides built-in support for SSR, along with code-splitting and other performance optimizations.

When it comes to leveraging server side rendering in a way that maximizes its performance benefits, you should be mindful of the impact of your application's data fetching distribution. Heavy data loads can slow down the SSR process and impact the performance of your application, which is one reason developers fetch data from the client as well.

When it comes to data fetching and processing on the server side, you can also start to incur some pretty hefty fees from your hosting provider. Keep a close eye on this if your project demands include an abundance of external data.

Overview and Concluding Thoughts

Server-side rendering (SSR) can be a powerful tool for improving the performance and user experience of web applications. By rendering HTML on the server before sending it to the client, SSR can significantly reduce the time required to display a web page, resulting in faster load times and a better user experience.

When used correctly, the technical perks of SSR usually translate to better SEO as well, as it provides search engines with easily crawlable HTML documents. If you are interested in learning more about server side rendering, check out OhMyCrawl to learn more.

Due to the complex nature of isomorphic system design, Next.js SEO can be a tricky topic to get your head around. Especially if you're coming from traditional React apps and you're relying solely on documentation.

With its built-in support for server-side rendering, static site generation, and now React server components, Next.js provides a robust platform for achieving quality SEO web metrics in your web application. It also helps you deliver exceptional user experiences across multiple pages in Node and React apps while making them SEO friendly.

Why Should You Learn NextJS for Front End Development?

In short, the newest version of NextJS is an open source platform that addresses a lot of rendering issues that React currently has. I wrote this article because a lot of front end developers get mad at me :-D.

They spend 6-9 months developing a React App, and then I have to ask them to refactor their code.

Next.js avoids a lot of rending issues – it makes it very easy for search engines to understand what your website is all about.

Who Will get the most out of this article?

This will be very helpful to you if you're a marketer or more advanced developer who's experiencing SEO issues.

However newer developers are welcome to review this info as well, as it will help you in the long term.

How Should You Render Your Next JS Web Page Application?

I've personally reviewed a ton of theses websites from my consultancy OhMyCrawl and made a video overview to help understand the benefits of using frameworks such as Next.js for SEO:

How is Next SEO Different from Other Frameworks?

Next SEO sets itself apart by streamlining so many features and free tools into a well-organized package that you can easily digest and apply in your single page applications. Next does a great job when it comes to tasks such as search engine optimization, image optimization, and minimizing cumulative layout shift.

The benefits of Next.js SEO don't stop there. We’ll be covering many of the goodies that Next.js brings to the table related to search engines, old and new.

Search Engines, SSR, and SSG Concepts Are Evolving

Most developers and SEO experts have become pretty comfortable with the existing page creation strategies and the whole SSR vs SSG paradigm. They've also developed a high level of trust in version 12 of Next.js, which provides a clear cut way to handle these two forms of page generation.

As usual, though, yet another web app paradigm shift is underway, this time in the form of React Server Components (RSCs), which are included by default in Next.js version 13.

SEO Concepts Haven’t Changed – Just the Approach

Next JS SEO won’t change much conceptually. If you’re looking for good search engine results and organic traffic, the game still revolves around the notion of fast page loads, quick paints, low cumulative layout shifts, and all the rest. Static pages still play a large role as well.

But Next.js gives us some pretty cool and novel features that help facilitate excellent search engine metrics, and it’s more than just React Server Components.

We'll explore some best practices along with a few different techniques and strategies for achieving great SEO optimization web metrics with Next.js. We'll also see how to take advantage of its unique features to improve your website's search engine visibility and user engagement.

What’s New With Next.js 13 that Relates to SEO?

Rather than give you a comprehensive guide to the technical changes found in version 13, we’re going to focus mainly on Next JS SEO related advantages. We'll also look at how you can leverage the best SEO practices to achieve the best possible results in search engines with much less sweat off your back than is typically needed.

The version 13 changes we’ll discuss here are as follows:

• React server components

• Streaming UI chunks

• Updated Next Image component

• Next Font component

On top of the existing default SEO properties of Next, these particular upgrades are the cornerstone of Next.js SEO improvements in version 13. Each one is awesome for its own reasons, which we’ll be going over shortly.

React Server Components

RSCs allow for a more fine-grained approach to rendering on both the client and the server.

Rather than being forced to decide whether to render an entire page on the client or server upon user requests, React allows developers to choose whether components should be rendered on the server or the client. This can give you a huge advantage in search engine results pages.

A huge majority of page optimization these days revolves around sending less JavaScript to the client. After all, this is the primary benefit of using pre-rendering and Server Side Rendering to create web pages and HTML pages.

RSCs are another tool to help achieve this end and gain as much SEO value from your web pages or single page applications as you can. This helps achieve better SEO by refreshing dynamic data in a React component while leaving the static parts of the page’s content intact.

Streaming UI Chunks

Next.js SEO made a huge leap adding RSC to the mix, and streaming UI chunks is the cherry on top. Streaming UI is a similar spin-off of a new and growing design pattern called “the island architecture,” which strives to send as little code to the client as possible at first load.

Allowing fine-grained control is great, but why not send a JavaScript-free, fully rendered page to the client, and send the rest later? That’s exactly what streaming UI chunks accomplish.

When Next.js renders a page on the server, the page typically comes with all the JavaScript bundled up and sent along with it. The ability to stream chunks of data eliminates this need, and allows an extremely tiny static page to be sent to the client, significantly improving web metrics such as first contentful paint and overall page speed.

Next.js 13 App Directory

When you start a new Next.js 13 project, you’ll notice a new directory called app. Everything within the app directory is preconfigured to allow for RSCs and streaming UI chunks. You need only create a loading.js component, which will wrap the page component entirely and any children within a suspense boundary.

You can achieve an even more granular loading pattern by manually creating the suspense boundaries yourself, essentially allowing for unlimited control over what gets loaded upon the initial request.

The steps for streaming UI chunks go something like this:

1. User makes initial request.

2. Barebones HTML page is rendered and sent to the client.

3. JavaScript bundles are being prepared on the server.

4. A page section requiring JavaScript becomes visible in the client browser.

5. JavaScript bundle for only that component is sent to the client.

This new tooling has important implications for technical SEO by allowing more interactive pages to compete with static pages in regards to page load speed and other web metrics that are used as ranking factors in search results by search engines.

Updated Next Image Component

Another important upgrade to the Next.js SEO sphere is the Image component. Although it’s been somewhat understated, the biggest improvement in my opinion is the utilization of native lazy loading.

Browsers have had great support for native lazy loading for some time now, and including extra JavaScript for this feature is simply a waste of bandwidth.

A few other great improvement for SEO are:

• Required alt tag by default.

• Better validation to pinpoint errors involving invalid properties.

• More easily styled due to a more HTML-like interface.

Overall, the new Image component is simplified and slimmed down, and in the programming world simpler is almost always better.

The Next Font Component

The font component is a huge win for Next.js SEO, and it will certainly help alleviate many headaches in the future. Any experienced developer knows how tedious it can be configuring fonts properly (proper is not relative in this case!).

Cumulative layout shifts due to slow loading is a common nuisance, and search engines like Google have openly stated that CLS is an important web metric.

Depending on the framework you’re working with (Gatsby comes to mind), it can be tricky getting your fonts to preload effectively. Making external requests to font repositories such as Google have been a necessary evil for some time, creating a hard to manage bottleneck in many SPA applications.

The Next Font Component aims to solve this problem by fetching all external fonts at build time, and self-hosting them from your own domain. Fonts are also optimized automatically, and zero cumulative layout shift is accomplished by automatic utilization of the CSS size-adjust property.

Common SEO-Related Tasks with Next.js

There are a few important topics to consider when configuring common Next.js SEO tasks for version 13.

Next.js SEO With Version 13

The Next version of the React Head component has typically been used to assign values to meta tags within the document head and also to inject structured data.

With version 13, however, the Head component goes out the window. At first, Next opted to utilize a special file called head.js that works in a similar fashion as the Head component. After version 13.2, Next implemented the Metadata component, which is a more proprietary implementation to solving the metadata problem by easily populating meta tags.

Let’s take a closer look at these two common SEO tasks, and examine how they used to be handled as opposed to the new version 13 way.

How to Configure the Head Tag for Search Engine Optimization

Prior to version 13, we would import the Next/Head component, and set any necessary metadata values such as title and description or other meta tags within the html file of the web page.

A simple example of the Head component in version 12 looks like this:

import Head from 'next/head'
const structData = {
'@context': 'https://schema.org',
'@type': 'BlogPosting',
headline: 'Learning Next.js SEO',
description: 'All about Next.js features and more',
author: [
{
'@type': 'Person',
name: 'Jane Doe',
},
],
datePublished: '2023-02-16T09:00:00.000Z',
};
function IndexPage() {
return (
<div>
<Head>
<meta name="viewport" content="initial-scale=1.0, width=device-width" />
<title>My page title</title>
<script
key="structured-1"
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(structData) }}
/>
</Head>
<p>Hello world!</p>
</div>
)
}
export default IndexPage

Adding structured data such as title and description or any additional meta tags in a page’s metadata is a simple matter of including a script tag with the dangerouslySetInnerHTML attribute, as seen in the example.

Most developers code an SEO component that utilizes the Head component in order to achieve a more DRY (don’t repeat yourself) approach. Here, you prevent the same data or HTML files from being sent multiple times to the user. But under the hood it’s all the same, and Head was the go-to approach for optimizing a web page in regards to meta tags.

The Next Special head.js File

With version 13, you can forget all about the usual Head component. Starting with the first iteration of version 13, Next implemented the head.js (or .tsx) file. This file can be included within any folder inside the app directory to dynamically manage SEO metadata and declare which tags, along with their values, will be utilized for a particular route and particular page.

Every folder in the app directory accounts for a new route, which is why you’ll need to create a head.js file within each folder to configure your metadata values. Here’s an example head.js file:

export default function Head(params) {
return (
<>
<title>head.js Example</title>
</>
);
}

Notice that we return a React fragment rather than an actual head tag, or any other element. This is a required aspect of the head.js component.

You can only return the following metadata tags from within the fragment:

Leveraging Helmet for metadata inclusion can significantly simplify the process of making a React app SEO and social media friendly.

Helmet lets us insert metadata into the tag in much the same way we would using standard HTML syntax.

In this article, we'll cover the following steps:

1. How to install and import the React Helmet library.

2. Basic usage for client and server side rendering (CSR vs SSR).

3. More advanced usage of Helmet for setting up an SEO component.

In order to understand these topics, you should have a basic knowledge of the React library.

React Helmet Installation and Setup

If you're already familiar with using React and Node, installing Helmet should be a breeze.

However, before demonstrating, it's important to note that the standard react-helmet library is now considered deprecated. Instead, you should use react-helmet-async.

This is because react-helmet led to a few bugs that resulted in memory leaks and poor data integrity. Suffice it to say, when React developers mention Helmet, they're almost always referring to react-helmet-async.

Now to the installation. Simply navigate to your project's directory in the terminal, and install react-helmet-async with your package manager of choice. Here's the syntax for yarn and npm:

yarn add react-helmet-async
npm i react-helmet-async

Once the installation completes, you can move on to importing and utilizing the Helmet component library.

React Helmet Basic Concepts and Usage

The two components we'll be importing from react-helmet-async are called Helmet and HelmetProvider.

1. HelmetProvider will wrap the entire app component in order to create context and prevent memory leaks. Therefore, this component will only need to be imported in the root App component.

2. Helmet will be imported into any page component where you want to implement meta tags. Think of as the tag for the page in question.

We're going to start with basic usage of both client side rendering (CSR) and server side rendering (SSR). Let's start by seeing how things work in a basic CSR implementation:

import React from 'react';
import { HelmetProvider } from 'react-helmet-async';
import NavBar from './NavBar';
import Landing from `./Landing;
export default function App() {
return (
<HelmetProvider>
<NavBar />
<Landing />
</HelmetProvider>
)}

As you can see, in the App component we only imported the HelmetProvider component from react-helmet-async. Pretty simple.

The SSR implementation is very similar, with one small addition. Let's have a look and see if you can spot the difference:

import React from 'react';
import { HelmetProvider } from 'react-helmet-async';
import NavBar from './NavBar';
import Landing from `./Landing;
export default function App() {
const helmetContext = {};
return (
<HelmetProvider context={helmetContext}>
<NavBar />
<Landing />
</HelmetProvider>
)}

If you noticed the addition of the helmetContext variable being passed as a prop to our HelmetProvider, you nailed it!

This paradigm is found using most popular state management systems such as Redux, and helps ensure that context is never scoped outside of the current instance of your app.

Now, let's assume the following page component is the landing page for your React app:

import React from 'react';
import { Helmet } from 'react-helmet-async';
export default function Landing() {
return (
<div>
<Helmet>
<title>Learning React Helmet!</title>
<meta name='description' content='Beginner friendly page for learning React Helmet.' />
</Helmet>
<h1>Cool Landing Page!</h1>
</div>
)
}

A quick review of the Landing page component shows that we imported the Helmet component, and used it to add the title and description metadata to the page.

We simply add the HTML equivalent meta tag inside the Helmet component, and the work of adding this to the HTML tag is handled for us.

Awesome! We're now on the road to creating an SEO-friendly React app.

Creating an SEO Component With React Helmet

Metadata isn't only about Google search results. We also want social media posts that reference our site to show up as cool preview cards.

When it comes to metadata and meta tags, there's a ton of different variants to remember. Facebook uses og (open graph) tags, Twitter uses its own twitter variant, and so on.

How to Use Components for Abstraction

One cool thing about creating React components with props is that you can reuse a prop inside the component however you please.

Using this knowledge, you can create a component called SEO that abstracts away the usage for commonly used metadata tags, saving you from having to track down each tag variant every time you build an SEO-friendly app.

An example SEO component that streamlines the process of adding Facebook and Twitter tags could look like this:

import React from 'react';
import { Helmet } from 'react-helmet-async';
export default function SEO({title, description, name, type}) {
return (
<Helmet>
{ /* Standard metadata tags */ }
<title>{title}</title>
<meta name='description' content={description} />
{ /* End standard metadata tags */ }
{ /* Facebook tags */ }
<meta property="og:type" content={type} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
{ /* End Facebook tags */ }
{ /* Twitter tags */ }
<meta name="twitter:creator" content={name} />}
<meta name="twitter:card" content={type} />
<meta name="twitter:title" content={title} />
<meta name="twitter:description" content={description} />
{ /* End Twitter tags */ }
</Helmet>
)
}

As shown above, our component accepts four props: title, description, name, and type. Using these four props, we were able to distribute the values across nine different types of meta tags!

Here’s an example of how we could implement this component in our Landing page component:

import React from 'react';
import { SEO } from './SEO’;
export default function Landing() {
return (
<div>
<SEO
title=’Learning React Helmet!’
description=’Beginner friendly page for learning React Helmet.'
name=’Company name.’
type=’article’ />
<h1>Cool Landing Page!</h1>
</div>
)
}

So, all we had to do is pass in our four props, and our custom SEO component handles all the heavy lifting of creating the multiple different types of metadata tags. Nice.

This example is far from an exhaustive list of meta tags. It doesn't take much imagination to visualize how useful this component would be if you wanted to include all relevant meta tags for your site.

Conclusion

In this article we went over why React Helmet is a useful addition to your React app. You learned not only basic setup and usage, but also a more advanced implementation that helps abstract away much of the repetitive work involved in metadata tags.

Hopefully you now feel confident enough to enhance your React SEO and social media performance by implementing the React Helmet Async library. Good luck and happy coding!

For more information on how to set up your JavaScript websites for search engine success, check out ohmycrawl.com.

Metadata is an integral part of any modern web app, because it's inherently tethered to search engine optimization (SEO).

Search engines and their respective results page (SERPS) rely on metadata to properly index and display relative information for each site.

Also, meta tags are relied upon to properly display content from your site on a given social media platform, such as articles or items for sale.

For this reason, it's crucial to understand how metadata is configured in a modern web app.

The single page application (SPA) is a modern web app implementation that is incredibly popular. Most frameworks today utilize it in some way. Configuring metadata in today’s most popular SPA frameworks will be the focus of this tutorial.

The Single Page Application and Metadata

The nature of SPAs make configuring metadata a less straightforward process than classic multiple page applications. I'm going to try to clarify this topic by describing the following key concepts:

1. The structure of an SPA.

2. The problem with modifying metadata in an SPA.

3. Available metadata solutions using what are probably the three most popular SPA frameworks: React, Svelte, and Vue.

You should have a basic understanding of HTML, metadata, and one of the three SPA frameworks to understand the concepts we’ll be going over. But, I’ll be keeping things beginner friendly, so don’t worry!

How Single Page Applications Work

Before diving in, you need a firm grasp of what constitutes an SPA.

As the name implies, a single page application literally consists of a single HTML page sent down from the server. This page is just an empty HTML shell, and will look something like this:

<!DOCTYPE html>
	<html>
		<head>
		<title>Home | Demystifying SPA Metadata</title>
		<meta name="description" content="How to configure popular SPA 			frameworks to maintain quality site metadata."/>
		<link rel="stylesheet" href="./stylesheet.css" type="text/css" 			/>
		</head>
		<body>
			<script src="/bundle.min.js" type="text/javascript">					</script>
		</body>
	</html>

You might be wondering how an entire website is derived from this empty HTML shell.

This is possible because along with the HTML page will be extensive client-side JavaScript code that generates the content for each page. This code is included in the page via the