Speed optimization or a redesign: which do you need?

How to tell whether a slow site needs targeted fixes or a rebuild, what each costs in risk, a table that sorts common findings, and the middle path.

In this guide

Start with the findings, not the verdict
What each path involves
Sort your findings
Signs that a rebuild is justified
What a redesign puts at risk
The middle path
Questions to ask whoever proposes the work
Mistakes to avoid
Check your own page
Sources

Start with the findings, not the verdict

"The site is slow, so it must be rebuilt" is a conclusion that skips the evidence. Run a speed test on the pages that matter and read what it found. Most findings fall into a few families, and most of those families can be fixed in place. See what to fix first and why is my website slow.

The 2025 Web Almanac's chapter on content management systems makes the same point from data. It says the aim is not to crown a fastest platform, but to see how platform defaults, hosting choices, themes, plugins and page builders combine in real use. Its examples:

Pass rates for good Core Web Vitals on mobile ranged widely: Duda at 85%, TYPO3 at 79%, Wix at 74% (up from 55% the year before), Weebly at 47% and WordPress at 45%.
The Almanac notes that wide performance variation among WordPress sites comes more from configuration and tooling choices than from WordPress core.
It adds that platforms with tighter control tend to reduce risk through consistent defaults, while extensible platforms shift more responsibility onto site owners and implementers.
Page weight acts as a compounding factor: large images, heavy JavaScript and globally loaded assets pile up, and raise the chance of slow loads, layout shifts and sluggish interactions.

Two lessons follow. A platform's average does not decide your site's speed, because your own choices do. And a platform that limits what you can add makes some problems less likely and others harder to fix.

What each path involves

	Optimize the site you have	Redesign or rebuild
What changes	Images, caching, scripts, fonts, hosting, plugin choices, and a few templates	The design, the templates, often the platform or theme, sometimes the structure and the addresses
Main risk	Breaking something that worked, which testing catches	Losing addresses and search visibility, new problems built into new code, and a long project
Speed outcome	Predictable, because each fix targets a measured finding	Depends on the new build; a heavier template can be slower than the old one
Best when	The design and structure still work, and the findings are specific	The structure is the problem, or the business needs a different site anyway

Sort your findings

Take the top findings from a speed report and decide for each whether it is a fix or a structural problem:

Finding	Usually	Where to look
Oversized images, wrong formats, no sizes	A fix	Image optimization
No page cache, slow server response	A fix, or a hosting change	Server response time, choosing hosting
Many third-party scripts and tags	A fix, and a policy	Third-party scripts
Fonts that flash or shift the layout	A fix	Web fonts and speed
Plugins that load code on every page	A fix: remove, replace or limit	Themes and plugins
A theme or builder that ships a lot of CSS and JavaScript, with no switches to turn it down	Maybe structural	Page builders
A huge, deeply nested page structure from a builder	Maybe structural, for those templates	DOM size
Layout shifts from sliders, pop-ups or embeds that are part of the design	A design change to that part	How to fix layout shift
A platform that cannot cache, compress or serve what you need	Structural	Hosting
Failures that sit in one or two templates only	Rebuild those templates	Lab and field data

If most of your findings are in the "fix" rows, optimize. If the biggest ones are structural and you have tried the available settings, a rebuild of those parts is worth a quote.

Signs that a rebuild is justified

You have tried the fixes and the structure blocks you. The theme or builder cannot stop loading what it loads, and nobody can change it.
The platform cannot do what you need. For example, it cannot serve the pages from a cache, or cannot handle your traffic.
The business has changed. The site's job, products, structure or languages are different now, and the design must change for that reason alone.
The code cannot be maintained. Nobody understands it, and every change breaks something.

Speed alone is rarely a good enough reason for a rebuild. A speed project that ends with a redesign should be the result of the evidence, not the starting point.

What a redesign puts at risk

Addresses. If page addresses change, every old link, bookmark and search result must be redirected to the right new page. See redirects and status codes and the website migration checklist.
What search engines already know. Titles, headings, canonical links, language links and structured data all need to carry over. See canonical tags and titles and headings.
A heavier build. New designs often add motion, video, custom fonts and scripts. The Almanac's measurements show the average page growing every year, and a redesign is a common moment when weight jumps. See why websites get slower over time.
A new framework with its own costs. A site rebuilt as a JavaScript application can make the visitor wait for code. See hydration and JavaScript and SEO.
Time. A rebuild takes much longer than fixes, and the old site goes on slowing visitors meanwhile.

The middle path

Fix first what is cheap and safe, such as images, caching, fonts and unused scripts. It often moves the numbers enough to change the decision.
Rebuild only what remains slow after the fixes: one template, one section, one component.
Write speed into the brief for any new design: targets for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, a page weight budget, and a test before launch. See automated testing and budgets and the speed checklist before launch.
Test the design early with real devices, before it is built across the whole site. See testing on real phones.
Plan the move as carefully as the design: the list of addresses, the redirects, and a check after launch.

Questions to ask whoever proposes the work

What exactly in the report does this change fix?
How will you show that the new site is faster, and with which numbers?
What happens to my current addresses?
What do I lose if I do only the fixes?
What do you not know yet?

Mistakes to avoid

Redesigning to fix a speed problem that a few settings would solve.
Optimizing forever a site whose structure cannot be fixed.
Judging by looks: a modern design can be slower than the old one.
No speed targets in the redesign brief.
Changing addresses without a redirect map.
Launching without testing on phones.

Check your own page

Run the free audit on your home page and your most important inner page. Copy the top five findings into the table above and mark each "fix" or "structural". The balance of the two columns is your answer.

Sources

CMS chapter, Web Almanac 2025: Core Web Vitals pass rates by platform, the role of configuration and tooling, and page weight as a compounding factor.
Page Weight chapter, Web Almanac 2025: how page weight has grown from year to year.