The internet depends on physical infrastructure: fiber-optic cables, satellites, and data centers often located thousands of kilometers away. Network requests travel at high speed, but they are still limited by the speed of light (around 300,000 km/s). For instance, a network request from Lagos, Nigeria to a server in San Francisco, USA travels more than 12,000 km, and takes about 150–200 milliseconds for a single round trip under ideal conditions. Multiply that by the 20–30 requests a typical web page makes (for HTML, CSS, images, APIs and more), and those milliseconds quickly add up to seconds of delay before a page fully loads.

In this article, we’ll explain in detail what Round Trip Time(RTT) is, why it is one of the most overlooked factors in web performance, and how you can use Next.js to minimize the number of RTTs to make your applications feel fast and responsive. You will learn how features like Server-Side Rendering (SSR), React Server Components (RSC), image optimization, and caching all work together to reduce Round Trip Time in a web page.

What You will Learn

• What You will Learn

• What is Round Trip Time (RTT)?

  • How Distance Increases Round Trip Time

• How Round Trip Time Affects Web Performance

  • Why Client-Side Rendering Feels Slower

• How to Reduce Round Trip Time with Next.js

  • Server-Side Rendering (SSR)

  • React Server Components (RSC)

  • Image Optimization

  • Caching and Static Rendering

• Trade-offs Across Next.js Rendering Methods

• When to Use Each Rendering Method

• Conclusion

What is Round Trip Time (RTT)?

When you visit a website, the browser makes a network request to a server. The server processes the request and then sends a response back. The Round Trip Time is the complete duration of this journey in milliseconds, which includes:

1. Travel Time: The amount of time it took the network request to get to the server.

2. Processing Time: The amount of time the server took to process the request.

3. Return Time: The amount of time it took the response get back to the browser.

How Distance Increases Round Trip Time

Round Trip Time depends heavily on the physical distance between the client and server. For example:

• A user in Lagos, Nigeria making a network request to a server in London that is about 5,000 km away might see a round trip time of 100–150 ms.

• A server in San Francisco that is about 12,000 km could push the roundtrip time to 200–300 ms. The farther the server, the higher the round trip time.

How Round Trip Time Affects Web Performance

Modern web pages make multiple network requests to load completely. Imagine loading an e-commerce product page that requires:

• 1 network request for HTML (about 200 ms)

• 5 network requests for CSS/JavaScript (about 1,000 ms)

• 10 network requests for images (about 2,000 ms)

• 4 network requests for product data via API (about 800 ms)

That shows that the product page will take 20 network requests to fully load, which is about 4 seconds of network delay.

The probability of bounce increases 32% as page load time goes from 1 second to 3 seconds (Google/SOASTA Research, 2017). That means about one-third of visitors leave before the page even loads.

Why Client-Side Rendering Feels Slower

In client side rendering applications, each request adds a round trip time, and traditional client-side rendering (CSR) in React apps increases this:

• The browser downloads a minimal HTML shell and a large JavaScript bundle.

• The JavaScript runs to fetch data and render the UI, requiring additional network requests.

• Each API call adds another RTT, delaying the First Contentful Paint (FCP).

First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page's content such as text, images,<svg> or <canvas> elements is rendered on the screen.

In CSR apps, FCP is delayed because the browser cannot display any meaningful content until JavaScript has finished loading, parsing, and executing the code needed to construct the UI. A regular CSR application may need 5 to 10 network round trips to get all the resources needed for the rendering of the UI, which can easily add several seconds of delay.

// pages/index.js (CSR)
import { useState, useEffect } from "react"

export default function Home() {
  const [products, setProducts] = useState([])

  useEffect(() => {
    // Fetch data after page loads
    fetch("https://api.example.com/products")
      .then((res) => res.json())
      .then((data) => setProducts(data))
  }, [])

  return (
    <div>
      <h1>Products</h1>
      {products.length ? (
        products.map((product) => <p key={product.id}>{product.name}</p>)
      ) : (
        <p>Loading...</p>
      )}
    </div>
  )
}

In the code above, when the Home component mounts, it initializes the state as an empty array. The useEffect hook then runs once to make an API request. While the request is in progress, the “Loading...” message is displayed on the screen. Once the request completes successfully, React updates the state with the fetched data and re-renders the UI to display the products. This process introduces an extra round trip, which further delays the FCP.

How to Reduce Round Trip Time with Next.js

You cannot eliminate round trip time completely. Data must still travel over the network. What Next.js does is to reduce how often those network requests happen and how much data each request carries. It does this through a number of techniques, such as Server-Side Rendering (SSR), React Server Components (RSC), image optimization, and caching or static rendering.

Server-Side Rendering (SSR)

Unlike traditional React.js applications, where the browser handles the majority of the work, such as fetching static files, JavaScript, and data required to render a page, the server generates the whole HTML, fetches the data, renders the page, and sends it to the browser in a single round trip time.

Advantages:

• Fewer Round Trips: Since data fetching and rendering take place on the server, the browser receives a ready-to-display page in one round trip time.

• Improved First Contentful Paint: Low round trip time means content displays on the page almost immediately.

// pages/index.js (SSR)
export async function getServerSideProps() {
  // Fetch data on the server
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

  return {
    props: { products }, // Pass data to the page
  };
}

export default function Home({ products }) {
  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
    </div>
  );
}

In the code above, getServerSideProps runs entirely on the server. When a user visits or refreshes the page, getServerSideProps() is called to fetch product data from the external API. The fetched data is then pre-rendered on the server, meaning the list of products is included in the HTML before it is sent to the browser to display. This removes the additional round trip seen in CSR and improves the FCP, since users see meaningful content as soon as the page loads.

React Server Components (RSC)

Server-Side Rendering is a technique where the whole page gets generated on the server. But imagine if only some portions of a page are to be rendered on the server while others are to be rendered on the client?

React Server Components allow partition of rendering between the server and the client.

For example, a ProductList component can be rendered on the server, while a SearchInput component renders on the client to manage user interactions.

Advantages:
RSC reduces the overall round trip time (RTT) and also increases the page first contentful paint.

// app/ProductList.jsx (Server Component)
async function ProductList() {
  // Fetch data on the server
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
      <ClientSearch /> {/* Client Component */}
    </div>
  );
}

export default ProductList;

In the code above, ProductList is a server component with a ClientSeacrch component as a child component. The ClientSearch renders in the browser while the rest of the ProductList renders on the server. When the page loads, the server runs fetch() to retrieve product data and renders the complete HTML for the product list on the server while ClientSearch renders on the client side to handle user interactions.

// components/ClientSearch.jsx (Client Component)
'use client';

import { useState } from 'react';

export default function ClientSearch() {
  const [query, setQuery] = useState('');

  return (
    <input
      type="text"
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search products..."
    />
  );
}

The ClientSearch component above handles user interactions, such as updating the search input with useState. It’s marked with 'use client', so it runs entirely in the client side.

Image Optimization

Images negatively impact round-trip time RTT when they are unoptimized, as larger files take a longer time to transfer from the server to the browser.

Next.js Image component optimizes images automatically:

Resizing: It adjusts image size based on the user’s device.

Compression: It uses new formats like WebP to shrink the file size significantly.

Lazy Loading: Loads images only when they enter the user’s viewport, which reduces the number of initial requests.

// pages/index.js
import Image from 'next/image';

export default function Home() {
  return (
    <div>
      <h1>Welcome to Our Store</h1>
      <Image
        src="/product.jpg"
        alt="Product Image"
        width={500}
        height={300}
      />
    </div>
  );
}

In the code above, the page uses Next.js built-in Image component to render an optimized image. When the page loads, Next.js optimizes the image resizing, lazy loading, and so on. This means the browser will only download the right image size for the device.

Caching and Static Rendering

With SSR and Server Component, round trip time can still remain high if the server has to process data on every request. Next.js solves this problem with Static Site Generation (SSG) and Incremental Static Regeneration (ISR).

Here’s how it works:

Static Site Generation: Pages are pre-rendered during build time, cached and delivered as static HTML from a CDN.

Incremental Static Regeneration: Pages are pre-rendered but can be re-generated in the background after an interval, for example, every 60 seconds.

// app/page.jsx
export const revalidate = 60; // Regenerate the page every 60 seconds

export default async function Home() {
  // Fetch data on the server
  const res = await fetch("https://api.example.com/products", {
    next: { revalidate: 60 }, 
  });
  const products = await res.json();

  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
    </div>
  );
}

In the code above, the page uses Incremental Static Regeneration (ISR). The revalidate = 60 option is to regenerate the page every 60 seconds. When a user visits the page, the server serves the pre-rendered HTML instantly. The next: { revalidate: 60 } inside the fetch() means that data is cached for 60 seconds. After 60 seconds, the next request will trigger the server to regenerate a fresh data.

Trade-offs Across Next.js Rendering Methods

With Server-Side Rendering (SSR), the browser gets the complete rendered page in only one round round trip. On the other hand, this can also lead to increased server load and a high TTFB. The TTFB (Time to First Byte) is the duration it takes for a user to see the content displayed on their browser.

With Incremental Static Regeneration (ISR), the page is pre-rendered and cached, thus getting an instantaneous response from the server. The page will be re-generated depending on a fixed period (such as every 60 seconds). The downside of this method is that users might see old content before it gets updated.

In Server Components, rendering takes place on the server, and only interactive parts are managed on the client. With this, server-side rendering are still maintained while still allowing client interactions. The only drawback is that developers need to be very particular while deciding what to run on the server and what to run on the client.

When to Use Each Rendering Method

Server-Side Rendering (SSR) should be applied to pages that updates frequently, such as dashboards, user profiles, and so on. SSR guarantee users to always see the latest data.

As for Incremental Static Regeneration (ISR), it should be applied to pages with infrequent changes, for instance, product listings, marketing pages, or blogs.

Use Server Components when you want part of the page to render on the server while some sections run on the client. For instance, pages that need user interaction like search inputs or filters, while data fetching and rendering takes place on the server.

Conclusion

Round Trip Time (RTT) is one of the hidden factors behind slow page loads. Each network request adds a round trip, and these network delays build up as the browser fetches several resources like scripts, images, and data files. Next.js deals with this issue by minimizing the number of network requests that need to be done before the first content paint.

• Server-Side Rendering (SSR) and React Server Components (RSC) shift data fetching and rendering to the server, which reduces client-side requests.

• Image optimization reduces image size and uses CDNs to deliver content faster from nearby servers.

• Caching and static rendering serve pre-generated pages instantly without further processing from the server.

With these techniques, you can build web applications that load faster and feel more responsive, even for users who are far from your origin server or are on slower networks.

At its core, every business thrives on delivering value to its users. When users are unable to access this value due to poor performance, it ultimately impacts the business's success. Slow load times, among other factors, frustrate users and drive them away before they even get a chance to engage.

Optimizing performance is more than just a technical detail – it’s also a critical part of creating a successful application. Without it, even the best features can go unnoticed if users don’t stick around long enough to see them.

In this article, we’ll explore key approaches to optimize your Next.js application, making it faster and more efficient.

Table of Contents

• Building a Performant Application

• How to Optimize Your Applications

• Key Techniques To Optimize Performance

  • Using The Next.js Image Component

  • Optimizing Third-Party Scripts with the Next.js Script Component

  • Remove Unused Packages/Dependencies

  • Caching and Incremental Static Regeneration (ISR)

  • Caching Frequently Used Content

  • Font Optimization With next/font

  • Lazy Loading And Code Splitting

  • Lazy Loading in Next.js

  • Code Splitting

• Conclusion

Building a Performant Application

Making your apps more performant means striking the right balance between speed, responsiveness, and efficient use of resources. You should strive to create an application that delivers value and keeps users satisfied.

Building a performant app is about making sure the app feels smooth and intuitive so that there are no frustrating lags when a user clicks buttons, scrolls, or navigates around. You’ll also want to make sure that data loads or updates without unnecessary delays.

How to Optimize Your Applications

The first step in optimizing your application is identifying problem areas. A number of tools and packages can help you analyze your application's performance effectively. Here's how you can use them:

Using npm run build

When you run npm run build, Next.js creates a production-ready version of your application and gives a detailed breakdown of your pages. This includes:

• Size: The size of the JavaScript files for each route. Highlighting any routes that are too large and could slow things down. Smaller page sizes generally result in faster load times while large pages might take longer to download, especially for users with slower network connections.

• First Load Js: This column provides information about the total amount of JavaScript the browser needs to download and execute to fully render the page for the first time. Large First Load JS values

  cause Slower Time-to-Interactive (TTI).

Running this command produces an analysis like below:

Using @next/bundle-analyzer

The bundle analyzer is a package provided by Next.js to analyze the size of JavaScript bundles by providing a visual representation of the application’s module and dependencies. Here’s how to use the package:

First, install the package by running this command:

npm install @next/bundle-analyzer

Or you can use yarn:

yarn add @next/bundle-analyzer

Then add the @next/bundle-analyzer configuration to your next.config.js file:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

module.exports = withBundleAnalyzer({
  // other Next.js config options here
});

To analyze your application bundles while generating a production build, run the following command:

ANALYZE=true npm run build

For a step-by-step guide on how to use the bundle analyzer effectively, check out this detailed video tutorial

Browser tools

Finally, modern browsers, including Google Chrome, Firefox, and Edge, offer powerful tools to analyze and improve your application's performance. Features like the Performance Tab help you record and visualize how your application runs, pinpointing issues like slow rendering or long tasks.

You can also use tools like Lighthouse (available in Chrome and Edge) to generate automated audits, highlighting problems such as large assets and unoptimized resources.

To access the Lighthouse and Performance tabs:

1. Open your browser's developer tools by right-clicking anywhere on the browser and selecting the Inspect option or pressing Command + Option + I (on Mac) or Ctrl + Shift + I (on Windows).

2. Look at the top menu in the developer tools.

3. If you don’t see the Lighthouse or Performance tabs right away, click the double right arrow (>>) to reveal hidden tabs.

4. Select the desired tab to start analyzing performance or generating a Lighthouse report.

Here is an example of a generated audit in the Performance tab on Chrome

Here’s another image showing the generated audit by lighthouse

Key Techniques to Optimize Performance

1.) Using The Next.js Image Component

Images often account for the largest portion of page weight, directly affecting load times and user experience. Large images slow down rendering and ultimately, increase bandwidth usage.

Next.js has a built-in Image component that automatically optimizes images, making it very useful for web performance. It takes care of resizing, lazy loading, and format optimization, so images are served in the most performant format (like .WebP) when the browser supports it.

import Image from 'next/image';

    <Image
      src="/house.jpg"
      alt="House Image"
      width={700}
      height={500}
      priority={false} // Lazy loads the image by default
    />

In the snippet above,

• src="/house.jpg": This points to the image file's location, which is in the public folder. Images in the /public directory are served statically, so you don’t need extra configuration.

• alt="House Image": The alt text (just like in the native HTML image element) provides a description of the image, which is great for accessibility (like screen readers) and also helps with SEO.

• width & height: By explicitly setting the width and height, Next.js can calculate the space the image will occupy on the page before it loads. This prevents the page layout from shifting as the image loads, which improves user experience and boosts performance metrics like Cumulative Layout Shift (as shown in the image above).

• priority={false}: This ensures the image will only load when it's near the user's viewport conserving the bandwidth and improving page load times for non-critical images. However, for important images that should load immediately (like those visible as soon as the page opens), you can set priority={true} to bypass lazy loading and ensure the image loads as quickly as possible.

One of the key advantages of the Next.js Image component is its built-in lazy loading feature. This means that images won’t be loaded until they are actually needed (when they enter the viewport). By only loading images that are about to be viewed, performance is improved and pages can load faster, even with many high-quality images.

2.) Optimizing Third-Party Scripts with the Next.js Script Component

Third-party scripts, such as analytics tools or advertising networks, can heavily affect your application's performance if not properly managed. Next.js has a Script component that makes it easy to load scripts efficiently, giving you control over how and when they load.

The Script component allows you to define a loading strategy for scripts, determining when and how they are fetched and executed. By prioritizing or deferring scripts based on their importance, you can improve the overall performance and user experience of your application.

• beforeInteractive: Use this strategy for scripts that must load before the page becomes interactive, like essential analytics or monitoring tools.

• afterInteractive: When you use this strategy, the script loads after the page becomes interactive, which is the default behavior. This is ideal for scripts that add functionality but aren’t essential for initial rendering.

• lazyOnload: Defers loading the script until all other page resources have finished loading. This is perfect for non-essential scripts like ads or social media widgets.

<Script src="https://example.com/non-essential.js" strategy="lazyOnload" /> //Pass the strategy as a prop to the component

By leveraging the Next.js Script component, you can prevent scripts from blocking critical rendering, reducing load times and improve Time to Interactive (TTI).

3.) Remove Unused Packages/Dependencies

Over time, as you build and maintain your project, unused dependencies can pile up in your codebase. These unnecessary packages increase the size of your project, slow down installation times, and make the code harder to maintain. Cleaning up these unused dependencies is essential for optimizing your application's performance and keeping your codebase clean.

The depcheck tool is a great way to identify and remove unused dependencies from your project. It analyzes your package.json and the project files to find unused dependencies, unused devDependencies, and missing dependencies.

You can run a depcheck like this:

npx depcheck

After identifying the unused dependencies, you can remove them by running:

npm uninstall <package-name>

or with yarn:

yarn remove <package-name>

Regularly running depcheck is a simple yet effective way to keep your project clean and efficient.

4.) Caching and Incremental Static Regeneration (ISR)

When you find yourself running the same calculations or database queries repeatedly, you should consider caching. It’s a simple yet powerful way to boost your web application's performance, especially for content that doesn’t change often. By storing frequently accessed data in a cache, you can avoid unnecessary processing and speed up load times.

In Next.js, you can take this a step further with Incremental Static Regeneration (ISR), which lets you serve static content instantly while keeping it fresh behind the scenes.

Incremental Static Regeneration (ISR) in Next.js lets you update static pages without rebuilding the whole site. Here's how it works:

