Website image check
Optimise website images: review the page before publishing
Use this guide to understand what the browser actually loads, select the correct size for each image, correct the HTML, and review the page before publishing.
Quick answer
Review the live page before exporting another file
The quickest image fix isn’t always a new converter. First identify heavy requests, missing sizes, a lazy-loaded LCP image, or outdated metadata. Start with the page, then export only necessary changes.
Initial check
Begin with what the browser downloads
Design files and media folders don’t reveal what users actually receive. The browser shows which image URL loads, its displayed size, if space is reserved, and whether a large file is reused where a smaller one would suffice.
Which URL is loaded?
Open the page and note the actual image URL, transfer size, displayed size, and if the browser selected the intended version.
What is the image size?
Measure the visible area rather than estimating from the source file. Cards, content columns, and social images should each have distinct exports.
Is it visible on the first screen?
Identify the probable LCP image, ensure it’s not lazy loaded by accident, and defer less critical images from the initial load.
Is the metadata consistent?
Verify alt text, Open Graph image, JSON-LD image, surrounding text, and file names to ensure the page conveys a consistent message.
Image plan
Plan every key image before conversion
An image plan separates this guide from converter articles by defining each image area's needs: size, loading order, fallback, metadata role, and a final verification that the correct file is used.
| Image area | Decision | Risk | Check |
|---|---|---|---|
| Main image | Specify the probable LCP image, exact dimensions, loading order, and fallback path. | Lazy loading or oversized files may delay the first meaningful image. | Compare displayed size, requested file size, and loading behaviour on the initial screen. |
| Article content image | Define content-width variants and reserve space using width and height. | The page might load a source image far wider than the reading column. | Review desktop and mobile widths and confirm the selected srcset option. |
| Repeated card image | Generate smaller versions for lists, hubs, related cards, and archive pages. | A single reused article image can significantly increase a listing page’s weight. | Scan the listing page to ensure repeated cards don’t load full article images. |
| Metadata image | Prepare Open Graph and JSON-LD images as planned assets, not accidental leftovers. | Search and sharing previews may display outdated, cropped, or unrelated images. | Examine rendered meta tags and structured data for the final URL. |
When the plan indicates files need new versions, use the Image conversion guide to decide the next step. Use the JPG to WebP guide for standard WebP tasks and the AVIF guide only for large photos needing further optimisation.
Image sizes
Define clear sizes for each image area
Responsive images function only if the HTML matches the layout. Measure the area, select a few practical widths, reserve the aspect ratio, and avoid sending a large original simply because it exists.
Simple check: if a 360 px card downloads a 2400 px file, compression isn’t the main issue. The page needs a smaller image version or the HTML points to the wrong file.
Loading sequence
Ensure the first image loads intentionally
The image defining the first screen requires different rules than those lower down. Identify the likely LCP image, avoid lazy loading it accidentally, and keep lower images inactive until needed.
- 1
Identify the LCP image
If the first significant image is likely the Largest Contentful Paint, avoid lazy loading it unintentionally.
- 2
Keep lower images unobtrusive
Images below the first viewport should generally use lazy loading and asynchronous decoding.
- 3
Inspect CSS backgrounds
A cropped background might still download a large file. Use a properly sized image for the visible section.
- 4
Inspect repeated requests
A small card image becomes costly if the same oversized file is used repeatedly across many instances.
HTML
Employ responsive HTML for the measured area
For key images, clarify the browser’s choice. The example below details width options, sizes, fixed dimensions, and fallback. Adjust loading behaviour according to the area, not by routine.
<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 illustrating the upload process"
width="960"
height="540"
loading="lazy"
decoding="async" />
</picture>Search and sharing
Ensure images, alt text, and metadata convey a unified message
Image SEO involves more than keywords. The visible image, surrounding text, useful alt text, Open Graph tags, and JSON-LD image links should consistently represent the page. Decorative images should remain decorative.
If the check finds weak social previews, proceed with the Open Graph image guide. If schema and meta tags are problematic, use the Blazor metadata guide to maintain consistency between JSON-LD and page metadata.
Steps
A straightforward image check for every page
- 1
Open the live page
Begin with the current URL, not the asset folder. Record the images that truly load.
- 2
Develop the image plan
For every key image, note target width, aspect ratio, loading sequence, fallback, and metadata function.
- 3
Convert only changed files
Use conversion tools only for files identified by the check, rather than re-exporting the entire media folder.
- 4
Update HTML and metadata
Direct srcset, sizes, dimensions, Open Graph, and JSON-LD image links to the prepared files.
- 5
Verify browser output
Inspect the page, network requests, social metadata, structured data, and mobile layout.
- 6
Preserve the rule for future use
Record image decisions to avoid guesswork in future updates.
Tooltip
Use PixelPress once you know which files to convert
When the check indicates a folder requires new WebP or AVIF files, PixelPress can convert them locally. Originals remain unchanged, and the output folder is easy to review.
Pre-publish checklist
Image checklist before publication
Use this list before an article, landing page, or product page goes live. It identifies issues that conversion alone might miss.
FAQs
What does a website image check do?
A website image check examines the images a live page loads, comparing them against the visible layout, loading sequence, responsive HTML, alt text, metadata, and structured data links.
Is image optimisation the same as converting to WebP or AVIF?
No. Conversion is just one part. The page may still be slow if HTML references incorrect files, sizes are absent, the LCP image is lazy loaded, or metadata is outdated.
How can I identify the image impacting performance the most?
Start with the first screen and network requests. Identify the largest visible image, oversized repeated card images, CSS backgrounds, and files where displayed size is much smaller than the downloaded file.
Should every image have alt text?
No. Useful images require meaningful alt text. Decorative images should remain outside the content narrative and not serve as keyword holders.
Where does PixelPress fit within this workflow?
PixelPress is used after the check identifies files needing new WebP or AVIF versions. It assists with local batch conversion while the page check determines sizes, loading order, metadata, and final verification.