Why We Rebuilt pagesmith.ai with Astro
Pagesmith started with a Next.js marketing site because our application already used that framework. Sharing one stack helped us move quickly.
The marketing site and the product eventually needed different things. The editor benefits from an application framework. The public site mainly serves product pages, articles, and documentation.
We moved pagesmith.ai to Astro so our public site follows the same architectural principles as the sites Pagesmith produces.
Why We Changed the Marketing Site
The requirements were straightforward:
- Marketing pages need fast delivery and clear HTML.
- Blog posts and documentation should render without client-side JavaScript.
- Interactive components should load only where the page needs them.
Using Astro also lets us test the same page and content patterns that Pagesmith users receive.
What Changed
Previous Architecture: Next.js
The previous site used the Next.js App Router. Next.js supports server rendering, but our implementation still included client-side framework code on pages that needed little interaction.
<!-- Illustrative Next.js Client Payload -->
<script src="/_next/static/chunks/framework.js"></script>
<script src="/_next/static/chunks/main.js"></script>
<script src="/_next/static/chunks/pages/_app.js"></script>That was more client-side code than the marketing site required.
New Architecture: Astro
Astro renders the main page as HTML and CSS. It does not add a client-side JavaScript bundle by default.
<!-- Astro Client Payload -->
<!-- No JavaScript bundles are loaded by default. -->Interactive components, such as forms and pricing controls, use Astro islands. Only those components load client-side JavaScript.
Performance Impact
This performance snapshot was recorded after the migration:
| Metric | Value |
|---|---|
| First Contentful Paint | 1.0s |
| Largest Contentful Paint | 1.5s |
| Total Blocking Time | 10ms |
| Cumulative Layout Shift | 0 |
| Speed Index | 1.0s |
The result reflects a page with little client-side work. Measurements still vary by page, device, network, and test run.
Why the Dashboard Still Uses Next.js
The Pagesmith application, including the editor and dashboard, remains on Next.js. It manages long-running state and application-style interactions, so its requirements differ from those of the marketing site.
Astro also supports server-rendered pages when a request needs dynamic data.
For example, the pricing page uses Astro SSR (Server-Side Rendering) to select a local currency at the edge. The server returns the selected price in the HTML response.
We use Astro for:
- Edge-rendered pages: Such as geo-aware pricing.
- Marketing pages: Where most content can ship as HTML.
- Content sections: Including the blog and documentation.
Marketing sites can include dynamic features without becoming Single Page Applications (SPAs). The rendering choice should follow the job of each page.
We use Next.js for the application and Astro for the public marketing site.
What We Learn by Using the Same Stack
Running our marketing site on Astro aligns our internal workflow with that of our users:
- We write articles in MDX.
- We use the same component patterns as generated sites.
- We encounter similar publishing and content edge cases.
- We can fix workflow friction after using it ourselves.
The shared stack gives us another real site for testing framework upgrades, content changes, and deployment behavior.
