How to Optimise Images for Websites: Formats, Sizing and Delivery
Slow websites are often weighed down by images. Oversized photos, incorrect formats and poor delivery slow loading times, reduce search visibility and diminish the site’s impact.
The solution isn’t a single format but a structured process: select the right format, export the correct size, deliver the appropriate variant, and manage metadata and publishing consistently.
Contents
Why optimising website images is important
Images are frequently the primary cause of slow page loading. When the largest files on a page are oversized photos, incorrect formats or poorly delivered responsive images, both user experience and search rankings decline.
This is why image optimisation requires a system, not ad hoc fixes. A clear plan for formats, sizing, delivery and the publishing workflow is essential.
Faster loading pages
Correctly sized images in modern formats reduce data transfer and help key visuals load more quickly.
Performance
Improved search visibility
Efficient image delivery, enhanced metadata and quicker pages improve crawl signals and page quality.
Search impact
Reduced publishing confusion
A structured image workflow prevents teams from publishing oversized originals, missing metadata images and inconsistent exports.
Operational clarity
Typical website images you require
Most websites don’t require more image types, but the correct image roles, properly sized and labelled. Consider tasks, not random uploads.
Hero or Largest Contentful Paint image
This is the primary visual near the top of the page. It often forms the Largest Contentful Paint element, so it requires precise sizing and should not be lazy loaded by default.
Purpose: first impression and Largest Contentful Paint
Inline content images
These images support the article content. They should clarify the subject, use appropriate alt text, and scale well across desktop and mobile layouts.
Purpose: support reading flow
Cards, thumbnails, and hub images
These smaller images appear in category pages, related article sections and navigation areas. They should be smaller than the main hero image.
Purpose: previews and navigation
Open Graph and social preview image
This image determines how the page appears when shared on chat apps and social media. It is a metadata asset, not merely a copy of the visible hero.
Purpose: share previews and encourage click-through
Structured data image for JSON-LD
Article and product schema can reference a primary image so search engines recognise the main visual asset associated with the page.
Purpose: schema completeness and entity clarity
Formats: choose the correct file type for the task
The ideal format depends on the image’s role. Most sites require a combination, not a single universal format.
| Format | Best suited for | Why it matters |
|---|---|---|
| WebP | Standard website images, cards, previews and typical content visuals | WebP is the practical default as it balances quality, compression and ease of use for routine publishing. |
| AVIF | Selected large photographic hero images and high-value visuals where additional compression justifies extra effort | AVIF can produce smaller files but encoding is slower; it works best as a selective optimisation step rather than a blanket default. |
| JPEG | Legacy compatibility and source files prior to modern export | JPEG remains common as an input format but should seldom be the final format for key website images. |
| PNG | Screenshots, transparent images and UI assets requiring lossless edges | PNG remains useful for interface graphics but is generally too large for typical photographic content. |
| SVG | Icons, diagrams, logos, and simple illustrations | SVG scales cleanly and often outperforms raster formats for crisp line-based graphics. |
Use WebP as the everyday format and reserve AVIF for a smaller set of photographic images where maximum savings are important.
For routine WebP use, see 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 don’t just have format issues; they often deliver one oversized image to all screen sizes. Responsive sizing resolves this.
- Create multiple widths so phones, tablets and desktops receive the appropriate asset.
- Specify width and height to reserve space and minimise layout shifts.
- Use smaller variants for cards and related content rather than reusing the full hero image everywhere.
- Retain a large original only when zoom, download or lightbox functionality genuinely requires it.
Example of delivery markup
Use a small, explicit image setup for content images and reserve eager loading for the main hero. This markup keeps browser behaviour and Lighthouse results clear.
<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 correct, delivery is the next key factor. The main rule: treat above-the-fold images as priority assets, not afterthoughts.
Recommendations for your hero image
Keep the hero image compressed and sized for the layout. Load it eagerly if it’s likely the Largest Contentful Paint element.
Use modern formats, set explicit dimensions, and avoid stacking multiple large banners above the fold.
Factors that hinder delivery
Common errors include lazy loading the main hero image, sending desktop-sized assets to phones, and using oversized PNGs for photos.
These problems degrade both Lighthouse scores and actual user experience.
Context: filenames, alt text and surrounding text
Image optimisation isn’t just about file size. Search engines and users need context about the image and its purpose on the page.
- Use filenames that describe the subject rather than camera exports or placeholders.
- Write alt text only when the image adds meaning, not to stuff keywords.
- Ensure headings, captions, and text near the image reflect its actual content.
- Ensure the image role supports the page topic and doesn’t seem random.
Metadata: the importance of Open Graph and JSON-LD images
A page may look fine in a browser but perform poorly in discovery if metadata images are missing. This is an easy quality gap to address.
Open Graph image
This controls how the page appears when shared externally. A strong Open Graph image boosts perceived quality and click-through rates on social and chat platforms.
JSON-LD image property
Structured data provides search engines with a clearer content package. Including a relevant image strengthens the link between your headline, description and main visual asset.
If you are developing with Blazor, use this guide alongside the Blazor metadata component guide to ensure the page title, description, canonical link, Open Graph image, and structured data remain consistent.
Workflow: a structured process for website images
- Define the image role before exporting: hero, inline, card, Open Graph or schema image.
- Choose the format for the task: WebP for routine images, AVIF for select heavy photos, SVG for vectors, PNG only when lossless transparency is needed.
- Export the correct sizes for the layout rather than delivering one oversized original everywhere.
- Set delivery priorities so the hero image is treated as a priority asset and secondary images remain efficient.
- Verify metadata images, alt text and filenames before publishing.
If selecting tools for this workflow, the best image converter for web guide covers the choice between local and online tools.
Website image optimisation checklist
- Every key page has a clear image role plan before export begins.
- WebP manages routine website images unless a stronger selective format is warranted.
- Large photographic images use AVIF only when the additional savings justify it.
- Hero images are sized for the layout and not lazy loaded if they are likely the LCP element.
- Card and hub images use smaller versions than the page hero.
- Open Graph images are used for sharing and previews.
- Structured data includes a relevant primary image.
- Width and height attributes are set to prevent layout shifts.
- Alt text and filenames clearly describe the image role.
- The workflow is consistent enough to prevent recurring mistakes on subsequent publishes.