1. Build time generation: ISR generates pages when the site is built.

2. Caching: It stores the pages so they load quickly when users visit.

3. Background updates: When content changes, ISR updates the pages behind the scenes without affecting users.

4. Dynamic updates: It combines the fast loading of static pages with the ability to update content regularly.

export async function getStaticProps() {

  const data = await fetchData();

  return {
    props: { data },
    //regenerate the page every 20 seconds.
    revalidate: 20,
  };
}

//pre-render the page as static content
function MyPage({ data }) {
  return (
    <div>
      <h1>My Page</h1>
      <p>{data}</p>
    </div>
  );
}

export default MyPage;

Caching Frequently Used Content

For websites with pages that get a lot of visitors, like product listings or blog posts, it's important to keep the content fast and up-to-date.

Caching helps achieve this by saving a copy of the page so it doesn't need to be created from scratch each time someone visits. The browser or server will store this cached page for a set amount of time, which is controlled by caching headers. Meanwhile, ISR (Incremental Static Regeneration) ensures that the page can be updated in the background when necessary, without needing to rebuild the entire site.

In applications with lots of data, caching can also speed up the process by storing API responses. This way, when users request the same data again, they can get it quickly from the cache instead of waiting for it to be fetched anew. Tools like Vercel and Content Delivery Networks (CDNs) help by storing these cached pages in multiple locations around the world, so visitors can access them faster.

export async function getStaticProps() {
  const data = await fetchData();

  return {
    props: { data },
    // Regenerate page at most once every 30 seconds
    revalidate: 30,
    // Cache for 1 hour at the CDN level
    headers: {
      'Cache-Control': 'public, max-age=3600, must-revalidate',
    },
  };
}

Here, the page regenerates every 30 seconds and is cached at the CDN level for one hour. The Cache-Control header tells the CDN and browser to cache the page for 1 hour and revalidate it afterward.

For a deeper dive into caching and its role in web performance, check out this insightful freeCodeCamp article on Caching vs. Content Delivery Networks.

5.) Font Optimization With next/font

The next/font module in Next.js automatically handles font loading for improved performance, so you don’t need to manually configure or use extra libraries. It loads only the essential parts of the font, which results in faster page load times.

To further reduce the font file size, you can provide the subsets array which ensures fewer bytes are transferred and pages load quickly.

Here’s how it works:

• Automatic font loading: The module optimizes font loading automatically, making sure fonts are served in the most efficient way, improving performance without extra effort.

• Subsetting fonts: You can specify the exact font characters needed for your app.

• Font display strategy: The font-display strategy determines how text is shown to the user while fonts are loading. Next.js typically uses the swap strategy by default, but you can manually configure it if necessary. The most common strategies are swap fallback optional and block.

•   import { Inter } from 'next/font/google'
  
    const inter = Inter({
      subsets: ['latin', 'latin-ext'], // Load only the Latin and extended Latin subsets
      weight: '400', // Choose the specific weight you need
      style: 'normal', // Specify the style if needed
    })
  
    export default function Page() {
      return <div className={inter.className}>Hello World</div>
    }
  

The snippet above uses the Next.js built-in tool for Google Fonts. Instead of adding the font link in your HTML or using a third-party library, you can import it directly like this for ease and efficiency.s

• subsets: Tells the app to load only the characters needed. Skipping other character sets like Cyrillic (used in Russian) or Greek, avoids downloading extra, unnecessary data, which keeps your app lightweight and faster to load.

• weight: Instead of loading all font weights (e.g., Bold, Light), you only bring in Regular (400). This reduces the overall size.

• style: Stick with the standard style (no fancy italics). This also trims down what’s downloaded.

6.) Lazy Loading and Code Splitting

When building web apps, you want to make sure your users don’t wait too long for your pages to load. A big part of this involves reducing how much JavaScript is loaded when the page first opens. Two techniques that help with this are lazy loading and code splitting, both of which Next.js makes easy to use.

Lazy Loading in Next.js

Think of lazy loading like waiting to download a movie only when you decide to watch it. Imagine you have a large component like a chart or a map that users only see after interacting with a page. Instead of loading it upfront, you can tell Next.js to load it only when it’s needed using next/dynamic.

Code Splitting in Next.js

Code splitting breaks your JavaScript into smaller pieces (called bundles), so users only load what’s necessary. For example, if a user visits your homepage, there’s no need to load JavaScript for other pages like "About Us" or "Dashboard". It typically happens during the build process or dynamically at runtime.

import dynamic from 'next/dynamic'

// Load HeavyComponent only when it’s rendered
const HeavyComponent = dynamic(() => import('./HeavyComponent'), { ssr: false })

export default function Home() {
  return (
    <div>
      <h1>Welcome Home!</h1>
      <HeavyComponent /> {/* This loads only when rendered */}
    </div>
  )
}

In the above code, dynamic dynamically imports the component only when needed. ssr: false disables server-side rendering for the component, which can save resources if the component doesn’t need to be pre-rendered.

Next.js automatically splits code by page, meaning each page only loads the necessary JavaScript when accessed, improving load times. For more granular control, next/dynamic allows you to dynamically import specific components, ensuring they are loaded lazily only when needed. While Next.js handles page-level code splitting by default, using next/dynamic gives you the flexibility to apply component-level splitting, optimizing resource loading and enhancing performance.

Conclusion

Creating a high-performance application is a very important aspect of any business. A faster and more efficient application enhances user engagement, lowers bounce rates, and boosts SEO rankings, which all contribute to business growth and customer satisfaction.

By utilizing these techniques we discussed in this guide, you can provide a smooth user experience while maintaining optimal efficiency behind the scenes.

Remember, every second saved in load time translates to happier users and, ultimately, better business outcomes.

Thank you for reading!

Want to connect with me?

• Twitter / X: @timi471

• Linkedin: Ayantunji Timilehin

• Email: ayantunjitimilehin@gmail.com

References

• Next.Js Documentation

• Caching-vs-content-delivery-network

• Using next/bundle-analyzer

• Cumulative layout shift

This typically happens because the website is trying to fetch all the necessary data as soon as you land on the page. It could be that a API request is being processed, or multiple APIs are fetching data sequentially, causing delays in loading the page.

The result? A poor user experience. You might think, "How can such a large company not prioritize user experience? This is disappointing." Consequently, users often leave the site, affecting key metrics and potentially impacting revenue.

But what if you could fetch the data for these heavy pages ahead of time, so that by the time a user lands on the page, they can interact with it instantly?

This is where the concept of prefetching comes in, and that's exactly what we'll be diving into in this blog post. So without further ado, let's get started!

Table of Contents

• Prefetching as a Solution

• How Prefetching Improves User Experience

• Understanding The Problem

• Solution #1: Prefetching Data in the Parent Component

• Solution #2: Prefetch Data on Page load

• How to Implement Prefetching with React

• Too much prefetching can also cause slowness

• Summary

Prefetching as a Solution

Here’s the revised version with just the grammar and spelling corrected:

For the problem above, what we want is to fetch the data for a given page before it's loaded onto the website so that the user doesn’t need to fetch the data on page load. This is called prefetching. From a technical perspective, its definition is as follows:

It is a way to fetch the required data beforehand so that the main component doesn’t need to wait for the data, thus enhancing the experience.

This can improve the user experience, boosting the customer’s confidence in your website.

Prefetching is a simple yet elegant solution that is more user-centric than a standard process. To implement prefetching, we need to understand the user’s behavior on the website. That is, the most visited pages, or which components fetch data on small interactions (such as hover).

After analyzing such scenarios, it makes sense to apply prefetching to them. However, as developers, we should be mindful of using this concept. Too much prefetching can also slow down your website since you're trying to fetch a lot of data for future scenarios, which might block the fetching of data for the main page.

How Prefetching Improves User Experience

Let us look at couple of scenarios where prefetching is beneficial:

1. Loading data/page earlier for the most visited link from your landing page. For example, consider that you have a “contact us” link. Let’s assume that this is the link that users mostly check and it contains a lot of data when it loads. Rather than loading the data when the contact us page loads, you can simply fetch the data on the homepage so that you don’t have to wait at the Contact Us page for the data. You can read more about prefetching pages here.

2. Prefetching table data for later pages.

3. Fetching data from a parent component and loading it in the child component.

4. Prefetching data that needs to be displayed in a popover.

These are some of the ways to achieve prefetching in your application and how it helps improve the user experience.

In this blog post we will be discussing about the last scenario: “prefetching data that needs to be displayed in the popover”. This is a classic example where prefetching can be beneficial and provides a smoother experience to the user.

Understanding The Problem

Let me define the problem here. Imagine the following scenario:

1. You have a component that displays specific information.

2. There is an element inside this component that shows another popover/tooltip when you hover on it.

3. The popover fetches data when it loads.

Now imagine that the user hovers on the element and needs to wait for the data to be fetched and displayed in the popover. During this wait, they see the skeleton loader.

The scenario will look like this:

It’s just frustrating how long the user has to wait whenever they hover on the image:

To solve this problem, there are two solutions that can help you get started and optimize the solution according to your needs.

Solution #1: Prefetching Data in the Parent Component

This solution is inspired from Martin Fowler’s blogpost. It allows you to fetch the data before the popup appears, instead of fetching on component load.

The popup appears when you hover on it. We can fetch the data when the mouse enters the parent component. Before the actual component—the image—is hovered on, we’ll have the data for the popover and will pass it to the popover component.

This solution doesn’t remove the loading state all together but it helps to significantly lower the chances of seeing the loading state.

Solution #2: Prefetch Data on Page load

This solution is inspired by x.com where, for the popover component, they fetch the data partially on the main page load and fetch the rest of the data when the component mounts.

As you can see from the above video, the user’s profile details are viewed in the popover. If you look closely, the details related to followers are fetched later.

This technique is highly efficient when you have a lot of data to be displayed in the popover but fetching them can be costly on popover mount or on the main page load.

A better solution would be to partially load the required data on the main page and load the rest of the data when the component mounts.

In our example, we fetched the data for the popover when the cursor entered the image’s parent element. Now imagine that you need to fetch additional details once the popover data is loaded. So based on the above x.com’s method, we can fetch additional data on popover load. Here is the outcome of it:

Here, we do the following things:

• We fetch the main data which is just necessary to render the popover when mouse enters the parent component of the image.

• This gives us enough time to fetch the main data.

• On popover load, we fetch another data, which is the album count. While the user reads data like name and email, we’ll have the next data ready to be seen.

This way, we can make small and smart tweaks to minimize the blank staring of loaders on the screen 😊.

How to Implement Prefetching with React

In this section we’ll briefly go through the how to implement the above prefetching example app.

Project Setup

To get started with creating the prefetching app, follow the process below:

You can use vitejs (this is what I used) or create-react-app to create your app. Paste the command below in your terminal:

yarn create vite prefetch-example --template react-ts

Once the app has been created, you should have the following folder structure when you open the prefetch-example folder with VS Code.

Now let us dive into the components that we are going to be building for this app.

Components

In this example we are going to be using 3 components:

• PopoverExample

• UserProfile

• UserProfileWithFetching

PopoverExample Component

Let us start with the first component which is the PopoverExample. This component displays an image avatar and some text to the right side of it. It should look like this:

The purpose of this component is to serve as an example similar to the real life scenarios. The image in this component loads a popover component when it is hovered on.

Here’s the code for the component:

import { useState } from "react";
import { useFloating, useHover, useInteractions } from "@floating-ui/react";
import ContentLoader from "react-content-loader";
import UserProfile from "./UserProfile";
import UserProfileWithFetching from "./UserProfileWithFetching";

export const MyLoader = () => (
    <ContentLoader
        speed={2}
        width={340}
        height={84}
        viewBox="0 0 340 84"
        backgroundColor="#d1d1d1"
        foregroundColor="#fafafa"
    >
        <rect x="0" y="0" rx="3" ry="3" width="67" height="11" />
        <rect x="76" y="0" rx="3" ry="3" width="140" height="11" />
        <rect x="127" y="48" rx="3" ry="3" width="53" height="11" />
        <rect x="187" y="48" rx="3" ry="3" width="72" height="11" />
        <rect x="18" y="48" rx="3" ry="3" width="100" height="11" />
        <rect x="0" y="71" rx="3" ry="3" width="37" height="11" />
        <rect x="18" y="23" rx="3" ry="3" width="140" height="11" />
        <rect x="166" y="23" rx="3" ry="3" width="173" height="11" />
    </ContentLoader>
);
export default function PopoverExample() {
    const [isOpen, setIsOpen] = useState(false);
    const [isLoading, setIsLoading] = useState(false);
    const [data, setData] = useState({});

    const { refs, floatingStyles, context } = useFloating({
        open: isOpen,
        onOpenChange: setIsOpen,
        placement: "top",
    });

    const hover = useHover(context);

    const { getReferenceProps, getFloatingProps } = useInteractions([hover]);

    const handleMouseEnter = () => {
        if (Object.keys(data).length === 0) {
            setIsLoading(true);
            fetch("https://jsonplaceholder.typicode.com/users/1")
                .then((resp) => resp.json())
                .then((data) => {
                    setData(data);
                    setIsLoading(false);
                });
        }
    };

    return (
        <div
            id="hover-example"
            style={{
                display: "flex",
                flexDirection: "row",
                alignItems: "center",
                textAlign: "left",
            }}
            onMouseEnter={handleMouseEnter}
        >
            <span
                style={{
                    padding: "1rem",
                }}
            >
                <img
                    ref={refs.setReference}
                    {...getReferenceProps()}
                    style={{
                        borderRadius: "50%",
                    }}
                    src="https://cdn.jsdelivr.net/gh/alohe/avatars/png/vibrent_5.png"
                />
            </span>
            <p>
                Lorem Ipsum is simply dummy text of the printing and typesetting
                industry. Lorem Ipsum has been the industry's standard dummy text ever
                since the 1500s, when an unknown printer took a galley of type and
                scrambled it to make a type specimen book. It has survived not only five
                centuries, but also the leap into electronic typesetting, remaining
                essentially unchanged. It was popularised in the 1960s with the release
                of Letraset sheets containing Lorem Ipsum passages, and more recently
                with desktop publishing software like Aldus PageMaker including versions
                of Lorem Ipsum.
            </p>
            {isOpen && (
                <div
                    className="floating"
                    ref={refs.setFloating}
                    style={{
                        ...floatingStyles,
                        backgroundColor: "white",
                        color: "black",
                        padding: "1rem",
                        fontSize: "1rem",
                    }}
                    {...getFloatingProps()}
                >
                    {isLoading ? (
                        <MyLoader />
                    ) : (
                        <UserProfile hasAdditionalDetails {...data} />
                    )}
                    {/* <UserProfileWithFetching /> */}
                </div>
            )}
        </div>
    );
}

There are couple of things happening here, let me explain them step-by-step:

• We have a parent div named hover-example that contains an image and some text.

• Next, we conditionally rendered a div with class name of floating. This is the actual popover component that opens when you hover on the image.

  • We made use of the floating-ui library and its basic hover example to achieve the hover effect for the popover.

• Inside the popover we conditionally loaded the UserProfile and the skeleton loader. This loader appears when we are fetching the data for the user’s profile. More on this later.

• We made use of the react-content-loader library in the MyLoader component. This library also has a website that helps you to create loaders, you can check it out here.

UserProfile Component

Now that we have defined our Popover example, it is time for us to get into the details of the UserProfile component.

This component appears inside the popover component. The purpose of this component is to load the name email phone website details which are fetched from JSON placeholder API.

To demonstrate the prefetching example, we have to make sure that the UserProfile component only acts as a presentational component; that is, no explicit fetching logic is present inside of it.

The key thing to note about this component is that fetching the data happens from the parent component which is the PopoverExample component. In this component, we start fetching the data when the mouse enters this component (the mouseenter event). This is the solution #1 we discussed previously.

This gives you enough time for fetching the data until the user hovers on the image. Here’s the code:

import { useEffect, useState } from "react";
import ContentLoader from "react-content-loader";

const MyLoader = () => (
    <ContentLoader
        speed={2}
        viewBox="0 0 476 124"
        backgroundColor="#d1d1d1"
        foregroundColor="#fafafa"
    >
        <rect x="4" y="43" rx="0" ry="0" width="98" height="30" />
    </ContentLoader>
);

export default function UserProfile(props: Record<string, string | boolean>) {
    const { name, email, phone, website, hasAdditionalDetails } = props;
    const [isLoading, setIsLoading] = useState(false);
    const [additionalData, setAdditionalData] = useState(0);

    useEffect(() => {
        if (hasAdditionalDetails) {
            setIsLoading(true);
            fetch("https://jsonplaceholder.typicode.com/albums")
                .then((resp) => resp.json())
                .then((data: Array<unknown>) => {
                    const albumCount = data.reduce((acc, curr) => {
                        if (curr.userId === 1) acc += 1;

                        return acc;
                    }, 0);
                    setAdditionalData(albumCount);
                })
                .finally(() => {
                    setIsLoading(false);
                });
        }
    }, [hasAdditionalDetails]);

    return (
        <div id="user-profile">
            <div id="user-name">name: {name}</div>
            <div id="user-email">email: {email}</div>
            <div id="user-phone">phone: {phone}</div>
            <div id="user-website">website: {website}</div>
            {hasAdditionalDetails && (
                <>
                    {isLoading ? (
                        <MyLoader />
                    ) : (
                        <div id="user-albums">Album Count: {additionalData}</div>
                    )}
                </>
            )}
        </div>
    );
}

This component makes use of the hasAdditionalDetails prop. The purpose of this prop is to load additional data when the component mounts. It illustrates the solution #2 mentioned above.

UserProfileWithFetching Component

This component is pretty similar to that of the UserProfile component. It just contains the logic for fetching data when the component loads. The purpose of this component is to show what the general solution without the prefetching technique would look like.

So this component will always load the data when the component mounts, which displays the skeleton loader.

Here is the code:

