How We Improved Core Web Vitals for a Business Website

When a business website starts feeling slow, the first instinct is often to rebuild it. Instead, we took a different approach. By identifying the biggest performance bottlenecks and fixing them one by one, we significantly improved Core Web Vitals without redesigning the website. Here's what we learned along the way.

The Problem

The website was slow to load, especially on mobile devices, and some pages felt unstable during loading.

We also noticed that the Core Web Vitals metrics were below the recommended thresholds, which could affect both user satisfaction and organic visibility.

Instead of starting over, we decided to inspect the actual bottlenecks and fix them one by one. That approach helped us focus on the changes that would create the biggest improvement.

How We Measured Performance

Before making any changes, we analyzed the website using several performance tools:

• Google PageSpeed Insights
• Lighthouse
• Chrome DevTools Performance panel
• Network tab
• Coverage tab

We looked at the key Core Web Vitals metrics and reviewed what the page was doing during load.

We focused on the following metrics:

• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• General loading behavior on desktop and mobile
• Render-blocking resources
• JavaScript execution time

This gave us a clear baseline and helped us avoid guessing.

What We Found

After reviewing the site, we found several common performance issues. None of them was unusual on its own, but together they created a slow experience.

The main issues we identified included:

• Large, unoptimized images
• Too much JavaScript loading at once
• Render-blocking CSS
• Fonts loading in a way that caused visual delays
• Third-party scripts adding extra weight
• Layout shifts from elements loading late

The good news was that these issues were fixable without changing the whole architecture.

The Fixes We Applied

We started with the highest-impact changes first.

1. Optimized Images

We compressed images, resized them appropriately for their display area, and converted them to modern formats such as WebP where possible-this significantly reduced page weight without affecting visual quality. We also served responsive images using the srcset attribute so browsers could download the most appropriate image size based on the user's device.

html
<img src="banner-800.webp" srcset=" banner-400.webp 400w, banner-800.webp 800w, banner-1200.webp 1200w" sizes="100vw" alt="Business website">

For images below the fold, we enabled native lazy loading to reduce the initial page load.

html 
<img src="hero.webp" loading="lazy" alt="Business dashboard">

Together, these optimizations reduced page weight, minimized unnecessary network requests, and improved Largest Contentful Paint (LCP), particularly on mobile devices.

2. Reduced JavaScript Overhead

We audited our JavaScript bundle and found several libraries loading on every page, even when they weren't used. We moved non-critical scripts behind dynamic imports and deferred analytics until after the initial render. This reduced the amount of JavaScript executed during page load and improved responsiveness.

We also deferred non-essential JavaScript so it wouldn't block HTML parsing.

html
<script src="/app.js" defer></script>

Using the defer attribute allows the browser to continue rendering the page while downloading the script, improving perceived performance.

3. Improved CSS and Font Delivery

We removed unused CSS, minimized render-blocking styles, and reduced the amount of CSS required for the initial page render.

For custom fonts, we preloaded the most important font files so the browser could fetch them earlier.

html
<link
  rel="preload"
  href="/fonts/inter.woff2"
  as="font"
  type="font/woff2"
  crossorigin>

Preloading critical fonts helped reduce visual delays and improved text rendering during page load.

4. Delayed Third-party Scripts

We reviewed analytics, widgets, and external embeds to see which ones could be delayed or loaded only when needed. That reduced the amount of work the browser had to do upfront.

5. Reduced Layout Shift

We set explicit sizes for images, banners, and other dynamic elements so the layout stayed stable while content loaded.

Results After Optimization

Once the optimizations were in place, the website felt noticeably faster, more responsive, and more stable.

After implementing these optimizations, we observed several noticeable improvements:

• Faster page loading on desktop and mobile.
• Reduced layout shifts during page load.
• Improved responsiveness by reducing unnecessary JavaScript execution.
• Better Core Web Vitals scores across key pages.
• A smoother browsing experience, especially on slower network connections.

While every website is different, the biggest gains came from optimizing images, reducing render-blocking resources, and delaying non-essential third-party scripts.

More importantly, the Core Web Vitals metrics improved because we focused on the real causes instead of making surface-level changes. The website became easier to use, especially on slower networks and mobile devices.

What We Learned

The biggest lesson was that performance issues usually come from a combination of small problems, not one massive bug. Once you identify the right bottlenecks, improvement becomes much more manageable.

We also learned that you do not always need a full rebuild to make a website faster. In many cases, careful optimization delivers meaningful results with far less effort.

Key Takeaways

If you're planning to improve your website's Core Web Vitals, start with these steps:

• Measure performance before making changes.
• Prioritize high-impact optimizations first.
• Optimize images and reduce unnecessary JavaScript.
• Eliminate render-blocking resources where possible.
• Validate every change with Lighthouse or PageSpeed Insights.

Final Thoughts

Improving Core Web Vitals isn't about chasing Lighthouse scores-it's about creating a faster, more reliable experience for real users. By measuring first, prioritizing the biggest bottlenecks, and validating every change, we achieved meaningful performance gains without rewriting the application.

In many cases, small, deliberate optimizations can deliver greater value than a complete website rebuild.

Let's Discuss

Every website has different performance challenges, and there’s rarely a one-size-fits-all solution. At EncodeDots, we’ve found that the biggest gains usually come from measuring first, fixing the highest-impact issue, and then validating the result.

What performance change made the biggest difference in your project?