Optimize Images for Web on Mac

The marketing site scores well on everything except image weight. Heroes are PNG at 2800 px wide, inline photos are camera JPEG at full resolution, and the CDN faithfully caches every byte. Optimize images for web by resizing to layout width, picking the right format, and tuning quality before deploy.

Why web images feel slow

Browsers download full file bytes even when CSS shrinks display size. Large sources hurt LCP, mobile data plans, and CMS upload limits.

Problem	Typical cause
Heavy hero	PNG or JPEG wider than 2x CSS width
Blurry on Retina	Source too small, not too large
Wrong format	Photo saved as lossless PNG
No fallback	WebP only without JPEG backup

Start with the display-size rule in how to compress images on Mac . Resize before format conversion every time.

Format choice for the web

Match format to content and browser support in your stack.

Content	Primary format	Fallback
Photo hero	WebP lossy	JPEG
UI with transparency	PNG or lossless WebP	PNG
Icon-like flat art	SVG when vector source exists	PNG
Email embed	JPEG	N/A

Read lossy vs lossless compression before you lossless-encode every photo. Lossy WebP or JPEG at quality 80 to 85 is usually enough for heroes after proper resize.

For the PNG to WebP step, see PNG to WebP on Mac . Keep a JPEG fallback in <picture> or your static site generator config.

Size quality and responsive delivery

Export width at roughly 2x the CSS column width for high-DPI screens.

CSS display width	Export width hint
960 px hero	1600 to 1920 px
720 px content column	1440 px
400 px card	800 px
Full-bleed 1280 layout	2560 px max when art demands it

Quality guidelines after resize:

• Photo heroes: WebP or JPEG quality 80 to 85
• Inline blog photos: 75 to 82
• Screenshots with text: verify at 100% zoom; prefer PNG or higher quality WebP

Responsive images in HTML use srcset with multiple widths. Generate 1x and 2x variants from one master export when your build pipeline supports it.

Google’s image SEO guidance recommends standard image elements, responsive candidates with a fallback src, descriptive filenames, and useful alt text. Compression helps delivery, but it does not replace crawlable markup or an accurate description of the image.

Lazy loading helps perceived speed but does not reduce total bytes downloaded when every visitor scrolls the full article. Smaller sources still matter for mobile data caps and CDN bills even when images load below the fold.

Test one page on a throttled 4G profile in browser devtools after you swap heroes. The network waterfall should show sub-200 KB figures for typical blog inline photos when widths match layout.

Export workflow on Mac

A repeatable local workflow beats one-off uploads:

1. Export from design at layout width, not monitor capture size.
2. Resize in Preview if the export overshoots (Tools → Adjust Size…).
3. Convert heroes to WebP with cwebp in Terminal:

brew install webp
cwebp -q 82 -m 6 hero.png -o hero.webp

4. Export matching JPEG fallback from the same resized PNG source.
5. Spot-check in browser devtools network panel before merge.

oxipng after resize helps transparency PNG assets that must stay PNG:

oxipng -o 4 --strip safe icon.png

Document width, quality, and format rules in the repo so the next campaign does not revert to 3x artboard exports.

Local processing for staging assets

Unreleased heroes, pricing screenshots, and beta UI belong on disk until launch. Online optimizers receive full-resolution sources when you upload.

See are online file compressors safe for what third-party upload means for confidential creative. Local apps and Terminal tools can process files without sending them to a compression website.

Strip location EXIF from photo heroes when GPS tags are not intended for public pages. Metadata removal is a separate step from byte optimization but matters for privacy.

When GetCompress fits web asset preparation

Preview, cwebp, or a build plugin is enough for an occasional asset. GetCompress is the better fit when design repeatedly hands engineering mixed PNG, JPEG, HEIC, and other sources that need consistent widths, previews, and web-format variants. Presets and batch queues prepare those files locally before they enter the build.

It does not replace responsive markup, CDN configuration, caching, or performance measurement. Test the deployed page and keep the source masters separate from generated web assets.