import { useEffect, useState } from "react";
import { MyLoader } from "./PopoverExample";

export default function UserProfileWithFetching() {
    const [isLoading, setIsLoading] = useState(false);
    const [data, setData] = useState<Record<string, string>>({});

    useEffect(() => {
        setIsLoading(true);
        fetch("https://jsonplaceholder.typicode.com/users/1")
            .then((resp) => resp.json())
            .then((data) => {
                setData(data);
                setIsLoading(false);
            });
    }, []);

    if (isLoading) return <MyLoader />;

    return (
        <div id="user-profile">
            <div id="user-name">name: {data.name}</div>
            <div id="user-email">email: {data.email}</div>
            <div id="user-phone">phone: {data.phone}</div>
            <div id="user-website">website: {data.website}</div>
        </div>
    );
}

The entire code for this app can be found here.

Too much prefetching can also cause slowness

A word of advice, too much prefetching is not good because:

• It might slow your app down.

• It can degrade user experience if prefetching is not applied strategically.

Prefetching needs to be applied when you know the behavior of the user. That is, you are able to predict the user movement by metrics and be able to tell if they visit a page often. In that case, prefetching is a good idea.

So remember to always apply prefetching strategically.

Summary

That’s all folks! Hope you like my blog post. In this blogpost, you learned that implementing prefetching can significantly enhance your web application’s speed and responsiveness, improving user satisfaction.

For further reading, please refer to the below articles:

• Prefetching pages

• Preload, Prefetch And Priorities in Chrome

• What not to prefetch

For more content, you can follow me on Twitter, GitHub, and LinkedIn.

Developers rely on tools like compilers and bundlers to transform their code, optimize performance, and ensure compatibility across different environments.

These tools are essential for modern JavaScript applications, enabling developers to write clean, maintainable code while leveraging the latest language features.

This article will help you understand what Speedy Web Compiler (SWC) is and how it helps optimize the performance of your web apps.

Table of Contents

• Introduction to Speedy Web Compiler

• Background of SWC

• How Speedy Web Compiler Works

• Benefits of Using Speedy Web Compiler

• How to Set Up Speedy Web Compiler in Your Project

• SWC Integration in Popular Frameworks

• Conclusion

What is Speedy Web Compiler?

First, let me break it down.

SWC stands for Speedy Web Compiler, and when broken down:

Speedy - This means it's fast! SWC processes and transforms JavaScript code, making it efficient to use in big projects.

Web - It’s all about web development. It focuses on improving how JavaScript (the language of the web) handles it.

Compiler - It takes code written in one form and transforms it into another form that can be better understood or used by computers.

Background of SWC

kdy1, a South Korean developer and maintainer of Next.js, created SWC as a faster tool for handling JavaScript code.

The motivation was the need for speed and efficiency, as web projects grow larger and more complex.

With numerous websites and apps depending on JavaScript, SWC helps developers save time and work more efficiently.

How Speedy Web Compiler Works

SWC uses Rust, a programming language known for its speed and safety.

SWC works by taking your JavaScript or TypeScript code and transforming it into a version that can run efficiently in various environments.

Understanding how SWC achieves this involves examining its core steps: parsing, transforming, and generating code.

How Does SWC Parse Code?

The first step in the compilation process is parsing.

Begins by reading and analyzing the code to understand its structure.

This is akin to taking a complex sentence and breaking it down into its grammatical components—subject, verb, object, etc.

In technical terms, SWC converts your code into an Abstract Syntax Tree (AST).

The AST is a tree-like representation of the source code, where each node in the tree corresponds to a construct occurring in the code, such as expressions, statements, and functions.

This tree structure allows SWC to process and understand the code’s logic in a way that is both efficient and scalable.

How Does SWC Transform Code?

After creating the AST, SWC moves on to the transformation phase.

This is where the magic happens—SWC applies various optimizations and changes to the code based on the target environment.

For instance, if you're targeting older browsers that don't support modern JavaScript features, SWC will transform your ES6+ code into a backward-compatible version.

During this phase, SWC also handles TypeScript transformations. It strips away TypeScript-specific syntax, such as types and interfaces, converting the code into pure JavaScript that gets executed by any JavaScript engine.

SWC can apply custom transformations based on plugins or specific configurations, making it highly versatile.

How Does SWC Generate Optimized Code?

After the transformations are complete, SWC proceeds to the final step: code generation.

In this step, SWC takes the transformed AST and converts it back into executable code.

In contrast, this process is not just a reversal of the parsing process.

SWC takes special care to generate code that is both functionally correct and optimized for performance.

For instance, SWC might remove dead code (code that will never be executed) or inline certain functions to reduce overhead.

The goal is to produce code that is as clean and efficient as possible, ensuring that it runs quickly and reliably in production environments.

Benefits of Using Speedy Web Compiler

Performance

One of the major benefits of using SWC is its outstanding speed. SWC achieves this exceptional speed by using Rust.

Developers can expect a significant performance improvement when compiling their code for large projects or codebases.

This speed greatly reduces build times, enhancing the efficiency and responsiveness of the development process. It is so fast, you might think it’s late for a meeting!

Optimized Output

SWC compiles your code and guarantees that the output is highly optimized for performance in production environment by removing dead code, in-lining functions, and reducing the size of the output.

This makes using SWC cost-effective, saving you from extra expenses during production.

The result is a leaner, faster, and more efficient code that can enhance loading times and performance in web applications.

Compatibility

SWC is fully compatible with modern JavaScript libraries and frameworks.

You do not have to worry about using ES6+ or TypeScript. This makes SWC a versatile choice for your projects.

How to Set Up Speedy Web Compiler

Installation

To install SWC in your JavaScript or TypeScript project, follow these steps:

1. Initialize your project: If you haven't already, start by initializing a new project. In your terminal, run:

npm init -y

2. Install SWC with npm: Run the following command to download the pre-built binaries:

npm install -D @swc/cli @swc/core

3. Create a JavaScript file: Create a src/index.js file with some code:

const greet = (name) => {
  return `Hello, ${name}!`;
};

console.log(greet("World"));

4. Compile with SWC: Run SWC from the command line to compile your JavaScript file:

npx swc src/index.js -o dist/index.js

5. Resulting Code: The resulting JavaScript code in dist/index.js will look like this:

"use strict";
var greet = function(name) {
    return "Hello, " + name + "!";
};
console.log(greet("World"));

This is the transpiled ES5 code produced by SWC, suitable for environments that require backward compatibility with older JavaScript versions.

SWC Integration in Popular Frameworks

If you are using Next.js, Deno, Vite, Remix, Parcel, or Turbopack, SWC is already integrated.

Notable improvements were made on Next.js, a popular React framework, since version 12 (Source: Next.js 12: The SDK for the Web)

Conclusion

In the constantly changing realm of JavaScript development, having the correct tools can make a significant difference.

SWC, the Speedy Web Compiler, distinguishes itself as a strong solution for converting and optimizing JavaScript and TypeScript code.

Its impressive speed, owing to its Rust-based implementation, along with its efficient management of code transformations and optimizations, positions it as a powerful tool for modern web development.

If you would like to stay in touch:

Connect with me on LinkedIn

Follow me on X

An application that takes more than 3 seconds to load is considered slow and may cause users to leave the application or website.

Next.js is a React-based framework you can use to build scalable, performant, and faster web applications and websites. With the inclusion of React Server Components in the Next.js app router release, developers have a new mental model for "thinking in a server components" way. It solves the problem with SEO, helps create zero bundle size React components, and the end result is faster loading of UI components.

But your application may not be always about the server components. You may need to use client components as well. Also, you may want to load them either as part of the application's initial load or on demand (say at the click of a button).

Loading a client component on the browser includes downloading the component code into the browser, downloading all the libraries and other components you had imported into that client component, and a few additional things that React takes care of for you to make sure your components are working.

Based on the user's internet connection and other network factors, the entire loading of the client component may take a while, which may keep your users from using the application more quickly.

This is where Lazy Loading techniques can come in handy. They can help save you from a monolithic loading of your client components on the browser.

In this article, we will discuss a couple of lazy loading techniques in Next.js for client component loading optimization. We will also talk about a few edge cases you should know to handle.

If you like to learn from video content as well, this article is also available as a video tutorial here: 🙂

Before we get started, a couple of things for you:

• We will write a bunch of code to build an app to demonstrate the lazy loading techniques. You can find all the source code from this GitHub repository: https://github.com/tapascript/nextjs-lazy-load. But I strongly suggest that you write the code yourself as we proceed and use the repository only as a reference.
• You can also access the app deployed publicly on Netlify here.

Let's start 🚀. Oh yes, if you are Tom & Jerry cartoon lover, you are going to enjoy this even more!

Table of Contents

• What is Lazy Loading?
• Lazy Loading Techniques in Next.js
• Lazy Loading with dynamic import and next/dynamic
• Lazy Loading with React.lazy() and Suspense
• How to Lazy Load the Named Exported Components
• Lazy Loading Your Server Components
• Should We Lazy Load All Client Components in Next.js?
• What's Next?

What is Lazy Loading?

In modern day web application development, we don't code all the logic in one JavaScript/TypeScript file, or all the styles into one mammoth CSS file. Rather, we split them at the source code level and create logical modules, business logic, presentational components, and style related files. This helps us organize our code better.

Then we use something called a bundler which kicks in at the build phase of the application development process. It creates bundles for our scripts and styles. Some of the famous bundlers are Webpack, Rollup, and Parcel, among others.

Bundler creating bundles from the source code

Now, as we have the bundles, if we try to load them on the browser all together, we will encounter some slowness. This is because the complete bundle needs to be loaded into the browser for the user interface to be functional.

Loading a huge bundle results in a poor loading experience

So, instead of waiting for the huge bundle to get loaded into the browser, modern web development libraries and tooling systems allow us to load the bundle in chunks.

We may want to load some of the chunks immediately, as users may need them sooner as the application loads. At the same time, we may want to wait to load certain parts of a web page until they're needed.

Breaking into chunks and loading what is needed

This mechanism of waiting to load part of the pages or application, and loading them only when they are absolutely necessary, is called Lazy Loading. The concept of lazy loading is not React or Next.js-specific. It is a performance optimization technique that you can implement with various libraries and frameworks.

Lazy Loading Techniques in Next.js

Lazy loading techniques in Next.js is used to reduce the amount of JavaScript needed by a route. This helps the initial load performance of the application be faster. We can defer the load of the client components and imported libraries until they are needed.

There are two ways we can implement lazy loading techniques in Next.js:

• Using dynamic imports with the help of the next/dynamic package.
• Using a combination of React.lazy() and Suspense.

Let's understand each of these techniques with code examples.

Lazy Loading With dynamic import and next/dynamic

next/dynamic is a combination of React.lazy() and Suspense from ReactJS. Using a dynamic import with the next/dynamic package is a preferred approach to achieve lazy loading in Next.js.

To demonstrate it, let's first create a Next.js app using the following command:

npx create-next-app@latest

You can start the app locally using the following command:

## Using npm
npm run dev

## Using yarn
yarn dev

## Or use pnpm, bun, whatever you wish!

Now create a folder called components under the app/ directory. We will create all our components under the component folder. Now, create a folder called tom under the app/components/. Finally, create a React component called tom.jsx under the app/components/tom/ directory with the following code:

// tom.jsx

const LazyTom = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Tom</h1>
      <p className="text-xl my-1">
        Tom, named &quot;Jasper&quot; in his debut appearance, is a gray and white
        domestic shorthair cat 🐈. &quot;Tom&quot; is a generic name for a male cat. He is
        usually but not always, portrayed as living a comfortable, or even
        pampered life. Tom is no match for Jerry&apos;s wits.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyTom;

To explain the above code:

• We have created a ReactJS component called LazyTom.
• It is a simple presentational component which has a heading and a couple of paragraphs talking about the cat, Tom, from the famous Tom & Jerry cartoon.
• At the end, we have default exported the component to import it elsewhere.

Now, create another file called tom-story.jsx under the app/components/tom/ directory with the following code:

// tom-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazyTom = dynamic(() => import("./tom"), {
    loading: () => <h1>Loading Tom&apos;s Story...</h1>,
});

function TomStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>dynamic</strong></h2>
            <button
                className="bg-blue-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐈 Tom&apos;s Story
            </button>

            {shown && <LazyTom />}
        </div>
    );
}

export default TomStory;

The main magic of lazy loading with dynamic is happening in the above code:

• We have created a client component called TomStory using the "use client" directive.
• First, we have imported the useState hook for managing a toggle state, and the dynamic function from the next/dynamic for the lazy loading of the component we created before.
• The dynamic function takes a function as an argument that returns the imported component. You can also configure a custom loading message by providing an optional configuration object as argument to the dynamic function.
• The dynamic() function returns the lazily loaded component instance – that is, LazyTom (could be any name). But this component is not loaded yet.
• In the JSX, we have a toggle button that shows and hides the LazyTom component. Note that the component will be lazy loaded into the user browser at the first instance of a button click. After that, if you hide and show it again, the LazyTom component will not be reloaded until we hard refresh the browser or clear the browser cache.
• Finally, we have default exported the TomStory component.

Now we need to test it out. To do that, open the page.js file in the app/ directory and replace the content with the following code:

import TomStory from "./components/tom/tom-story";

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
    </div>
  );
}

This is a simple ReactJS component that imports the TomStory component and uses it in its JSX. Now open your browser window. Open the browser's DevTools and open the Network tab. Make sure that the All filter is selected.

Now access the app on your browser using http://localhost:3000. You should see the button to load Tom's story. Also a bunch of resources will be listed on the Network tab. These are resources required in the initial load of the application and have been downloaded on your browser.

The LazyTom component from the tom.jsx has not been downloaded yet. This is because we haven't yet clicked on the Load Tom's Story button.

The button to lazy load Tom's story

Now, click on the button. You should see a loading message for a moment and then the component will be loaded with Tom's story. You can now see the tom.jsx component listed in the Network tab and also the component rendered on the page with the Tom's story.

Now Tom's story is lazily loaded

Now that you have experienced how the dynamic function from next/dynamic helps us load a component lazily, let's get started with the other technique using React.lazy() and Suspense.

Lazy Loading with React.lazy() and Suspense

To demonstrate this technique, let's start with Jerry's story, my favourite character from the Tom & Jerry cartoon.

First, we'll create a folder called jerry under the app/components/ directory. Now, create a file called jerry.jsx under the app/components/jerry/ with the following code:

// jerry.jsx

const LazyJerry = () => {
  return (
    <div className="flex flex-col justify-center">
      <h1 className="text-3xl my-2">The Lazy Jerry</h1>
      <p className="text-xl my-1">
        Jerry 🐀, whose name is not explicitly mentioned in his debut appearance,
        is a small, brown house mouse who always lives in close proximity to
        Tom. Despite being very energetic, determined and much larger, Tom is no
        match for Jerry&apos;s wits. Jerry possesses surprising strength for his
        size, approximately the equivalent of Tom&apos;s, lifting items such as
        anvils with relative ease and withstanding considerable impacts.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyJerry;

The content of jerry.jsx is structurally similar to tom.jsx. Here we have posted Jerry's story, instead of Tom's, and default exported the component.

Like the last time, let's create a jerry-story.jsx file to showcase the lazy loading of Jerry's story. Create the file under the app/components/jerry/ directory with the following code:

// jerry-story.jsx

"use client";

import React, { useState, Suspense } from "react";

const LazyJerry = React.lazy(() => import('./jerry'));

function JerryStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1"> Demonstrating <strong>React.lazy()</strong></h2>
            <button
                className="bg-pink-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐀 Jerry&apos;s Story
            </button>

            {shown && <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
            </Suspense>}
        </div>
    );
}

export default JerryStory;

Here also we have a client component, and we will be using the lazy() method and Suspense from React, so we have imported them. Like the dynamic() function in the last technique, the lazy() function also takes a function as an argument that retrurns the lazily imported component. We have also provided the relative path to the component that we are trying to load.

Note that with dynamic() we had an opportunity to customize the loading message as part of the function itself. With lazy(), we will be doing that as part of the Suspense fallback.

Suspense uses a fallback when you wait for the data to load. If you would like to understand the Suspense and Error Boundary from ReactJS in-depth, you can check out this video tutorial.

Here, as our LazyJerry component is loading lazily, we have provided a fallback to show a loading message until the component code is download into the browser successfully and rendered.

{shown && 
    <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
    </Suspense>
}

Also, as you can see, we are loading the component on the first button click. Here also, the component will not be reloaded every time we click on the button unless we refresh the browser or clear the browser cache.

Let's now test it by importing it into the page.js file and adding the component in its JSX.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
    </div>
  );
}

Now, you'll see another component appear on the user interface with a button to load Jerry's story. At this stage, you will not see the jerry.jsx component loaded into the browser.

The button to lazy load Jerry's story

Now, click on the button. You will see that the component is loaded, and you can see it on the Network tab list. You should be able to read Jerry's story rendered as part of the lazily loaded component.

Jerry's story is lazily loaded

How to Lazy Load the Named Exported Components

So far, with both the techniques we have imported a component that was exported with the default export and then lazy loaded it. In JavaScript (and so in React), you can export and import modules in two different ways:

• With the default keyword. In this case, the exported module can be imported with any name. You would use this if you wanted to export only one functionality from a module.
• Without the default keyword, this is called a named export. In this case, you have to maintain the same module name for the export and import. You also need to enclose the module name in the curly brackets ({...}) while importing. You would use this if you wanted to export multiple functionalities from a module.

If you want to get into JavaScript modules and how they work in greater detail, I would suggest going through this crash course published on freeCodeCamp's YouTube channel.

To demonstrate the lazy loading of a named export component, let's create another simple presentational React component. This time we will use the angry but cute dog named Spike from the Tom & Jerry cartoon.

Create a folder called spike under the app/components/ directory. Now, create a file called spike.jsx under the app/components/spike/ directory with the following code:

// spike.jsx

