Image File Size Targets: How Big Should Web Images Be for Mobile Speed?

There is no official limit for web image file size. Core Web Vitals measure timing, not kilobytes, so no file size is required to pass them. What exists are rules of thumb: a full-width hero photo often lands around 60 to 200 KB, an image inside an article tens of KB, a thumbnail a few KB to a few tens of KB, and an icon or logo a few KB, usually as SVG. Those numbers are starting points to test, not limits, and the right target depends on the picture and on your visitors' connections.

This guide is for site owners and developers who want a defensible size for each image, with ways to measure and budget. The Core Web Vitals "good" thresholds are LCP at or under 2.5 seconds, CLS at or under 0.1 and INP at or under 200 ms, each at the 75th percentile of page loads. Image weight mostly affects LCP.

Before you begin

You will need a short list of your most important pages, Chrome or another browser with developer tools (ideally also a real phone), access to the image files or template code, and about an hour. The main risk is squeezing images so hard that they look poor, so change one group at a time and compare before and after.

Why bytes matter on mobile networks

Connection speed in megabits per second (Mbps) counts bits, and eight bits make a byte. So transfer time is roughly file size in kilobits divided by speed in kilobits per second. The table is plain arithmetic, using 1 KB as 1,000 bytes, with three example speeds.

File size	At 1.6 Mbps	At 5 Mbps	At 20 Mbps
100 KB	0.5 s	0.16 s	0.04 s
200 KB	1.0 s	0.32 s	0.08 s
500 KB	2.5 s	0.8 s	0.2 s
1 MB	5.0 s	1.6 s	0.4 s
2 MB	10 s	3.2 s	0.8 s

These figures are illustrative. They count only transfer time, ignore connection set-up, latency and server time, and assume the image has the whole connection to itself, which it never does. Real mobile speeds vary a lot. The point is the shape: halving the bytes roughly halves the transfer time.

Page weight and the hero image

Page weight is the total bytes a page downloads: HTML, CSS, JavaScript, fonts, images and more. Images are often a large share, but measure your own pages instead of assuming.

The hero image is the large picture at the top of a page. It is often the element that Largest Contentful Paint measures. According to web.dev, LCP time breaks into four parts: time to first byte, resource load delay, resource load duration and element render delay. Image bytes mostly affect the third part. Shrinking a hero image helps only if the other parts are not the bottleneck, so also check that it is discovered early and not lazily loaded. See Fix Largest Contentful Paint (LCP) on Mobile for the full diagnosis.

Web image file size by role: rules of thumb

These ranges are rules of thumb, not official limits. They assume photographs in modern formats (WebP, AVIF or well-tuned JPEG) at mobile-appropriate dimensions. Flat graphics are often far smaller, and very detailed photographs can run larger.

Image role	Displayed width on a phone (CSS px)	Intrinsic width to serve	Rule-of-thumb size
Hero or banner photo	Full width, about 360 to 430	About 800 to 1,200	About 60 to 200 KB
Image inside an article	About 340 to 400	About 700 to 800	About 30 to 120 KB
Card image or thumbnail	About 100 to 180	About 200 to 400	About 5 to 30 KB
Avatar or profile photo	About 40 to 64	About 100 to 200	About 2 to 10 KB
Logo or icon	Varies	Use SVG where possible	Often 1 to 5 KB as SVG
Decorative background	Full width	About 800 to 1,200	As small as you can; or use CSS

A detailed hero photo may need more than 200 KB to look good, and that can be fine: a rule of thumb is a prompt to ask why, not a failure condition. Many small files also add up: thirty thumbnails at 25 KB is 750 KB.

What changes file size

Four things drive the number of bytes: pixel dimensions, format, quality setting and image content (noise, texture and fine detail cost more than flat areas). Pixel dimensions come first: halving an image's width and height leaves a quarter of the pixels, and file size typically falls by a large amount, though not exactly a quarter. For format choices see Use WebP and AVIF Images to Improve Website Speed, and check AVIF support at caniuse.com.

