Website image check

Optimize website images: check the page before publishing

Use this guide to see what the browser really loads, choose the right size for each image, fix the HTML, and check the page before publishing.

Quick answer

Check the live page before you export another file

The fastest image fix is often not a new converter. First find heavy requests, missing sizes, a lazy-loaded LCP image, or metadata that still points to an old file. Start with the page, then export only what must change.

Check requests, not folders The page can still load a heavy file even when an optimized file exists somewhere else.
Choose per image A hero image, article image, repeated card, and metadata image need different rules.
Show the browser what to use Use srcset, sizes, width, and height so the browser can choose a good file and reserve space.
Check the published page Look for wrong URLs, layout shifts, lazy-loaded LCP images, broken social previews, and old schema images.

Check first

Start with what the browser downloads

Design files and media folders do not show what users really get. The browser shows which image URL loads, how large it appears, whether the page reserves space, and whether a large file is reused where a small one would work.

Network check

Which URL loads?

Open the page and write down the real image URL, transfer size, shown size, and whether the browser chose the expected version.

Layout check

How large is the image?

Measure the visible area instead of guessing from the source file. Cards, content columns, and social images should not share one export.

Load check

Is it in the first screen?

Find the likely LCP image, avoid lazy loading it by mistake, and keep less important images out of the first load.

Context check

Does the metadata match?

Check alt text, Open Graph image, JSON-LD image, nearby text, and file name so the page tells one clear story.

Image plan

Plan each important image before conversion

An image plan keeps this guide separate from converter articles. It asks what each image area needs: size, loading order, fallback, metadata role, and a final check that proves the page uses the right file.

Image area Decision Risk Check
Main image Set the likely LCP image, exact dimensions, loading order, and a fallback path. Lazy loading or oversized files can delay the first useful image. Compare shown size, request size, and loading behavior in the first screen.
Article content image Define content-width versions and reserve space with width and height. The page may load a source image much wider than the reading column. Check desktop and mobile widths and verify the chosen srcset candidate.
Repeated card image Create small versions for lists, hubs, related cards, and archive pages. One reused article image can add a lot of weight to a listing page. Scan the listing page and confirm repeated cards do not load full article images.
Metadata image Prepare Open Graph and JSON-LD images as planned files, not accidental leftovers. Search and sharing previews can show old, cropped, or unrelated images. Inspect rendered meta tags and structured data for the final URL.

When the plan says files need new versions, use the image conversion guide to choose the next step. Use the JPG to WebP guide for normal WebP work and the AVIF guide only for large photos that still need more savings.

Image sizes

Set clear sizes for each image area

Responsive images work only when the HTML matches the layout. Measure the area, choose a few useful widths, reserve the aspect ratio, and avoid sending a large original just because it already exists.

Measure the area Use the visible width as the starting point, not the original file size.
Use a short width list A few planned versions are easier to maintain than a folder full of random exports.
Reserve layout space Set width and height or an aspect ratio so image loading does not move the page.
Separate preview images Social and schema images have their own job and should not be random copies of visible page images.
Shrink repeated images Images repeated across hubs, related sections, and archive pages need their own smaller files.
Keep originals for later Store source files clearly, but keep published HTML pointed at optimized output.

Simple check: if a 360 px card downloads a 2400 px file, compression is not the main problem. The page needs a smaller image version, or the HTML points to the wrong file.

Loading order

Make the first image load on purpose

The image that shapes the first screen needs a different rule than images lower on the page. Find the likely LCP image, avoid lazy loading it by mistake, and keep lower images quiet until they are needed.

  1. 1

    Name the LCP image

    If the first meaningful image is likely to become Largest Contentful Paint, do not lazy load it by accident.

  2. 2

    Keep lower images quiet

    Images below the first viewport should normally use lazy loading and async decoding.

  3. 3

    Check CSS backgrounds

    A cropped background can still download a huge file. Use a correctly sized file for the visible area.

  4. 4

    Check repeated requests

    A small card image becomes expensive when the same oversized file repeats dozens of times.

HTML

Use responsive HTML for the measured area

For important images, make the browser choice clear. The example below shows width options, sizes, fixed dimensions, and a fallback. Change loading behavior based on the area, not by habit.

