Why Your Website Is
Slow (And What
Actually Fixes It)

Everyone says "make your site faster." Nobody tells you which fixes actually matter. We've optimized dozens of sites over the past few years, and the pattern is always the same: most speed improvements come from 3–4 changes, not 30. The long checklists you find online are mostly noise.

You've probably run a Lighthouse audit, seen a score in the 30s or 40s, and felt that sinking feeling. Then you Google "how to speed up my website" and get a 47-point checklist that includes everything from minifying JavaScript to enabling HTTP/2 push. You spend a weekend ticking boxes. Your score goes from 38 to 44. Barely noticeable.

That's because most of those 47 points don't matter. Not in a meaningful, measurable way. The fixes that actually move your Lighthouse score from red to green are specific, predictable, and the same across almost every slow site we've worked on.

Core Web Vitals: What Google Actually Measures

Before we get into fixes, a quick primer on what we're optimizing for. Google uses three metrics called Core Web Vitals to evaluate your site's performance. They affect search rankings, but more importantly, they're decent proxies for "does this site feel fast to a human?"

These metrics replaced the old PageSpeed score as ranking signals. But honestly, the ranking impact is secondary. A slow site loses visitors before Google even gets involved. 53% of mobile users abandon a page that takes longer than 3 seconds to load. That's not a Google penalty. That's human impatience.

The 4 Fixes That Actually Matter

We've worked on enough slow sites to see the pattern. These four fixes account for almost all of the speed improvement on every project. In order of impact.

1. Images: The Biggest Offender by Far

On almost every slow site we audit, images are the single largest payload. It's not unusual to find a homepage loading 8–12MB of images. That's insane. A fast page should be under 1.5MB total.

The problems are always the same. Someone uploaded a 4000px wide photo from their camera for a hero image that displays at 1200px. The images are served as PNG or JPEG when WebP or AVIF would cut the file size by 30–50%. Nothing below the fold is lazy-loaded, so the browser downloads every image on the page before the user can even see the first one.

A real example: An e-commerce client was serving product images as full-resolution PNGs. Their category page loaded 14MB of images. We converted to WebP, added responsive srcset attributes, and lazy-loaded everything below the first row. Total image payload dropped to 1.2MB. LCP went from 4.8s to 1.6s. No code changes. No server changes. Just images.

2. Third-Party Scripts: Death by a Thousand Tags

Open your site's source code and count the third-party scripts. Google Tag Manager. Google Analytics. Facebook Pixel. LinkedIn Insight Tag. Hotjar. Intercom. Drift. That cookie consent banner. The live chat widget. The review widget. The social sharing buttons.

Each one adds 200–500ms of load time. They're not polite about it either. Most of them load synchronously, block rendering, and phone home to their own servers before your page can finish painting. A site with 8–10 third-party scripts can easily add 2–3 seconds to load time, even on a fast connection.

"Every third-party script is a tax on your users' time. Most sites are paying taxes they don't even know about, for services nobody's using."

The fix: Audit ruthlessly. For every script, ask: is anyone actually looking at this data? Is this tool worth the milliseconds it costs? If you added the Facebook Pixel two years ago and haven't run a Facebook campaign since, remove it. If you have both Hotjar and Microsoft Clarity, pick one. If your chat widget gets 3 conversations a month, it's not worth 400ms.

For the scripts you keep, defer them. Use async or defer attributes. Load them after the main content renders. Your analytics can wait 2 seconds. Your user's first impression can't.

3. Server Response Time (TTFB): The One Nobody Checks

Time to First Byte, or how long your server takes to start responding after the browser asks for a page. If your TTFB is 800ms, your page physically cannot load in under 800ms. Everything else stacks on top of that delay.

Shared hosting is the usual culprit. You're paying $3–8/month for a server shared with 200 other sites. When any of those sites gets traffic, yours slows down. TTFB on cheap shared hosting typically ranges from 600ms to 1.2 seconds. That's before a single image loads or a single CSS file parses.

Modern edge platforms like Vercel, Netlify, or Cloudflare Pages serve pages from CDN nodes close to the user. TTFB drops to 30–80ms. That's not a small improvement. That's removing nearly a full second from every single page load.

4. Render-Blocking CSS and JavaScript

When a browser loads your page, it has to download and parse your CSS before it can render anything. If your main stylesheet is 400KB (common with WordPress themes), the browser sits there waiting while it downloads and processes all 400KB. Most of that CSS isn't needed for the initial view. Your contact page doesn't need the styles for the blog carousel.

The fix is two parts. First, inline the critical CSS. That means extracting the styles needed to render the above-the-fold content and putting them directly in the HTML. The browser can start rendering immediately without waiting for an external stylesheet. Second, defer everything else. Load the full stylesheet asynchronously so it doesn't block rendering.

The waste here is wild. Most WordPress sites ship 300–500KB of CSS from their theme, plugins, and page builder. Actual CSS used on any given page? Usually 30–60KB. So 85–90% of the CSS your visitors download is never used on the page they're viewing. It just sits there, making the browser wait for nothing.