export const LazySpike = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Spike</h1>
      <p className="text-xl my-1">
        In his attempts to catch Jerry, Tom often has to deal with Spike 🦮, known
        as &quot;Killer&quot; and &quot;Butch&quot; in some shorts, an angry, vicious but easily
        duped bulldog who tries to attack Tom for bothering him or his son Tyke
        while trying to get Jerry. Originally, Spike was unnamed and mute, aside
        from howls and biting noises as well as attacking indiscriminately, not
        caring whether it was Tom or Jerry though usually attacking Tom.
      </p>
      <p className="text-xl my-1">
      In
        later cartoons, Spike spoke often, using a voice and expressions,
        performed by Billy Bletcher and later Daws Butler, modeled after
        comedian Jimmy Durante. Spike&apos;s coat has altered throughout the years
        between gray and creamy tan. The addition of Spike&apos;s son Tyke in the
        late 1940s led to both a slight softening of Spike&apos;s character and a
        short-lived spin-off theatrical series called Spike and Tyke.
      </p>
    </div>
  );
};

Again, this component is structurally exactly same as the tom.jsx and jerry.jsx components we have seen before, but with two major differences:

1. Here, we have exported the component without the default keyword, hence it is a named export.
2. We are talking about the dog, Spike.

Now, we need to handle the lazy loading of a named exported component and it's going to be a bit different from the default exported component.

Create a file called spike-story.jsx under the app/components/spike/ directory with the following code:

// spike-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

function SpikeStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>Named Export</strong></h2>
            <button
                className="bg-slate-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🦮 Spike&apos;s Story
            </button>

            {shown && <LazySpike />}
        </div>
    );
}

export default SpikeStory;

Like tom-story, we are using the dynamic import with the next/dynamic. But let's zoom into the following block from the above code:

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

The changes you will notice here are that we are resolving the promise explicitly from the import("./spike") function using the the .then() handler function. We get the module first, and then pick the exported component by its actual name – that is LazySpike in this case. The rest of the things remain the same as before as in the tom-story.

Now to test it out, again import the component into the page.js file, and use it in the JSX like the last two times.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />
    </div>
  );
}

There you go – you should see the new component rendered on the browser with a button to load Spike's story from the spike.jsx file which is not loaded yet.

The button to lazy load Spike's story

Clicking on the button will load the file into the browser and render the component to show you Spike's story.

Spike's story is lazily loaded

Below you can see all three components demonstrating three different techniques and uses cases side-by-side. You can test them together. The image below is showcasing lazy loading of two components in parallel where another component was already lazily loaded.

Lazily loading multiple components in parallel

Here is another case where all three components were lazy loaded, on demand with the respective button clicks.

All the stories lazy loaded

Lazy Loading Your Server Components

We spoke about the lazy loading techniques of client components. Can we use the same on server components as well? Well, you can but you don't have to, as server components are already code split and the loading aspect is already been taken care of by Next.js. You are not going to get any kind of error if you are trying to do so, but it would be unnecessary.

In case, you are dynamically importing a server component that has one or more client components as children, those client components will be lazy loaded. But there won't be any impact on the (parent) server component itself.

Here is an example of a server component that has two client components as children:

// server-comp.jsx

import ComponentA from "./a-client-comp";
import ComponentB from "./b-client-comp";

import React from 'react'

const AServerComp = () => {
  return (
    <div className="flex flex-col m-8 w-[300px]">
      <ComponentA />
      <ComponentB />
    </div>
  )
}

export default AServerComp

Now, we are dynamically importing the server component into the page.js file and using it in its JSX. The child client components of the dynamically imported server component will be lazy loaded, but not the server component itself.

// page.js

import dynamic from "next/dynamic";

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story";

const AServerComp = dynamic(() => import('./components/server-comps/server-comp'), {
  loading: () => <h1>Loading Through Server Component...</h1>,
})


export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />

      <AServerComp />
    </div>
  );
}

Should We Lazy Load All Client Components in Next.js?

I had this question when I first started learning about lazy loading. Now that I have gained more experience with this technique, here is my perspective:

You don't have to lazy load all client components. Optimzation is great, but over optimization can have adverse effects. You need to identify where these optimizations are required.

• Do you have client components that are really bulky?
• Are you unnecessarily putting so many things into one component that you should break it down and refactor?
• Do you import heavy libraries into your client components?
• Have you opted for tree-shaking?
• Can you mark bulky client components per route and is it fine not to load some or all of them at the initial load of the page for that route?

As you see, these are a bunch of meaningful questions to ask before you step into optimizing things. Once you have answers, and decide you need lazy loading, then you can implement the techniques you learned from this article.

What's Next?

That's all for now. Did you enjoy reading this article and have you learned something new? If so, I would love to know if the content was helpful. I have my social handles provided below.

Up next, if you are willing to learn Next.js and its ecosystem like Next-Auth(V5) with both fundamental concepts and projects, I have a great news for you: you can check out this playlist on my YouTube channel with 20+ video tutorials and 11+ hours of engaging content so far, for free. I hope you like them as well.

Let's connect.

• Subscribe to my YouTube Channel.
• Follow me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.
• Check out and follow my Open Source work on GitHub.
• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

In the world of network optimization, Content Delivery Networks (CDNs) and caching play a vital role in improving website performance and user experience.

And while both aim to speed up website loading times, they have distinct purposes and mechanisms.

In this tutorial, we'll dive deep into the details of CDNs and caching to understand their similarities, differences, and how they contribute to enhancing online experiences.

Here's what we'll cover:

1. What is Caching?
2. What is a Content Delivery Network (CDN)?
3. Caching vs CDNs – What's the Difference?
4. When to Use Caching
5. When to use CDNs
6. Combining Caching and CDNs
7. Wrapping Up

What is Caching?

Imagine you’re a librarian managing a popular library. Every day, readers come in asking for the same set of books like “Think and Grow Rich” or “The Intelligent Investor.”

Initially, you fetch these books from the main shelves, which takes time and effort. But soon, you notice a pattern: the same set of books are requested repeatedly by different readers. So, what do you do?

You decide to create a special section near the entrance where you keep copies of these frequently requested books. Now, when readers come asking for them, you don’t have to run to the main shelves each time. Instead, you simply hand them the copies from the special section, saving time and making the process more efficient.

This special section represents the cache, storing frequently accessed books for quick retrieval.

Caching is a technique used to store copies of frequently accessed data temporarily. The cached data can be anything from web pages and images to database query results. When a user requests cached content, the server retrieves it from the cache instead of generating it anew, significantly reducing response times.

When a web server receives a request, it can follow different caching strategies to handle it efficiently. One prevalent strategy is known as read-through caching:

1. Request Received: The web server gets a request from a client.
2. Check Cache: It first looks into the cache to see if the response to the request is already there.
3. Cache Hit: If the response is in the cache (hit), it sends the data back to the client right away.
4. Cache Miss: If the response isn’t in the cache (miss), the server queries the database to fetch the required data.
5. Store in Cache: Once it gets the data from the database, it stores the response in the cache for future requests.
6. Send Response: Finally, the server sends the data back to the client.

What to Consider When Implementing a Cache System

Decide When to Use a Cache:

• A cache is best for frequently read but infrequently modified data.
• Cache servers are not suitable for storing critical data as they use volatile memory.
• Important data should be stored in persistent data stores to prevent loss in case of cache server restarts.

Set an Expiration Policy:

• Implement an expiration policy to remove expired data from the cache.
• Avoid setting expiration dates too short (to prevent frequent database reloads), and too long (to prevent stale data).

Maintain Synchronization Between Data Stores and Cache

• Inconsistencies can arise due to separate operations on data storage and cache, especially in distributed environments.

Mitigate Failures:

• Use multiple cache servers across different data centers to avoid single points of failure.
• Over-provision memory to accommodate increased usage and prevent performance issues.

Implement an Eviction Policy:

• When the cache is full, new items may cause existing ones to be removed (cache eviction).
• A popular eviction policy is Least Recently Used (LRU), but other policies like Least Frequently Used (LFU) or First In, First Out (FIFO) can be chosen based on specific use cases.

Real-World Applications of Caching

Social Media Platforms: Imagine scrolling through your Facebook feed. Thanks to caching, you see profile pictures, trending posts, and recently liked content instantly, even if millions of users are accessing the platform simultaneously.

Caching these frequently accessed elements on servers or your device minimizes delays and makes the experience smoother and more engaging.

E-commerce Websites: When browsing Amazon for a new gadget, you expect a seamless shopping experience. Caching plays a crucial role here. Product images, descriptions, and pricing information are cached, enabling the website to display search results and product pages rapidly.

This is especially crucial during peak seasons like Black Friday or Cyber Monday, where caching helps handle surges in traffic and ensures customers can complete their purchases without encountering delays.

Content Management Systems (CMS): Millions of websites rely on CMS platforms like WordPress. To ensure smooth performance for all these users, many CMS platforms integrate caching plugins. These plugins cache frequently accessed pages, reducing the load on the server and database.

This translates to faster page loading times, improved SEO ranking due to faster indexing by search engines, and a more responsive website overall, providing a better experience for visitors.

What is a Content Delivery Network (CDN)?

Now, think of a CDN as a global network of book delivery trucks. Instead of storing all the books in one central library, you have local branches worldwide, each with copies of the most popular books.

When readers request a book, you don’t have to ship it from the main library. Instead, you direct them to the nearest branch, where they can quickly pick up a copy. This cuts down on travel time (data transfer time) and keeps everyone happy with fast access to their favorite books.

In technical terms, a CDN is a network of servers distributed across various locations globally. Its primary purpose is to deliver web content, such as images, videos, scripts, and stylesheets to users more efficiently by reducing the physical distance between the server and the user.

How CDNs Work:

First, imagine that User A wants to see an image on a website. They click on a link provided by the CDN, like “https://mywebsite.cloudfront.net/image.jpg". This requests the image.

Then, if the image isn’t in the CDN’s storage (cache), the CDN fetches the image from the original source, like a web server or Amazon S3.

In response to that, the original source sends the image back to the CDN. It might include a Time-to-Live (TTL) header, indicating how long the image should stay cached.

Next, the the CDN stores the image and serves it to User A. It stays cached until the TTL expires.

Then let's say that user B requests the same image. At that point, the CDN checks if it’s still in the cache. If the image is still cached (TTL hasn’t expired), the CDN serves it from there (a hit). Otherwise (a miss), it fetches a fresh copy from the origin.

What to Consider When Implementing a CDN

• Cost Management: CDNs charge for data transfers. It’s wise to cache frequently accessed content, but not everything.
• Cache Expiry: Set appropriate cache expiry times. Too long, and content might be stale. Too short, and it strains origin servers.
• CDN Fallback: Plan for CDN failures. Ensure your website can switch to fetching resources directly from the origin if needed.
• Invalidating Files: You can remove files from the CDN before they expire using various methods provided by CDN vendors.

Real-World Applications of a CDN

Video Streaming Services: Imagine you're in Sydney, Australia, craving to watch the latest season of your favorite show on Netflix. Without a CDN, the data would have to travel all the way from a server in, say, California, leading to buffering and frustrating delays.

But thanks to CDNs, Netflix caches popular content on edge servers closer to you, in Sydney or its surrounding region. This significantly reduces the distance the data needs to travel, ensuring smooth playback and an uninterrupted viewing experience, regardless of your location.

In fact, studies show that CDNs can reduce video startup time by up to 50%, making a significant difference in user satisfaction.

Gaming Content Distribution: Gamers know the pain of waiting for massive game updates or DLC downloads. But companies like Steam and Epic Games leverage CDNs to make things faster.

These platforms cache game files, updates, and multiplayer assets on edge servers close to gaming communities. This means whether you're downloading a new game in New York or patching your favorite title in Tokyo, the data doesn't have to travel across continents.

Using CDNs can decrease download times quite a bit, leading to quicker access to the games you love and smoother multiplayer experiences with minimal lag.

Global News Websites: Staying informed about global events shouldn't be hindered by slow loading times. Major news organizations like BBC News and The New York Times use CDNs to ensure their breaking news updates and multimedia content reach audiences worldwide instantly.

By caching critical information like articles, videos, and images on servers across different continents, CDNs enable news websites to deliver real-time updates quickly, keeping readers informed regardless of their location.

During major events or emergencies, this can be especially crucial, as evidenced by a case study where a news organization using a CDN reported a 20% increase in website traffic without any performance issues during a breaking news event.

Caching vs CDNs – What's the Difference?

Similarities between caching and CDNs:

Improved Performance: Both CDNs and caching aim to enhance website performance by reducing latency and speeding up content delivery.

Efficient Resource Utilization: By serving cached or replicated content, both approaches help optimize resource utilization and reduce server load.

Enhanced User Experience: Faster load times lead to a better user experience, whether achieved through CDNs or caching.

Differences between Caching and CDNs

Scope:

• CDNs: CDNs are a network of servers located in different geographic locations around the world.
• Caching: Caching is a method of storing web content on a user’s local device or server.

Implementation:

• CDNs: CDNs require a separate infrastructure and configuration.
• Caching: Caching can be implemented within a web application or server using caching rules and directives.

Geographic Coverage:

• CDNs: Designed to deliver web content to users across the world.
• Caching: Typically used to improve performance for individual users or within a local network.

Network Architecture:

• CDNs: Use a distributed network of servers to cache and deliver content.
• Caching: This can be implemented using various types of storage such as local disk, memory, or a server-side cache.

Performance Benefits:

• CDNs: Provide faster and more reliable content delivery by caching content in multiple locations.
• Caching: Improves performance by reducing the number of requests to the origin server and delivering content faster from a local cache.

Cost:

• CDNs: Can be more expensive to implement and maintain due to the need for a separate infrastructure and ongoing costs for network maintenance.
• Caching: Can be implemented using existing infrastructure and server resources, potentially reducing costs.

When to use Caching

Caching is ideal for frequently accessed content that doesn't change frequently. This includes static assets like images, CSS files, and JavaScript libraries.

It's particularly effective for websites with a substantial user base accessing similar content, such as news websites, blogs, and e-commerce platforms.

Caching can also significantly reduce server load and improve response times for users, especially in scenarios where content delivery latency is a concern.

When to use CDNs

CDNs are invaluable for delivering content to a global audience, especially when geographical distance between users and origin servers leads to latency issues.

They are well-suited for serving dynamic content, streaming media, and handling sudden spikes in traffic.

CDNs also excel in scenarios where content needs to be delivered reliably and consistently across diverse geographic regions, ensuring optimal user experience regardless of location.

Combining Caching and CDNs

In many scenarios, employing both caching and CDNs together yields optimal results, particularly for dynamic websites and applications where a mix of static and dynamic content delivery is essential. Let's consider a popular news website as an example.

Imagine a bustling news website that regularly publishes breaking news articles, accompanied by images and videos. While the core news content is dynamic and frequently updated, the images and videos associated with older articles remain relatively static and are accessed repeatedly by users.

To address this, the website can implement a combined strategy:

1. Caching on the Origin Server: Frequently accessed elements like website templates, navigation menus, and static content are cached directly on the origin server. This caching reduces server load and enhances performance for initial page loads.
2. CDN Caching: The website leverages a CDN to cache frequently accessed images and videos associated with news articles on edge servers located worldwide. This ensures that users, regardless of their geographic location, can swiftly access these elements with minimal latency.

There are many benefits of the combined approach, such as:

• Faster Loading Times: By serving cached content from both the origin server and CDN edge servers, users experience significantly faster loading times, leading to a more engaging browsing experience.
• Reduced Server Load: Caching alleviates pressure on the origin server, enabling it to efficiently process dynamic content updates while serving static elements from cache.
• Improved Global Reach: The CDN ensures that users worldwide can access the website and its content with minimal delays, irrespective of their proximity to the origin server.

But there are also some factors to consider:

• Cache Invalidation: Regularly updating cached content ensures users access the latest information. Most CDNs offer efficient cache invalidation mechanisms to facilitate this process.
• Cost Optimization: While combining caching and CDNs enhances performance, it's crucial to evaluate the cost-effectiveness of caching specific content. Analyzing user access patterns helps determine the optimal caching strategy.

By strategically combining caching and CDNs, you and your team can create a robust content delivery infrastructure that delivers a superior user experience worldwide.

Wrapping Up

Both CDNs and caching play crucial roles in optimizing website performance and user experience by speeding up content delivery.

While caching stores frequently accessed data locally for quick retrieval, CDNs provide a geographically distributed network of servers to deliver content efficiently to users worldwide.

Understanding their similarities in performance improvement and resource utilization, as well as their key differences in scope, implementation, and cost is crucial for choosing the right approach for your specific needs.

Performance testing is a routine software practice which is carried out to determine the stability of a system in terms of scalability, reliability, and data management, among other parameters.

In this tutorial, I'll walk you through what performance testing entails, and the common tools used for backend testing. We'll also walk through a demo performance testing project together.

The tutorial is simplified and suitable for beginners, mid-level developers, and professional developers. Being proficient in performance testing is fundamental to growing as a backend developer, and this guide will serve as a good review even if you're more advanced in your career. With that said, let's dive in.

Prerequisites:

• Intermediate knowledge of Node.js
• Basic knowledge of JavaScript operations
• Knowledge of API development\

Table of Contents:

1. What is Performance Testing?
2. Examples of Performance Testing Tools
3. Demo Project
4. Conclusion

What is Performance Testing?

Performance testing serves quite a lot of purposes – one of the most important of which is to test system efficiency in performing and sustaining tasks. It also serves as a standard you can use to compare systems of varying efficiency and builds and enables you to choose the most effective one.

Performance testing also helps reveal vulnerabilities. State-of-the-art testing tools are well optimized to efficiently analyze the code to detect any errors. They're quick to highlight the areas where these errors occur.

The end goal of performance testing is dependent how you're using the application. It might be concurrency-oriented or transaction rate-oriented, depending on whether the app involves end users or not.

Performance testing could also involve load testing, which is usually carried out to evaluate the behavior of a web service under a specific expected load. Other types of testing you can do include integration testing, spike testing, soak testing, and stress testing.

