Storefront framework
Astro for ecommerce stores
Astro builds pages that ship no client-side JavaScript unless a component actually needs it, which makes it well suited to the parts of an ecommerce site that are read rather than interacted with: guides, comparisons, landing pages and large sets of generated pages. We use it where content volume and page speed matter, alongside a store that keeps handling carts and orders, and occasionally for a full storefront reading a commerce API.
Astro
Storefront framework · by Astro. A text wordmark, not a logo: we are not affiliated with the vendor and make no claim to its trademarks.
What we do with it
The work inside Astro
Deciding what belongs outside the store platform
Product, cart and checkout stay where they are. What moves is the content layer: buying guides, category explainers, comparison pages and campaign landing pages that a store platform renders slowly or a page builder renders badly. The split is chosen by which system each page type is genuinely better at serving.
Interactivity only where it earns its place
Components render to plain markup by default, and anything that needs to run in the browser, such as a calculator, a filter or a size finder, is loaded as an isolated island. The result is a page that renders immediately and downloads code only for the parts that do something.
Content as data, pages as templates
Structured content in files or a data source drives templated pages, so a set of two hundred location or category pages is generated from one template and reviewed as data. That makes bulk changes tractable, and it stops the quality of the last page in a set from depending on who was writing that afternoon.
Commerce data where it is needed
Pages can read product data from the platform's storefront API to show live pricing, availability or a related product block, while the actual purchase happens in the store. Keeping the transaction on the platform is what allows the content layer to stay simple and fast.
One domain, correct URLs and redirects
Two systems serving one site is a routing exercise before it is a design exercise. We agree the path structure, set up the proxy or routing rules, and plan the redirects so content sits in a subfolder of the main domain rather than on a separate subdomain that starts its authority from nothing.
When it fits
Astro is the right tool when
Stores whose content is held back by the platform's blog
When guides and editorial are a real acquisition channel, the limits of a built-in blogging tool become the limits of the strategy.
Programmatic page sets built from structured data
Large families of pages generated from a dataset need a template system and a review process. That is a build problem, and it is what this kind of framework is designed for.
Brands where landing page speed is a paid media cost
Every campaign page carrying a page builder's payload is spending budget on load time. Lightweight pages change what a click is worth without touching the ad account.
What to watch
Where accounts drift
Facts about defaults and costs, not criticism. These are the settings we check on every account.
Two systems need one owner
Navigation, footers, tracking and design tokens exist in both places and drift apart unless someone is responsible for keeping them consistent. Shared components and a documented style source reduce that, but they do not remove the need for ownership.
Routing decisions are hard to reverse
Whether content lives at a subfolder or a subdomain, and which system answers the root, affects search performance and is disruptive to change later. Decide it before launch and write it down.
Anything interactive is a build
A cart drawer, a wishlist or a filtered product grid is not free here the way it is in a theme. Where a page needs commerce interaction, consider whether it belongs on the store platform instead.
Frameworks carry upgrade work
Major versions and dependency updates arrive on their own schedule. A small allowance of maintenance time each quarter keeps a fast site from becoming an outdated one that nobody wants to touch.
Should the blog live on the store platform or on a separate front end?
On the platform if the content is occasional and the built-in tools are adequate. On a separate front end when content is a primary acquisition channel and needs templates, structured data and speed the platform's blog cannot provide. Either way it belongs on the main domain.
Does shipping less JavaScript actually affect sales?
It affects the measurable things that lead to sales: how quickly the page becomes usable, how stable it is while loading, and how it behaves on a mid-range phone. Whether that shows up in revenue depends on how slow the current pages are and how much traffic arrives on mobile.
Can it run a complete storefront?
It can, reading a commerce API for catalog data and handing off for checkout. Whether it should depends on how much storefront functionality you are prepared to build and maintain, which is the same calculation as any other custom front end.
How do you keep the content site and the store looking like one brand?
Shared design tokens, a shared component library where practical, and a single source for navigation. We also put both systems in the same review cycle so a header change is applied in one place and checked in both before it ships.
Is there a search risk in moving content to a new system?
Yes if URLs change without redirects, and manageable otherwise. The plan covers a redirect map, unchanged canonical rules, structured data parity and a crawl before and after. Content moved carefully to a faster template typically holds its positions.
Works alongside
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.