How to Convert a Slow Website Into a Fast, Modern Site

“We need a faster website” usually arrives as a vague emergency after a sales team complains, after Google flags Core Web Vitals, or after a founder watches a competitor’s site load while theirs still spins. The instinct is a full redesign. Sometimes that’s right. Often it’s an expensive way to delay the fixes that would recover conversions this month.

I’ve converted slow marketing sites, bloated React SPAs, and plugin-heavy CMS builds into fast modern frontends for clients who couldn’t pause acquisition. This is the process I use: measure, triage, sequence wins, then decide whether a rebuild is justified. It complements the business case in How Businesses Lose Customers to Slow Websites with an execution playbook.

Step 1: Measure the Real Problem

Before rewriting anything, gather:

• Lab data: Lighthouse on mobile for homepage, top landing page, and checkout/lead page
• Field data: CrUX / Search Console Core Web Vitals for real users
• Analytics: Bounce and conversion by device, especially mobile
• Network waterfalls: What’s blocking render — JS, images, fonts, third parties?

You need a baseline you can defend in a budget meeting. “It feels slow” doesn’t unlock budget. “Mobile LCP is 5.1s on our highest-spend landing page” does.

For metric-level debugging patterns, see Optimizing Core Web Vitals on Modern Frontend Projects.

Step 2: Triage Into Three Buckets

I bucket findings before proposing work:

Quick wins (days)

• Compress and modernize image formats; fix missing dimensions
• Defer non-critical third-party scripts
• Preload only the LCP image/font when justified
• Remove dead CSS/JS and unused apps/plugins
• Cache headers / CDN for static assets

Structural fixes (weeks)

• Route-level code splitting; reduce client JS on content pages
• Font strategy cleanup
• Template-level CLS fixes (skeletons, reserved space)
• Replace heavy carousels/hero videos that aren’t earning their cost

Architecture changes (weeks to months)

• Move content pages from CSR SPA to Astro/static or SSR
• Rebuild marketing site separately from the app
• CMS/platform migration when the old stack can’t meet a performance budget

Most businesses jump to bucket three because it’s exciting. Revenue usually returns from buckets one and two first.

Step 3: Put a Performance Budget in Writing

Example budgets I use for marketing sites:

Metric	Target (mobile)
LCP	≤ 2.5s
INP	≤ 200ms
CLS	≤ 0.1
JS transferred (content pages)	as low as practical; challenge every 100KB

Budgets stop endless opinions. If a new chat widget breaks INP, you have a rule — not a debate.

Step 4: Decide Refresh vs Rebuild

Use this filter:

Refresh the current stack if the platform can meet budgets after script/image/template work and content editing still works for the team.

Rebuild on a modern frontend if you’re fighting the architecture:

• Multi-megabyte JS for brochure pages
• Theme/plugin constraints that prevent LCP fixes
• No sane path to SEO-friendly rendering
• Marketing wants independence CMS tooling the old stack won’t support cleanly

When Astro is the right destination for content properties, Why Astro Is My First Choice for Content Websites explains the rationale. When Next.js is required for product/marketing hybrid needs, performance work follows Next.js Performance Optimization.

Step 5: Sequence Work Without Killing Campaigns

A pattern that works for paid-acquisition businesses:

1. Stabilize tracking and forms so experiments remain trustworthy
2. Win LCP on the highest-spend landing templates
3. Cut main-thread JS that hurts INP on CTA interactions
4. Roll fixes to secondary templates
5. Only then consider visual modernization / full redesign

Teams that redesign first often reintroduce the same performance sins with prettier CSS.

Step 6: Modern Doesn’t Mean Heavier

“Modern” should mean:

• Clean visual hierarchy and mobile-first layouts
• Maintainable components and design tokens
• Predictable CMS editing
• Fast default experience

It should not mean:

• Autoplaying background video heroes
• Three animation libraries on a five-page site
• Client-rendered blog posts
• Tag managers with two dozen unsupervised pixels

Motion and richness are fine when budgeted. I cover purposeful motion in Animation Techniques That Actually Improve UX — note the emphasis on actually improve.

Step 7: Prove Impact After Shipping

Compare against baseline:

• Lab scores on the same URLs/devices
• Field CWV status in Search Console over following weeks
• Conversion rate on optimized templates
• Bounce rate on mobile

Tie the project to money. That’s how performance stops being a one-off cleanup and becomes an operating standard.

What a Typical Engagement Looks Like With Me

When clients hire me to convert a slow site into a fast modern frontend, engagements usually look like:

1. Paid audit with ranked recommendations and effort estimates
2. Quick-win sprint (often 1–2 weeks) for measurable gains
3. Optional rebuild phase if architecture is the ceiling
4. Handoff with a performance budget and monitoring notes

You don’t need to commit to a rewrite on day one. Many clients stop after the remediation sprint because the business goal was already met.

Case Study: B2B Agency Site in Austin

A content-marketing agency in Austin came to me after their unpaid media team complained that Case Study pages took forever on phones — and paid LinkedIn traffic to those URLs bounced harder than branded search.

What we measured

URL type	Mobile LCP (lab)	Field CWV	Notes
Homepage	4.8s	Needs improvement	Hero video + three widgets
Top case study	5.1s	Poor	Uncompressed PNGs, chat on every page
Contact	3.9s	Needs improvement	Form third-party blocking input