Displayed size, intrinsic size and 2x/3x screens

Intrinsic size is the pixel dimensions stored in the file. Displayed size is the width and height of the box the image fills on the page, measured in CSS pixels, the unit the browser uses for layout. Device pixel ratio (DPR) is how many physical screen pixels make up one CSS pixel along each side. A 2x screen has a DPR of 2, a 3x screen has 3, and a plain desktop monitor is often 1.

To look sharp, an image needs roughly displayed width multiplied by DPR in pixels. An image shown 390 CSS pixels wide needs about 390 pixels at 1x, 780 at 2x and 1,170 at 3x. Many phones are 2x or 3x, but you do not have to serve full 3x pixels. Higher-DPR images can often be compressed more strongly, because the extra pixels are tiny and artifacts are harder to see, so many teams cap delivery at 2x. Test on a real phone and decide.

The waste to look for is an intrinsic size much larger than displayed size times DPR. A 3,000-pixel-wide photo shown at 390 CSS px on a 3x phone needs about 1,170 pixels; the rest is wasted data. Do not enlarge either: a 400-pixel file stretched to an 800 CSS px box adds nothing but blur.

Sizing with srcset and sizes

Because screens differ, serve several widths and let the browser choose:

<img
  src="/img/hero-800.webp"
  srcset="/img/hero-480.webp 480w,
          /img/hero-800.webp 800w,
          /img/hero-1200.webp 1200w,
          /img/hero-1600.webp 1600w"
  sizes="(min-width: 1024px) 800px, 100vw"
  width="1200" height="800"
  alt="Wooden desk with a laptop and notebook"
  fetchpriority="high">

Each w value is the image file's width in pixels. The sizes attribute tells the browser how wide the image will be displayed: here 800 CSS pixels on viewports 1,024 pixels wide or more, otherwise the full viewport width (100vw). The browser multiplies by DPR and picks the closest candidate. A handful of widths, often four to six, is enough.

The width and height attributes let the browser reserve space, which prevents layout shift (CLS). fetchpriority="high" asks the browser to fetch the hero image sooner; check caniuse.com for browser support. Never put loading="lazy" on the hero. Details are in Responsive Images with srcset and sizes: Serve the Right Size and Lazy Loading Images for SEO: Defer Images Without Hiding Them.

Measure with DevTools and Lighthouse

Network tab. Open Chrome DevTools, go to Network, tick "Disable cache", filter by "Img" and reload. The Size column shows the bytes transferred over the network on its top line and the uncompressed resource size beneath it. Sort by Size to see the heaviest images first. Use the throttling dropdown to simulate a slower connection.

Displayed vs intrinsic. In the Elements panel, hover over an <img> tag to see its rendered size and intrinsic size. To check every image at once, paste this into the Console:

console.table([...document.images].map((i) => ({
  src: i.currentSrc.split("/").pop(),
  intrinsic: i.naturalWidth + "x" + i.naturalHeight,
  displayed: i.clientWidth + "x" + i.clientHeight,
  dpr: window.devicePixelRatio,
  oversize: i.clientWidth
    ? (i.naturalWidth / (i.clientWidth * window.devicePixelRatio)).toFixed(2)
    : "n/a"
})));

An oversize value well above 1 means the file has more pixels than the screen needed. Use DevTools device mode to try phone-sized screens.

Lighthouse. Run it in Chrome DevTools or from the command line and read its image audits, such as those about properly sized images and modern formats. Audit names change between versions. Lighthouse is a lab test; see Mobile Lighthouse Score Lower Than Desktop? Fix the Right Issues for the mobile gap.

Budget worksheet

A budget is a limit you choose and then check. Here is a way to build one.

Choose a connection and an arrival time (your own assumptions).
Convert to bytes. At 5 Mbps, one second moves about 5,000 kilobits, about 625 KB, if nothing else is downloading.
Subtract room for HTML, CSS, JavaScript and fonts. If those use half, about 300 KB is left for images.
Split what remains, for example 150 KB for the hero and 150 KB for the rest of the first view.

