Images are usually the heaviest thing on a website. Not always the most obvious problem. Just the one quietly eating page speed, mobile data, Core Web Vitals, and sales.

That matters because Google says Core Web Vitals measure real-world loading performance, responsiveness, and visual stability, and Google recommends site owners hit good Core Web Vitals for Search and user experience. Images touch two of those three metrics directly: Largest Contentful Paint when the hero image loads, and Cumulative Layout Shift when images don’t reserve space.

For business owners, this is not a nerdy file-size cleanup project. It’s the difference between a site that feels ready and a site that makes people wait. For web professionals, it’s one of the easiest places to find measurable wins.

Here are 55 current website image optimization statistics for 2026, with every number linked to its source so you can cite, share, and use them in planning.

The Big Picture: Images Still Carry the Web’s Weight

  1. The median 2025 home page weighed 2.86 MB on desktop and 2.56 MB on mobile. HTTP Archive’s 2025 Web Almanac found that images made up the largest byte category on both device types. (HTTP Archive)

  2. The median desktop page loaded 1,059 KB of image bytes. The same dataset found a median of 911 KB of image bytes on mobile pages. (HTTP Archive)

  3. Desktop home pages used 239% as many image bytes as comparable inner pages at the median. At the 90th percentile, desktop home pages used 6,856 KB of image bytes, compared with 3,431 KB on inner pages. (HTTP Archive)

  4. The median individual image request was only 8 KB on mobile and desktop. HTTP Archive explains that small tracking pixels can make the median individual image look lighter than the visible images users actually notice. (HTTP Archive)

  5. At the 90th percentile, home page images reached 185 KB per individual image request. Inner-page images reached 123 KB at the same percentile. (HTTP Archive)

  6. Images are the most requested asset type for most websites. Web.dev cites HTTP Archive data and notes that images usually take up more bandwidth than any other resource. (web.dev)

  7. At the 90th percentile, sites send more than 5 MB of images on desktop and mobile. That is before counting JavaScript, CSS, fonts, video, analytics, or ads. (web.dev)

  8. In the 2024 Web Almanac media chapter, 99.9% of more than 10 million scanned pages requested at least one image. In plain English, nearly every modern web page depends on image delivery. (HTTP Archive)

  9. The median mobile page contained 13 image elements in 2024. At the 90th percentile, mobile pages contained 56 image elements. (HTTP Archive)

  10. The largest number of image elements found on one mobile page was 2,174. That is an extreme case, but it shows how quickly templates, product grids, icons, carousels, ads, and tracking images can pile up. (HTTP Archive)

Image Optimization and Core Web Vitals

  1. Google’s recommended LCP target is 2.5 seconds or less for at least 75% of page visits. LCP measures when the largest image or text block becomes visible in the viewport. (web.dev)

  2. Google’s recommended INP target is under 200 milliseconds. INP measures responsiveness after a user clicks, taps, or types. (Google Search Central)

  3. Google’s recommended CLS target is less than 0.1. CLS measures visual stability, which images can hurt when width and height are missing. (Google Search Central)

  4. Mobile Core Web Vitals pass rates rose from 36% in 2023 to 44% in 2024 and 48% in 2025. Desktop pass rates rose from 48% in 2023 to 55% in 2024 and 56% in 2025. (HTTP Archive)

  5. Only 48% of mobile sites had good Core Web Vitals in 2025. That means more than half of mobile origins still had work to do. (HTTP Archive)

  6. In 2025, 74% of desktop pages achieved good LCP, compared with 62% of mobile pages. Mobile also had a higher poor-LCP rate, at 13% versus 7% on desktop. (HTTP Archive)

  7. The 2024 Web Almanac found that 68% of mobile pages had an image as the LCP element. That makes image delivery one of the most common direct paths to LCP improvement. (HTTP Archive)

  8. The 2025 Web Almanac found JPG accounted for 57% of LCP images, while PNG accounted for 26%. WebP reached 11%, while AVIF was still under 1%. (HTTP Archive)

  9. JPG usage for LCP images dropped by 4 percentage points from 2024 to 2025. WebP increased by 4 percentage points over the same period. (HTTP Archive)

  10. Only 17% of mobile pages with LCP images used fetchpriority="high" in 2025. Preload usage for LCP images was much lower, at about 2.1% to 2.2%. (HTTP Archive)

  11. In 2025, 0.3% of pages used fetchpriority="low" on LCP images. HTTP Archive called that likely unintentional, because the LCP image is usually the one image that should not be deprioritized. (HTTP Archive)

  12. Cross-hosted LCP images appeared on 16% to 18% of pages in 2025. HTTP Archive notes that cross-origin LCP images can pay extra DNS, TCP, and TLS connection costs unless mitigated. (HTTP Archive)

  13. Same-host LCP images appeared on 51% of desktop pages and 44% of mobile pages. Keeping the main image on the same host can help the browser reuse an existing connection. (HTTP Archive)

  14. Google breaks LCP into four subparts: TTFB, resource load delay, resource load duration, and element render delay. Compressing a hero image helps only the resource load duration part, so developers still need to check discovery, priority, and rendering. (web.dev)

  15. Google recommends looking at CrUX field data before acting on lab-only LCP results. PageSpeed Insights surfaces real-user CrUX data when enough traffic is available. (web.dev)

