Yuvraj Raulji | Next.js
Next.js is the default way to build a decoupled storefront in React, and choosing it settles far less than people expect. What decides whether the result is fast is the rendering tier each template sits in, what invalidates the cache, and how much the GraphQL boundary is asked to return. Teams that get those three right succeed on any framework. Teams that do not are slower than the theme they replaced.
Quick answer
Next.js is a React framework used to build storefronts that are decoupled from the commerce platform behind them. It matters for commerce because it gives you a rendering choice per template: a product page can be built at deploy time and revalidated when the product changes, while cart and account render per request. That choice, not the framework itself, is what makes a headless storefront fast. It connects to Shopify through the Storefront API and to Magento through GraphQL, and the same rendering rules apply to both.
Best suited for
- A decoupled storefront over Shopify or Magento
- A front end that has to release independently of the commerce platform
- Content and commerce served from one application
- Core Web Vitals that the platform theme cannot reach
Business problems
The symptom as the person with the problem describes it, what it is costing, and where the technology actually helps.
The Next.js build is slower than the theme it replaced
The central promise of the project is visibly unmet, and every future front-end investment is now under suspicion. It is the most common way a headless rebuild loses its budget.
Opportunity
Almost always too much rendering per request. Moving templates into a cached tier that revalidates on commerce events is configuration rather than a rewrite, and it is where the recoverable time is.
Nobody can say what is cached, or for how long
Stale prices and stock, and a team afraid to touch caching in case something breaks. Cache behaviour nobody can reason about becomes cache behaviour nobody changes.
Opportunity
Invalidation driven by webhooks on price, stock and publish, so the rule is legible: this event clears these pages. Time-based revalidation is a guess, and on a catalogue it is wrong in both directions at once.
GraphQL returns far more than the page shows
Paid for twice, by the storefront waiting and the commerce platform working. It is invisible in the browser, which is why it survives so long.
Opportunity
A boundary designed around what each template renders rather than mirroring the platform schema. Fixing it improves the storefront and the backend in the same change.
Rankings moved after the rebuild, and the URLs did not
Canonical tags, internal linking, heading structure and structured data are all regenerated by the new templates, so markup changes even when the address does not. It is easy to miss because nothing looks broken.
Opportunity
A deliberate diff of the rendered markup against the template it replaced, per template, before the traffic moves.
Approach
Five stages, in this order, on every engagement. Skipping the first one is the most expensive habit in this industry.
Understand
BottleneckChannelsTeamRoadmap
What is actually being waited on, and whether a decoupled front end is the answer to it. This step ends some projects, and that is a cheaper outcome than the alternative.
Architect
Rendering tiersInvalidationAPI boundaryPreview
Static, cached and revalidated, or per request, chosen per template rather than site wide. Then the events that invalidate each tier and the query shape each template needs. Everything downstream inherits this.
Build
TemplatesCart and checkoutSearchAnalytics
Including everything third party that lived in the old theme: consent, reviews, on-site search, personalisation and A/B tooling. The forgotten ones are found by marketing after launch.
Optimize
Core Web VitalsBundle budgetsImagesCache hit rate
Field data by template, cache hit rate on a dashboard, and route-level bundle budgets enforced in the pipeline. A budget nobody enforces is a preference.
Scale
Failure modesMulti-channelHandoverRelease cadence
A timeout and a fallback for every third-party call, so the storefront loses a widget rather than a page, and enough documentation that the team can add a template without asking.
Capabilities
Rendering
- Static generation
- Incremental revalidation
- Server components
- Edge and CDN caching
Commerce data
- Shopify Storefront API
- Magento GraphQL
- WooCommerce REST
- Query shape and over-fetch
Performance
- Core Web Vitals
- Bundle budgets
- Image pipeline
- Font loading
- Layout stability
Search
- Rendered markup parity
- Canonicals and pagination
- Structured data
- Sitemaps and redirects
AI and technology
What each application does, how it works, where the value is, where a person still reviews it, and what it will not do.
Semantic search over the catalogue
- What it does
- On-site search that reads a query as a goal rather than matching it against product titles.
- How it works
- Embeddings over product text and attributes, queried from the storefront and blended with the keyword index so SKUs and part numbers still match exactly. In a decoupled front end this sits behind the same API boundary as everything else.
- Where the value is
- No-result rate and conversion on search sessions, which is where customers who have already decided to buy go missing.
- Where a human reviews
- A merchandiser reviews the failing queries. The gaps they expose are usually a buying decision rather than a search one.
- What it will not do
- It amplifies the catalogue it is given. Thin product data produces confident, thin results, whatever the front end is built in.
Architecture
How the pieces sit together, top to bottom. Only technologies actually used appear here.
Customer
Web and mobile, and any second channel the same commerce data has to serve.
BrowserPWA
Storefront
The Next.js application: templates, rendering tiers and the cache that makes them fast.
Next.jsReactServer components
Edge
Where the cached tiers are served from, and where invalidation lands.
CDNEdge cacheRevalidation
Commerce APIs
The boundary the storefront reads through. Designed around templates, not mirrored from the schema.
Storefront APIGraphQLREST
Commerce platform
Catalogue, pricing, cart and orders. Still the system of record.
ShopifyMagento 2WooCommerce
Content
Editorial served by the same application, with preview that does not bypass the cache design.
Headless CMSDraft mode
When to use it
Good fit
- Front-end work genuinely blocked behind commerce releases
- One commerce backend serving more than one channel
- An experience the platform theme cannot express
- A team that will own rendering and caching afterwards
Think twice
- A slow theme, which is usually cheaper to fix than to replace
- No second channel and no blocked release cycle
- Nobody to own the deployment and cache once it ships
- A rebuild being run at the same time as a platform migration
Comparison
A well-built theme beats a badly configured decoupled storefront comfortably, and most stores asking for this want the theme fixed. The comparison only starts once the release cycle is genuinely the constraint.
| Criterion | Next.js | Platform theme | Hydrogen |
|---|---|---|---|
| Release cycle | Independent of the platform | Tied to the platform | Independent, Shopify only |
| Rendering control | Per template, yours | The platform decides | Per route, Shopify primitives |
| You now own | Cache, deploys, preview, on-call | Very little | The same, on Oxygen |
| Works with | Shopify, Magento, WooCommerce | Its own platform | Shopify |
| Staffing | React, widely available | Platform specialists | React plus Shopify specifics |
Relevant work
A headless storefront and a custom B2B platform, both built over an API boundary rather than inside a platform theme.
Headless commerce · FashionHeadless fashion storefront
High-performance headless commerce architecture for India’s fastest-growing men’s fashion brand.
HeadlessStorefront APIPerformance
Custom platform · B2BProcurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Business outcomes
A storefront that does what it was built for
When a decoupled front end underperforms the theme it replaced, the project has not delivered its central argument. Moving templates into the right rendering tier is usually what closes that gap, and it is rarely a rewrite.
A cache anyone on the team can explain
The durable result is not a score. It is that a new engineer can say what is cached, for how long, and what invalidates it, which is the property that lets the storefront keep changing safely.
This site
Built on Next.js, and measurable
yuvrajraulji.com is a Next.js static export: no render-blocking third-party CSS, self-hosted fonts, dimensioned and lazy-loaded images, and every page pre-rendered. It is not a client engagement and it is not offered as one, but it is the one Next.js build on this site anyone can open the source of.
Where this came from
Verifiable directly, rather than reported.
No percentage is quoted for a client build. The headless hub gives the reason and it applies here with more force: results from a decoupled storefront are inseparable from the rendering and caching decisions made alongside them, so a figure from another build would describe its architecture rather than what is available in yours.
FAQ
- Does Next.js make a storefront faster?
- Not on its own. Speed comes from the rendering and caching strategy, and a Next.js storefront that renders every request against a slow GraphQL query is slower than the theme it replaced. What Next.js gives you is the choice: which templates are built ahead of time, which are cached and revalidated on a commerce event, and which genuinely need to render per request.
- Next.js or Hydrogen for a Shopify storefront?
- Hydrogen is closer to Shopify's own primitives and Oxygen hosting; Next.js is more general, easier to staff for, and suits builds that also serve non-commerce content. The decision is usually about the team you will have in two years rather than the framework's features today.
- Can Next.js work with Magento or WooCommerce?
- Yes. Magento exposes GraphQL and WooCommerce a REST API, and the rendering rules are the same in all three cases. What differs is how much work the boundary has to do: a Magento catalogue with deep attribute structure needs more deliberate query design than a small WooCommerce store.
- What does a Next.js storefront cost to own after launch?
- A rendering strategy, cache invalidation, content preview, a deployment pipeline and someone accountable for the front end being up. None of that appears in a build estimate and all of it is permanent, which is why the ownership cost matters more than the project cost when deciding.
- Is SEO harder on a Next.js storefront?
- It is not harder, it is less automatic. The platform theme generated canonicals, internal linking and structured data for you; now your templates do. The risk is a rebuild that keeps the URLs and quietly changes the markup, so each moved template needs an explicit diff against the one it replaced rather than an assumption of parity.
Working together
Anyone can scaffold a Next.js storefront. What decides whether it is faster than the theme it replaced is which templates are cached, what invalidates them, and how much the GraphQL boundary is asked to return. That is judgement rather than output, and it is the part worth engaging one person for.
On Next.js this usually starts as a rebuild request and turns into a rendering and caching conversation, because that is what actually decides the result.
Next step
Let us look at your business model, the systems you already run and where you are trying to get to, before choosing the technology. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.