If a page-speed audit has ever told you to "properly size images" or "serve images in next-gen formats", this guide is the fix. Images are usually the heaviest assets on a web page, and shrinking them is the single highest-return speed change you can make — far cheaper than rewriting JavaScript or buying faster hosting. Done right, your pages load measurably faster and nobody can tell the photos are smaller.
This guide gives you the repeatable workflow: export at the display width, compress to a friendly quality, and convert photos to WebP. It ties every step to Google's current Largest Contentful Paint threshold so you are not guessing. The whole pipeline runs in your browser — your original photos are never uploaded to a server.
Why images are your fastest page-speed win (LCP)
Google's Core Web Vitals measure real user experience in the field. The metric that images move most is Largest Contentful Paint (LCP): the moment the largest visible element on the screen finishes rendering. On blog posts, shop pages and landing pages that largest element is very often the hero image — not a paragraph of text. A bloated 4 MB hero photo delays that clock directly.
Google's current LCP ratings, verified against Google's own Core Web Vitals documentation on 2026-10-06, are:
| LCP rating | Threshold | What it means |
|---|---|---|
| Good | 2.5 seconds or less | The largest element paints fast; aim here |
| Needs improvement | Over 2.5 s, up to 4.0 s | Mobile users feel the wait; compress the hero |
| Poor | Over 4.0 seconds | Likely costing conversions and rankings |
These numbers come from real-user field data at the 75th percentile, measured separately on mobile and desktop. The "Good" bar remains 2.5 seconds in 2026 — it has not been lowered to 2.0 seconds, despite rumours circulating in some SEO blogs. The other two Core Web Vitals, INP and CLS, are affected by images too (unstated width and height causes layout shift), but compression mainly moves LCP.
Two levers: dimensions first, quality second
Most people open a compressor and drag a quality slider. That is the smaller lever. The bigger one is shipping the right number of pixels.
Lever 1 — serve the right dimensions
A phone camera produces a 4000-6000 px wide photo. If that image displays in an 800 px wide content column, you are shipping five times more pixels than anyone can see. Resizing the long edge to roughly the display width — at most 2x for retina screens — usually cuts the file by 60-80% on its own, with zero visible quality loss. This is the single most effective step.
Lever 2 — then reduce quality (lossy)
Once the dimensions are correct, a moderate lossy compression (around 75-85% quality) trims another chunk with no perceptible change. Do it in that order: compress after resizing. Crushing the quality of a full-resolution original wastes effort and produces blocky results.
Step-by-step: compress images for the web
- Export at the exact display width. Know where the image appears. A hero may justify ~1600-2400 px wide; a content image ~1200-1600 px; a thumbnail ~400-600 px. Use the image resizer with aspect ratio locked so width and height scale together. Ship no more than 2x the display size for retina.
- Lossy compress to ~75-85% quality. Drop the resized image into the browser compressor and tune the quality until the file sits in the target band below. At 75-85% most people cannot tell the difference from the original.
- Convert photos to WebP. A WebP at matched quality is about 25-35% smaller than the equivalent JPG. Run JPG to WebP for photographs and PNG to WebP for graphics that keep transparency. Serve a JPG fallback with a picture element for older browsers.
- Check the rough size targets. Hero images under ~200 KB, content images under ~100-150 KB, thumbnails under ~30-50 KB. These are practical 2026 bands, not a Google rule — adjust for your design.
If a source image is genuinely soft or out of focus, fix that before you compress: a light enhancement pass recovers close-but-small detail, and you then resize and compress the sharper result. If a portal also demands an exact KB (not just web weight), see the guide on compressing to a target file size for that binary-search method.
| Where the image shows | Target long edge | Target file weight | Format |
|---|---|---|---|
| Hero / above the fold | 1600-2400 px | < 200 KB | WebP, JPG fallback |
| In-article content image | 1200-1600 px | < 100-150 KB | WebP, JPG fallback |
| Thumbnail / gallery tile | 400-600 px | < 30-50 KB | WebP |
| Logo or flat graphic | Exact display size | As small as possible | PNG or WebP (alpha) |
"Without losing quality" — what it really means
The phrase "without losing quality" on this page means perceptually lossless at normal viewing size, not bit-for-bit identical. Lossy formats throw away information the eye barely notices (fine colour detail in smooth skies), and at 75-85% quality the result looks clean. Two honest limits apply:
- No re-saving chains. Every lossy re-save of the same JPEG compounds artefacts. Always compress once from the original, never from an already-compressed export.
- There is no free lunch. A 4000 px photo crushed to 50 KB will look soft. The way to keep perceived quality is the resize-first workflow above, not a magic setting.
Format cheat-sheet: JPG, PNG, WebP and AVIF
Pick the format by the job. Getting this right beats any quality slider.
| Format | Best for | Transparency | Size at equal quality |
|---|---|---|---|
| JPG | Photographs | No | The reference baseline |
| PNG | Screenshots, logos, flat graphics with sharp edges | Yes | Often much larger for photos |
| WebP | Default modern web format (lossy + lossless + alpha) | Yes | ~25-35% smaller than JPG |
| AVIF | Next-gen, aggressive compression | Yes | ~40-55% smaller than JPG |
AVIF compresses even better than WebP, but PixlReady encodes and exports JPG, PNG and WebP only — it does not produce AVIF. If you want AVIF, you need a separate tool; for most sites WebP already captures the bulk of the win. One more rule: always set width and height attributes on your <img> tags so the browser reserves space — unstated dimensions cause layout shift (CLS), the third Core Web Vital.
Common mistakes that slow your site down
- Compressing before resizing. You waste effort crushing a 4000 px photo when the fix is to ship 1200 px. Resize first, then compress.
- Shipping a PNG for a photograph. Photos in PNG are 3-10x heavier than the same photo in JPG or WebP. Use PNG only when you actually need transparency or a sharp graphic.
- Re-compressing an already-compressed JPEG. Always start from the original. Re-saving a file that was already saved at quality 60 stacks artefacts on artefacts.
- Forgetting width and height. An image with no stated dimensions shifts the whole page down when it loads, which hurts CLS even after the LCP is fast.
- Using an upload-based tool for sensitive images. Most compressors send your file to a server. For product shots, client photos or anything private, use a local, no-upload compressor — and see our take on why a no-upload compressor matters.
Once your images are sized and compressed, you may want the rest of the toolkit in one place — see our roundup of the best free online image tools in 2026.
Common questions
What is LCP and why is my hero image usually the problem?
LCP (Largest Contentful Paint) is the Core Web Vital that measures when the largest visible element on a page finishes loading. On most pages that largest element is the hero or banner image, not the text. Google rates LCP as Good at 2.5 seconds or less, Needs Improvement between 2.5 and 4.0 seconds, and Poor above 4.0 seconds, measured at the 75th percentile on real-user field data. These thresholds were verified against Google's own Core Web Vitals documentation on 2026-10-06; the Good bar is still 2.5 seconds and has not been lowered to 2.0 seconds.
Does compressing images reduce quality?
At moderate quality levels, no visible loss. A JPEG or WebP saved at roughly 75-85% quality looks identical to the original on screen and in print at normal viewing size, while being 30-80% smaller. The honesty caveat: compression is not bit-exact, and every repeated lossy re-save of the same file adds generation loss, so compress once from the original rather than re-compressing an already-compressed copy.
What is the best image format for a website?
Use WebP as the default for photos and graphics, because it is roughly 25-35% smaller than a JPG at the same visual quality and supports transparency and animation. Keep a JPG fallback for older browsers. Use PNG only for sharp screenshots, logos or graphics that need transparent edges; never ship a PNG for a photograph. PixlReady encodes and exports JPG, PNG and WebP; it does not output AVIF.
Should I use WebP on my website?
Yes, in 2026 WebP is supported by all current major browsers and is the highest-yield upgrade for most sites. Convert photos from JPG to WebP and serve a JPG fallback with a picture element for the small share of old browsers left. Expect files around a quarter to a third smaller than the JPG they replaced, with no perceptible quality drop.
What size should website images be, in kilobytes?
A practical 2026 target is under 200 KB for a hero or above-the-fold image, under 100-150 KB for a content image, and under 30-50 KB for a thumbnail. Pair file weight with pixels: a hero only has to be as wide as its display slot, roughly 1600-2400 px wide at most (2x for retina), not the 4000-6000 px straight off a camera.
How do I compress a JPG or PNG for the web without it looking blurry?
Resize to the display width first, then compress. Keeping a 4000 px photo and crushing the quality slider is what causes blurry, blocked images; shrinking the dimensions to where the image actually shows lets you save at a friendly 75-85% quality. Convert the result to WebP. If a source image is genuinely low-detail, start it with an enhancement pass, then resize and compress.