Why your WordPress site got slower after the redesign

A client sends me a message I've seen dozens of times: "The new site looks great, but it feels slower than the old one." They're usually right. And when I open the hood, the culprit is almost never the design itself. It's what quietly changed during the rebuild.

Here are the five things I check first, in the order I usually find them.

1. Hero images uploaded straight from the designer

The new homepage has a beautiful full-width photo. It's also a 4.8 MB JPEG at 6000 pixels wide, because that's what came out of the design handoff. WordPress generates smaller sizes, but plenty of themes and page builders still output the original on the hero section.

• Resize to the largest size actually displayed (usually 2400px wide is plenty).
• Serve WebP or AVIF, and make sure srcset is present on the element.
• Never lazy-load the hero — it's your Largest Contentful Paint element. Add fetchpriority="high" instead.

2. A second page builder left installed

The old site was built in WPBakery, the new one in Elementor. Nobody deactivated WPBakery because "some old pages might still use it." Now both builders load their CSS and JavaScript on every page. That's often 300–500 KB you're paying for twice.

Find the pages still using the old builder, migrate or retire them, then remove the plugin completely.

3. Render-blocking fonts

New designs love new typefaces. Three families, four weights each, loaded from a third-party server in the <head>. The browser can't paint text until they arrive.

• Self-host the fonts and preload the one or two used above the fold.
• Use font-display: swap.
• Cut weights you don't use. Designers rarely need more than three.

4. An unbounded query on the homepage

"Show our latest projects" became a query with posts_per_page => -1. Fine with eight projects at launch. Painful with eighty a year later. The same goes for related-product widgets that run uncached queries on every request.

Always set a limit, and cache expensive queries with a transient.

5. Caching that was never turned back on

This one is the most common and the easiest to fix. During development, caching gets switched off so changes show up immediately. Then the site launches — and nobody switches it back on. Page cache, object cache, CDN — check all three on launch day.

A redesign is the best moment to make a site faster. It's also the easiest moment to make it slower without noticing.

A simple launch checklist

1. Run PageSpeed Insights on the old site before the rebuild and save the numbers.
2. Run it again on staging before launch. If anything got worse, find out why.
3. Check caching, image sizes and active plugins on launch day.
4. Re-test a week later with real-user data in Search Console.

If your site got slower after a redesign and you can't tell why, send me the URL. A quick audit usually finds the cause within an hour.