Same principle applies to JavaScript. If it doesn't need to run before the page renders, defer it. If it's not needed on this page at all, don't load it.

Real Project Data

Before & After: Full Optimization Pass

E-commerce site, WordPress + WooCommerce, 2024 engagement

Before LCP

4.2s

After

1.1s

Before TTFB

820ms

After

45ms

Before CLS

0.25

After

0.02

Before Lighthouse

38

After

96

Lighthouse score improved 153%. Total optimization time: 2 weeks.

Impact Analysis

LCP Improvement by Optimization Type

Average milliseconds saved per fix, based on 30+ site optimizations

Image Optimization (format, sizing, lazy load) –1,800ms

Hosting / TTFB Improvement –750ms

Third-Party Script Cleanup –600ms

Critical CSS / JS Deferral –400ms

Minification (CSS + JS) –50ms

What Doesn't Matter (Much)

I'm going to save you some time. Here are the things that show up on every "speed optimization" checklist but won't make a noticeable difference until you've fixed the big four.

Minification. Removing whitespace and comments from your CSS and JavaScript. On a typical site, this saves 5–15KB. That's roughly 20–50ms on a fast connection. It's not zero, but if your LCP is 4 seconds, minification is rounding error. Do it eventually, but it's not urgent.

HTTP/2 Server Push. Browsers have gotten smart enough to handle resource prioritization on their own. Server Push was a neat idea that turned out to be more trouble than it was worth in practice. Chrome actually removed support for it. Don't waste time on this.

AMP (Accelerated Mobile Pages). Google dropped AMP as a ranking requirement for the Top Stories carousel. AMP creates a worse development experience, limits your design options, and the speed benefits are mostly achieved by the same optimizations you'd do anyway. Unless you have a specific AMP-related use case, skip it.

Fancy caching headers for first-time visitors. Cache-Control headers help returning visitors, which is great. But they do nothing for the first page load, which is where you're losing most people. Fix the first load first. Cache headers are optimization for visit #2.

The Speed-vs-Features Tradeoff Nobody Talks About

Every feature has a performance cost. That animated hero slider with 5 high-res images? 2–3MB and 800ms. That live chat widget in the corner? 300–500KB and 400ms. That embedded YouTube video on the homepage? 500KB+ just for the iframe to initialize, even if nobody clicks play.

The question isn't "can we add this?" It's "is this worth 200ms?"

We worked with a SaaS company that had a beautiful homepage with a video background, animated counters, a chat widget, three analytics tools, and social proof notifications popping up every 10 seconds. Gorgeous page. Lighthouse score: 29. Mobile load time: 8.4 seconds.

We asked them a simple question for each element: what's the conversion impact? The video background had no measurable impact on sign-ups. The animated counters were decorative. The social proof pop-ups annoyed more people than they converted (they checked the data, and it was true). Two of the three analytics tools hadn't been logged into in 6 months.

They removed the video background, the social proof pop-ups, and the two unused analytics tools. Lighthouse went from 29 to 71 with zero code changes. Then we optimized images and deferred the remaining scripts. Final score: 94. Sign-up rate actually increased because the page loaded fast enough for people to see the CTA before getting bored and leaving.

Where to Start (In Order)

Here's what to do right now, in order.

Step 1: Run Lighthouse. Open Chrome DevTools, go to the Lighthouse tab, run a mobile audit. Note your overall score, LCP, INP, CLS, and TTFB. If you're below 80, keep reading. If you're above 80, you're already ahead of 70% of the web.

Step 2: If you're below 50, start with images and hosting. These are your biggest wins. Convert images to WebP, add lazy loading, and properly size everything. If your TTFB is above 500ms, move hosts. These two changes alone should get you into the 60–75 range.

Step 3: If you're between 50–80, audit third-party scripts. Open the Network tab in DevTools, filter by "JS, " and sort by size. Count everything that's not yours. Remove or defer aggressively. This should push you past 80.

Step 4: If you're above 80 and want to push to 90+, inline critical CSS and defer non-critical stylesheets. This is the polish phase. Tools like critical (npm package) can extract above-the-fold CSS automatically. PurgeCSS removes unused styles.

Step 5: Set up monitoring. Performance degrades over time. New images get added without optimization. Someone installs a new analytics script. A plugin update adds 200KB of JavaScript. Run Lighthouse monthly. Set up a CrUX dashboard to track real-user data. Don't let your score slide back.

"Every byte you send is a choice. If it's not helping someone buy, read, or sign up, it's just making them wait."

So, What Now?

Website speed isn't complicated. It's just unglamorous work that most people skip because redesigning the homepage feels more productive. But slow pages cost you money every day they stay slow. And the fixes are the same for nearly every site.

Images. Third-party scripts. Server response time. Render-blocking resources. Fix those four things and you'll fix 90% of your speed problems. Everything else is incremental.

Open Lighthouse right now. Below 80? Start with images and hosting. Above 80? Audit your third-party scripts. That's genuinely all most sites need.

Your users won't send you a thank-you note for a faster site. They'll just stay longer, click more, and buy more. Which is better than a thank-you note anyway.