Optimize Website Images Before You Upload

Updated: September 29, 2026

Quick answer: Resize each image to the largest width your layout shows, export WebP or JPEG at quality 75-85, keep heroes under roughly 200 KB, set width and height on every image, lazy-load below-the-fold images, and test the published URL on a phone.

Most slow pages are not slow because of code. They are slow because someone uploaded a 4 MB camera photo into an 800-pixel column. The fix happens at export time, before the file ever reaches your CMS.

This is the before-you-upload workflow. No build tools, no CDN configuration. If you publish through WordPress, Squarespace, Shopify, or a hand-built site, this is the whole system in five steps.

Why images are the first thing to fix

Images are usually the heaviest part of a page, often close to half of its total bytes. They are also the part you fully control before publishing.

The three levers are not equal. Resizing removes the most data. Format choice removes the next chunk. The quality slider is the smallest lever, and the one people reach for first.

A sense of scale: a 4000×3000 photo contains 12 million pixels. The same photo at 800×600 is 480,000 pixels — 96% less data before any compression even starts. No quality slider can compete with that.

Developers solve this with build tools and CDN transforms. That machinery is nice to have, not required. The same result is available to anyone willing to export deliberately, which is what the rest of this guide does.

The five-step workflow

1. Resize to the slot. Find the widest the image renders in your layout, then export at up to 2x that width for sharp screens. A blog column that displays 800px wide needs a 1600px export, not a 4000px one. Full-width sections top out around 1600-1920px.
2. Pick the format by content. Photos: WebP, or JPEG where the destination rejects WebP. Screenshots and flat graphics: PNG or lossless WebP, because small text must stay crisp. Logos and icons: SVG. Our settings quick reference has the full table.
3. Compress at a tested quality. Start at 75-85 for photos and inspect the result at 100% zoom. Look at faces, straight edges, and smooth gradients. Lower quality until you see damage, then step back up one notch. That notch is your setting.
4. Upload with dimensions and alt text. Set width and height on every image so the browser can reserve space before the file arrives — missing dimensions are the top cause of pages that jump while loading. Write alt text that describes what the image shows.
5. Verify the live page. Run PageSpeed Insights on the published URL. Then open the browser's network panel and confirm what a phone actually downloaded: the right format, the right width, and a sensible number of bytes.

Verification catches the mistakes the export dialog cannot see. Pages get re-scaled by the CMS, themes inject their own sizes, and caches serve stale copies. Thirty seconds in the network panel settles it.

Two notes on step 4. Images below the first screen should get loading="lazy" — most CMSs expose it as a checkbox or the theme adds it automatically. And the image in the first screen should never be lazy-loaded, because it is usually what the visitor is waiting for.

Settings that work for most sites

Image type	Max width	Format	Starting quality	Typical size
Full-width hero	1600-1920px	WebP (JPEG fallback)	75-80	150-250 KB
Blog inline image	800-1200px	WebP or JPEG	75-85	60-150 KB
Product photo, zoomable	1600-2000px	WebP	80	150-250 KB
Screenshot or UI capture	1200-1600px	PNG or lossless WebP	lossless	100-300 KB
Full-bleed background	1920px	WebP	70-80	200-350 KB

Treat these as starting points, not rules. A flat, simple hero can pass at 60 KB. A detailed product shot at 2x can pass at 300 KB. The slot decides, and step 5 keeps you honest.

Hero images are often the Largest Contentful Paint element, so use the Core Web Vitals image guide when LCP is the actual problem. CSS background images follow different loading rules, but the same resize-before-compress principle still applies.

Compress in your browser, then upload once

Most online compressors upload your file to a server, process it there, and send it back. For client photos, unreleased products, or internal screenshots, that is a habit worth breaking.

LessMB processes JPG, PNG, WebP, AVIF, and HEIC files locally in your browser. When a hero has a hard budget, target-size mode aims to land at or below that threshold and reports when a safe result cannot meet it.

There is a workflow bonus too. Your CMS re-encodes whatever you give it. A 4 MB original means a slow upload and a heavy derivative. A clean 160 KB export goes up fast and stays clean.

FAQ

What size should web images be?

Match the slot, not the camera. Most blog columns render at 680-800px, so a 1600px export covers sharp screens. Full-width heroes rarely need more than 1600-1920px.

Is quality 75 too low for photos?

Usually no. At display size, quality 75-85 looks identical for most photos. Inspect faces, text, and gradients at 100% zoom and raise quality only where you can see the difference.

Do I still need JPEG?

Mostly as a fallback. WebP works in every current browser and saves 25-35% at similar quality. Keep JPEG for platforms and email clients that reject WebP.

How much smaller will my page get?

Resize first. A 4000px photo resized to 800px loses about 96% of its pixels. Format and quality settings then cut the remainder by another 30-50%.

Does my CMS not do this automatically?

Partly. Most platforms scale uploads and some serve WebP, but the uploaded file sets the ceiling. Compress before uploading, then check what the live page actually serves.

Sources and related guides

• web.dev: Optimize images — the developer-side reference for what this guide simplifies
• PageSpeed Insights — the verification step
• Related: Image compression and Core Web Vitals, compress images for mobile