This is an example of the method, not a recommendation. Copy this table and fill it in for your key pages:

Image	Role	Displayed width (CSS px)	DPR to serve	Needed intrinsic width	Format	Target KB	Actual KB	Pass?
Example: home hero	Hero	390	2x	780	WebP	150
Example: team thumbnail	Thumbnail	120	2x	240	WebP	15

Needed intrinsic width is displayed width times DPR. To enforce a budget automatically, see Lighthouse CI and Performance Budgets: Catch Regressions Early.

Step-by-step instructions

Step 1: Record current sizes

Open two to five important pages at phone size. Use the Network tab and the Console snippet to write down each above-the-fold image's transferred KB, intrinsic size, displayed size and oversize ratio.

What success looks like: your worksheet has an Actual KB for every image on the list.

Step 2: Set targets by role

Start from the rules of thumb above, then adjust for your pictures. Write a target KB for each row.

What success looks like: every row has a target you can explain.

Step 3: Fix dimensions before quality

Resize any image whose intrinsic size is far above displayed width times DPR, and add srcset and sizes where one file serves very different screens.

What success looks like: oversize ratios are close to 1.

Step 4: Adjust format and quality, then re-measure

If an image still misses its target, try a more efficient format or a slightly lower quality, and compare with the original on a phone. Reload with the cache disabled, run Lighthouse and note the changes.

What success looks like: each image meets its target or has a written reason it does not.

Final verification checklist

Each important image has a target size and a reason for it.
No image has an intrinsic width far above displayed width times the DPR you serve.
Images are not enlarged beyond their intrinsic size.
The hero image is not lazily loaded and, if it is the LCP element, is discovered early.
Large images use srcset and sizes, or another responsive technique.
Images have width, height and meaningful alt text.
Before and after sizes are recorded, with at least one visual check on a real phone.

Common mistakes to avoid

Treating rules of thumb as official limits. There is no standard size cap. Use the ranges to start a conversation, then test.
Measuring on a fast office connection only. Throttle the network or test on a phone.
Optimising a below-the-fold image while the hero is 2 MB. Start with the largest above-the-fold file.

Frequently asked questions

How big should a web image be?

There is no official size. As a rule of thumb, a full-width hero photo is often around 60 to 200 KB, an in-article image around 30 to 120 KB, and a thumbnail under about 30 KB, in WebP, AVIF or well-tuned JPEG. Detailed photographs may need more, so judge by how the image looks as well as by bytes.

Is 1 MB too big for an image?

For most pages a 1 MB image is larger than needed: by the arithmetic above it takes about 1.6 seconds at 5 Mbps on its own. A page image can usually be made much smaller by resizing and compressing.

What is the difference between displayed size and intrinsic size?

Displayed size is the box an image fills on the page, in CSS pixels. Intrinsic size is the pixel dimensions stored in the file. Wasted bytes appear when the second is much larger than the first times the screen density.

Should I use 2x or 3x images for phones?

Many phones are 2x or 3x. Serving about displayed width times 2 is a common compromise, and 3x pixels can often be compressed harder. Test on a real device and decide.

Do I need a performance budget for images?

It helps, because it turns "make it smaller" into a number you can check. Start with the worksheet above.

Do smaller images improve SEO?

Smaller images can make pages load faster, which can help metrics such as LCP. Search ranking depends on many signals, so smaller files cannot promise a ranking change.

Using Crawvix

Crawvix's Image Doctor can show you which images to look at first. It lists the images written into the HTML of the pages of a full scan of a verified website (up to 2,000), checks up to 200 of them for status, type and file size, and reports missing or generic alt text, broken images, large files, missing width and height, a lazily loaded first image, older formats and generic file names. Each finding includes evidence and what to do, and there is a CSV export you can paste into the worksheet. It only reads a website and never changes it.

Official references

Next step: Run Image Doctor to see which images on your verified website are large, in older formats or missing dimensions, or scan the whole site with Crawvix. This guide provides technical information, not a guarantee of rankings, traffic or indexing.