Examples of Performance Testing Tools

There are many tools commonly used to test the efficacy and latency of web applications. In this section, I'll discuss some of the popular tools used, and highlight their strengths and use cases.

Jest

Jest is a multi-platform testing tool used to assess the correctness of JavaScript-based applications. It's the one we'll be using in this demo.

Jest was initially created to test the efficiency of React applications, but has since been extended to test the efficiency of Node.js apps as well. It also offers a code coverage feature.

Mocha

Mocha is a concise asynchronous JavaScript-based testing tool for Node.js applications. It is also used with assertion libraries such as [Chai]( https://www.npmjs.com/package/chai) and [should]( https://www.npmjs.com/package/should).

Pythagora

Pythagora offers a unique integrating testing feature to help test how different part of the application works together. It also has a code coverage feature.

Artillery

Artillery is a stack agnostic testing tool. This means it can be used for multiple web applications based on different programming languages and still produce an optimal test outcome.

This tool provides efficient load testing features which help to determine the optimal status of the application when exposed to a large load of traffic. It also checks the speed at which an app responds to a user request without crashing.

Ava

Ava is a JavaScript-based performance unit testing tool used to test the efficacy of Node.js applications. It works asynchronously, running multiple concurrent tests to determine the suitability of multiple code units.

Loadtest

Loadtest is a special Node package which is used to load test Node.js applications. It evaluates their ability to cope with requests of varying volumes and it evaluates for efficiency and concurrency.

Apache J-meter

Apache J-meter offers load-testing features for web applications. It has an in-built IDE to enable interaction with the user. It is multithreaded, increasing its ability to mimic several users.

There are other testing tools which are also useful. But in this tutorial, we will be utilizing Jest to test our back-end application.

Demo Project

Install Jest

We'll now perform a unit test on our code using the Jest testing tool. To do this, you'll need to install the Jest package in your code folder. Type npm install jest in the command prompt. A success message will be displayed when the installation is completed.

Configure package.json

In this tutorial, we'll test the efficiency of some selected routes in our Node.js application. This will necessitate writing different unit tests for each route and evaluating its correctness.

Now let’s optimize our file structure to successfully unit test our application. Navigate to the package.json file and edit it to include the following code:

"scripts": {
    "test": " jest",
    "start": "nodemon index.js"
  },

Modifying the package.json file to include this code ensures that the Node.js server recognizes Jest as our default unit testing tool for the project. By so doing, any time we enter npm test in the command prompt, Jest gets activated.

Set up the test environment

Create a folder in the root directory named “tests”. This helps the Jest operator locate the specific files housing the routes to be tested.

Within the test folder, create a test file. The file can be named whatever you prefer, but the suffix .test.js should be added to enable Jest to recognize it and execute it.

After completing these steps, let’s get into the core details of unit testing in our project.

Run the unit tests

The demo project we'll test in this tutorial is an eBook library application which contains some functions such as a get all books route, Get a single book route, upload a book route, and delete a book route. We'll create unit tests for the GetAllBooks route in the example below, and then you can try to create your own for the other routes.

So firstly, we'll import the book database into the test.js file like this:

const Book = require('../models/Book')

The code above imports and initializes our default book MongoDB database model.

Then we'll import the functions that we'll test in each route:

const Book =  require("../models/Book")

async function GetAllBooks (req, res)  {
    try {
const allBooks =  await Book.find();
res.status(200)
res.send(allBooks)
    }
    catch (err) {
res.status(500)
res.send(err) 
    }
}
module.exports = {GetAllBooks};

const {GetAllBooks} = require("../controllers/Books");

The code above imports the getAllBooks function from a controller folder.

Having imported the function, let's now go ahead to setup our Jest unit test function.

jest.mock("../models/Book");

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

it("it should return all the books in the database", async () => {

Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));

  await GetAllBooks(req, res);


expect(res.status).toHaveBeenCalledWith(200);

expect(res.send).toHaveBeenCalledTimes(1);
});

First of all, Jest offers you the ability to create a fake database by copying the structure of the default database. This is known as mocking. This enables the unit test to operate faster and eliminate the lag that comes with getting responses from large databases.

Testing which involves the real database is referred to as end-to-end testing as opposed to unit testing.

Here's how you can do that in Jest:

jest.mock("../models/Book");

The code above illustrates database mocking. In order to get a faster unit test, we have to mock the existing Book database model we're using in our application.

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

The above code contains the default sample requests and response objects. The sample response object contains both the status and send functions, which return a defined output if executed successfully or not.

it("it should return all the books in the database", async () => {
Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));
  await GetAllBooks(req, res); 
expect(res.status).toHaveBeenCalledWith(200);
expect(res.send).toHaveBeenCalledTimes(1);
});

Now the It function contains a short description of what the test should be about. This is then coupled to an anonymous asynchronous function which contains a mock implementation of the database model with some dummy data.

After that, the getAllBooks request is triggered and executed with a null request passed to it and the format of the response object is included.

The expect statement returns passed if the function satisfies the requirements expected. For this code, the requirements are that the response object should return a status code of 200 and the response.send object should be called at least once with the response object included. If it fails, a failed status will be returned.

Tests passing

You now know the basics of how to unit test functions. You can also try to test the delete book route, upload a book route and find a specific book route.

Conclusion

In this tutorial, you've been able to harness the usefulness of testing tools in optimizing your web applications.

You've learned about various testing tools available and their use cases, and you also implemented a unit test in a web application.

Following the steps highlighted in this tutorial, you will be able to perform unit tests on your coding projects.

I sincerely hope you learned something new and enjoyed this tutorial. Until next time, keep on coding.

In today's digital landscape, the performance of a website is a key factor in its success. Writing efficient CSS code can greatly influence how quickly your web pages load, impacting everything from user experience to search engine rankings.

This guide delves into effective strategies to help you refine your CSS, ensuring that your website not only looks great but also loads swiftly and runs smoothly.

How CSS affects Web Performance

When a user visits a webpage, the browser retrieves the site's structural HTML and its stylistic CSS. This is a set of detailed instructions on how each part of the webpage should look.

If the CSS is packed with too much information or is too complex, it's like giving the browser a puzzle that takes longer to solve. This can lead to longer waiting times for users, which can be annoying.

That's where the art of streamlining CSS comes into play. It's not just about tidying up the code, but also making sure the browser can get the webpage ready faster.

When CSS is made leaner and simpler, it's like giving the browser a clear, easy-to-follow map. This makes webpages load faster, making everything feel more responsive.

1. Write Shorter CSS

When writing CSS, use the popular software development principle Don’t Repeat Yourself (DRY). This advocates for conciseness and clarity in your code.

This is important here, because in practice, CSS involves repeating properties across various selectors. The goal should be to identify and consolidate these repetitive properties. By doing so you eliminate redundancies, leading to cleaner and more manageable CSS.

For instance, in the code below, multiple elements (h1and h2) share the same font-size and color.

h1 {
    font-size: 20px;
    color: #fff;
}
h2 {
    font-size: 20px;
    color: #fff;
}

So instead of declaring these properties separately for each selector, you can group them under a common class. This not only streamlines your stylesheet but also makes future updates easier and less error-prone.

You can rewrite the above code to look like this:

h1, h2 {
    font-size: 20px;
    color: #fff;
}

Using shorthand properties is another effective strategy for minimizing the size of your CSS, making your code more efficient. It also allows you to set multiple related CSS properties with a single declaration. Here's how you can write effective shorthand CSS:

When all sides of an element have the same value, use that one value.

/* Before shorthand */
.same-sides {
    padding-top: 15px;
    padding-right: 15px;
    padding-bottom: 15px;
    padding-left: 15px;
}

/* After shorthand */
.same-sides {
    padding: 15px;
}

When all sides of an element have different values, use all four.

/* Before shorthand */
.different-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 15px;
    padding-left: 25px;
}

/* After shorthand */
.different-sides {
    padding: 10px 20px 15px 25px;
}

When top/bottom and right/left have the same value, use two values.

/* Before shorthand */
.two-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 10px;
    padding-left: 20px;
}

/* After shorthand */
.two-sides {
    padding: 10px 20px;
}

When only the right/left values are the same but the top and bottom aren't, use three values.

/* Before shorthand */
.three-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 15px;
    padding-left: 20px;
}

/* After shorthand */
.three-sides {
    padding: 10px 20px 15px;
}

2. Use Shallow CSS Selectors

Shallow CSS selectors are direct and concise selectors with fewer levels of nested elements that don't dig too deep into the HTML structure.

Simplifying your selectors can significantly speed up your webpage rendering because deeply nested selectors take longer for browsers to evaluate, which results in a slower page render.

Consider the example in the code below: to assign property values to a deeply nested selector like header nav ul li a is cumbersome and will cause rendering delays because the browser needs time to check each level (header, then nav, then ul, and so on) to find the right <a> tag to style).

Alternatively, giving it a direct class .nav-link is straightforward and quicker for browsers to interpret. Class selectors are generally more efficient than nested tags because the browser simply looks for elements with a class and applies the styles, without worrying about their position in the DOM tree.

/* Less efficient: Deeply nested selector */
header nav ul li a { 
   color: #000;
   font-size: 10px;
 }

/* More efficient: Class selector */
.nav-link {
   color: #000;
   font-size: 10px;
}

3. Segment CSS Code

Segmenting your CSS code into smaller, more focused segments like separate files for different website components and creating page-specific styles can greatly improve your website's performance. This approach not only makes it easier to find and edit specific styles but also ensures that webpages load only the CSS they need, avoiding unnecessary bulk.

Enhanced maintainability and faster page loading are the most obvious key benefits. Smaller CSS files are easier to manage, much like a well-organized toolbox where everything is easy to find. But also, by loading only the essential CSS for each page, the browser has less work to do hence improving the user experience.

Original CSS

Suppose you have a CSS file that contains styles for various parts of your website:

/* Styles for the home page */
.homepage {
    background-color: #f0f0f0;
    padding: 10px;
}

/* Styles for the services page */
.services {
    background-color: #333;
    color: white;
}

/* Styles for the contact page */
.contact {
    background-color: #222;
    color: white;
    padding: 20px;
}

Segmented CSS

Now, let's segment this CSS into different files based on their purpose:

1. Home page Styles (homepage.css):

.homepage {
    background-color: #f0f0f0;
    padding: 10px;
}

2. Services page Styles (services.css):

.services {
    background-color: #333;
    color: white;
}

3. Contact page Styles (contact.css):

.contact {
    background-color: #222;
    color: white;
    padding: 20px;
}

Each CSS file is focused on a specific part of the website. Now, when a user visits your website, each page loads only the CSS it requires hence enhancing the website's performance.

4. Optimize CSS Delivery

You can make your CSS files lighter and faster to load by shrinking your CSS – that is, you can remove extra spaces and lines (this is called minifying). Then you can compress these files so they're smaller and quicker for users to download.

Also, make sure the most important styles of your website load first, so people see your page faster. The other styles can load in the background without slowing things down.

You can also make your website faster for people who visit more than once, by saving some of your CSS in their browser (this is known as caching). This means it doesn’t have to load again every time they visit.

Also, if you use a CDN or a network of servers, your CSS files can be stored in many places around the world to load faster no matter where your users are.

Graphic comparing file size between an unminified CSS file at 167KB and a minified CSS file at 92KB

Original CSS

/* Main Stylesheet */
/* Header Style */
header {
  background-color: #333;
  color: white;
  padding: 10px;
}

/* Navigation Style */
nav {
  background-color: #444;
  margin-top: 10px;
}

The above CSS code is readable and well-commented, but it contains extra spaces and comments that increase the file size.

Minified CSS

header{background-color:#333;color:white;padding:10px}nav{background-color:#444;margin-top:10px;}

The minified version combines all the rules into a single line, removing unnecessary spaces and comments, which reduces the file size for quicker loading.

Conclusion

Optimizing your CSS speeds up your website and consequently improves the overall user experience.

By implementing the practices outlined in this article, you can achieve more performant, efficient and maintainable CSS. The performance savings may not be significant from tweaking a few lines but over hundreds more across different stylesheets, the impact will begin to show.

Remember, web performance is an ongoing process. Regularly review and refine your CSS to keep up with best practices and emerging trends.

Additional Resources

• MDN Web Docs on CSS
• Google Web Fundamentals
• Web Performance In Action

Among the plethora of strategies you can use to enhance web performance, lazy loading stands out for its efficiency and impact.

But what exactly is lazy loading, and how does it revolutionize the way we handle web resources? That's what we'll cover in this article.

What is Lazy Loading?

Lazy loading is a web performance optimization strategy that plays a critical role in how resources are loaded on a webpage.

Traditionally, when you go to access a webpage, the browser attempts to load all resources (images, scripts, stylesheets) immediately. This can lead to longer load times, especially if the page contains many large files.

Lazy loading addresses this by marking certain resources as non-blocking or non-critical, loading them only when they are needed. This method is especially effective for elements that aren't immediately visible on the initial page load, such as images and videos that appear further down the page.

Key benefits of lazy loading:

• Improved Performance: By loading only the necessary resources, the initial page load is faster, leading to a better user experience.
• Reduced Bandwidth Usage: Lazy loading minimizes the amount of data that needs to be transferred initially, saving bandwidth for both the user and the server.
• Enhanced User Engagement: Faster load times generally lead to lower bounce rates and higher engagement, as users are less likely to leave a slow-loading site.

Lazy loading can be implemented in various ways, with the most common method being JavaScript-based. But modern web development practices have introduced native HTML ways to implement lazy loading, such as the loading attribute for images.

The Role of the Image Loading Attribute in Lazy Loading

As we delve deeper into the practicalities of lazy loading, you'll see that the loading attribute in the <img> element is a game-changer.

This attribute, a relatively recent addition to the HTML specification, offers a simple yet powerful way to implement lazy loading natively, without the need for additional JavaScript. By leveraging the loading attribute, you can significantly enhance web performance and user experience, especially in content-heavy websites.

Browser-Level Lazy Loading

Primarily, browsers like Chrome and Firefox support the loading attribute for and

This method is efficient and enhances performance by loading images only when they are likely to be viewed by the user. But it's important to note that the lazy value for

Let's look at some examples to see how this works.

Basic lazy loading of a single image

<img src="image-1.jpg" alt="A scenic landscape" loading="lazy">

In this example, the loading="lazy" attribute in the <img> tag tells the browser to defer loading this image until it's about to enter the viewport. This means the image won't load when the page initially loads, but only when the user scrolls near it.

Lazy loading with high-priority images

<img src="logo.jpg" alt="Company Logo" loading="eager"> 
<img src="featured.jpg" alt="Featured Product" loading="lazy">

Here, the first image (logo) uses loading="eager", which is the default behavior to load the image immediately. It's useful for important images that need to be seen right away. The second image (featured product) uses loading="lazy", ideal for images that are not critical to see immediately.

Lazy loading in a gallery

<img src="gallery-image-1.jpg" alt="Gallery Image 1" loading="lazy"> 
<img src="gallery-image-2.jpg" alt="Gallery Image 2" loading="lazy">
<img src="gallery-image-3.jpg" alt="Gallery Image 3" loading="lazy">

For image galleries, using loading="lazy" for each image ensures that images load as the user scrolls through the gallery, improving page load time and reducing bandwidth usage.

Combining Lazy Loading with Art Direction

Art direction in web design refers to the practice of adapting the presentation of content to suit different contexts, devices, or demographics. It often involves using different images or visual styles to convey a specific message or feeling that resonates with various audience segments or fits different screen sizes.

For instance, a website might display a detailed, large image on a desktop but a simpler, smaller image on a mobile device – both delivering the same message but optimized for their respective viewing contexts.

Here’s how you can implement this alongside lazy loading:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg" loading="lazy">
  <source media="(min-width: 400px)" srcset="medium.jpg" loading="lazy">
  <img src="small.jpg" alt="Responsive Image" loading="lazy">
</picture>

In this code, the <picture> element contains multiple <source> elements, each with a different srcset attribute for different screen sizes, and a default <img> element. The loading="lazy" attribute is added to each source to enable lazy loading.

Intersection Observer for Polyfilling

The Intersection Observer API is a modern web API that provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or the viewport. Essentially, it allows you to execute code when an element enters or leaves the viewport, which is perfect for lazy loading images.

Polyfilling is a technique in web development where modern functionality is replicated in older browsers that do not support that functionality natively. A polyfill is a piece of code (usually JavaScript) that provides the technology that developers expect the browser to provide natively.

When it comes to lazy loading, if a browser does not support the loading attribute, we can use the Intersection Observer as a polyfill to achieve lazy loading behavior.

This JavaScript-based method involves observing <img> elements to determine their visibility within the viewport. When an image becomes visible, its src and srcset attributes are updated to load the actual image.

This method requires additional markup, including a class attribute for selection, a src attribute for a placeholder image, and data-src and data-srcset attributes for the actual image URLs

First, the HTML setup:

<img class="lazy" src="placeholder.jpg" data-src="actual-image.jpg" alt="Description">

• class="lazy": A class identifier for JavaScript selection.
• src: A placeholder image URL.
• data-src: The actual image URL to be loaded.

Then, the JavaScript:

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Fallback for browsers without Intersection Observer support
  }
});

This section of code demonstrates how you can use the Intersection Observer API to implement lazy loading. It checks if the Intersection Observer is supported in the browser and, if so, uses it to load images only when they enter the viewport.

Wrapping Up

Using lazy loading, particularly through the loading attribute in HTML, can significantly help you improve web performance. By selectively deferring the loading of images and iframes until they are needed, this technique not only enhances the speed and efficiency of web pages but also contributes to a more seamless and responsive user experience.

Whether you apply lazy loading to individual images, galleries, or complex responsive layouts, the versatility of the loading attribute allows you to cater to various web development scenarios, ensuring that resources are utilized effectively and efficiently.

