Why My Website Loaded So Slow (Until I Fixed My Images)

What PageSpeed Insights Actually Showed Me

I ranGoogle PageSpeed Insightson my homepage URL. The Opportunities section was long. Every image on the page was flagged. The specific numbers:

Why Phone Photos Are So Large

My phone shoots at 4032×3024 pixels. My site displays images at maximum 800 pixels wide. The browser downloaded the full 4032px image — 25× more pixels than it displayed — then downscaled it on-screen. That is 25× the data transfer for zero quality benefit. The waste hides because the page still looks fine once everything settles. The cost shows up on the mobile connection, where those extra megabytes are the difference between a page that loads and a page that spins.

Resizing to the actual display dimensions is the single highest-impact step. A 4032×3024 photo scaled to 800×600 drops from roughly 4MB to 300KB before any compression — just from having fewer pixels to encode.

Why WebP Beats JPEG for Web Images

According toGoogle's WebP study, WebP files are 25–34% smaller than JPEG at equivalent visual quality. That is not a marketing claim. It reflects a genuinely more efficient compression algorithm. The same image, the same quality setting, always produces a smaller WebP file than a JPEG. If you want the deeper codec comparison before you commit, our image compression guide explains what lossy and lossless actually mean at the byte level.

Browser support for WebP is now essentially universal: Chrome, Firefox, Safari 14+, Edge, and Opera all support it. The only remaining reason to serve JPEG is compatibility with very old systems — which rarely applies to web portfolios.

Why This Actually Moves the Needle on Google's Ranking Signals

It is worth explaining why fixing images specifically, rather than any other part of the page, made the biggest visible difference. Google's Core Web Vitals measure three things: how fast the largest visible element loads (Largest Contentful Paint, or LCP), how stable the layout is while loading (Cumulative Layout Shift), and how quickly the page responds to input. On most content and portfolio pages, the largest visible element is a hero image. That means LCP, the metric with the most direct line to perceived speed, is very often just “how long does the biggest image take to arrive.” Shrinking that one file has an outsized effect on the score compared to trimming a few kilobytes of JavaScript elsewhere.

Google's own LCP guidance lists “good” as under 2.5 seconds. A 3.2MB unoptimized hero image on an average mobile connection will blow past that on its own, before the browser has rendered anything else on the page.

The Three-Step Fix

Step 1: Find Your Display Dimensions

Right-click any image on your site in Chrome > Inspect > look at the Computed styles panel for width and height. Or hover over an img element in DevTools — the tooltip shows intrinsic size vs rendered size. If intrinsic is 4032px and rendered is 800px, you have a 25× waste.

Step 2: Resize to Display Width

Resize images to 1.5–2× the maximum display width to support retina screens. If an image displays at 800px wide, resize to 1200px. This handles 2× pixel density displays without serving unnecessarily large files.

Step 3: Convert to WebP at 80–85% Quality

An 800px resized image typically needs to be under 150KB. WebP at 80% quality achieves this for most photographic content without visible quality loss. Use ourimage compressorto convert and compress in the browser — processed locally.

What Else Affects Page Speed

Lazy Loading Below-the-Fold Images

<!-- loading="lazy" defers image download until near viewport --><img  src="project-screenshot.webp"  alt="Project screenshot"  width="800"  height="600"  loading="lazy"     /* Only loads when close to the viewport *//> <!-- Always include width and height to prevent layout shift (CLS) --><!-- Without these, the page reflows when the image loads -->

Responsive Images with srcset

<!-- Serve different sizes based on device — no JS needed --><img  src="hero-800.webp"  srcset="    hero-400.webp 400w,    hero-800.webp 800w,    hero-1200.webp 1200w  "  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"  alt="Hero image"  width="1200"  height="600"/><!-- Mobile devices get the 400w version → faster load on 4G -->

The Quick Summary

For a deeper technical understanding of image compression — what lossy and lossless mean, what quality settings actually change at the codec level — read our image compression guide. For the format comparison (WebP vs AVIF vs JPEG) that determines which format to serve in 2026, our AVIF vs WebP guide covers the browser support and compression efficiency differences.

None of these numbers are guesses. The 2025 HTTP Archive Web Almanac found that a typical home page now runs somewhere around 2.7–2.9 MB, and images make up the single largest share of that weight. That is exactly why fixing image size fixes load time faster than almost anything else. Google's own WebP documentation and the web.dev image guide go deeper into the format-level tradeoffs. The next time a client asks why their site is slow, skip the server audit. Open DevTools, sort by image size, and ask one question: why is a file this big being sent to a screen this small?