Why Images Matter

Images are heavy

Open any typical web page in your browser's network panel and sort the requests by size. Chances are the largest entries are images — often by a wide margin. According to the HTTP Archive, images account for roughly 40–50% of the total bytes transferred on median pages. The median desktop page ships around 1,000 KB of image data; the median mobile page is only slightly lighter, and both figures have grown substantially over the past decade.

Every kilobyte of image data has a real cost:

• Time — bytes in transit delay rendering. On a 4G connection at 10 Mbit/s a 1 MB image takes around 0.8 seconds to download — before the browser even starts decoding it.
• Money — mobile data plans are not unlimited worldwide. Users in many markets pay per megabyte, and you are spending their budget when your page loads unnecessary images.
• CPU and battery — decoding large images is compute-intensive. On low-end devices it can cause visible jank; on any device it drains the battery faster.
• Carbon — data transmission has an energy cost. Fewer bytes transferred means less energy consumed in transit and in data centres.

A typical page payload breakdown

The chart below shows approximate median byte-sizes for the main resource categories on a modern web page (based on HTTP Archive data). Images dominate.

Images affect outcomes

Page speed is not an abstract engineering metric — it has direct, measurable effects on whether people stay on your site, complete tasks, and convert.

Google's research consistently shows that pages loading in one second have conversion rates three times higher than pages that take five seconds. Bounce rates rise sharply with every additional second of load time, especially on mobile. For e-commerce, media, and news sites the correlation between image-heavy pages and poor engagement is well documented.

Google formalised image performance into its Core Web Vitals framework — a set of metrics that directly influence search ranking:

• Largest Contentful Paint (LCP) — measures how quickly the largest visible element renders. On most pages, the LCP element is a hero image or a large banner photograph. A good LCP score is under 2.5 seconds. A slow-loading hero image is the single most common cause of poor LCP.
• Cumulative Layout Shift (CLS) — measures how much the page layout jumps as resources load. An image without declared width and height attributes causes the browser to reserve zero height for it initially; when the file arrives the page reflows, pushing content down and disorienting the reader.

Both metrics are addressed in detail in Tutorial 09: Performance & Loading. The key insight here: images are the primary lever for both metrics. Fixing image weight and image loading order is the highest-impact performance work on most pages.

Pages that perform best in Core Web Vitals tend to share a pattern: they use fewer images, the images they do use are aggressively compressed and sized, and above-the-fold images are explicitly prioritised while everything below is deferred.

A framework for image decisions

Every image on a page is a choice. The most effective mental model is a four-step funnel — you should move down only when the step above is exhausted:

1. Eliminate

   Ask first: is this image necessary? Can the design achieve its goal through typography, color, whitespace, or CSS alone? A decorative stock photo that "makes the page feel warmer" but adds 200 KB for every visitor is often better removed than optimised. Fewer images is always faster.

2. Reduce count

   If you need multiple images, look for opportunities to combine them. CSS sprites pack many small images into one file, trading multiple small requests for one slightly larger one. Icon fonts or inline SVG can replace a directory of image files entirely. Fewer requests matters less under HTTP/2 than it used to, but combining images still reduces per-request overhead. See Tutorial 11: Optimization & Delivery for patterns.

3. Reduce size

   Once you have committed to an image, squeeze it as small as possible without unacceptable quality loss:

   • Choose the right format — AVIF and WebP can be 50% smaller than JPEG at equivalent quality. See Tutorial 04: Raster Formats and Tutorial 05: Choosing a Format.
   • Scale to the display size — serving a 3000-pixel image that will be displayed at 600 pixels wastes 25× the pixels. Match the image's intrinsic dimensions to its rendered size.
   • Compress aggressively — JPEG quality 75–80 is typically indistinguishable from quality 95 at a fraction of the file size. See Tutorial 11.

4. Load when needed

   Even an optimally sized, perfectly formatted image should not be downloaded until it is actually needed:

   • Lazy loading — loading="lazy" defers off-screen images until the user scrolls near them, saving bandwidth for images never seen.
   • Priority loading — fetchpriority="high" tells the browser to fetch the LCP hero image as early as possible, before it would otherwise be discovered.
   • Preloading — a <link rel="preload"> in the <head> starts the fetch before the parser reaches the <img> tag.

   These techniques are covered in depth in Tutorial 09: Performance & Loading.

The golden rule

The four-step framework condenses into a single principle that you should apply to every image decision you make as a developer:

Each clause maps directly to the tutorials in this series:

• Less data — choose a modern format (AVIF/WebP) and compress well. See Tutorial 04, Tutorial 05, and Tutorial 11.
• Less often — serve one image that works at multiple sizes using srcset/sizes, rather than many per-device variants managed separately. See Tutorial 06.
• When needed — lazy-load off-screen images; prioritise the LCP element. See Tutorial 09.
• From nearby — use an image CDN or edge network so bytes travel the shortest possible path from server to user. See Tutorial 11.

Keep this rule visible as you work through the rest of the series. Every technique you learn is ultimately a way to satisfy one or more of these four clauses.