Formats: WebP, AVIF, JPG, PNG, and GIF

  1. WebP images are usually 25% to 35% smaller than comparable JPEG and PNG images. Web.dev says this decreases page size and improves performance. (web.dev)

  2. YouTube found that switching to WebP thumbnails resulted in 10% faster page loads. That is a good example because thumbnails are small on their own but large in volume across a real site. (web.dev)

  3. Facebook reported 25% to 35% file-size savings for JPEGs and 80% file-size savings for PNGs after switching to WebP. That is why WebP is often the practical first conversion target for older sites. (web.dev)

  4. In the 2024 Web Almanac, JPEG fell from 40% of all images in 2022 to 32% in 2024. That eight-point drop was the largest absolute format shift in the dataset. (HTTP Archive)

  5. WebP gained three percentage points from 2022 to 2024. SVG gained just under two points, and AVIF gained almost one point. (HTTP Archive)

  6. AVIF usage was almost four times higher in 2024 than in 2022. Adoption was still small, but the growth rate was strong. (HTTP Archive)

  7. The 2024 Web Almanac found the median image weighed 12 KB. That sounds small until you remember that most pages contain many images and at least one large image. (HTTP Archive)

  8. Most mobile pages in 2024 had at least one image of 135 KB or more. The largest image per mobile page was 8% heavier than in 2022. (HTTP Archive)

  9. At the 90th percentile, the largest image on a mobile page was almost exactly 1 MB in 2024. HTTP Archive found the heaviest images were getting heavier faster than the median image. (HTTP Archive)

  10. The median web image was compressed to 2.1 bits per pixel in 2024. HTTP Archive says that was 8% to 10% more compression than the 2022 survey. (HTTP Archive)

  11. Roughly 6.4% of mobile image requests and 6.0% of desktop image requests were 1×1 pixel images in 2024. HTTP Archive says these are most likely tracking beacons and spacer GIFs. (HTTP Archive)

  12. The share of single-pixel images fell by about one percentage point from 2022 to 2024. That is a small but useful sign that old tracking and spacer habits are slowly fading. (HTTP Archive)

Responsive Images, Sizing, and Layout Stability

  1. The median image in the 2024 Web Almanac had 0.058 megapixels, about 240×240 pixels at a square aspect ratio. That was about 25% larger than the previous survey. (HTTP Archive)

  2. Most pages had one image around 0.54 megapixels or larger in 2024. HTTP Archive equated that to roughly 735×735 pixels at a square aspect ratio. (HTTP Archive)

  3. HTTP Archive concluded that many mobile pages send more pixels than the viewport can display. The report specifically points to responsive image markup as the way to avoid that waste. (HTTP Archive)

  4. One third of web images were exactly square in 2024. Only one in eight images were taller than they were wide. (HTTP Archive)

  5. The most common exact image aspect ratio was 1:1, at 33.2% of mobile images. The next most common exact ratios were 4:3 at 3.5% and 3:2 at 2.9%. (HTTP Archive)

  6. Google lists images without dimensions as one of the most common causes of poor CLS. Ads, embeds, dynamic content, and web fonts are also common causes. (web.dev)

  7. Google recommends adding width and height attributes to all image tags. The browser can then reserve space before the image file finishes loading. (web.dev)

  8. Without width and height, image dimensions can default to 0×0 pixels in edge cases. Web.dev warns that galleries can then load more images than expected because the browser thinks they all fit in the viewport. (web.dev)

  9. Lazy loading can save network resources but increase layout-shift risk if image space is not reserved. Google recommends pairing lazy loading with explicit dimensions. (web.dev)

