Why Image Optimization is the Secret to 1-Second Load Times

Images are often the heaviest assets on a page. A single photo straight from a phone camera can be several megabytes, which is more than the rest of the page combined. If images are not optimized they slow down your Largest Contentful Paint (LCP), the Core Web Vital that measures when the main content becomes visible.

Google treats 2.5 seconds or less as a good LCP. On many pages the LCP element is an image: a hero banner, a product photo or an article's lead image. That is why image work tends to move the needle more than almost any other front-end change, and why it is the first thing to look at when a page feels slow.

A one-second load is an ambitious target, and images alone will not get every page there. But a page with heavy images will not get close, however good the rest of the code is.

Do not optimize blindly. Ten minutes of measuring tells you which images are worth your time.

1. Run your most visited pages through PageSpeed Insights or Lighthouse (built into Chrome DevTools). Note the LCP element and any warnings about image size or format.
2. Open the Network tab in DevTools, filter by images and sort by size. The largest three or four files are usually where most of the weight is.
3. Compare each image's intrinsic size with the size it is displayed at. A 3000-pixel-wide file shown in an 800-pixel column is wasting most of its bytes.

Write the numbers down so you can compare them after the changes.

Nearly every image problem comes down to one of three things:

• Resize before upload: do not serve a 4000px-wide photo into an 800px container.
• Compress smartly: lower the quality setting until you can just see a difference, then go one step back.
• Use a modern format: WebP for most photos and graphics.

You can do all three in the browser. The Image Resizer scales an image to the dimensions you need and lets you set the output quality. The WebP Converter converts JPEG and PNG files to WebP, several at a time. The Image Optimizer combines resizing, compression and format conversion in one step. Images are processed in your browser, so nothing needs to be installed.

As a starting point, try a quality setting of around 75–85 for photos. Below that, artifacts start to show around edges and text; above it, file size grows quickly with little visible benefit.

A frequent mistake is a logo exported as a large PNG when an SVG would be a few kilobytes. If you need the opposite, for example a raster version of a vector logo for a platform that does not accept SVG, use the SVG to PNG converter. For the small icon in the browser tab, the Favicon Generator creates the sizes you need from one source image.

A phone does not need the same file as a desktop monitor. With the srcset and sizes attributes you give the browser a list of versions and let it pick the smallest one that still looks sharp:

<img
  src="/images/team-800.webp"
  srcset="/images/team-400.webp 400w,
          /images/team-800.webp 800w,
          /images/team-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="533"
  alt="Support team at their desks"
/>

Three widths are enough for most layouts: one for phones, one for the normal desktop size and one at double that for high-density screens. Export each version with the Image Resizer, then list them in srcset.

Always include width and height. The browser uses them to reserve space before the image arrives, which prevents the layout from jumping and keeps your Cumulative Layout Shift (CLS) low.

The browser cannot know which image matters most unless you tell it. Two attributes do that:

<!-- Main above-the-fold image: load it first -->
<img src="/images/hero-1200.webp" width="1200" height="600"
     fetchpriority="high" alt="..." />

<!-- Images further down the page: load them when needed -->
<img src="/images/chart-800.webp" width="800" height="450"
     loading="lazy" alt="..." />

• loading="lazy" delays images until the visitor scrolls near them. Use it for everything below the fold.
• fetchpriority="high" asks the browser to fetch the main image early. Use it on one image per page.
• Never lazy-load the LCP image. It is one of the most common reasons for a slow LCP on otherwise well-built pages.
• Avoid setting the hero image as a CSS background if you can; the browser discovers it later than an <img> tag in the HTML.

For a typical content page on a fast connection, the path toward a one-second LCP looks like this:

1. Audit your heaviest pages and list the largest images (see above).
2. Resize each image to the largest size it is displayed at, plus a double-width version for high-density screens.
3. Convert and compress to WebP at a quality of around 80, and check the result by eye.
4. Name files descriptively, for example blue-running-shoes.webp instead of IMG_4821.webp. The Slug Generator makes clean, hyphenated names.
5. Update the markup: add srcset, width, height, alt text and the right loading attributes.
6. Serve with long cache lifetimes, ideally from a CDN, so returning visitors do not download the same files again.
7. Measure again and compare with your starting numbers.

If LCP is still slow after this, the cause is probably elsewhere: slow server response, render-blocking CSS or JavaScript, or web fonts. Image work is one part of launch readiness; the 2026 SEO checklist for new websites covers the rest.

• Uploading originals and letting CSS shrink them. The visitor still downloads the full file.
• Saving photos as PNG. Use WebP or JPEG unless you need lossless output.
• Compressing an already compressed file again and again. Keep the original and always export from it.
• Missing dimensions, which causes layout shift.
• Text inside images. It blurs when compressed and search engines and screen readers cannot read it reliably. Use real text.
• Empty or stuffed alt text. Describe what the image shows in a short sentence; leave alt empty only for purely decorative images.
• Autoplaying animated GIFs. They are often several megabytes; a short muted video is usually far smaller.