Optimization

Optimization of your Catalyst storefront falls into two major categories:

• Resource utilization: Optimizing CPU usage and reducing total inbound and outbound network requests is important for making your storefront scalable to high traffic scenarios, as well as managing cost on cloud hosting providers that implement usage-based billing.
• Page performance: Your storefront should implement an optimized strategy for the frontend user experience, with critical page data loading as fast as possible.

Catalyst includes optimizations for both. This page covers the built-in mechanisms Catalyst uses, practices to follow in your own customizations, and other considerations for optimizing your storefront.

Next.js Data Cache

Fetching data from external web APIs can be one of the most expensive processes in a web application, both from a resource utilization and page performance perspective. This is particularly relevant for a headless frontend like Catalyst, which is powered exclusively by data fetched in this way.

Catalyst uses the Next.js Data Cache to avoid duplicate API requests, and you should use it in your own requests where you can. See Caching for how to configure it.

BigCommerce CDN for images

Next.js transforms images with its Image component. However, depending on your hosting provider, image transformation may come with its own utilization costs.

Every BigCommerce store includes a CDN that can handle image transformations instead of your host’s infrastructure. Catalyst combines common Next.js patterns with this BigCommerce CDN, avoiding extra image transformation costs.

Use the Catalyst <Image> component for all BigCommerce-sourced images, and consider hosting any static images in your store’s WebDAV storage. See CDN and Images for how this works.

KV storage for route caching

The withRoutes proxy resolves SEO-friendly URLs, such as /fancy-high-top, to the Next.js route that renders them. Each lookup is an additional blocking API request, so Catalyst caches the results in a KV store. Production deployments should use a shared KV store:

Suspense and streaming

A key strategy for optimizing page performance is to display the most critical content to a user as soon as possible, streaming in less critical content without blocking the initial page render.

<Suspense> in React supports this pattern by displaying a fallback until a component is fully rendered, and React Server Components in Next.js make it possible to use this pattern with server-rendered content.

In this example, <Suspense> wraps a component that handles its own data fetching:

async function OuterComponent() {
  return (
    <>
      ...
      <Suspense fallback={<FallbackComponent />}>
        <DataFetchingComponent />
      </Suspense>
    </>
  );
}

Catalyst enhances the capabilities of <Suspense> with the custom <Stream> component, which is useful when a component relies on data fetching outside itself. <Stream> makes it possible to write clean component props that don’t need to be concerned with whether data is being fetched asynchronously.

In this example, <Stream> renders products that the parent component fetches:

async function OuterComponent() {
  const streamableProducts = Streamable.from(async() => {
    return await fetchProducts();
  });
  return (
    <>
      <Stream fallback={<FallbackComponent />} 
        value={streamableProducts}>
      
        {(products) => (    
          <ProductsComponent products={products} />
        )}
      </Stream>
    </>
  );
}
function ProductsComponent({
  products
}: {
  products: Product[];
}) {
  ...
}

Firewall configuration

Blocking unwanted traffic, such as bots, before it reaches your application reduces your storefront’s resource utilization. Many hosting providers offer firewall rules that block bot traffic or apply rate limiting.

For Vercel, see the documentation on WAF Managed Rulesets and WAF Custom Rules.