Why Is My Website Slow? Lighthouse Score, Core Web Vitals & the Real Fix

Google's own research found that 53% of mobile visitors abandon a page that takes longer than three seconds to load. Amazon has separately reported that every 100 milliseconds of added latency measurably costs them sales. Speed isn't a vanity metric — it directly affects whether visitors stay, convert, or leave.

So when a site feels slow, the instinct is usually to blame the hosting provider, the JavaScript framework, or "too many plugins." Sometimes that's true. But for the overwhelming majority of websites, the actual bottleneck is something far more mundane: unoptimized images.

What Lighthouse actually measures

Lighthouse is Google's built-in auditing tool (in Chrome DevTools, or at pagespeed.web.dev). It loads your page the way a real visitor would, measures what happens, and produces a score from 0 to 100. Google treats anything in the 90-100 range as "good," 50-89 as "needs improvement," and below 50 as "poor."

That single number is a composite of several underlying metrics, three of which Google calls Core Web Vitals — the metrics that matter enough to directly factor into Google Search ranking:

Of these three, LCP is the one images influence most directly — because the largest visible element on most pages is an image: a hero banner, a product photo, a blog cover image. If that file is heavy, LCP is slow, no matter how fast your server responds or how clean your code is.

Why images are usually the real culprit

On a typical website, images account for more total page weight than HTML, CSS, and JavaScript combined. A single unoptimized hero photo straight off a phone or DSLR can easily be 3-5MB. Browsers have to fully download that file before they can paint it on screen — and on a mobile connection, a multi-megabyte image can single-handedly blow past Google's 2.5-second LCP target.

Lighthouse knows this, which is why several of its most common warnings are image-specific:

• "Serve images in next-gen formats" — flags PNG/JPEG files that would be significantly smaller as WebP or AVIF
• "Properly size images" — flags images larger than the dimensions they're actually displayed at
• "Efficiently encode images" — flags images compressed at a higher quality setting than necessary

All three point at the same root cause, and all three have the same fix: smaller image files.

How much difference format choice actually makes

Format choice alone — without touching dimensions or visual quality — typically produces the biggest single improvement available to most sites:

A smaller LCP image translates almost directly into a faster LCP time — there's no ambiguity about whether it "helps," the browser simply has fewer bytes to download before it can paint. Exact savings depend on your source images and quality settings. For more detail on when to use each format, see our full AVIF vs WebP vs PNG vs JPEG comparison.

Implementing it without breaking older browsers

You don't have to choose one format and abandon compatibility. The standard pattern is the HTML <picture> element, which lets the browser pick the best format it supports:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Description" loading="lazy" />
</picture>

Modern browsers load the AVIF version, older ones fall back to WebP, and anything ancient still gets a working JPEG. If you're on Next.js, the built-in next/image component already does this automatically — no manual markup required.

The part that actually takes time: converting your existing library

Implementing the <picture> tag is five minutes of work. The real friction is converting hundreds or thousands of existing JPEG and PNG files you already have sitting in a media library. This is where most teams get stuck, because the common options are all painful in their own way:

• Online converters impose per-file size limits and process images one at a time
• Cloud image services require uploading your entire library to a third party, which raises both privacy questions and recurring cost
• Command-line tools work, but require comfort with the terminal and scripting

This is exactly the gap a local-first tool like TinyPixels fills. You drag your entire image folder in, pick WebP or AVIF as the target format, and it converts everything using your machine's own CPU cores — nothing leaves your computer, there's no upload step to wait on, and there's no per-file cap. Run it once against your media library and you've addressed the "Serve images in next-gen formats" warning across your entire site in one pass.

A practical checklist

None of this requires a server migration, a framework rewrite, or a performance consultant. For most sites, fixing image format and size alone resolves the majority of what Lighthouse is complaining about.

Frequently asked questions