Storefront
The storefront is the product
Everything else in the stack exists so the storefront can answer quickly and correctly. We build it in React and Next.js, against a performance budget agreed before the first commit, and we enforce that budget in the pipeline for as long as we are involved.
- Server rendered and statically regenerated pages for everything a search engine or a first time visitor needs
- Edge caching with tag based invalidation, so a price change clears exactly the pages it should
- A component library with tokens, states and accessibility built in, documented in Storybook
- Image, font and script budgets enforced by CI, with the build failing when a budget is broken
- Consent, analytics and tag management implemented once, correctly, without blocking render
How a page is served
Where the milliseconds go
Request path for a product detail page
Figure 03 / request pathFigure 03. The cheapest request is the one that never reaches the origin. Cache design is a first class part of the storefront work, not an operations afterthought.
Rendering strategy
Every page type gets a decision, not a default
Rendering mode, cache layer and revalidation are chosen per template and written into the technical design. This is the table we agree with you before build starts.
| Template | Rendering | Cache | Revalidation | LCP target |
|---|---|---|---|---|
| Home | Static with incremental regeneration | Edge, full page | On publish, tag based | 0.9 s |
| Category and listing | Static with incremental regeneration | Edge, full page, facets on the client | 15 minutes or on catalogue event | 1.0 s |
| Product detail | Static with incremental regeneration, price hydrated | Edge, full page, price fragment private | On price or stock event | 1.0 s |
| Search results | Server rendered | Edge, 60 seconds, keyed on query | Time based | 1.2 s |
| Cart | Client rendered on a static shell | No shared cache | Live | 1.2 s |
| Checkout | Server rendered, no third party scripts | No cache | Live | 1.1 s |
| Account and orders | Client rendered on a static shell | No shared cache | Live | 1.4 s |
Table 02. LCP targets are p75 field values on a mid range Android device over 4G, measured in the field rather than in a lab.
Measured result
Before and after on a real replatform
Largest contentful paint by template, Northline Retail
Figure 04 / field data, p75 mobileFigure 04. The same catalogue, the same markets, the same marketing scripts. The difference is rendering strategy, cache design and a build that fails when the budget is broken.
Scope
What a storefront engagement includes
01
Design system
Tokens, components, states and accessibility, documented in Storybook and wired to your design tool so design and code do not drift.
02
Templates and journeys
Home, category, product, search, cart, checkout, account, content and campaign templates, all responsive and all keyboard operable.
03
Content model
A CMS model that lets marketing build pages from approved blocks, with preview, scheduling and no developer in the loop.
04
Performance engineering
Budgets in CI, image and font pipelines, script governance, third party isolation and synthetic checks on every deploy.
05
SEO foundations
Server rendered markup, canonical and hreflang handling, structured data for products, breadcrumbs and reviews, clean pagination.
06
Analytics and consent
Consent mode, server side tagging where it helps, and an event schema that answers the questions the business actually asks.
Next step
Tell us what is slowing your commerce platform down
Send the brief. A principal architect reads it, then you get a written technical assessment with options, effort and risk inside five working days. No sales call required first.