What we did in two weeks (refresh, not rebuild)

1. Replaced the autoplay hero with a static image + optional play control
2. Converted case-study images to AVIF/WebP with explicit dimensions
3. Loaded chat only after idle + on /contact and /book
4. Deferred non-essential Tag Manager containers on case studies
5. Preloaded the LCP image on the two highest-spend templates

Result: Lab LCP on the money case-study template dropped under 2.4s. Mobile bounce on that template fell enough that the client paused the redesign RFP. We scheduled a later Astro migration for the blog — but the revenue problem was already smaller.

The lesson: their “slow website” brief was really “slow revenue pages.” Fixing those first changed the architecture conversation from panic to planning. Related patterns live in Common Frontend Mistakes That Hurt Website Performance.

Case Study: SaaS Marketing SPA in Berlin

A Series A SaaS team in Berlin had a CRA-style public site sharing the product shell. Content marketing was strategic; Core Web Vitals on blog URLs were not.

We didn’t start with a full rewrite. Sequence:

1. Audit proving brochure routes shipped dashboard JS
2. Split www to a content frontend while app stayed React
3. Redirect map for blog URLs that had Search Console equity
4. Performance budget written into PR checklist

Blog LCP became competitive with category peers within a sprint of the split going live — not because of clever micro-optimizations, but because marketing pages stopped paying the SPA tax. If your public site is trapped in an app shell, Is Your React SPA Hurting SEO? is the companion diagnosis.

Practical Checklist: First 10 Days

When a client hires me to convert a slow site, the first ten days usually look like this:

• Capture lab baselines on homepage + top 3 landing URLs (mobile)
• Pull Search Console CWV + Analytics mobile CVR for those URLs
• Inventory third-party scripts and owners (marketing vs product)
• Identify LCP element on each money template
• Ship image + deferral quick wins behind a feature flag or staging
• Re-measure the same URLs before proposing architecture work
• Write the performance budget into the proposal for phase two

If day ten still shows the platform blocking the budget — theme locks, plugin maze, CSR shell — then rebuild planning starts with evidence, not taste.

How I Document Remediation Plans

Clients get a short ranked table, not a mystery PDF:

Priority	Finding	Effort	Expected impact	Owner
P0	Oversized hero on paid lander	S	LCP	Frontend
P0	Chat on all pages	S	INP/LCP	Marketing + Frontend
P1	Font loading strategy	M	LCP/CLS	Frontend
P2	SPA shell for blog	L	Architecture	Founder decision

I keep language plain enough that a marketing lead in Manchester or a founder in Denver can approve tiers without decoding jargon. Budget conversations after that are calmer because every line traces to money pages.

When “Modern” Means Astro vs Next.js

After triage, stack choice matters:

• Astro when the destination is mostly content, campaigns, and editorial velocity — see Why Astro Is My First Choice for Content Websites
• Next.js when www must share React systems with the product or needs server logic on marketing routes — with discipline from Next.js Performance Optimization
• Refresh in place when the CMS and hosting can meet the budget after template work

“Convert to modern” is not synonymous with “rewrite in the framework I like this year.” Modern means measurable speed, maintainable components, and an editing workflow the business can actually run.

Tooling I Use During Conversion Projects

Owners sometimes ask what “the audit” actually looks like day to day. Typical stack:

• Chrome DevTools Performance + Network on real mid-tier phones when possible
• Lighthouse CI or manual mobile runs on named templates
• Search Console CWV + CrUX for field truth
• WebPageTest when waterfalls need a second opinion
• Analytics segments for mobile conversion on the same URLs

I don’t chase green scores on irrelevant interior pages while /pricing bleeds. The dashboard follows the money. If you’re comparing vendor PDFs, demand the same URL list in lab and field — and ask how recommendations map to Core Web Vitals optimization.

Communication Cadence With Stakeholders

Performance projects fail socially as often as they fail technically. A pattern that works:

1. Kickoff: baselines + budget + out-of-scope marketing scripts
2. Mid-sprint: before/after on one money URL (screenshot + metric table)
3. Gate review: decide refresh vs rebuild with evidence
4. Handoff: monitoring notes and who can approve new tags

A founder in Denver once almost killed a remediation sprint because marketing added two new pixels mid-week without telling engineering. Written budgets prevent that from being a personality conflict — they’re a process.

Conclusion

Converting a slow website into a fast, modern site is a sequenced engineering project, not a vibe. Measure field and lab data, ship quick wins, enforce a budget, and rebuild only when the platform itself is the bottleneck. Doing it in that order recovers conversions sooner and prevents cosmetic relaunches that stay slow.

If your team is stuck between “tweak the theme” and “burn it down,” start with website performance optimization — or hire an Astro developer when the architecture itself is the bottleneck — then send me your top landing URLs. I’ll tell you which bucket you’re in and what the smallest effective plan looks like. When the pain is specifically paid landers under-converting, scope landing page optimization before a full-site rebuild.

The turnaround path — triage, quick wins, then structural fixes — is what fix slow website engagements are built for.

Key Takeaways

• Start with lab + field measurements on revenue-critical pages
• Triage into quick wins, structural fixes, and architecture changes
• Write a performance budget before adding new marketing scripts
• Refresh when possible; rebuild when the stack blocks the budget
• Optimize paid landing templates before a full visual redesign
• Prove impact with CWV and conversion deltas, not only Lighthouse screenshots

---