The new site looks far better than the old one. Bigger photos, smoother animations, a proper brand font, sections that slide into view as you scroll. Then the first speed test comes back worse than the old site ever managed, and a customer mentions that it takes a while to open on their phone. You paid for an upgrade, and in one way that matters, it is a downgrade.
Nobody was necessarily careless. A website slow after a redesign is mostly a product of how redesigns are judged: on a large screen in a meeting, on a fast connection, by people who have seen each page dozens of times. Speed is rarely in the brief, so it is rarely tested until launch. What to do next depends on whether your site is already live or still with the designer, and both cases are covered below.
Why the new website is slower than the old one
The reasons are fairly predictable. Most redesigns that end up slower have several of these at once.
- A heavier theme or page builder. Multipurpose themes and visual builders make design work faster, and they often output more code, more styles and more scripts than a simpler theme. Builders also make it easy to nest sections inside sections, which adds to the page. The broader trade-off is discussed in page builders versus the block editor for speed.
- Add-on packs. Extra widget bundles for the builder, each loading its own files, sometimes on every page.
- Large images. Designers work with high-resolution photos, and stock images are often downloaded at full size. If they are uploaded without resizing, the site carries files far larger than any screen needs.
- More fonts. A brand font in several weights, a second font for headings, and an icon font, each a separate download.
- Animation and effects. Scroll animations, parallax, counters, hover effects, background video. Each tends to bring its own script.
- New tools added at launch. Marketing often uses the launch to add a chat widget, a new analytics or heatmap tool, a popup or a reviews widget.
- Caching not set up. The new site was built on a staging copy where caching was off, and nobody switched it on, or configured it properly, when it went live.
None of these is wrong in itself. Together, they can easily make the new site much heavier than the old one without any single decision looking unreasonable.
Measure the gap before blaming anything
Before you start removing things, find out how much slower the new site is and where.
If you tested the old site before the redesign, compare against those results with the same tool, location and device setting. If you did not, you may still have a copy of the old site on staging or in a backup that can be restored somewhere temporary. Failing that, use the general approach in working out why a website is slow to see whether the problem is the server response or the page itself.
For the new site, test the pages that matter most to the business, not just the home page: a key service or product page, a contact or booking page, and any landing page used in ads. Note the total page size, the number of requests, the server response time and the Largest Contentful Paint for each. Then sort the browser’s Network panel by size. On redesigned sites the top of that list is usually images, video, fonts and builder scripts. Each of those has its own section in our guide to improving website speed, so once you know which items dominate, you know where to read next.
Website slow after a redesign and already live: what to fix first
If the site is live and you want it faster without undoing the design, this order usually gives the most improvement for the least visual change.
- Check caching is on and working. It costs nothing visually and is often missing after launch.
- Resize and compress the images. Replace oversized originals with versions sized for their use. The design does not change; only the files get lighter.
- Trim fonts. Keep the weights you actually use. Two weights of one family often cover most needs.
- Remove unused add-ons and widgets. If an add-on pack is installed for one widget, consider whether the builder’s own widgets can do the job.
- Tone down animation. Keep the effects that genuinely help, drop the rest, especially on phones.
- Review what marketing added. Each new tool should earn its place. Several can usually be loaded later in the page, after the main content.
- Look at the heaviest section of the heaviest page. A background video or slider at the top often deserves a rethink rather than tuning.
Test after each step, not at the end. That way you know which changes were worth it, and if something looks wrong, you know what caused it.
Still in the redesign: what to agree with your designer
This is where most of the cost can be avoided. Speed is much easier to build in than to add afterwards, and it is much easier to agree in writing at the start than to argue about after launch.
Put speed in the brief
State plainly that the new site should be at least as fast as the current one on the pages that matter, measured on mobile. Name the tool and the pages. That turns a vague hope into something both sides can check.
Agree some limits
A simple set of limits helps both sides: a maximum page size for key pages, a cap on font families and weights, no autoplay video without agreement, and a limit on outside scripts. This is called a performance budget, and setting a speed budget for a website shows how to write one that designers and marketers can work with.
Agree how images will be handled
Who resizes and compresses images before upload, what sizes are used for which purpose, and which format. If staff will add images after launch, agree the rules for them too.
Choose the theme and builder with speed in mind
Ask which theme and builder the designer plans to use, which add-ons, and why. A designer who has a clear answer about what each one adds is a good sign.
Test on a real phone before launch
Ask to see the staging site on an ordinary phone over mobile data, logged out, before sign-off. A desktop demo in a meeting room tells you very little about how customers will experience it.
Agree who handles caching at launch
Make it someone’s job, by name, to set up and test caching when the site goes live, and to run speed tests after launch.
Our website redesign checklist covers the rest of the redesign process, from content to redirects; the points above are the speed part of it.
Testing before launch
A short pre-launch speed routine catches most of the problems listed above.
- Test the key pages on mobile and desktop, three runs each, and compare with the old site.
- Check the largest files on each page and whether any image is far larger than its display size.
- Count the fonts and font weights being downloaded.
- List every outside domain the page contacts and confirm each one is wanted.
- Load the site on a mid-range phone over mobile data.
- After launch, confirm caching is serving pages and test again.
- Repeat the tests a month later, once real content, staff uploads and any new tools have been added, because that is when sites quietly put weight back on.
Frequently asked questions
Can I ask my designer to make the new site faster at no extra cost?
It depends on what you agreed. If speed targets or limits were written into the brief or contract, it is reasonable to ask for them to be met. If speed was never mentioned, many designers will still help with obvious issues such as oversized images, but larger changes may be treated as new work.
Should I switch back to the old site until the new one is faster?
Usually not. Switching back means handling redirects, content changes and search engines twice. Most redesigns can be made noticeably faster by fixing images, caching, fonts and add-ons without changing the look, so it is normally better to fix the new site in place.
Is the page builder the reason my new site is slow?
It can be part of it, but it is rarely the whole story. Images, fonts, add-on packs, animations and missing caching usually add more weight than the builder itself. Fix those first and test again before deciding the builder has to go, because rebuilding without it is a large job.
When during a redesign should speed be tested?
Test the old site before work starts to get a baseline, test early templates on staging as soon as the main pages exist, and test again before launch on a real phone. Problems found while the design is still changing are far cheaper to fix than after the site has gone live.
A redesign rarely needs undoing. Our speed optimisation service works on how the new site loads, through images, caching, fonts and scripts, rather than on how it looks, and where the design itself is the limit we will point to it and leave the decision with you.