When conversion rates fall or organic performance starts slipping, a redesign can feel like the obvious answer.
The website looks old. Competitors look newer. Mobile feels a little clumsy. Maybe a fresh interface will fix everything.
Sometimes it will.
But sometimes design isn't the main problem.
A customer may be waiting too long for the product image to appear. A large JavaScript bundle may make filters slow to respond. Several marketing tools may be competing for resources on every page. The backend may take too long to generate a category page.
Replacing the visual design without fixing those problems can produce a newer-looking website with the same performance bottlenecks underneath it.
Before planning a full redesign, measure how the current site actually performs.
A focused performance pass can reveal whether the problem needs a redesign, development work, infrastructure changes, or a much smaller fix.
See how we approach Website speed optimization →
First decide whether speed is actually the problem
Speed optimisation and redesign solve different problems.
Performance work asks:
- Why does important content appear slowly?
- Why does the page respond slowly to interactions?
- Why does content move while loading?
- Why are some templates much heavier than others?
- Why does the site slow down under traffic?
A redesign asks different questions:
- Is navigation confusing?
- Can customers find the right products?
- Is the information hierarchy unclear?
- Does the visual system still fit the brand?
- Does the current template structure limit important UX improvements?
Sometimes both are necessary.
But you shouldn't treat them as the same project.
Performance can also expose a redesign problem
A speed audit does not always end with “keep the existing website.”
It may reveal that the current frontend architecture makes every improvement expensive.
For example, the site may depend on:
- A theme that loads large amounts of unused code
- Components that cannot be optimised independently
- A frontend architecture that has accumulated years of technical debt
- Page templates that require heavy scripts for basic interactions
In that case, performance evidence can become part of the redesign brief.
The difference is that the decision is based on a diagnosed constraint rather than a general feeling that the site needs something new.
1. Measure real performance before changing the design
Start with evidence.
A website's performance cannot be summarised by one Lighthouse score.
PageSpeed Insights provides two useful types of information:
Field data shows aggregated performance from real Chrome users where enough data is available.
Lab data uses Lighthouse to run a controlled test and help diagnose technical problems.
We use both.
The Core Web Vitals
The current Core Web Vitals measure three different parts of the experience:
- LCP (Largest Contentful Paint): how quickly the likely main visible content appears
- INP (Interaction to Next Paint): how responsive the page is when users interact with it
- CLS (Cumulative Layout Shift): how visually stable the page remains while loading
TTFB, or Time to First Byte, is also useful.
It measures how long it takes before the browser receives the first byte of the response.
TTFB is not a Core Web Vital, but a slow initial server response can contribute to poor loading performance, including LCP.
Test templates, not only the homepage
The homepage is often the first URL everybody runs through Lighthouse.
It may not be where performance matters most.
For eCommerce, we normally want to understand:
- Category pages
- Product pages
- Search results
- Cart
- Checkout where measurement is practical
- Important campaign landing pages
A homepage can be fast while the product template struggles with large galleries, reviews, recommendations, and variant logic.
Before redesigning the whole store, identify where the actual performance problem lives.
2. Fix image delivery before replacing the visual system
Image-heavy pages are normal in eCommerce.
Customers need product photography.
The goal is not to remove the imagery that helps them make a decision.
The goal is to stop delivering more image data than the page needs.
Serve images close to their display size
If a section displays an image at roughly 800 pixels wide, sending the browser a 4000-pixel original creates unnecessary transfer and processing work.
Responsive image delivery allows the browser to choose a more appropriate asset for the screen and layout.
This becomes especially important on mobile, where customers often have both smaller screens and slower connections.
Use efficient formats
WebP and AVIF can often produce smaller files than older formats at similar visual quality.
But format alone is not an image strategy.
A 4000-pixel AVIF can still be unnecessarily large if the page only displays it at 600 pixels.
Think about:
- Dimensions
- Compression
- Format
- Responsive variants
- Loading priority
Lazy-load what customers do not need yet
Images below the initial viewport are strong candidates for lazy loading.
If the customer never scrolls to them, the browser may not need to download them at all.
But do not apply lazy loading blindly.
An image that is visible immediately and becomes the LCP element should normally be requested early rather than deliberately delayed.
Prioritise the actual LCP image
Sometimes the main visual is discovered later than it should be.
This can happen when it is:
- Referenced as a CSS background
- Inserted by JavaScript
- Hidden behind a slider implementation
- Incorrectly lazy-loaded
Depending on the implementation, making the resource discoverable earlier, using fetchpriority="high", or selectively preloading it can improve LCP.
But preload is not something we add to every hero image automatically.
Preloaded resources compete for early bandwidth too.
Measure which resource actually needs priority.
Think twice about heavy sliders and video
A redesign is not necessary to question whether a homepage really needs a five-slide carousel with several large images or an autoplaying background video.
If customers rarely interact with it and the asset dominates the initial load, simplifying that component may preserve the overall visual identity while removing a large performance cost.
For frontend and template-level improvements, see our Development services →
3. Fix caching and delivery before assuming the frontend needs rebuilding
Sometimes the page itself is reasonable but the delivery is inefficient.
The browser repeatedly downloads files it could have reused.
Static content is served from one distant origin.
Every request forces the backend to rebuild the same response.
That is where caching and CDN strategy can help.
Browser caching
Static files such as:
- Images
- CSS
- JavaScript
- Fonts
can often be cached so returning visitors do not need to download the same unchanged resource again.
Long cache lifetimes work particularly well when static assets use versioned or fingerprinted filenames.
For example:
app.7e4b91.js
If the code changes, the filename changes too.
That means browsers can safely keep the previous version while the new page requests the new file.
CDN delivery
A CDN can cache suitable resources at distributed locations and serve them closer to users.
This can reduce network latency and reduce work on the origin infrastructure.
But enabling a CDN does not guarantee that every page suddenly becomes fast.
A CDN cannot:
- Remove unnecessary JavaScript
- Resize oversized images automatically unless configured to do so
- Fix slow database queries
- Make a poorly designed API efficient
- Correct unsafe cache rules
It improves the delivery layer.
The rest of the stack still matters.
Server-side and application caching
Some pages require expensive database queries or application processing each time they are requested.
Where the content can safely be reused, application or server-side caching can reduce repeated work.
But eCommerce needs careful rules.
Pages containing:
- Customer accounts
- Carts
- Checkout information
- Personalised prices
- Session-specific content
cannot simply be cached like a public CSS file.
The objective is not to cache everything.
It is to cache what is safe and useful.
See how we approach caching, delivery, and infrastructure on our DevOps and hosting → page.
4. Remove performance debt from scripts and marketing tools
Sometimes the original website was fast.
Then the business started using it.
A Meta Pixel was added.
Then Google Ads tracking.
Then analytics, a heatmap, reviews, recommendations, chat, A/B testing, a consent platform, and a marketing automation tool.
Individually, each tool had a reason.
Together, they changed the page.
Every script does more than download
JavaScript can require the browser to:
- Download the file
- Parse it
- Compile it
- Execute it
- Run callbacks and event handlers
- Modify the page
That work can compete with rendering and customer interactions.
A large amount of JavaScript running on the main thread can contribute to slow responsiveness and poor INP.
Start by removing what no longer has a purpose
Before optimising scripts, audit them.
We often look for:
- Old campaign tags
- Duplicate pixels
- Tools nobody actively uses
- Widgets loading globally when needed on only one template
- Libraries added by plugins that are no longer required
The cleanest optimisation is often deletion.
Then control the remaining scripts
Depending on what a tool does, improvements may include:
- Loading it only on relevant pages
- Deferring non-critical JavaScript
- Delaying suitable tools until after the critical page experience
- Following the site's consent rules
- Replacing disproportionately heavy widgets
Do not simply delay everything.
Some measurement, consent, or application functionality may need to be available earlier.
The loading strategy should reflect the purpose of the script.
Tag governance matters after the optimisation too
A one-time cleanup helps.
But six months later the site can be slow again if every campaign is allowed to add another permanent script.
For active marketing teams, it helps to define:
- Who can add tags
- What each tag is for
- Which pages require it
- When temporary tags should be removed
- How performance is checked after new tools are introduced
This prevents performance from becoming an annual cleanup project.
5. Check whether the bottleneck is actually hosting or backend infrastructure
After image, frontend, and third-party issues are considered, the bottleneck may sit deeper.
A fast frontend still has to wait for the server.
If the initial response takes too long, the browser starts the rest of the loading process later.
TTFB can point us in the right direction
High TTFB can have several causes:
- Slow application code
- Expensive database queries
- Underpowered infrastructure
- Network latency
- Cache misses
- Several backend services being called before the response can be generated
That is why “upgrade the hosting plan” is not always the right first response.
If the database query is inefficient, giving the server more CPU may only make an inefficient process slightly faster.
Look for production symptoms
Infrastructure deserves closer investigation when you see patterns such as:
- Simple pages have consistently high server response times
- Performance deteriorates sharply during traffic spikes
- Checkout or APIs time out under load
- Database activity becomes a recurring bottleneck
- Background jobs affect customer-facing performance
- The current hosting environment prevents useful caching or scaling strategies
Sometimes an infrastructure change is justified
If the current environment genuinely cannot support the traffic, reliability, or architecture the store needs, moving or upgrading infrastructure may be appropriate.
The benefit can include:
- More predictable response times
- Better capacity under load
- More control over caching and deployment
- Better monitoring and incident response
But make that decision after measuring the bottleneck.
Do not migrate servers because a Lighthouse score is low and assume the two problems are the same.
Speed optimisation and redesign solve different symptoms
A performance audit can help decide which direction makes sense.
| Start with performance optimisation when... | Investigate redesign when... |
|---|---|
| The visual direction still fits the brand | The visual system no longer reflects the business |
| Important pages load or respond slowly | Customers struggle to understand navigation or product hierarchy |
| Real-user Core Web Vitals are weak | Product discovery is confusing even when performance is good |
| Images, scripts, or backend response are clear bottlenecks | Existing templates cannot support the required UX |
| The site became slower as tools accumulated | The design system has become inconsistent and difficult to maintain |
| A specific technical problem can be isolated | The underlying frontend architecture makes repeated improvements impractical |
There is also a third possible result:
neither.
A conversion decline may come from pricing, stock, traffic quality, an offer change, broken tracking, increased competition, or another business factor.
A redesign should not become the default explanation for every performance decline.
Speed can support SEO, but do not redesign for a Core Web Vitals score
Google uses Core Web Vitals within its ranking systems and recommends good Core Web Vitals for both Search and user experience.
But Google also makes the limitation clear:
Good Core Web Vitals do not guarantee high rankings.
Search still prioritises useful and relevant content.
This is why we would not recommend a redesign simply because a site has weak Core Web Vitals.
First identify the specific cause.
An LCP problem caused by an oversized product image may require an image-delivery fix.
An INP problem caused by a heavy third-party widget may require removing or changing that widget.
A CLS problem caused by missing image dimensions may require a small template fix.
Those are not redesign projects.
Speed can support conversion, but do not promise a universal lift
It is tempting to turn website-speed advice into formulas:
Improve speed by X and conversion will increase by Y.
Real stores are not that predictable.
A performance improvement can remove friction, but the effect depends on:
- How bad the original problem was
- Which pages were affected
- Traffic mix
- Device mix
- Product and pricing
- Customer intent
- The rest of the buying experience
This is why we prefer before-and-after measurement on the actual store.
Measure performance.
Ship the fix.
Then review:
- Core Web Vitals
- Page behaviour
- Conversion funnel
- Revenue where enough data exists
That gives the business its own evidence instead of an industry average from another website.
What we would check before recommending a redesign
If a client comes to us saying, “The site is slow and we think we need a redesign,” we would first want to answer five questions.
1. Which pages are actually slow?
Homepage, category, product, cart, checkout, or all of them?
2. Which performance metric is failing?
Loading, responsiveness, stability, or server response?
3. What causes the bottleneck?
Images, JavaScript, third-party tools, backend processing, delivery, or something else?
4. Is the UX itself also a problem?
Would customers still struggle with navigation, product discovery, or checkout if every page loaded instantly?
5. Can the existing architecture support the required fixes?
If yes, optimisation may be the better investment.
If no, those technical constraints become useful requirements for the redesign.
Optimise first, redesign with evidence
A redesign can be valuable when the website has genuine structural, usability, brand, or technical limitations.
But it is one of the larger changes a business can make to its website.
It should solve a diagnosed problem.
Performance optimisation gives you useful information before making that decision.
You may discover that responsive images, cleaner scripts, better caching, and a backend fix are enough.
Or you may discover that the existing architecture is exactly why those fixes are difficult.
Both results are useful.
The important thing is knowing which one you are dealing with before starting a redesign.
Fix the drag before changing the shape
A new design does not automatically create a fast website.
A fast website does not automatically mean the UX is good.
And neither one can fix a weak offer, poor traffic, or unreliable tracking.
So before replacing the whole site, identify what is actually slowing the business down.
If the bottleneck is performance, fix performance.
If it is UX, redesign the relevant experience.
If the existing architecture prevents both, then a larger rebuild may be the right answer.
Thinking about a redesign because the current site feels slow?
Creative Brackets can review your real-user performance, Core Web Vitals, frontend assets, third-party scripts, caching, and backend response before you commit to a larger rebuild.
FAQ
1. How do we know whether we need speed optimisation or a full redesign?
Start by separating performance problems from UX problems. If important pages are slow or unresponsive but the structure and buying journey still work well, optimisation may be enough. If customers struggle with navigation, product discovery, information hierarchy, or checkout even when performance is good, redesigning those experiences may be justified. Sometimes both are necessary.
2. What speed fixes often deserve investigation first?
Images, third-party scripts, caching, and backend response are common places to investigate because they can create substantial performance costs. But there is no universal order. Start with the metric and template that are actually performing poorly, then trace the cause.
3. Which Core Web Vitals should we measure?
The current Core Web Vitals are LCP for loading performance, INP for responsiveness, and CLS for visual stability. TTFB is also useful when diagnosing loading problems, but it is not itself a Core Web Vital.
4. Should we preload the hero image?
Not automatically. If the hero or main product image is the LCP resource and the browser discovers it too late, preload or a higher fetch priority may help. If the image is already discovered early, another preload may provide little benefit or compete with other important resources. Measure first.
5. Will adding a CDN make the website fast?
A CDN can improve the delivery of suitable cached resources and reduce latency, especially for geographically distributed users. It cannot remove excessive JavaScript, fix inefficient backend code, or correct oversized assets on its own.
6. Does improving Core Web Vitals improve SEO rankings?
Google uses Core Web Vitals within its ranking systems and recommends good results, but they are only part of the wider search picture. Improving Core Web Vitals does not guarantee ranking improvements. Relevant, useful content and many other signals still matter.
7. Will speed optimisation increase conversion rate?
It can remove performance friction, especially when the original problem affects important buying journeys. The commercial effect varies by website, audience, device mix, and the size of the original problem. Measure the store before and after the change rather than assuming a universal percentage increase.
8. Can performance work reduce the scope of a redesign?
Yes. An audit may show that the current design and structure are sound while a few technical bottlenecks create most of the perceived problem. It can also reveal the opposite: that the existing architecture makes meaningful performance and UX improvements too difficult. Either way, the redesign decision becomes better informed.
