Images dominate page weight. HTTP Archive data shows they account for 40–50 percent of total bytes on a typical webpage. For developers building performance-sensitive applications, image optimization is one of the highest-leverage improvements available.
This guide covers the technical decisions: format selection, encoder choices, compression settings, metadata handling, and how these choices affect Core Web Vitals.
Format Selection: The Technical View
JPEG via MozJPEG
MozJPEG is a production JPEG encoder from Mozilla that produces 5–10 percent smaller files than libjpeg-turbo at the same quality setting. It achieves this through optimized Huffman coding, trellis quantization, and scan optimization.
For web use, quality 75–85 is the practical sweet spot. Below 75, JPEG artifacts become visible in gradients and flat areas.
PNG via OxiPNG
OxiPNG is a Rust-based PNG optimizer (successor to OptiPNG) that applies multiple compression strategies and selects the smallest output. Since PNG is lossless, optimization reduces file size by 10–30 percent without changing a single pixel.
WebP via libwebp
WebP supports both lossy (VP8-based) and lossless compression. At equivalent SSIM quality metrics, WebP lossy files are 25–35 percent smaller than MozJPEG output. WebP lossless is typically 20–25 percent smaller than optimized PNG.
Browser support for WebP is approximately 97 percent as of mid-2026, making it safe for production use without fallbacks in most contexts.
AVIF via libavif
AVIF (based on AV1 video codec) offers 20–35 percent smaller files than WebP at equivalent quality. The trade-off is encoding speed — AVIF is significantly slower to encode, making it less practical for on-the-fly processing but excellent for static assets.
Browser support sits at approximately 93–94 percent. Use the <picture> element for progressive enhancement:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Description" width="800" height="600" loading="eager" fetchpriority="high">
</picture>
Metadata Preservation in Compression Pipelines
Most compression tools strip EXIF, IPTC, and XMP metadata by default. This creates problems in workflows that depend on embedded data:
- Geotagged images lose GPS coordinates after compression
- Rights-managed images lose IPTC copyright and licensing fields
- Archival workflows lose camera settings, timestamps, and descriptions
The technical challenge is that metadata is stored in format-specific containers (APP1 for EXIF in JPEG, tEXt/iTXt chunks in PNG, RIFF metadata in WebP). Format conversion requires re-mapping metadata between these containers.
GeoImageTagger's Image Compressor and Image Converter handle this by running compression/conversion client-side via WASM, then using a server-side step to copy metadata from the original to the processed output and verify field-by-field that the transfer succeeded. A "Preserve Metadata" toggle (enabled by default) controls this behavior.
Core Web Vitals Impact
Images directly affect two of three Core Web Vitals:
LCP (Largest Contentful Paint): The LCP element is frequently a hero image. Reducing its file size from 2 MB to 150 KB can cut LCP from 4+ seconds to under 1.5 seconds on a 4G connection.
CLS (Cumulative Layout Shift): Images without explicit width/height attributes cause layout shifts. Always specify dimensions or use CSS aspect-ratio.
For the LCP image specifically:
- Do not lazy-load it
- Add
fetchpriority="high" - Preload it in
<head>if it is a CSS background or dynamically loaded - Serve the smallest format the browser supports
Practical Compression Workflow
original.jpg (4.2 MB, 4000×3000)
→ resize to 1920×1440 (max layout width)
→ compress as WebP quality 80 (MozJPEG for JPEG fallback)
→ preserve metadata if geotagged or rights-managed
→ output: 180 KB with all EXIF/GPS/IPTC intact
That is a 95 percent file size reduction with no visible quality difference and no metadata loss.
For batch processing, both the compressor and converter on GeoImageTagger support up to 10 images per batch, with ZIP download for the results.
Key Takeaways
- Use WebP as your default format; AVIF for static hero images
- Compress at quality 75–85 for lossy formats
- Always resize to your maximum display dimension before compressing
- Preserve metadata when GPS, copyright, or descriptions matter
- Set explicit image dimensions to prevent CLS
- Never lazy-load the LCP image
Full guide with format comparison tables and FAQ: How to Optimize Images for Website Speed and SEO
Top comments (4)
The local version of this problem is often operational, not just SEO. A site should expose the facts that determine whether a customer can act now—service scope, area, hours, contact path, and real work evidence.
Great point. For local businesses especially, images carry operational context that goes beyond page speed, a geotagged photo of your storefront or a product shot with IPTC contact fields embedded is evidence that you operate where you say you do.
That is actually one of the reasons we built metadata preservation into the compression pipeline. Stripping GPS coordinates during optimization removes a signal that helps Google connect your images to your business location. Same with IPTC fields like service area or contact info, they are machine-readable context that reinforces what your page content already says.
The operational angle you are describing is exactly where image optimization and local search strategy overlap. Thanks for raising it.
I agree with the operational point, with one caveat: metadata should support the visible business evidence, not become a substitute for it. The durable win is preserving useful context through optimization and keeping it consistent with the page, profile, and real-world location.
Exactly right. Metadata is supporting evidence, not the evidence itself. A geotagged photo with IPTC fields intact strengthens what the page, profile, and Google Business listing already show, it does not replace any of that.
Consistency across all three is the key. Good insight.