How I Shipped a 50% Conversion Lift by Rebuilding a Marketing Site in Next.js

A walkthrough of the Webflow → Next.js migration I led at Lifesight, what actually moved the numbers, and what I’d do differently.

When I joined Lifesight as a Growth Engineer in mid-2023, the marketing site was on Webflow. It had gotten the company far — fast to edit, no engineering bottleneck, good enough design. But it was hitting a ceiling.

Three problems kept surfacing:

1. Scaling content was painful. Every new product page meant rebuilding layouts by hand. The site had grown organically, and no two pages shared the same structure.
2. Performance was inconsistent. Core Web Vitals were fine on some pages, poor on others. We had no systematic way to fix it.
3. SEO experiments were slow. Anything programmatic — generating pages from a dataset, A/B testing layouts, running structured experiments — wasn’t really possible inside Webflow without workarounds.

The mandate I was given was simple: rebuild the site so we can grow faster without the engineering becoming the bottleneck.

Here’s what we did, and what actually moved the conversion number.

The decision: why Next.js

I looked at staying on Webflow with heavy customization, moving to a headless CMS with a custom frontend, or going full Next.js. We picked Next.js for three reasons:

• Server-side rendering out of the box — critical for SEO on a marketing site.
• Component model — we could build a design system once and reuse it across 15+ product pages instead of rebuilding each page.
• Programmatic page generation — the foundation for the SEO work I wanted to do next.

The tradeoff was real: marketing would lose the ability to edit pages visually without an engineer. We mitigated that later by structuring content so non-technical edits stayed cheap.

What we actually rebuilt

The revamp wasn’t just a port. We rebuilt the architecture around three ideas:

1. A shared component library. Hero sections, feature grids, testimonial blocks, CTAs — all standardized. This is what let us ship 15+ product pages with consistent UI/UX without each page being a bespoke project.

2. Layout decisions driven by data, not opinions. We looked at where users were dropping off (checkout was the worst offender) and redesigned those flows specifically. The 30% reduction in checkout drop-off came from this — not from a global redesign, but from targeted fixes on the pages where users were actually leaving.

3. Performance as a first-class constraint. Every component had a Core Web Vitals budget. Images were optimized by default. Fonts were preloaded. Third-party scripts were deferred aggressively.

What actually moved the 50%

If I’m being honest, the conversion lift didn’t come from “we moved to Next.js.” It came from what the migration allowed us to do:

• Clearer CTAs. The old site had CTA ambiguity on most pages — multiple competing actions, no clear primary. The new component system forced us to pick one.
• Faster pages. Users don’t articulate “this page is slow,” they just leave. Improving LCP across product pages meaningfully reduced bounce.
• Consistent trust signals. Logos, testimonials, and case study snippets were standardized and placed consistently. Small thing, compounding effect.
• A shorter path to conversion. We cut a step out of the checkout flow that wasn’t earning its place.

The Next.js migration was the enabler. The conversion lift came from the decisions it let us make.

The SEO layer on top

Once the site was on Next.js, I built programmatic SEO pipelines in Python using SEMrush and PageSpeed Insights. The idea: generate targeted landing pages from structured data, monitor performance, iterate.

In three months, organic traffic grew 40%. This wouldn’t have been possible on the old stack.

What I’d do differently

Three things, looking back:

1. Ship the component library before the pages. We built both in parallel and it created rework. Next time, I’d lock the design system first.
2. Instrument earlier. We added detailed analytics mid-migration. Had we done it first, we’d have known which pages to prioritize rebuilding.
3. Involve marketing earlier in the tradeoff conversation. Losing Webflow’s visual editing was a real cost. We handled it, but the transition was rougher than it needed to be.

The takeaway

Framework migrations don’t move business metrics. What moves metrics is what the new framework lets you do — faster pages, clearer flows, programmatic experimentation.

If you’re considering a rebuild, the question isn’t “which stack is better.” It’s “what can’t we do today that we need to do in 12 months?” Answer that, and the stack choice becomes obvious.

I’m a Frontend Engineer currently at Bradken, building Intervia on the side, and open to Senior Frontend Engineer roles in Bengaluru. Reach me at ganeshgovind11@gmail.com or ganeshgovind.in.