As web technologies continue to evolve, adopting such performance-centric strategies will become increasingly vital in delivering content that meets the expectations of modern web users.

So you might wonder – how do you make sure your application runs without breaking? To handle this, you can send tasks to a queue outside your application's flow.

What is a Message Queue?

A message queue is a tool that facilitates the communication and transfer of data between services within a single application (or externally). It stores these data or messages using the First-In-First-Out (FIFO) principle. This means that older data that's passed into these queues gets processed before newer data.

Different components make up a message queue, such as:

• Messages: These are the data that are sent to the queue. They are often referred to as jobs.
• Queues: These are the data structures used for storing messages.
• Producers: These are a service that sends messages or data into the queue system.
• Consumers: These are a service that listens to the queue and executes messages passed in it.

Message Queuing Tools

Now, there are various message queuing tools you can use in asynchronous systems, like the following:

• RabbitMQ: a reliable and flexible option for implementing message queues in applications.
• Apache Kafka: an efficient message queuing tool, also very good at event stream processing.
• Redis: an in-memory store used for message queuing, caching, and data processing.

Note that some of these tools are not limited to message queuing but can be used for other purposes as well, like stream processing.

In this article, you will create a simple Nest.js project which will use RabbitMQ as the Message Queue Service Provider.

The tutorial will be divided into 3 parts:

• How to Set Up a Nest.js Project for Basic User Registration Flow
• How to Set Up an Email Service for User Registration
• How to Integrate a Queue Service using RabbitMQ

Prerequisites

• You'll need to have Node installed on your system. If you don't have it, here is its official site: https://nodejs.org/en.
• You'll need to have Node Package Manager (NPM) installed, which you can download here if you don't have it: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm.
• You'll need to have installed RabbitMQ. Here is where you can get it in case you haven't yet: https://www.rabbitmq.com/download.html
• You'll need to have a text editor. For this article, I'll use VSCode. You can download it here: https://code.visualstudio.com/download or use the code editor of your choice.

How to Set Up a Nest.js Project

Spinning up a Nest.js application is fast and simple if you use the Nest CLI. Open up your terminal and enter this command below to install the CLI:

 $ npm install -g @nestjs/cli

This installs the Nest.js CLI globally on your system, meaning you can call the CLI commands regardless of the directory you are currently in.

Moving forward, to create a simple REST API project, you will enter the command below:

nest new simple-queue

Simple-queue here is the directory name that will be created. Inputting this command gives you a prompt to select a package manager.

When that's done, navigate to the created directory and open it in your text editor by entering this command:

cd simple-queue && code .

This opens up your text editor. We want to work on a project that will best show how a message queue can be used in a real-world scenario – so let's set up a basic user registration form. On successful data entry it sends an email to the user, but you'll handle the email service separately by passing it into a queue to improve performance.

For this, we'll be using an SQLite database, TypeOrm, class-validators, and the dotenv package so you can secure your config variables. Go ahead to install them by typing this command in your terminal:

npm install --save @nestjs/typeorm typeorm sqlite3 class-validator dotenv

When the installation is complete, go to your root app module, and then include the TypeOrm configuration for your database.

SQLite is a lightweight SQL database which allows us to quickly spin up and test data. It's optimal for this use case – and now we'll configure it.

Configuring the SQLite Database

import { Module } from "@nestjs/common";
import { TypeOrmModule } from "@nestjs/typeorm";
import { AppController } from "./app.controller";
import { AppService } from "./app.service";

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type:'sqlite',
      database: 'mini-db.sqlite',
      entities: [__dirname + '/**/*.entity{.ts,.js}'],
      synchronize: true,  
  })],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Congrats! You have successfully connected a DB to your project. Now it's time to create the services that will handle the user registration.

In order to do this, you will have to go back to your dear friend the Nest CLI. There, you'll be inputting a different command to help generate a resource folder for the User, which will contain the entity, service, dto, and the controller.

To do this, open your terminal and enter in this command:

nest generate resource users

A prompt to select your transport layer will be shown. Select the first one which is the REST API. Then, another prompt will ask if you would like to generate CRUD endpoints – you can type Yes. Then you can make modifications according to your requirements.

To proceed, you first have to define what information each user should have. First, create a User entity. You can do this by navigating to the user entity file in the created entity subfolder in the user folder. Then define the user data like this:

import { Entity, PrimaryGeneratedColumn, Column } from "typeorm";

@Entity('users')
export class User {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column({ length: 100, unique: true })
  username: string;

  @Column({ length: 100, unique: true })
  email: string;
}

For this mini-project, you'll use basic user data to make the process faster. The username and email field have been set to be unique, meaning that there won't be a duplicate of the data instance passed in for this user table.

Now having done this, modify the create user dto file that was generated like this:

import { IsNotEmpty, IsString, IsEmail } from "class-validator";

export class CreateUserDto {
    @IsNotEmpty()
    @IsString()
    username: string;

    @IsNotEmpty()
    @IsString()
    @IsEmail()
    email: string;
  }

This was created to validate the payload that will be sent in your request by using the class-validator package.

Now, modify the create method in the user service file.

import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";
import { CreateUserDto } from "./dto/create-user.dto";
import { User } from "./entities/user.entity";

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    return await this.userRepository.save(newUser);
  }
}

Next you'll modify the controller file. You've already defined the create endpoint, so you'll just have to clean up the other endpoints that are not needed.

import { Controller, Post, Body } from "@nestjs/common";
import { CreateUserDto } from "./dto/create-user.dto";
import { UsersService } from "./users.service";

@Controller('users')
export class UsersController {
 constructor(private readonly usersService: UsersService) {}
  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

Open up the user module file and make some adjustments by adding the import field to the Module decorator and using the TypeOrmModule property.

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
import { UsersController } from './users.controller';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './entities/user.entity';

@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Next, start up your server by entering this command on your terminal: npm run start:dev. Once the server is up and running, open up your API client of choice. For this article, we'll use Postman. Then make a POST request to the endpoint, which will be localhost:3000/users, providing the payload data required.

A request was made and a user instance was created.

Next up is adding an email service to your project which will help notify new users who are registering.

How to Set Up an Email Service for User Registration

For this, you'll use some packages which are required to create an email service. Open up your terminal and input the command below to install these packages:

npm install --save @nestjs-modules/mailer nodemailer

When these packages are installed, you can now implement the mail service. Using the Nest CLI, create a mailer module and service by entering this command in your terminal:

nest generate module email && nest generate service email

When it's done, open up the newly created module file in the mail folder. You'll use the MailerModule property of the @nestjs-modules/mailer package to configure your mail service here. It requires an SMTP client whose keys you'll need to configure this MailerModule.

For that you can use https://app.elasticemail.com to get these SMTP keys. Sign up and connect to the SMTP API. You'll then be given keys for your private use.

Note that this free mode of the SMTP client has limitations and it cannot send to all emails – so you should use a test email service.

How to Configure the Mailer Module

Once you have gotten that set up, go back to your application and create a .env file. Set your secrets for the SMTP keys. Then configure your MailerModule like this:

import { Global, Module } from "@nestjs/common";
import { EmailService } from "./email.service";
import { MailerModule } from "@nestjs-modules/mailer";

require('dotenv').config();
@Global()
@Module({
  imports: [
    MailerModule.forRoot({
      transport: {
        service: 'QueueTest',
        host: process.env.SMTP_HOST,
        port: process.env.SMTP_PORT,
        auth: {
          user: process.env.SMTP_USER,
          pass: process.env.SMTP_PASSWORD,
        },
      },
      defaults: {
        from: process.env.FROM_EMAIL,
      },
    }),
  ],
  providers: [EmailService]
})
export class EmailModule {}

The global decorator was set in order to make sure the MailModule can be called anywhere in your application. Make sure your secrets are properly loaded and thaqt you have a valid Email set in the from: process.env.FROM_EMAIL.

Check to make sure that the EmailModule is also imported in the root App Module the same way your UsersModule was imported in the Imports Array of the App Module.

Next, open your email service file – you'll need to make some modifications to the EmailService class. Add a constructor and call the MailService property from the @nestjs-modules/mailer package. Then go ahead and create a function that will handle sending the emails.

Below is a class and method that does this:

import { MailerService } from '@nestjs-modules/mailer';
import { HttpException, HttpStatus, Injectable } from '@nestjs/common';

@Injectable()
export class EmailService {
  constructor(private mailerService: MailerService) {}
  async sendEmail(options: { email: string; subject: string; html: string;
  }) {
    try {
      const message = {
        to: options.email,
        subject: options.subject,
        html: options.html
      };
      const emailSend = await this.mailerService.sendMail({
        ...message,
      });
      return emailSend;
    } catch (error) {
      throw new HttpException('Error', HttpStatus.INTERNAL_SERVER_ERROR);
    }
  }
}

Now you've defined the method to send an email. You've also put an exception handler in place for better error handling.

Now it's time to add this newly created service to your user registration flow.

Navigate to your user service file, and add the mail service to your constructor as a provider. Then call the service in your create user method like this:

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
    private emailService: EmailService
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    const user =  await this.userRepository.save(newUser);
      const emailData = {
        email: user.email,
        subject: 'Welcome to Our Community',
        html: `<p>Hello ${user.username},</p>
        <p>Welcome to our community! Your account is now active.</p>
        <p>Enjoy your time with us!</p>`,
      };
      await this.emailService.sendEmail(emailData)
    return user
  }
}

Make sure to modify your modules in order to correct any dependency injection errors. In your email module file, add the EmailService to the exports array:

 providers: [EmailService],
 exports: [EmailService]

Add it below your providers to export the Email Service so it can be accessed in other modules. Then import the EmailModule to your User module file and add it to your import array like this:

@Module({
  imports: [TypeOrmModule.forFeature([User]), EmailModule],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Now it's time to test it. Get a free account from any online email testing platform and open Postman. Make a request to the create user endpoint with your valid email. You should get an email response like this:

Email response you should get

How to Integrate a Queue Service using RabbitMQ

To get started with this, you'll have to install some packages that let you implement queues using RabbitMQ. Enter the command below to install these packages:

npm install --save amqplib @types/amqplib amqp-connection-manager

Configure the Producer Service

Once installation is complete, it's time to configure RabbitMQ. You'll create a new folder in your src directory and name it queues. Then create the queue producer file. Import these packages and set them up like this:

import { HttpException, HttpStatus, Injectable, Logger } from '@nestjs/common';
import amqp, { ChannelWrapper } from 'amqp-connection-manager';
import { Channel } from 'amqplib';

@Injectable()
export class ProducerService {
  private channelWrapper: ChannelWrapper;
  constructor() {
    const connection = amqp.connect(['amqp://localhost']);
    this.channelWrapper = connection.createChannel({
      setup: (channel: Channel) => {
        return channel.assertQueue('emailQueue', { durable: true });
      },
    });
  }

  async addToEmailQueue(mail: any) {
    try {
      await this.channelWrapper.sendToQueue(
        'emailQueue',
        Buffer.from(JSON.stringify(mail)),
        {
          persistent: true,
        },
      );
      Logger.log('Sent To Queue');
    } catch (error) {
      throw new HttpException(
        'Error adding mail to queue',
        HttpStatus.INTERNAL_SERVER_ERROR,
      );
    }
  }
}

The AMQP connection was set and is running on localhost with the default RabittMQ port which is 5432. You also established a channel on that connection with an option input which is executed anytime a new channel is created. This helps if you have any configuration for that channel.

You also created an emailQueue with the assertQueue property which checks that a queue with that name does not already exist. If it does exist, it has no effect so it's idempotent.

Then you created an option durable: true to make sure that the queue will survive a server restart.

Next, you defined the method to add the email data to a queue. This calls the sendToQueue property of the channelWrapper, passing in the queue name you want to send the data to. Ideally, it should be the same name as the one you defined with the assertQueue property.

The second argument is the mail data, but firstly you converted it to a JSON string then to a Buffer. You do this because messages in RabbitMQ are mostly transmitted as binary data.

You can then set an option persistent: true to ensure that the data being sent to the queue won't be lost if the server crashes. Then with some error handling and the method to send messages to the queue, it's good to go.

Set Up the Consumer Service

Now that you've configured the producer service, it's time to set up the consumer service.

Create another file in the queue sub-folder. It's quite similar, but in this case, you will be consuming the data from the queue. Below is the configuration for the consumer service:

import { Injectable, OnModuleInit, Logger } from '@nestjs/common';
import amqp, { ChannelWrapper } from 'amqp-connection-manager';
import { ConfirmChannel } from 'amqplib';
import { EmailService } from 'src/email/email.service';

@Injectable()
export class ConsumerService implements OnModuleInit {
  private channelWrapper: ChannelWrapper;
  private readonly logger = new Logger(ConsumerService.name);
  constructor(private emailService: EmailService) {
    const connection = amqp.connect(['amqp://localhost']);
    this.channelWrapper = connection.createChannel();
  }

  public async onModuleInit() {
    try {
      await this.channelWrapper.addSetup(async (channel: ConfirmChannel) => {
        await channel.assertQueue('emailQueue', { durable: true });
        await channel.consume('emailQueue', async (message) => {
          if (message) {
            const content = JSON.parse(message.content.toString());
            this.logger.log('Received message:', content);
            await this.emailService.sendEmail(content);
            channel.ack(message);
          }
        });
      });
      this.logger.log('Consumer service started and listening for messages.');
    } catch (err) {
      this.logger.error('Error starting the consumer:', err);
    }
  }
}

First, you defined your consumer class. For this, it implements the onModuleInit interface which is provided by @nestJs/common. This specifies that the defined class should have a method named onModuleInit().

Like the name says, the method will be called automatically during the module initialization which is when the module containing this class is loaded.

In the class constructor, you added the emailService because you'll be using the sendEmail method of that class.

In the onModuleInit() method, you defined a channel. This is necessary because you need a channel to consume messages from a queue.

From this, the channel is then used to assert a queue which should be similar in name and options to what you have on your producer service. If it's not, you won't be able to listen to the queue created on the producer service.

Then you used the consume method of channel to listen and execute the message coming from the queue you have registered.

Recall that before, you had to convert the message to Buffer in order to send it into a queue. Now, you have to convert it to a JavaScript object. Then call the emailService method to send an email and pass in the converted JavaScript object as the argument of that method.

Finally, you called the ack method which is used to inform the queue that the message has been received and processed successfully in order for it to be removed from the queue.

Now that you've defined these services, create a module file and set them in the providers array. Then export the producer service because you will be calling it in another module.

import { Module } from '@nestjs/common';
import { ConsumerService } from './consumer.file';
import { ProducerService } from './producer.file';

@Module({
  providers: [ProducerService, ConsumerService],
  exports: [ProducerService],
})
export class QueueModule {}

Next up is to add the emails being sent on user registration to the queue service that you just created.

Navigate back to your user service file and make some modifications: replace the email service with the producer service as a provider in the constructor, and then call the service and the method to add to the email queue as shown below:

import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";
import { CreateUserDto } from "./dto/create-user.dto";
import { User } from "./entities/user.entity";
import { ProducerService } from "src/queues/producer.file";

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
    private producerService: ProducerService,
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    const user = await this.userRepository.save(newUser);
    const emailData = {
      email: user.email,
      subject: 'Welcome to Our Community',
      html: `<p>Hello ${user.username},</p>
        <p>Welcome to our community! Your account is now active.</p>
        <p>Enjoy your time with us!</p>`,
    };
    await this.producerService.addToEmailQueue(emailData);
    return user;
  }
}

Also in the user module file, replace the EmailModule with that of the QueueModule to avoid dependency injection errors when you start up your server.

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
import { UsersController } from './users.controller';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './entities/user.entity';
import { QueueModule } from 'src/queues/queue.module';

