Compress every image before upload
Use lossy compression (imperceptible quality loss at reasonable settings) to dramatically reduce file size — an unoptimized photo straight from a camera or stock library can be 5-10x larger than it needs to be for web display. Automating this as part of a publishing pipeline (rather than relying on manual compression before every upload) prevents it from being skipped under deadline pressure.
Use modern formats — WebP or AVIF — with a fallback
WebP and AVIF offer meaningfully better compression than older JPEG and PNG formats at equivalent visual quality. Most modern CMS platforms and image-serving tools handle format conversion and fallback automatically; where that's not automatic, explicitly generating and serving these modern formats is worth the setup effort given the Core Web Vitals impact.
Name image files descriptively before upload
A file named navy-wool-overcoat-front.jpg gives search engines context before the page even loads the image; a file named IMG_4482.jpg gives none. This is a small, easy step that's frequently skipped simply because it requires renaming files before upload rather than using whatever name a camera or design tool auto-generated.
Write specific, accurate alt text
Every informational image needs alt text describing what it actually shows, specific enough to be useful without keyword-stuffing; purely decorative images should use an empty alt attribute instead. See the dedicated Alt Text guide for the full framework.
Serve appropriately sized images per device
Serving a 2000px-wide image to a mobile viewport that only displays it at 400px wastes bandwidth and slows load time for no visual benefit — responsive image techniques (the srcset attribute, or a CMS's built-in responsive image handling) serve an appropriately sized version per device rather than one oversized file to everyone.
Lazy-load images below the fold
Images not visible in the initial viewport can be set to load only as a user scrolls toward them, rather than all loading immediately — this speeds up the initial page load and Largest Contentful Paint score, since the browser isn't competing to load a dozen images at once when only one or two are actually visible yet. Images in the visible initial viewport should not be lazy-loaded, since delaying them can actually hurt LCP.
Common mistakes to avoid
- Lazy-loading the hero image at the very top of the page, which delays the Largest Contentful Paint element instead of speeding it up.
- Uploading full-resolution camera images directly without any compression step.
- Using generic file names and alt text across an entire product gallery.
Related terms
- Image Compression
- Alt Text
- Core Web Vitals
- Largest Contentful Paint (LCP)
FREE BACKLINK PLAN
Build authority with backlinks that matter
Get a shortlist of sites that already link to competitors in your niche, ranked by authority, without doing the outreach research yourself.
- 20 link opportunities matched to your niche
- Discover competitor backlink sources
- Get actionable link-building opportunities

We'll email you the results and occasional SEO tips. Unsubscribe anytime.
Common questions
There's no single universal target, but keeping individual images under roughly 100-200KB after compression (often achievable with negligible visible quality loss) is a reasonable general guideline for most web use cases.
Indirectly but meaningfully — it's a major factor in Core Web Vitals and overall page speed, both of which are confirmed ranking signals, plus it directly affects image search visibility.
Related Reading

How to Do Local SEO for a Multi-Location Business
Local SEO for one location is mostly about a single, well-optimized Google Business Profile. Local SEO for six, twenty, or two hundred locations is a structural problem — duplicate content risk, citation consistency at scale, and internal competition between your own location pages if it's not planned deliberately.



