Image SEO file size has no fixed number: Google does not publish a byte limit for images, so the working target is the page’s LCP of 2.5 seconds or less. In practice that means serving each image at the width it renders, in AVIF or WebP, with the hero given priority. Here is the decision table, the sourced thresholds and the settings.
| What you are sending | The limit you hit | The Smol setting |
|---|---|---|
| Hero or banner that is the LCP element | LCP over 2.5 s at the 75th percentile | Compress, output AVIF, maximum width = rendered width x 2 for retina, quality 60 to start |
| In-article and gallery images | Page weight; slow image load duration | Compress, output WebP or AVIF, width to the layout column, quality 65 to 75 |
| Client-supplied PNG or camera JPEG | Oversized pixels, not just bytes | Resize first (fit mode), then set quality |
| Screenshots and UI graphics | Large PNGs on docs and landing pages | Compress to the same format or WebP; inspect text edges |
| Images that must keep alt text and EXIF out | Privacy and clean files | Metadata is stripped by default; alt text lives in your HTML, not the file |
What is the right image SEO file size?
There is no ranking threshold in kilobytes. Google’s image guidance states no numeric file-size limit; it notes that images are often the largest contributor to overall page size. The measurable proxy is the page’s vitals, which Google states its ranking systems use, while also saying good scores do not guarantee a top position.
So set a byte budget per template instead of per image, then verify it with field data. Treat any kilobyte figure you hear as a starting point for your own pages, not a rule. The same logic applies to image optimization for SEO in general: smaller images help only when they move LCP or page weight on pages that currently fail.
Which sourced thresholds should you audit against?
Audit against these five published figures, each from Google or web.dev. They are the targets your file sizes serve.
| Item | Figure | Source |
|---|---|---|
| LCP, good / poor | 2.5 s or less / above 4.0 s, at the 75th percentile, mobile and desktop segmented | web.dev LCP |
| LCP breakdown | About 40% first byte, under 10% load delay, about 40% load duration, under 10% render delay | web.dev optimize LCP |
| CLS, good / poor | 0.1 or less / above 0.25 | web.dev CLS |
| Formats Google Search supports | BMP, GIF, JPEG, PNG, WebP, SVG, AVIF | Search Central |
| fetchpriority guidance | High on one or two images at most; never lazy-load the LCP image | web.dev optimize LCP |
The breakdown matters for file size: roughly 40% of the LCP budget is load duration, the part a smaller file shortens. The other subparts are server, discovery and rendering problems that compression cannot fix.
How do you shrink a largest contentful paint image?
Cut pixels to the rendered size first, then pick the format and quality. An <img>, a video poster or a CSS background image can all be the LCP element, per web.dev. If the hero renders 720 pixels wide, a 4,000 pixel source wastes most of its bytes.
- Keep the LCP image in the initial HTML, not behind a lazy-load, and give only it
fetchpriority="high". - Export at the rendered width, or twice that for high-density screens, and no larger.
- Serve AVIF or WebP with a JPEG fallback in
<picture>if your audience needs one. - Set
widthandheighton every image so layout does not shift. In our Core Web Vitals test, one unsized image produced a CLS of 0.1577 on desktop and 0.1842 on a phone, and 0 once sized.
Smol handles the pixel and byte part. Priority, preload and dimensions belong in your templates, covered in our guide for web developers.
WebP vs AVIF for SEO: which should you ship?
Google Search lists both as supported formats, so the difference that matters is bytes: web.dev says WebP and AVIF “will generally provide better compression than older formats”, and its format guide notes colors in lossy output may differ from an equivalent JPEG.
In our own measurement with command-line encoders, AVIF was 23 to 39% smaller than a well-encoded JPEG at equal perceptual quality on four photos, and WebP ranged from 23% smaller to 3% larger. Smol’s numbers are separate: its AVIF needed 22 to 26% fewer bytes than the best JPEG at the same SSIMULACRA2 score, on the benchmark of 24 small 768 × 512 photographs. At default settings, compressing those PNGs to AVIF at quality 65 saved 92.1%. Those are small images; your hero will differ, so compare real files.
Practical rule: AVIF for photos where you can afford its encode time, WebP when a tool or platform you use does not accept AVIF, JPG when a system downstream cannot read the others. Our AVIF converter page and PNG to WebP guide cover the mechanics.
Which settings give the right image size for page speed?
Set output format and maximum width first, then quality. Quality numbers below are starting points we chose, not measured thresholds; check the output and the rendered result.
| Image role | Format | Quality | Maximum dimension |
|---|---|---|---|
| LCP hero photo | AVIF | 60 (starting point) | Rendered width x 2 |
| Blog or product photo | WebP or AVIF | 65 to 75 | Column width x 2 |
| Thumbnail | WebP | 70 | Thumbnail width x 2 |
| UI screenshot | WebP or original format | 75; check text edges | Rendered width x 2 |
| Fallback for old systems | JPG | 75 (default) | Same as above |
One job produces one size. For a srcset ladder, run separate jobs at each width and rename the outputs, because the default name is name_compressed.ext each time. Smol does not generate a responsive set from one run. Google asks for a src fallback whenever you use srcset. Running this across client sites? See our pages for web agencies and WordPress sites.
Do filenames and alt text matter as much as bytes?
Yes, for image search. Search Central calls alt text the most important image attribute and prefers short descriptive filenames over IMG00023.JPG. Rename before you compress so the suffix is the only change. Smol never writes alt text.
How do you optimize a folder of site images on a Mac?
Pull the real rendered widths from the page
Use DevTools to read each image’s displayed width, and list your LCP image per template.
Copy the source folder
Originals stay untouched by default; Smol writes a copy with a
_compressedsuffix.Drag the folder in and set format and width
Choose AVIF or WebP, set the maximum dimension, keep fit mode so nothing is cropped.
Run and read per-file sizes
Smol shows before and after for each file. Sort by size and re-run outliers at a lower quality.
Inspect the hero at 100%
Look for banding in skies and softness in text before it ships.
Upload and re-test
Run PageSpeed Insights or your field data and confirm LCP moved. Smol sets quality and pixels, not bytes, so measure the result.
What do SEOs use today, and how does Smol compare?
Start with what you already have. Built-in and free options are fine for a few files; the gap shows up with batches and client folders.
| Option | Good for | Limits |
|---|---|---|
| Preview export | One-off JPEG quality changes | Manual, one file at a time |
| sips (Terminal) | Fast scripted resizes | Command-line only; see the guide for what it can and cannot write |
| Squoosh | Comparing formats visually, one image | Browser-based, aimed at single images |
| ImageOptim | Lossless cleanup of existing files | Lossless by default, so savings are small; Smol is lossy only |
| Smol | Folders of client images to AVIF, WebP or JPG with a resize | macOS only; no lossless mode; slower than a sips loop |
Our image compressor comparison has the longer version.
When is Smol the wrong tool?
- You need a build-time pipeline on Linux CI or an on-the-fly image CDN. Smol is a Mac app; for a server-side option see the Smol API, or use an image library in your build.
- You need lossless output. Smol always re-encodes images. ImageOptim is the answer for pixel-identical optimization.
- You need SVG or JPEG XL. Smol does not write them.
- You need to resize one source into a full responsive set in a single pass. Smol makes one size per run.
- You are fixing a slow server, render-blocking CSS or a late-discovered LCP image. Compression will not change those subparts.
Frequently asked questions
What is the ideal image SEO file size?
Google publishes no byte limit for images, so there is no ideal number. The measurable target is LCP of 2.5 seconds or less at the 75th percentile, per web.dev. Set a byte budget per template, serve each image at its rendered width, and confirm the change in PageSpeed Insights or field data rather than trusting a kilobyte rule.
Does image optimization for SEO actually affect rankings?
Indirectly. Google says its ranking systems use Core Web Vitals, but also that good scores do not guarantee a top position. Smaller images help when they improve LCP or page weight on pages that currently fail. Filenames and alt text separately help images appear in image search.
How do I fix a slow largest contentful paint image?
Resize it to the rendered width, serve AVIF or WebP, keep it in the initial HTML, and give only it fetchpriority high. web.dev says never to lazy-load the LCP image. Compression shortens the load duration, which is about 40% of a healthy LCP; server time and discovery delay need separate fixes.
What image size is best for page speed?
The size that matches how the image renders. A 720 pixel wide slot needs about 720 pixels, or 1440 for high-density screens, not a 4,000 pixel source. In Smol, set the maximum dimension to that width and choose quality after. Check the result, because Smol sets quality and pixels, not output bytes.
WebP vs AVIF for SEO: which is better?
Google Search supports both, so the difference is bytes. AVIF is often smaller: on Smol’s benchmark of 24 small photos it needed 22 to 26% fewer bytes than the best JPEG at matched quality. Test your own hero image in both formats.
Does compressing images remove alt text or hurt image search?
Alt text lives in your HTML, not in the image file, so compression does not touch it. Smol strips metadata such as EXIF, GPS, IPTC and XMP by default; alt text is separate and stays in your HTML. Keep descriptive filenames, because Search Central recommends them, and rename before compressing.
Keep reading
Smol for other teams