@Module({
  imports: [TypeOrmModule.forFeature([User]), QueueModule],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Now finally, it's time to test the user registration flow again. So navigate back to Postman and then type in a valid email and username and hit enter. On the terminal of your server running, you will see logs that were set in order to track the way the message got sent and how it was received and executed.

Logs that help you track the message

You can also open up the RabbitMQ dashboard to view queue activity on http://localhost:15672, By default the user is "guest", so enter in guest for the username and password.

RabbitMQ Queues and Streams

Here's the link to the GitHub repository. Feel free to check it out whenever you're stuck.

Conclusion

In this article you learned what a message queue is along with some major components of how they work. You also built a mini Nest.js project and implemented an email service in it. Finally, you integrated the queue service into your project, showing how it works in a real-life scenario.

Understanding message queue behaviors and patterns is an essential skill when developing scalable applications. This helps reduce lag and improves the speed and efficiency of your applications.

I hope you enjoyed reading this article. You can follow me on Twitter.

esbuild is a lightweight and efficient bundler for React apps. Here's an overview of how to use esbuild to bundle a basic React application.

How to Install esbuild Globally

We'll start by installing esbuild globally in your system by running npm install -g esbuild in the command line. This will install the latest version of esbuild globally on your system.

After installation, you can access esbuild from the command line by typing esbuild.

How to Create a New Directory for Your React Application

To create a new directory for your React application, open the terminal and navigate to the directory where you want to create the new directory. Then run the following command:

mkdir my-react-app

This will create a new directory named my-react-app. You can replace it with whatever name you want to give your React application directory.

After creating the directory, navigate into it by running:

cd my-react-app

Initialize a new npm project by running the following command and following the prompts:

npm init -y

Install React and React DOM by running npm install react react-dom in the terminal. This will install the latest versions of React and React DOM in your project, along with any required dependencies.

How to Create the Necessary Files and Folders

Let's create the necessary files and folders. Here's a basic structure:

my-react-app
├── src
|   |
│   |── index.js
├── |--- index.html
│  
└── package.json

Add the code shown below in your app, following the above structure:

index.html:

<!DOCTYPE html>
<html>

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <title>Hello, esbuild!</title>
</head>

<body>
  <div id="root"></div>
  <script src="Bundle.js"></script>
</body>

</html

The above code outlines the fundamental structure of an HTML5 web page. It starts with a declaration indicating the use of HTML5. The main structure consists of an <html> root element containing a <head> section for metadata, including character encoding and viewport settings for responsiveness.

The <title> element defines the browser tab's title, while the actual content resides in the <body> element. Within the <body>, a <div> element with the id "root" serves as a placeholder for potential dynamic content.

Additionally, there's a <script> tag pointing to an external JavaScript file named "Bundle.js," generated by esbuild, to be executed by the browser.

This structure sets the foundation for building a web page with HTML5, CSS, and JavaScript functionality.

index.js

import React from "react";
import ReactDOM from "react-dom";

function App() {
  return (
    <div>Hello, esbuild! </div>
  );
}

ReactDOM.render(<App />, document.getElementById("root"));

Our React code sets up a simple React application with a single component App. It renders a <div> element with the text Hello, esbuild! and mounts it into the DOM, specifically into the element with the id of root.

How to Create the Build Function

Let's add the following build script using the esbuild bundler in our package.json file:

"scripts": {
        "build": "esbuild src/index.js --bundle --outfile=Bundle.js --loader:.js=jsx --format=cjs"
},

This build script starts with the entry point src/index.js and proceeds to bundle all the dependencies. The resulting bundled code is saved as Bundle.js.

The script also specifies that files with the .js extension should be treated as jsx files, indicating the usage of JSX syntax.

Finally, the output format is set to CommonJS (cjs) which is the module system utilized by Node.js.

By executing this build script, the esbuild bundler will process the files, apply the necessary transformations, and generate a single bundled JavaScript file ready for deployment or further usage.

Overview of the Build Function and its Purpose

The build script using esbuild is JavaScript code that bundles your JavaScript code into a single file. This is useful for optimizing your code for production environments, reducing the number of HTTP requests needed to load your application, and improving load times.

The build method takes an options object as its argument, which allows you to configure how your code is bundled. The options object specifies properties such as entryPoints, outfile, format, bundle, and loader.

Once the build method is configured with the desired options, the build function is called, which triggers the build process. This will output a single bundled file containing all of your JavaScript code.

Finally, the build script is run by executing the script using Node.js. You can do this by updating the package.json file to include a script that runs the build script, as shown above.

Build the React app using the following command:

npm run build

Then run the app using this command:

npx http-server

Conclusion

By following these steps, you can bundle your basic React application using esbuild and have it ready for deployment or further usage. Here is the demo.

Happy coding!

The N+1 query problem is a performance issue you might face while building APIs, regardless of whether they're GraphQL or REST APIs.

In fact, this problem occurs when your application needs to return a set of data that includes related nested data – for example, a post that includes comments.

But how can you fix this problem? To avoid this issue, you should understand what is it and how it occurs.

So in this tutorial, you'll learn what the N+1 query problem is, why it is easy to fall into it, and how you can avoid it.

Before starting, it is good to know:

• The examples in this article are just for the sake of simplicity.
• SELECT * is very bad, and you should avoid it.
• You should care about pagination if you’re working with large data sets.

You can find the examples in this article in this repo. Let's dive in.

Understanding the N+1 Query Problem

The N+1 problem occurs when your application needs to return a set of data that includes related data that exists in:

• Another table.
• Another database (in the case of microservices, for example)
• Or even another third-party service.

In other words, you need to execute extra database queries or external requests to return the nested data.

If you are wondering about what the name means (N+1), follow the below example, which uses a single database:

Illustration of N+1 problem

As you can see, the relationship between Post and Comment is one-to-many, respectively.

So, if your application needs to return a list of posts and their related comments, you might end up with this code:

const posts = await rawSql('SELECT * FROM "Post"'); // Get all posts (1 database query)
for (const post in posts) {
    // For sure, you can replace the following query with an external request if you need to retrieve the post's comments from another service
    const comments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" = ${post.id}`); // Get all comments for every post (n database query for n posts)
    post.comments = comments;
}

So, you have executed N queries to retrieve every post’s comments and 1 query to retrieve all posts (N comments queries + 1 posts query).

But, why you should be aware of this problem?

Why Is the N+1 Query Problem a Serious Issue?

Here are some reasons why the N+1 query problem can cause serious performance issues in your application:

1. Your application makes a lot of database queries or external requests to retrieve a list of data like posts.
2. The more data your application retrieves, the slower your request is going to be and the more resources your application is going to consume.
3. A large data set might end up with notable network latency.
4. It is going to be challenging to scale the application to handle larger data sets.

On top of that, you are going to see the performance impact in numbers in the benchmarks section later in this article.

Now that you understand the N+1 query problem and its impact on your application, let’s introduce some effective ways you can avoid this problem.

Strategies to Avoid the N+1 Query Problem

Fortunately, there are a few simple strategies you can follow to avoid the N+1 query problem.

Let’s apply them to our previous example.

1) Eager Loading (Using SQL Joins, for example)

In this strategy, instead of returning the post’s comments separately for every post, you can use SQL Joins.

const postsAndComments = await rawSql(`
    SELECT * 
    FROM "Post"
    JOIN "Comment"
    ON "Comment"."post_id" = "Post"."post_id"
`);

When you're using this strategy, it's good to know that:

• It is only one database query to return all posts and their nested comments.
• You can't apply this strategy if you are consuming your data sets from a different database or service.

2) Batch Loading

In this strategy, your code should follow the below steps:

• Execute one request to retrieve all posts.
• Execute another request to load a batch of posts’ comments instead of loading every post’s comments separately.
• Map every comment to its corresponding parent post.

Let’s jump into an example:

const posts = await rawSql('SELECT * FROM "Post"'), // 1- Retrieve all posts in one request
    postsIds = posts.map(post => post.id),
    postsComments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" IN (${postsIds})`); // 2- retrieve all posts’ comments in another request

for (const post in posts) { // 3- Map every comment to its parent post
    const comments = postsComments.filter(comment => comment.post_id === post.id);
    post.comments = comments;
}

As you see, in this strategy, there are just two requests: one to retrieve all posts and another one to retrieve their comments.

3) Caching

You may be familiar with caching and its impact on any application's performance.

You can implement caching on your client side or server side using Redis, Memcached, or any other similar tool. Wherever you can properly use caching, it significantly pushes your application's performance.

Let’s get back to our example and cache the posts’ comments in a Redis store.

    const posts = await rawSql('SELECT * FROM "Post"'),
        postsIds = posts.map(post => post.id),
        cachedPostsComments = getPostsCommentsFromRedis(postsIds);

for (const post in posts) {
    const comments = cachedPostsComments.filter(comment => comment.post_id === post.id);
    post.comments = comments;
}

As you might guess, you can cache the posts’ comments or even the posts themselves which significantly minimizes the load on databases.

4) Lazy Loading

In this strategy, you are distributing the responsibility between the server side and the client side.

You shouldn’t return all data at once from the server side. Instead, you prepare two endpoints for the client side like this:

• GET /api/posts: Retrieves all posts.
• GET /api/comments/:postId: Retrieves a post’s comments on demand.

And now, the data retrieval is up to the client side.

This strategy is very useful because:

• It enables the client side to load the parent post first and display its content, and then load its related comments lazily. So users don't have to wait for the entire data set to be returned from the server side.
• You have full control over sorting, filtering, pagination and so on over every endpoint.

The key point of this strategy is that it gets rid of nested data like comments and flattens all data sets in their own endpoint.

5) GraphQL Dataloader

As you might guess, this strategy works with GraphQL APIs.

Dataloader is a GraphQL utility that works by batching multiple database queries into one request. So, it uses the Batch Loading strategy under the hood.

Let’s jump into our example:

const DataLoader = require('dataloader');

// 1- GraphQL Schema Definition
const typeDefs = gql`
  type Post {
    post_id: ID!
        comments: [Comment]
  }

    type Comment {
        comment_id: ID!
    post_id: ID!
  }

  type Query {
    posts: [Post]
  }
`;

// 2- Resolve the GraphQL Schema
const resolvers = {
  Query: {
    posts: async () => {
      const posts = await rawSql('SELECT * FROM "Post"');
            return posts;
    }
  },

  Post: {
    comments: (post, args, { dataLoaders }) => {
      return dataLoaders.commentsLoader.load(post.id);
    }
  }
};

// 3- Define Dataloaders
const commentsBatchFunction = async postsIds => {
      const comments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" IN (${postsIds})`);
        const groupedComments = comments.reduce((tot, cur) => {
      if (!tot[cur.post_id]) {
        tot[cur.post_id] = [cur];
      } else {
        tot[cur.post_id].push(cur);
      }
      return tot;
    }, {});
        return postsIds.map((postId) => groupedComments[postId]);
    },
    createCommentsLoader = new DataLoader(commentsBatchFunction),
    createDataloaders = () => ({
        commentsLoader: createCommentsLoader()
    });

// 4- Inject Dataloaders in the GraphQL Context
const server = new ApolloServer({
    typeDefs,
    resolvers,
    context: () => {
    return {
      dataLoaders: createDataloaders(),
    }
  }
});

So how does it work? To get more detailed information, you can check out the documentation. But we'll go through the basics here.

The key point of the Dataloader is the Batch Function. Here, the batch function commentsBatchFunction takes an array of keys postsIds and returns a Promise which resolves to an array of values comments, [ [post1comment1, post1comment2], [post2comment1], ... ].

On top of that, the batch function has two constraints:

• The size of the keys array postsIds must equal the values array comments. In other words, this expression must be true: postsIds.length === comments.length.
• Each index in the keys array postsIds must correspond to the values array comments. So you might note that I looped over the postsIds to map each corresponding comment.

As a result, you can see that GraphQL Dataloader uses the second strategy (Batch Loading) under the hood.

Let’s get back to our example to walk through its implementation:

1. First, we defined the GraphQL schema.
2. Then we resolved the GraphQL schema. Keep in mind, if you resolved the comments in the Post type using this query await rawSql('SELECT * FROM "Comment" WHERE "post_id" = ' + post.id);, you’re going to fall into the N+1 query problem.
3. Next, we defined the comments batch function and then created the comments dataloader.
4. Finally, we injected dataloaders in the GraphQL Context to be able to use them in resolvers.

So, by using GraphQL Dataloader, if you have 10 posts and every post has 5 comments, you would end up with two queries – one to retrieve the 10 posts and another one to retrieve their comments.

Take a look at the following screenshot:

Illustration of process with and without Dataloader

Benchmarks About N+1 Query Problem

In this section, let’s compare each strategy in terms of performance.

Note that the results of the Cache strategy are coming just after caching the data set. The first query is ignored as caching is missed.

These results were generated from the following environment:

• Seeded data: 1000 posts and 50 comments for every post.
• CPU: AMD Ryzen 5 3600 6-Core Processor 3.60 GHz.
• RAM: 32.0 GB.
• OS: Windows 10 Pro.

To be able to retest these strategies in your environment, follow these steps:

• Clone this repo.
• Then run docker-compose up.
• For GraphQL, open http://localhost:3000/graphql.
• A query suffers from the N+1 problem: query only commentsWithNPlusOne in the Post type.
• Dataloader strategy: query only commentsWithDataloader in the Post type.
• For REST, follow these endpoints:
• A query suffers from the N+1 problem: http://localhost:3000/api/postsWithNPlusOne.
• Eager Loading strategy: http://localhost:3000/api/postsWithEagerLoading.
• Batch Loading strategy: http://localhost:3000/api/postsWithBatchLoading.
• Caching strategy: http://localhost:3000/api/postsWithCache.

My notes about these benchmarks:

• These strategies are way too efficient.
• You may notice that the slower strategy in REST, the Eager Loading strategy, is about 34 times faster than the N+1 query in the REST API.
• The Dataloader strategy is about 6.4 times faster than the N+1 query in the GraphQL API.
• If you compared the results of REST and GraphQL APIs, you may notice that REST is faster than GraphQL. I think this is because of the internal implementations of GraphQL, which makes sense.

Conclusion

In this article, you learned that the N+1 query problem is a performance issue you might encounter when working with APIs.

You then learned about some strategies you can follow to avoid this problem like:

• Eager Loading using SQL Joins
• Batch Loading by executing fewer requests and then mapping each corresponding item to its parent.
• Caching using Redis
• Dataloader in the GraphQL world.

Finally, we created some benchmarks about the N+1 query problem so we could see how efficiently these strategies improve our API performance.

Before you leave

If you found this article useful, you can check out some of my other articles on my personal blog as well.

Thanks a lot for staying with me up till this point. I hope you enjoy reading this article.

In some recent tutorials, I covered supporting file uploads on the front end, supporting file uploads on the back end, and optimizing costs by moving file uploads to object storage.

Today, I'll continue to focus on more architectural work, but this time it’ll be focused on optimizing performance.

Overview of Object Storage Solution

Let's say we have an application that stores uploaded files somewhere in the world. For this example, it’s an Object Storage bucket from Akamai cloud computing services, and I've deployed it to the us-southeast-1 region.

You may be using a different provider and different region, but the following points will still apply.

So when I upload a cute photo of Nugget making a big ol’ yawn, I'll be able to access it at some URL like austins-bucket.us-southeast-1.linodeobjects.com/files/nugget.jpg

Nugget is a super cute dog. Naturally, a lot of people are going to want to see this. Unfortunately, because this photo is hosted in the us-southeast-1 region, anyone that lives far away from that region has to wait longer before their eyes can feast on this beast.

Latency sucks.

And that’s why CDNs exist.

What is a CDN?

CDN stands for "content delivery network". It’s a connected network of computers that are globally distributed and can store copies of the same files so that when a user makes a request for a specific file, it can be served from the nearest computer to the user.

By using a CDN, the distance a request must travel is reduced. This helps resolve requests faster, regardless of a user’s location.

Here’s a webpagetest.org test results for that photo of Nugget. The request was made from their servers in Japan, and it took 1.1 seconds for the request to complete.

Instead of serving the file directly from my Object Storage bucket, I can set up a CDN in front of my application to cache the photo all over the world.

So users in Tokyo will get the same photo but served from their nearest CDN location (which is probably in Tokyo), and users in Toronto are going to get that same file, but served from their nearest CDN location (which is probably in Toronto).

This can have significant performance implications.

Let’s look at that same request, but served behind a CDN. The webpagetest.org results still show the same photo of Nugget, and the request still originated from Tokyo, but this time it only took 0.2 seconds – a fraction of the time!

When the request is made for this image, the CDN can check if it already has a cached version. If it does, it can respond immediately. If it doesn’t, it can go fetch the original file from Object Storage, then save a cached version for any future requests.

Note: the numbers reported above are from a single test. They may vary depending on network conditions.

The Compounding Returns of CDNs

The example above focused on improving delivery speeds of uploaded files. In that context, I was only dealing with a single image that is uploaded to an Object Storage bucket. It shows almost a full second improvement in response times, which is great, but things get even better when you consider other types of assets.

CDNs are great for any static asset (CSS, JavaScript, fonts, images, icons, and so on). By putting it in front of my application, all the other static files can automatically get cached as well. This includes the files that Nuxt.js generates in the build process, and which are hosted on the application server.

This is especially relevant when you consider the “Critical rendering path” and render-blocking resources like CSS, JavaScript, or fonts.

When a webpage loads, as the browser comes across a render-blocking resource, it will pause parsing and go download the resource before it continues (hence “render-blocking”). So any latency that affects a single asset may also impact the performance of other assets further down the network cascade.

This means the performance improvements from a CDN are compounding. Nice!

So is this about showing cute photos of my dog to more people even faster, or is it about helping you make your applications run faster? YES!

Whatever motivates you to build faster websites, including a CDN as part of your application infrastructure is a crucial step if you plan on serving customers from more than one region.

How to Connect Akamai CDN to Object Storage

Now I want to take a little side-quest and share how I set up Akamai with Object Storage. I didn’t find much information on the subject, and I’d like to help anyone in this specific situation. If it doesn’t apply to your use case, feel free to skip this section.

With something like 300,000 servers across 4,000 locations, Akamai is the largest CDN provider in the world. It’s used by some of the biggest companies in the world, but it’s hard to find Akamai-related content because most large companies don't like to share unnecessary information about their infrastructure.

But I'm not most companies :)

(Note: You will need an Akamai account and access to your DNS editor)

In the Akamai Control Center, I created a new Property using the Ion Standard product, which is great for general purpose CDN delivery.

After clicking “Create Property”, you’ll be prompted to choose whether to use the setup wizard to guide you through creating the property, or you can go straight to the Property Manager settings for the new property. I chose the latter.

In the Property Manager, I had to add a new hostname in the Property Hostnames section. I added the hostname for my application. This is the URL where users will find your application. In my case, it was uploader.austingil.com.

Part of this process also requires setting up an SSL certificate for the hostname. I left the default value selected for Enhanced TLS.

With all that set up, Akamai will show me the following Property Hostname and Edge Hostname. We’ll come back to these later when it’s time to make DNS changes.

• Property Hostname: uploader.austingil.com
• Edge Hostname: uploader.austingil.com-v2.edgekey.net

Next, I had to set up the actual property’s behavior, which meant editing the Default Rule under the Property Configuration Settings. Specifically, I had to point the Origin Server Hostname to the domain where my origin server will live.

In my DNS, I created a new A record pointing origin-uploader.austingil.com to my origin server’s IP address, then added a CNAME record that points uploader.austingil.com to the Edge Hostname provided by Akamai.

• A: origin-uploader.austingil.com -> origin server IP
• CNAME: uploader.austingil.com -> uploader.austingil.com-v2.edgekey.net

This lets me build out my CDN configuration and test it as needed, only sending traffic through the CDN when I’m ready.