HTMLResponsive image example
<picture>
  <source
    type="image/avif"
    srcset="/images/article/product-640.avif 640w,
            /images/article/product-960.avif 960w,
            /images/article/product-1280.avif 1280w"
    sizes="(max-width: 768px) 100vw, 720px" />
  <source
    type="image/webp"
    srcset="/images/article/product-640.webp 640w,
            /images/article/product-960.webp 960w,
            /images/article/product-1280.webp 1280w"
    sizes="(max-width: 768px) 100vw, 720px" />
  <img
    src="/images/article/product-960.jpg"
    alt="Dashboard screenshot showing the upload flow"
    width="960"
    height="540"
    loading="lazy"
    decoding="async" />
</picture>

Search and sharing

Make images, alt text, and metadata tell one story

Image SEO is not just adding keywords. The visible image, nearby text, helpful alt text, Open Graph tags, and JSON-LD image links should describe the same page clearly. Decorative images should stay decorative.

File names explain the image Use names tied to the page and subject instead of camera exports or temporary downloads.
Alt text must help Describe useful images clearly and leave decorative images out of the keyword game.
Nearby text supports the image Headings, captions, and nearby paragraphs should match what the image actually shows.
Metadata is checked Open Graph and JSON-LD image links should point to prepared files that represent the page.

When the check finds weak social previews, continue with the Open Graph image guide. When schema and meta tags are the problem, use the Blazor metadata guide to keep JSON-LD and page metadata consistent.

Steps

A simple image check for each page

  1. 1

    Open the real page

    Start from the current URL, not the asset folder. Record the images that actually load.

  2. 2

    Create the image plan

    For each important image, write down target width, aspect ratio, loading order, fallback, and metadata role.

  3. 3

    Convert only what changed

    Use conversion tools only for files the check found, instead of re-exporting the whole media folder.

  4. 4

    Update HTML and metadata

    Point srcset, sizes, dimensions, Open Graph, and JSON-LD image links to the prepared files.

  5. 5

    Verify browser output

    Check the page, network requests, social metadata, structured data, and mobile layout.

  6. 6

    Keep the rule for next time

    Document the image decisions so future updates do not start with guesswork again.

Tool tip

Use PixelPress after you know which files to convert

When the check shows that a folder needs new WebP or AVIF files, PixelPress can convert them locally. Originals stay untouched, and the output folder is easy to review.

Open PixelPress

Checklist

Image checklist before publishing

Use this list before an article, landing page, or product page goes live. It catches page problems that conversion alone can miss.

Actual requests were checked The check looked at the images loaded by the page, not only files in the repository.
Each important image has a rule Width, aspect ratio, loading order, fallback, and metadata use are decided for every important image.
Shown size matches the file The browser is not forced to download a file several times larger than the visible image.
First screen is intentional The likely LCP image is not lazy loaded by mistake, oversized, or hidden behind a background.
Responsive HTML was checked Important content images use srcset, sizes, dimensions, and useful fallbacks where needed.
Visual quality was reviewed Text, faces, product detail, gradients, and screenshots still look clean in the page.
Metadata points to planned files Open Graph and JSON-LD image links point to planned files, not random leftovers.
Old originals are not referenced Published HTML loads optimized files instead of heavy source files.

FAQ

What is a website image check?

A website image check looks at the images a real page loads, then compares them with the visible layout, loading order, responsive HTML, alt text, metadata, and structured data links.

Is image optimization the same as converting to WebP or AVIF?

No. Conversion is only one step. The page can still be slow if HTML points to the wrong file, sizes are missing, the LCP image is lazy loaded, or metadata images are old.

How do I find the image that hurts performance most?

Start with the first screen and the network requests. Look for the largest visible image, oversized repeated card images, CSS backgrounds, and files whose shown size is much smaller than the downloaded image.

Should every image get alt text?

No. Useful images should have helpful alt text. Decorative images should stay out of the content story instead of becoming keyword containers.

Where does PixelPress fit in this workflow?

PixelPress fits after the check shows which files need new WebP or AVIF output. It can help with local batch conversion, while the page check still decides sizes, loading order, metadata, and final checks.