How to Optimize Images for Websites: Formats, Sizing, and Delivery
Slow websites are often image-heavy websites. Oversized photos, wrong formats, and poor delivery drag down load time, hurt search visibility, and make the site feel worse than the design deserves.
The fix is not one magic format. It is a structured workflow: choose the right format, export the right size, deliver the right variant, and keep metadata and publishing steps organized.
Table of Content
Why website image optimization matters
Images are often the main reason a page feels slow. When the biggest bytes on the page come from oversized photos, wrong formats, or weak responsive delivery, both user experience and search performance suffer.
That is why image optimization needs a system, not random fixes. You need a clear plan for formats, sizing, delivery, and the publishing workflow that produces those assets in the first place.
Faster pages
Right-sized images in modern formats reduce transfer weight and help important visuals load sooner.
Performance
Better search visibility
Cleaner image delivery, stronger metadata, and faster pages support better crawl signals and stronger page quality.
Search impact
Less publishing chaos
A structured image workflow stops teams from shipping huge originals, missing metadata images, and inconsistent exports.
Operational clarity
Which website images you normally need
Most websites do not need more image types. They need the right image roles, sized and labeled correctly. Think in jobs, not in random uploads.
Hero or LCP image
This is the main visual near the top of the page. It often becomes the Largest Contentful Paint element, so it needs careful sizing and should not be lazy loaded by default.
Purpose: first impression and LCP
Inline content images
These support the article itself. They should explain the content, use sensible alt text, and scale well between desktop and mobile layouts.
Purpose: support the reading flow
Cards, thumbnails, and hub images
These smaller images appear in category pages, related article modules, and navigation surfaces. They should use smaller variants than the page hero.
Purpose: previews and navigation
Open Graph and social preview image
This image shapes how the page looks when shared on chat apps and social platforms. It is a metadata asset, not just a copy of the visible hero.
Purpose: share previews and click-through
Structured data image for JSON-LD
Article and product schema can reference a primary image so search engines understand the main visual asset tied to the page.
Purpose: schema completeness and entity clarity
Formats: pick the right file type for the job
The best format depends on the image role. Most sites need a mix, not one universal winner.
| Format | Best for | Why it matters |
|---|---|---|
| WebP | Routine website images, cards, previews, and most day-to-day content visuals | WebP is the practical default because it balances quality, compression, and easy repeat use across normal publishing work. |
| AVIF | Selected large photographic hero images and high-value visuals where extra compression is worth extra care | AVIF can deliver smaller files, but encoding is slower and it works best as a selective optimization step, not a blanket default. |
| JPEG | Legacy compatibility and source files before modern export | JPEG is still common as an input format, but it should rarely be the final format for important website images. |
| PNG | Screenshots, transparency, and UI assets that need lossless edges | PNG stays useful for interface graphics, but it is usually too heavy for normal photographic content. |
| SVG | Icons, diagrams, logos, and simple illustrations | SVG scales cleanly and often beats raster formats for sharp line-based graphics. |
Use WebP as the everyday workhorse and keep AVIF for the smaller set of photographic images where maximum savings matter more.
For the routine WebP path, read the JPG-to-WebP workflow guide . For selective hero-image compression, use the JPEG-to-AVIF guide .
Sizing: responsive images, dimensions, and layout stability
Slow websites do not just have a format problem. They often ship one oversized image to every screen size. Responsive sizing fixes that.
- Generate multiple widths so phones, tablets, and desktops can receive the right asset.
- Set width and height to reserve space and reduce layout shift.
- Use smaller variants for cards and related content instead of reusing the full hero everywhere.
- Keep a large original only when zoom, download, or lightbox behavior truly requires it.
Delivery markup example
Use a small, explicit image setup for content images and reserve eager loading for the true hero. This is the kind of delivery markup that keeps browser behavior and Lighthouse results easy to reason about.
<picture>
<source
type="image/avif"
srcset="/images/articles/hero-640.avif 640w,
/images/articles/hero-1024.avif 1024w"
sizes="(max-width: 768px) 100vw, 720px" />
<source
type="image/webp"
srcset="/images/articles/hero-640.webp 640w,
/images/articles/hero-1024.webp 1024w"
sizes="(max-width: 768px) 100vw, 720px" />
<img
src="/images/articles/hero-1024.jpg"
alt="Product dashboard preview"
width="1024"
height="576"
loading="lazy"
decoding="async" />
</picture>Delivery priorities: lazy loading, LCP, and Core Web Vitals
Once formats and sizes are right, delivery becomes the next big lever. The main rule is simple: treat the above-the-fold image like a priority asset instead of an afterthought.
Do this for your hero image
Keep the hero image compressed and sized for the actual layout. Load it eagerly when it is the likely Largest Contentful Paint element.
Use modern formats, explicit dimensions, and avoid stacking multiple giant banners above the fold.
What hurts delivery
Lazy loading the primary hero image, shipping desktop-sized assets to phones, and using oversized PNGs for photographic content are still common mistakes.
These issues weaken both Lighthouse and real user experience.
Context: filenames, alt text, and surrounding copy
Image optimization is not only about bytes. Search engines and users also need context around what the image is and why it is on the page.
- Use filenames that describe the subject instead of camera exports or placeholder names.
- Write alt text when the image adds meaning, not as a place to dump keywords.
- Keep nearby headings, captions, and copy aligned with what the image actually shows.
- Make sure the image role supports the page topic instead of feeling random.
Metadata: why Open Graph and JSON-LD images matter
A page can look fine in the browser and still be weak in discovery if its metadata images are neglected. This is one of the easiest quality gaps to fix.
open graph image
This controls how the page looks when shared externally. A strong Open Graph image improves perceived quality and click-through on social and chat platforms.
JSON-LD image property
Structured data gives search engines a cleaner content package. Including a relevant image strengthens the connection between your headline, description, and primary visual asset.
If you are building with Blazor, pair this guide with the Blazor metadata component guide so the page title, description, canonical link, Open Graph image, and structured data all stay in sync.
Workflow: a structured process for website images
- Define the image role before exporting anything: hero, inline, card, Open Graph, or schema image.
- Pick the format for the job: WebP for routine work, AVIF for selected heavy photos, SVG for vectors, PNG only when lossless transparency matters.
- Export the right sizes for the layout instead of shipping one oversized original everywhere.
- Set delivery priorities so the hero behaves like a priority asset and secondary images stay efficient.
- Check metadata images, alt text, and filenames before publishing.
If you are choosing tooling for that workflow, the best image converter for web guide covers the local-versus-online decision.
Website image optimization checklist
- Every important page has a clear image role plan before export starts.
- WebP handles routine website images unless a stronger selective format is justified.
- Large photographic images use AVIF only when the extra savings are worth it.
- Hero images are sized for the layout and not lazy loaded when they are the likely LCP element.
- Card and hub images use smaller variants than the page hero.
- Open Graph images exist for sharing and previews.
- Structured data includes a relevant primary image.
- Width and height are present to avoid layout shifts.
- Alt text and filenames describe the image role clearly.
- The workflow is consistent enough that the same mistakes do not return on the next publish.