Moving a React site to WordPress without losing the speed

The awkward brief

Madsheets build custom spreadsheet and automation systems for small businesses. Their website was React, hosted on Vercel, and genuinely quick.

They came to me wanting to move it to WordPress.

That sounds like a step backwards, and developers often treat it as one. It was not. The site was fast but inert — publishing a blog post meant a developer, a commit and a deploy. They wanted to publish regularly for SEO, and a platform nobody on the team could write on was the thing standing in the way.

So the requirement was specific: WordPress for the publishing, without paying for it in speed. They had lived with a fast site and were not willing to accept a slow one.

Why that is harder than it sounds

A React app on Vercel gets a lot for free — static delivery, a CDN, an asset pipeline that does the right thing by default.

WordPress with a page builder starts from the opposite position. Elementor is excellent for handing control to a client, which was the entire point here, but a default build carries a lot of weight: the theme’s stylesheet, Elementor’s own CSS and JS, whatever any addon decides to enqueue, and icon and font files loaded whether the page uses them or not.

Matching a Vercel-hosted React site from that starting point is the actual work. It does not happen by installing a caching plugin at the end.

The section Elementor could not build

One part of the design did not map onto anything Elementor offers.

The usual escape hatches are both bad. An HTML block gets it on screen but takes it out of the page builder, so the client can never touch it again — which defeats the reason for choosing WordPress. Bending three stacked widgets into approximately the right shape leaves something fragile that breaks the first time anyone edits it.

So I wrote it as a custom Elementor widget instead: a PHP class registering proper controls, so it appears in the editor like any other widget and the client can edit its content without touching code.

That is more work up front than pasting in markup. It is much less work later, and it keeps the promise the platform choice was made on.

Keeping email alive through the migration

They use Google Workspace for mail. Moving hosting meant moving nameservers, and nameservers carry the MX records that route email.

This is a routine way for a business to lose a day of mail: the DNS moves, the MX records are not carried across, and mail silently bounces until somebody notices. The client rarely finds out from the developer — they find out from a customer who says nobody replied.

Handled in the right order, with the mail records confirmed at the new nameservers before the switch, nothing dropped.

Where it landed

The blog is live and the team writes on it without me. On my own measurement — median of three cold loads from a single location — the homepage reaches first contentful paint in about a second, which is not typical for an Elementor build.

What I would look at next

Being honest about what is left: the page still loads around forty font files, including two full icon-font families of roughly a megabyte combined, for a handful of icons that could be inline SVG. Some of that is Elementor and the theme registering the same font more than once.

None of it stops the site feeling fast — first paint is already good — but it is the obvious next gain, and worth doing before the blog grows.