A client came to us running a React SPA on WordPress. Clean enough code - but their Lighthouse scores told a different story:
● Performance score: 54 / 100 ● Largest Contentful Paint: 4.1 seconds ● Google ranking signal: Penalized for months
The Starting Point: Why the Legacy Stack Was FailingOur client ran a marketing site and e-commerce storefront built on a React SPA served through WordPress as a headless CMS. On paper, this is a reasonable architecture. In practice, it had accumulated three years of technical debt and was quietly hurting business performance - not through crashes or errors, but through slowness.
Before we touched a line of code, we ran a full Lighthouse audit across five representative pages. The results were consistent - and consistently bad.
| Metric | Before | After |
|---|---|---|
| Performance Score | 54 / 100 | 91 / 100 |
| Largest Contentful Paint (LCP) | 4.1 s | 1.4 s |
| Cumulative Layout Shift (CLS) | 0.28 | 0.04 |
| Time to First Byte (TTFB) | 820 ms | 190 ms |
| Total Blocking Time (TBT) | 680 ms | 120 ms |
A Performance score of 54 is not a minor inconvenience. Google's Core Web Vitals use LCP and CLS as explicit ranking signals. An LCP of 4.1 seconds places a page firmly in the "Poor" band - below Google's 2.5s threshold and far from the 1.2s target needed for competitive rankings.
Slow is not just a UX problem - it is a revenue problem. Every 100ms of additional page load time correlates with roughly a 1% drop in conversions. At 4+ seconds, you are losing visitors before they ever see your product.
Why Next.js? The Case for MigratingWe evaluated Gatsby, Remix, Astro, and Next.js before committing. The decision came down to three factors: ecosystem maturity, built-in asset optimization, and one architectural feature that solved our hardest problem - Partial Prerendering.
Partial Prerendering: Static Speed with Dynamic DataThe fundamental tension in web performance is the conflict between static and dynamic content. Static pages are fast - HTML is pre-built at deploy time and served from a CDN edge node globally in under 200ms. Dynamic pages are slow - they require a server round-trip, a database query, and server-side rendering before the first byte reaches the browser.
Most e-commerce and SaaS products need both. The product page shell - navigation, hero section, product descriptions - is static and identical for every visitor. The cart total, recently viewed items, and personalized recommendations are dynamic and unique per session. Before Partial Prerendering, you had to choose one or the other. Next.js 14 eliminates that tradeoff entirely.
Next.js splits each page into two layers at build time. The static shell is pre-rendered to HTML and cached at the CDN edge - it loads near-instantly for users around the world, regardless of origin server load. Dynamic sections are isolated into separate slots that stream in right after the shell loads, replacing skeleton placeholders as data arrives from the server.
From the user's perspective, the page appears almost instantly and fills in progressively - no blank white screen, no waiting. That is why LCP dropped from 4.1 seconds to 1.4 seconds without removing a single piece of dynamic functionality from the product.
The Asset Pipeline: Images and Fonts Automatic Image OptimizationThe legacy stack used standard image tags with manually exported JPEGs - typically two to four times larger than necessary, served in JPEG format regardless of browser support, and with no declared dimensions. That last point was the primary driver of the 0.28 CLS score.
Switching to Next.js's built-in Image component delivered the following automatically, with zero additional configuration:
● Responsive sizing - the right image size is served for every screen width. Browsers only download what they actually need. ● Modern format conversion - WebP is served to Chrome and Edge users, AVIF to supported browsers. AVIF delivers 40–50% smaller file sizes than JPEG at equivalent visual quality. ● Lazy loading by default - images outside the initial viewport are deferred until the user scrolls toward them. ● Dimension reservation - declaring width and height reserves space in the layout before the image loads, which eliminates layout shift from images entirely.
Self-Hosted Fonts with Zero Layout ShiftThe original setup loaded Google Fonts via a stylesheet link in the document head. This creates two performance costs that are easy to overlook. First, the browser must resolve external DNS for Google's font servers - adding 100 to 200 milliseconds of latency on every page load. Second, while the font file downloads, browsers either render text in a fallback font causing a visible layout shift, or they block rendering entirely, pushing LCP higher.
Next.js resolves both issues by downloading font files once at build time and serving them directly from the same origin as the application. There are no external DNS lookups, no third-party network requests at runtime, and no visible font swap. Font-induced CLS becomes zero.
Results: 90-Day Post-Migration MetricsThe migration ran across six weeks in four phases, using Next.js's incremental adoption capability - new pages went live in production while the old stack continued running in parallel, with zero downtime during the final cutover.
| Business Metric | Before | After |
|---|---|---|
| Organic search traffic | Baseline | +40% (90-day window) |
| Bounce rate (mobile) | 68% | 49% |
| Page load abandonment | 18% | 7% |
The organic traffic increase is the headline number, but the bounce rate and abandonment reductions are equally significant. A 40% traffic increase from a pure technical migration - no new content, no backlink campaign, no paid spend - is a strong signal of how severely the previous stack was being penalized by Google's Core Web Vitals scoring.
What We'd Do Differently● Plan the static and dynamic split earlier - map out which parts of each page need to be dynamic versus static during the architecture review phase, before any code is written. It is a 30-minute conversation that prevents several days of rework later. ● Measure Core Web Vitals in a staging environment - Lighthouse scores in local development do not fully reflect real-world performance under network variance, multiple device types, and third-party scripts firing simultaneously.
Is This Migration Right for Your Product?Not every project running on WordPress or a React SPA needs to migrate to Next.js. The return on investment is strongest when:
● Your product depends on organic search traffic ● You are managing a mix of static marketing content and dynamic user-specific data ● Your team is spending meaningful time on manual asset optimization ● You are running on a frontend architecture that is more than three years old
If you are building a new product from scratch, Next.js should be your default starting point rather than a migration target. If you are running an existing product, the question is simply whether your current scores are costing you measurable traffic and conversions.
At TecoFize, we run free technical discovery calls - an honest assessment of whether a migration makes sense for your stack, with no sales pressure attached. Let us help you build faster.