Finally, to serve files in my Object Storage instance through Akamai, I created a new rule based on the blank rule template. I set the rule criteria to apply to all requests going to the /files/* sub-route.

The rule behavior is set up to rewrite the request’s Origin Server Hostname and change it to my Object Storage location: npm.us-southeast-1.linodeobjects.com.

This way, any request that goes to uploader.austingil.com/files/nugget.jpeg is served through the CDN, but the file originates from the Object Storage location. And when you load the application, all the static assets generated by Nuxt are served from the CDN as well. All other requests are passed through Akamai and forwarded to origin-uploader.austingil.com, which points to the origin server.

So that’s how I’ve configured Akamai CDN to sit in front of my application. Hopefully, it all made sense, but if you have questions, feel free to ask me.

To Sum Up

Today we looked at what a CDN is, the role it plays in reducing network latency, and how to set up Akamai CDN with Object Storage.

But this is just the tip of the iceberg. There’s a whole world of tweaking CDN configuration to get even more performance.

There are also a lot of other performance and security features a CDN can offer beyond just static file caching: Web Application Firewalls, faster network path resolution, DDoS protection, bot mitigation, edge compute, automated image and video optimization, malware scanning, request security headers, and more.

My colleague Mike Elissen also covers some great security topics on his blog.

The most important thing that I wanted to convey today is that using a CDN improves file delivery performance by caching content close to the user.

Thank you so much for reading. If you liked this article, and want to support me, the best ways to do so are to share it, sign up for my newsletter, and follow me on Twitter.

You can find this and my other articles published on austingil.com.

React is a popular JavaScript library for building user interfaces. As applications built with React become more complex, their performance can start to degrade.

Poor performance can lead to a frustrating user experience and a negative impact on user engagement. So in this article, we will discuss how to measure and improve the performance of a React application.

Table of Contents

• How to define performance

• How to measure performance

  • React dev tools

• How to improve performance

  • Optimizing images

  • Code splitting and Lazy Loading

  • Optimizing the DOM

  • Avoid unnecessary component re-renders

  • Rendering patterns

  • CDNs

• Wrapping Up

How to Define Performance

In web development, "performance" generally refers to the speed and efficiency of a website or web application. It encompasses several different factors, including:

1. Page load time: This refers to the time it takes for a page to fully load and display all of its content. Faster load times generally lead to a better user experience.

2. Responsiveness: This refers to the speed at which a website responds to user interactions, such as clicking a button or scrolling. A responsive website feels snappy and quick, which can also improve user experience.

3. Resource usage: This refers to the amount of server resources (such as CPU and memory) that a website uses to serve pages and respond to requests. A well-optimized website will use resources efficiently, allowing the server to handle more traffic and reducing costs.

4. Scalability: This refers to a website's ability to handle increased traffic and load without sacrificing performance. A scalable website can handle sudden spikes in traffic without slowing down or crashing.

Optimizing website performance is important because it can directly impact user experience, search engine rankings, and even business revenue.

How to Measure Performance

The first step in improving the performance of a React application is to measure its current performance. There are several tools available for measuring performance, including:

1. Lighthouse – Lighthouse is an open-source tool from Google that audits web pages for performance, accessibility, and more. Lighthouse generates a report that includes suggestions for improving the performance of the application.

2. WebPageTest – WebPageTest is a free tool that allows you to test the speed of your website from multiple locations around the world. WebPageTest provides detailed reports on the performance of your website, including suggestions for improvement.

3. Google PageSpeed Insights – Google PageSpeed Insights analyzes the content of a web page and generates a report that identifies opportunities to improve the page's performance.

All three tools work basically in the same way. You provide the URL of the site you'd like to analyze, and the tools will run through it and provide you with a detailed report covering improvement opportunities in performance, and also accessibility, SEO and general best practices.

These tools are nice to get an objective measure of our apps. Some of them can even be integrated into CI/CD pipelines so we can monitor how changes impact in performance through time.

React dev tools

Another useful tool for measuring performance in a React app is the profiler of React DevTools. React DevTools is a browser extension that allows you to inspect and debug React applications in the Chrome, Firefox, or Edge browsers.

The "profiler" is a tool that allows you to record the activity in your app, and later on generate a report showing what components were rendered, how many times and when each component was rendered, and how long each render took.

It's quite useful for detecting unnecessary component re-renders and renders that take too long, generating performance bottlenecks.

If you'd like to get a deeper dive into how profiler works, I recommend this video.

How to Improve Performance

Now that we have an idea of how can we identify performance issues in our app, let's go through some of the optimization techniques we can use to make it better.

Optimizing Images

Images are one of the primary culprits for slow loading websites. You can optimize images by compressing them without compromising their quality. Tools like tinyPng can compress your images and help you reduce the size of your website, and therefore it's load time.

Meta frameworks such as Next come with built-in image optimization.

Code splitting and Lazy Loading

Lazy loading involves loading content only when it is needed, instead of loading everything at once. This is done through something called "code splitting". This is a bundling technique that allows you to break up code in smaller chunks that are downloaded only when needed, instead of downloading the whole code in the first render.

A classic example of when this technique can come in handy is when navigating through different routes. Let's say our website has two main routes, "Home" and "Contact".

We'd only want to download the code related to the "Home" page when we're in that route, and the "Contact" code to download when we are in that other route. Code splitting allows us to do that, and in this way help reduce the initial load time of the application and improve the user experience.

You can use tools such as React.lazy() and Suspense to implement lazy loading in your application. If you'd like a deeper dive into how these tools work, check out this video.

Optimizing the DOM

The size of the Document Object Model (DOM) can impact the performance of the application. The bigger and more complex it is, the longer it'll take to load and be modified.

You can optimize the DOM by reducing the number of elements, removing unnecessary elements, and minimizing the use of CSS animations.

Avoid unnecessary component re-renders

As you may know, React is a library that allows us to build user interfaces. In React, each piece of the UI is represented in code by a component. When a piece of the UI needs to be modified, React re-renders the component with the updated information.

There are two things that trigger a component re-render: A change in state or a change in props. But sometimes, components can re-render unnecessarily, meaning there's no actual change in the information to be displayed.

To prevent unnecessary re-renders, we can implement some of the following techniques:

• Memoization: In React, memoization allows a component to "remember" the value of the state and/or props it receives. Before re-rendering, it can check if the value has actually changed. If it hasn't, then it doesn't re-render. This technique can be achieved through hooks like useMemo and useCallback. If you'd like a deeper dive on that, check out this article I wrote.

• Use key prop for lists: When rendering a list of items in React, it's important to provide a unique key prop for each item. This helps React identify which items have changed and need to be re-rendered. If you don't provide a key prop, React will use the index of the item in the array, which can lead to unnecessary re-renders if the order of the items changes.

• Keeping state as local as possible: By keeping state local, I mean that the state that a component uses should be (when possible) within the component itself or as close in the component tree as possible. This is because when a component re-renders, all children components will re-render as well. It's not necessarily a terrible thing, but if we can avoid it, we probably should. So It's not a good idea to centralize all state in a single parent component, unless that states needs to be used from multiple parts of the application down the component tree. Here's a great article about this topic if you're interested in learning more.

Rendering patterns

Another thing that can have an impact on the performance of your app is the rendering pattern it uses. A rendering pattern refers to the way in which the HTML, CSS, and JavaScript code is all processed and rendered in a web application or website.

Different rendering patterns are used to achieve different performance and user experience goals. The most common rendering patterns in web development are:

1. Client-side rendering (CSR): In CSR, the client's browser generates the HTML content of a web page on the client-side using JavaScript. This approach can provide a fast and interactive user experience but can be slower for initial loading times and bad for SEO.

2. Server-side rendering (SSR): In SSR, the web server generates the HTML content of a web page on the server-side and sends it to the client's browser. This approach can improve initial loading times and SEO (search engine optimization) but can be slower for dynamic content.

Server-Side Rendering (SSR) can help improve the initial load time of the application by rendering the initial page on the server-side. This can help improve the Time-to-Interactive (TTI) and First Contentful Paint (FCP) metrics. You can use tools such as Next.js or Gatsby to implement SSR in your application.

The choice of rendering pattern depends on the specific needs and requirements of a project, such as performance, SEO, user experience, and flexibility. If your priority is to provide users with a fluid, native-like experience, CSR is probably a good choice. If you need ultra fast page load times, SSR or SSG can be a better option.

For a deeper dive into rendering patterns, check out this article I recently wrote.

Content Delivery Network (CDN)

A CDN, or Content Delivery Network, is a system of distributed servers or nodes that work together to deliver web content, such as images, videos, and other files, to users based on their geographic location.

When a user requests content from a website, the CDN will serve the content from the server closest to the user, which helps to reduce latency and improve website performance. CDNs can also help to reduce the load on a website's origin server by caching frequently accessed content and delivering it from the CDN's servers instead of the origin server.

CDNs are normally used to host static content (meaning content that doesn't change frequently over time), such as images, videos, blog posts and so on. Also, if you're using Static Site Generation (SSG) as a rendering pattern, you could host your rendered sites in a CDN for an even faster delivery.

Some examples of popular CDNs are Cloudflare and Amazon CloudFront.

For more detail on how CDNs work, check out this awesome video.

Wrapping Up

Well everyine, in this article we've discussed how to measure and improve the performance of a React application.

We defined the concept of website performance, including page load time, responsiveness, resource usage, and scalability, and outlined how to measure performance using tools such as Lighthouse, WebPageTest, Google PageSpeed Insights and React dev tools.

Finally, we've seen some optimization techniques such as optimizing images, code splitting and lazy loading, optimizing the DOM, and avoiding unnecessary component re-renders.

As always, I hope you enjoyed the article and learned something new.

If you want, you can also follow me on LinkedIn or Twitter. See you in the next one!

Next.js is a popular React-based web framework that has gained popularity and a growing community in recent years. It's a powerful tool for building fast and SEO-friendly web applications with dynamic pages that work great on mobile devices.

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: , <meta>, <link> (with the precedence attribute) or <script> (with the async attribute).</p> <p>Next never fully fleshed out this component, which is why most developers baked up custom implementations for adding structured data to the mix. Although, a bit later on Next did start recommending that structured data be added into the layout or page component instead, which we’ll go over a bit later.</p> <p>This component became deprecated in version 13.2, and the Vercel team moved on to the <strong>Metadata</strong> component.</p> <h3 id="heading-the-next-metadata-component">The Next Metadata Component</h3> <p>With the release of Next version 13.2, Next decided to opt out of a head component altogether, and instead created the <strong>Metadata</strong> component. </p> <p>At the time of writing, there isn’t a whole lot of material out there for usage examples and such. In fact, 13.2 hasn’t even been released, and we’re only up to 13.1.7-canaray at the moment.</p> <p>Nonetheless, Next has a decent write-up in their documentation, so we’ll go over the usage and give a basic analysis. It’s important to be informed on this if you plan on being on top of Next.js SEO, because it’s coming down the pipe.</p> <p>The Metadata component aims to be the one-stop shop for populating the <strong>head</strong> tag with title and description and other dynamic metadata in an efficient and easy to use manner. The usage is really quite simple, and involves exporting either an object called <strong>metadata</strong> or a function called <strong>generateMetadata</strong> from the page component itself.</p> <p>Let’s take a look at a basic usage example:</p> <h3 id="heading-nextjs-export-metadata-example">Next.js export metadata Example</h3> <p><strong>examplePage.tsx</strong></p> <pre><code class="lang-js"><span class="hljs-keyword">import</span> type { Metadata } <span class="hljs-keyword">from</span> <span class="hljs-string">'next'</span>; <span class="hljs-keyword">export</span> <span class="hljs-keyword">const</span> metadata: Metadata = { <span class="hljs-attr">title</span>: <span class="hljs-string">'Example component'</span>, <span class="hljs-attr">description</span>: <span class="hljs-string">'Learning Next.js SEO'</span>, }; <span class="hljs-keyword">export</span> <span class="hljs-keyword">default</span> <span class="hljs-function"><span class="hljs-keyword">function</span> <span class="hljs-title">Page</span>(<span class="hljs-params"></span>) </span>{ <span class="hljs-keyword">return</span> ( <span class="xml"><span class="hljs-tag"><></span> <span class="hljs-tag"><<span class="hljs-name">div</span>></span>Example page component…<span class="hljs-tag"></<span class="hljs-name">div</span>></span> ) <span class="hljs-tag"></></span></span> } </code></pre> <p>This will automatically populate the <strong>examplePage.tsx</strong> component with the proper HTML meta tags and given values.</p> <p>The <strong>metadata</strong> component offers a set of default tags as well, which automatically sets the following <strong>charset</strong> and <strong>viewport</strong> meta tags:</p> <pre><code class="lang-js"> <meta charset=<span class="hljs-string">"utf-8"</span> /> <span class="xml"><span class="hljs-tag"><<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"viewport"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"width=device-width, initial-scale=1"</span> /></span></span> </code></pre> <h3 id="heading-nextjs-export-generatemetadata-example">Next.js export generateMetadata Example</h3> <p>In many applications, especially ecommerce, you’ll run across the need to dynamically populate meta tags, and ensure that this data always reflects changes to a database or some other store of data.</p> <p>For cases such as these, Next offers the <strong>generateMetadata</strong> function, which can be exported from any page component along with any necessary API calls to fetch and inject the desired data.</p> <p>Here’s an example page component that utilizes this method:</p> <p><strong>pageExample.tsx</strong></p> <pre><code class="lang-js"><span class="hljs-keyword">import</span> type { Metadata } <span class="hljs-keyword">from</span> <span class="hljs-string">'next'</span>; <span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">function</span> <span class="hljs-title">getInfo</span>(<span class="hljs-params">id</span>) </span>{ <span class="hljs-keyword">const</span> res = <span class="hljs-keyword">await</span> fetch(<span class="hljs-string">`https://someapi/product/<span class="hljs-subst">${id}</span>`</span>); <span class="hljs-keyword">return</span> res.json(); } <span class="hljs-keyword">export</span> <span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">function</span> <span class="hljs-title">generateMetadata</span>(<span class="hljs-params">{ params }</span>): <span class="hljs-title">Promise</span><<span class="hljs-title">Metadata</span>> </span>{ <span class="hljs-keyword">const</span> product = <span class="hljs-keyword">await</span> getInfo(params.id); <span class="hljs-keyword">return</span> { <span class="hljs-attr">title</span>: product.title } } <span class="hljs-keyword">export</span> <span class="hljs-keyword">default</span> <span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">function</span> <span class="hljs-title">Page</span>(<span class="hljs-params"></span>) </span>{ <span class="hljs-keyword">return</span> ( <span class="xml"><span class="hljs-tag"><<span class="hljs-name">div</span>></span>Example page…<span class="hljs-tag"></<span class="hljs-name">div</span>></span></span> ) } </code></pre> <p>As you can see, we created a method that returns some information about a product from an API, and used that method in our <strong>generateMetadata</strong> function to then populate the <strong>title</strong> property. This in turn will set the title tag in our rendered HTML page.</p> <p>It’s important to note that the <strong>generateMetadata</strong> function can only be used within server components, which we discussed earlier. Remember, all components within the <strong>app</strong> directory are automatically configured as server components by default.</p> <p>For an exhaustive list of properties and property extensions available with the <strong>Metadata</strong> component, take a look at the <a target='_blank' rel='noopener' href="https://beta.nextjs.org/docs/api-reference/metadata">docs</a>. Pretty much anything you can think of can be accomplished with relative ease.</p> <h2 id="heading-how-to-implement-structured-data-with-next-13">How to Implement Structured Data With Next 13</h2> <p>Next recommends adding structured JSON-LD data to the layout or page component. In all honesty, this has always been a much simpler solution because Google has never said anything about excluding structured data from the page itself.</p> <p>In fact, this has long been a common practice, and it’s a bit of a mystery as to why many developers have become fixed on the idea of placing it in the head tag.</p> <h3 id="heading-how-to-add-structured-data-to-the-layout-or-page-component">How to Add Structured Data to the Layout or Page Component</h3> <p>Adding structured data to a component, whether the layout or page, looks something like this (example pulled straight from the docs):</p> <pre><code class="lang-js"><span class="hljs-keyword">export</span> <span class="hljs-keyword">default</span> <span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">function</span> <span class="hljs-title">Page</span>(<span class="hljs-params">{ params }</span>) </span>{ <span class="hljs-keyword">const</span> product = <span class="hljs-keyword">await</span> getProduct(params.id); <span class="hljs-keyword">const</span> jsonLd = { <span class="hljs-string">'@context'</span>: <span class="hljs-string">'https://schema.org'</span>, <span class="hljs-string">'@type'</span>: <span class="hljs-string">'Product'</span>, <span class="hljs-attr">name</span>: product.name, <span class="hljs-attr">image</span>: product.image, <span class="hljs-attr">description</span>: product.description }; <span class="hljs-keyword">return</span> ( <span class="xml"><span class="hljs-tag"><<span class="hljs-name">section</span>></span> {/* Add JSON-LD to your page */} <span class="hljs-tag"><<span class="hljs-name">script</span> <span class="hljs-attr">type</span>=<span class="hljs-string">"application/ld+json"</span>></span><span class="javascript">{<span class="hljs-built_in">JSON</span>.stringify(jsonLd)}</span><span class="hljs-tag"></<span class="hljs-name">script</span>></span> {/* ... */} <span class="hljs-tag"></<span class="hljs-name">section</span>></span></span> ); } </code></pre> <p>As you can see, this is super simple, and there’s really no need to complicate things by attempting to inject structured data into the head tag.</p> <h2 id="heading-nextjs-seo-wrapping-things-up">Next.js SEO – Wrapping Things Up</h2> <p>We went over quite a bit here for <a target='_blank' rel='noopener' href="https://www.ohmycrawl.com/next-js-seo/">Nextjs SEO</a>. From the new features included with Next 13 that aim to solve many SEO related problems, to old features being revamped and streamlined for a better developer experience, things are looking great for Next.</p> <p>If you plan on using Next.js as your framework of choice, I highly recommend experimenting with Next 13. Although features such as the Font component are still in beta, and the whole thing is still in canary (testing phase), much of version 13 is already considered stable and being used by many developers and the world's leading companies.</p> <p>Major version updates can be daunting, but make sure to read the full documentation and give it a spin in order to ensure you’re staying at the cutting edge of Next.js SEO. </p>