A Performance-First Rebuild: perk.com on Astro

A Performance-First Rebuild: perk.com on Astro

After consolidating the brand on perk.com , the next problem was the platform underneath it. Years of migrations, CMS changes, and acquisitions had left the Next.js codebase carrying real technical debt. Performance plateaued. Tier 1 page scores sat where they shouldn't.

Perk asked Makers' Den to migrate perk.com from Next.js to Astro. The goal was performance. The path cleared the debt at the same time.

Nick Roberts

Director Growth Marketing

“We're very confident in Makers' Den's technical work and expertise.”

Read on Clutch

The Challenge

Two things needed solving simultaneously, which is usually a budget problem:

1. Performance. Next.js can hit good Core Web Vitals with effort. The path to taking the existing Perk site there meant a deep rework of how rendering and interactivity were handled across hundreds of pages.

2. Technical debt. Components had drifted across rewrites. Patterns from earlier eras coexisted. Untangling it on the existing stack was its own multi-month project.

Doing both at once on a Next.js base would have stretched the budget. The Astro rebuild let them be solved together, which is the actual story.

Why Astro

Astro is static-first with islands of interactivity hydrated only where needed. For a content-heavy marketing site (blog, glossary, customer stories, reports, hundreds of templated pages), that model fits the workload. JavaScript ships only where it has a job.

Next.js is flexible and performs well when tuned, but tuning is the operative word. With Astro, strong performance is the default rather than the destination.

The Approach

Three calls shaped delivery:

1. AI acceleration under tight engineering supervision. A migration this size (205 Storyblok components, 9 locales, 29 page templates, hundreds of pages) wouldn't have fit the budget on traditional engineering effort alone. Makers' Den used AI agents under engineering review to port components, generate types, and translate patterns. Every change was verified by a human. AI compressed the timeline, not the quality bar. This is the part that made the project economically viable.

2. Ship fast to retire the parallel-stack tax. Two production codebases mean two places to fix bugs, ship features, and test. Every week of parallel operation was duplicated work. The project optimized for cutover speed: 13 weeks from first commit to production. Non-blocking polish continues post-launch, deliberately.

3. Same content, same infrastructure. Storyblok content model preserved without a schema rewrite. Same AWS Lambda + CloudFront hosting. Same tracking architecture. The migration was scoped to what actually needed to change: the rendering layer.

Technical Implementation

Stack

• Framework: Astro, server-rendered via @astrojs/node standalone, packaged into AWS Lambda

• Islands: React 19, hydrated only where genuine interactivity lives (calculators and similar)

• Navigation: Astro View Transitions for SPA-style routing on top of SSR

• CMS: Storyblok, schema unchanged, 205 components mapped

• Tracking: Existing Segment + GTM + Marketo + Usercentrics architecture ported, consent-gated from day one

• RUM: Datadog Browser RUM wired up before cutover specifically to measure the change

Cutover via CloudFront alias swap

The Astro renderer deployed alongside the Next.js renderer as a separate Lambda behind a separate CloudFront distribution. Cutover was a CloudFront alias swap, instant and reversible. No DNS dance, no TTL wait. If something needed rolling back, it was a one-line change.

Performance work

Dedicated Core Web Vitals passes shipped before launch: heavy animations replaced with optimized media, unused CSS removed, fonts moved to CDN, LCP elements audited per template, image preconnects added, build-time compression enabled, CSS code-split and inlined. Image transformation pushed entirely to Storyblok's CDN; the Lambda doesn't do image work.

i18n and SEO

Nine locales preserved. Translated path slugs (recursos, ressourcen, ressources) routed natively. Hundreds of redirects covering acquisition history, the brand rename, and legacy URLs handled in middleware as 301s. Dynamic per-locale sitemaps. JSON-LD schema across content types.

The Outcome

On Day 1 in production, Tier 1 pages were already hitting the launch thresholds:

• Mobile PageSpeed: 70+

• Desktop PageSpeed: 95+

• Load time: <3s

• Accessibility: 90+

Early commercial signals across paid landing pages trended in the right direction post-launch. The 13-week timeline minimized time spent maintaining two codebases in parallel, which was the budget's real risk.

The site is now a base that gets faster as Astro evolves, instead of one that needs constant defensive engineering to hold the line.

Final Thoughts

This kind of project (full re-platform of a content-heavy production site, performance-led, debt-clearing) used to fail the budget test. The combination of Astro's static-first model and supervised AI acceleration moved that economic line. Perk got a faster site, a cleaner codebase, and shipped before the parallel-stack tax compounded.

Performance isn't the only outcome. The result is a platform Perk's team can extend without fighting it.