Your Images Are Optimized — So Why Is the Website Still Slow?

The hero image is stored as WebP. Its file size looks reasonable. Lighthouse still reports a slow main view, and on a phone the page shows an almost empty space before the image finally appears.

That sounds contradictory, but it is a very common website problem: an image can be compressed and still be delivered incorrectly.

Performance rarely fails because of one large file alone. More often, several small implementation choices make the browser discover the most important image too late, download the wrong size, or reserve its space only after it arrives. Users do not experience that as a technical detail. They experience a slow, unstable, or unfinished website.

Red flag 1: The most important image is lazy-loaded

Lazy loading is useful for images below the fold. Applied to the main hero or product image, it can have the opposite effect.

When the likely largest visible element is requested late, the page waits for a resource that should have started early. The problem becomes worse when the image is hidden behind JavaScript, a carousel, or a CSS background and the browser cannot discover it during the initial HTML parse.

Check whether:

• the first large visible image uses loading="lazy",
• it is inserted only after client hydration or carousel initialization,
• its URL exists only in CSS or a JavaScript object,
• several competing hero images are present in the DOM.

For a genuinely critical image, fetchpriority="high" can provide an additional signal to the browser. MDN also advises using this hint sparingly. If every image is marked important, the prioritization stops being useful.

Red flag 2: Mobile users receive the desktop image

A 2,000-pixel-wide image may be appropriate for a large display. Sending the same file to a phone where it renders at 360 or 430 CSS pixels often wastes bandwidth.

Responsive images are not simply images made smaller with CSS. The browser should be able to choose an appropriate source through srcset and sizes, based on the actual layout and device pixel density. Chrome's guidance is straightforward: pages should avoid serving images that are substantially larger than their rendered size.

A common failure is having a srcset but an inaccurate sizes value. Multiple files exist, yet the browser still selects an oversized source.

In DevTools, inspect more than the visible width. Check:

• the image URL actually selected,
• transferred bytes,
• intrinsic dimensions,
• the evaluated sizes value,
• behavior across viewports and device pixel ratios.

Red flag 3: Width and height are missing

When the browser does not know an image's dimensions, it may be unable to reserve the correct space before the file loads. Text, buttons, and forms then move when the image arrives.

This is not merely cosmetic. A user is about to tap a button, the image appears, and the button moves away. Layout shifts cause accidental clicks and make the interface feel unreliable.

Provide trustworthy width and height attributes or an appropriate aspect ratio. Responsive CSS can still scale the image fluidly. The important part is allowing the browser to calculate the space before the download completes.

Red flag 4: The format is modern, but the encoding is poor

A .webp or .avif extension is not proof of good optimization. A modern image can still be unnecessarily heavy when:

• quality is set much higher than the visible use requires,
• metadata is retained,
• photographic content is encoded losslessly,
• expensive transparency or animation is unnecessary,
• every CMS size points to the same original file.

Chrome recommends combining appropriate dimensions, modern formats, compression, and responsive variants. The useful comparison is not merely “JPEG versus WebP.” It is: what visible quality is required at this specific size and in this context?

Red flag 5: The image pipeline ends at upload

Many websites optimize images once during launch. Afterward, editors upload new files directly from cameras, Canva, or stock libraries. Within months, the homepage is heavy again.

A durable process needs more than a one-time cleanup:

1. upload limits for dimensions and file size,
2. automatic derivatives for relevant breakpoints,
3. sensible quality defaults,
4. modern formats with appropriate fallbacks,
5. defined rules for hero, card, and article images,
6. recurring performance checks after content changes.

A quick self-check

Open your most important landing page in a private browser window, enable mobile network throttling in DevTools, and reload it. Do not look only at the score. Ask:

• Does the most important image appear early, or is there a long empty area?
• Does content move when images arrive?
• Does a phone download a surprisingly large source file?
• Are below-the-fold images loading immediately?
• Is the hero discoverable in HTML, or only after JavaScript runs?
• Are decorative images treated differently from meaningful content images?

This takes only a few minutes and reveals far more than the statement “we already use WebP.”

What Website-Pflichtencheck would inspect

A performance review should examine the entire delivery chain: dimensions, transfer size, formats, srcset, sizes, loading priorities, lazy loading, layout stability, CMS derivatives, caching, and real rendering across viewport sizes.

The goal is not to compress every image as aggressively as possible. It is to deliver the right image, at the right size, at the right time.

If the website still feels slow despite “optimized images,” the problem may not be in the image editor. It may be in the implementation. That is worth reviewing before mobile visitors keep paying the bandwidth cost for pixels they never actually see.