Lazy Loading and Priority Mistakes

  1. Browser-level lazy loading works through the loading attribute on image tags. The two supported values are lazy and eager. (web.dev)

  2. Google says images visible in the first viewport should load normally, especially LCP images. Above-the-fold images should not be lazy-loaded. (web.dev)

  3. Google recommends fetchpriority="high" for important images such as the LCP image. The eager loading value does not make an image load faster than a normal image. (web.dev)

  4. Images far below the viewport can be deferred until the user scrolls near them. That is the main value of native lazy loading on long pages, product grids, galleries, and blog archives. (web.dev)

  5. Chrome changed its lazy-loading distance thresholds in July 2020 from 3000px to 1250px on fast connections and from 4000px to 2500px on slower connections. Google said the change better matched developer expectations. (web.dev)

  6. Browsers that don’t support the loading attribute ignore it. Google says unsupported browsers do not get the lazy-loading benefit, but the attribute does not create a negative impact. (web.dev)

What to Fix First

  1. Start with the LCP element because Google defines LCP as the largest image or text block rendered in the viewport. On many sites, that means the hero image, product image, or top banner. (web.dev)

  2. Use WebP or AVIF for photographic images because modern formats offer better compression than legacy formats. HTTP Archive’s 2025 performance chapter says modern formats reduce file sizes and improve transfer time. (HTTP Archive)

  3. Use lazy loading only below the initial viewport. Google says the browser cannot lazy-load an image until it knows where the image should be, which can slow visible images if used incorrectly. (web.dev)

The Practical Image Optimization Checklist

If you’re auditing a website, don’t start with every image in the media library. Start where users and search engines feel the pain first.

  • Find the LCP image. Use PageSpeed Insights, Chrome DevTools, or WebPageTest, then confirm whether the real-user CrUX data has an LCP problem.
  • Convert old formats. Move JPG and PNG hero and product images to WebP or AVIF, with fallbacks where needed.
  • Set dimensions. Add width and height to image tags so the browser can reserve space.
  • Use responsive markup. Serve the right image size for the screen instead of sending a desktop asset to a mobile viewport.
  • Fix priority. Do not lazy-load the LCP image. Use fetchpriority="high" when the main image needs it.
  • Lazy-load the long tail. Defer images below the first viewport, especially galleries, related posts, reviews, and product grids.

That sequence works because it matches how browsers actually load pages. The first screen matters most. The biggest visible element matters most. The images nobody sees until they scroll can wait.

FAQ

What is image optimization?

Image optimization means reducing file size, choosing the right format, serving the right dimensions, setting image priority correctly, and preventing layout shifts. Google ties these decisions directly to LCP and CLS through its Core Web Vitals guidance. (Google Search Central)

Are WebP images still worth using in 2026?

Yes. Web.dev says WebP images are usually 25% to 35% smaller than comparable JPEG and PNG files, and the 2025 Web Almanac found WebP adoption for LCP images increased from 2024 to 2025. (web.dev, HTTP Archive)

Is AVIF better than WebP?

AVIF can produce smaller files for many photographic images, but the practical answer depends on your tooling, quality settings, browser support needs, and fallback setup. HTTP Archive found AVIF usage grew nearly four times from 2022 to 2024, but WebP remains much more common. (HTTP Archive)

Should I lazy-load every image?

No. Google recommends eager loading images visible in the first viewport, especially the LCP image, and using lazy loading for offscreen images. (web.dev)

What image problem should a small business fix first?

Fix the top-of-page image on your most valuable pages first: home page, service pages, product pages, quote-request pages, and landing pages. If that image is the LCP element, it can affect the user’s first impression and Google’s loading-performance metric. (web.dev)

Need Help Fixing Image Speed Problems?

A lot of small business websites don’t need a rebuild. They need someone to find the heavy images, broken templates, slow hero sections, and old media habits that are costing them leads.

Your Web Team helps business owners clean up the technical problems that make websites slow, clunky, and hard to grow. If your site feels heavier than it should, start here and we’ll take a look.