Next.js Commerce

Commerce is where the Next.js rendering model earns its keep, and where getting it wrong is most expensive. A product page that takes three seconds does not convert, and every storefront template we have inherited made the same architectural choice: one use client at the top, because the cart needs state.

That decision makes the catalogue - the part that should be static, cached at the edge and indexed - as dynamic as the checkout.

How we split it

The catalogue is static. Product pages, collections and search landing pages are generated at build or revalidated by tag when the backend says something changed. They come off the CDN, they are indexable, and their LCP does not depend on your commerce API being awake.

The cart is a client island. A small component, not a boundary around the page. Quantity, mini-cart and add-to-cart are interactive; the product description, images, reviews and structured data around them are not, and stay on the server.

Prices and stock are the exception, handled deliberately. They cannot be stale, and they also cannot be allowed to make the page dynamic. Either they stream in behind Suspense while the rest of the page paints, or they are tag-revalidated on the backend's webhook. Which one depends on how often your prices actually move - we will ask rather than assume.

Checkout stays where it is. If you are on Shopify, the hosted checkout is PCI-compliant, converts well and is not worth rebuilding. We integrate up to it. A custom checkout is a project of its own and we will tell you when it is not justified - and when it is, it is built on a division of trust that does not include the browser, with a return page that survives the redirect.

What we do about the parts that decide revenue

Product structured data with real Offer and availability, so rich results show a price. Correct canonicals across variant and filter URLs - a faceted catalogue generates thousands of near-duplicate addresses, and left alone they spend your crawl budget on parameter combinations nobody searches for.

Core Web Vitals treated as a commerce metric rather than an engineering one, measured on the templates that carry traffic, with a budget enforced in CI so the next theme change does not undo it.

Which backend

Shopify (Storefront API), Commerce Layer, Medusa, BigCommerce, or your own service. The storefront architecture is the same in each case; what differs is the data layer, and that is the part we type and cache carefully.

If you are on Shopify's own themes and considering a headless storefront, the honest answer is that it is worth it when you have a real front-end team or us, and not worth it when you do not. A Liquid theme maintained well beats a headless storefront nobody owns.

How an engagement runs

We start from revenue rather than architecture. Which templates carry the traffic, where the funnel loses people, and what the current platform makes impossible.

The scope that follows names the backend, the template list, the URL map with its redirect plan, and the performance budget, priced per phase. It is signed before the build begins. The URL map in particular is agreed up front, because a replatform that discovers its redirects late has already lost the rankings.

Then the build, deployed per phase, with the budget enforced in CI from the first one.

What you receive

The storefront, the typed data layer against your commerce backend, the URL map with its redirects, and the performance budget running in CI on the templates that carry traffic.

Also the parts nobody demos: the cache strategy per template written down, what the page does when the backend is slow or down, and the faceting rules that decide which parameter combinations a crawler is allowed to reach.

The two numbers that move commerce revenue live on the templates carrying the traffic. LCP, which on a product page is almost always the image. And the rest of Core Web Vitals, measured on real visitors and not in a lab. Facets, pagination and parameter URLs are the other half, and keeping them out of the index is structural, not a setting.