Images are usually the heaviest part of a page—and also the easiest place for quality and accessibility to quietly slip. This guide gives you a step-by-step workflow you can reuse in Safari to review images the same way every time.

Workflow diagram for auditing website images in Safari

You’ll end up with a short list of fixes that actually move the needle.

Before you start, pick one page (homepage, product page, article) and review it end-to-end. Don’t try to audit the entire site in one sitting.

Open the page in Safari, then open Developer tools.

If you don’t see the Develop menu: Safari settings → Advanced → enable “Show Develop menu in menu bar.”

Now you can reuse this loop on any URL.

Step 1: Inventory the images on the page (what exists, and where)

Your first pass is just an inventory. You want to know: how many images, which ones are “above the fold,” and which are decorative versus meaningful.

Inventory view of page images and sections

In Safari, open Web Inspector and use these quick checks:

  • Elements tab: click key page sections and look for <img>, <picture>, and CSS background images.
  • Reader-ish reality check: scroll the page slowly and note which images load late, pop in, or shift layout.
  • Make a mini list: hero image, logo, 2–3 main content images, icons, and any repeating thumbnails.

At the end of Step 1, you should have 5–15 “important” images worth checking in detail.

Step 2: Find the heavy images (transfer size vs. dimensions)

Next, identify which image requests are doing the most damage to load time.

Open the Network tab, reload the page, then filter to images (or look for common extensions like .jpg, .png, .webp, .avif).

Comparing image file weights to find biggest downloads

For each important image, capture these two facts:

  • Transfer size: what the browser actually downloaded (compressed file size).
  • Rendered size vs. intrinsic size: how big it displays vs. how big the file actually is in pixels.

What to flag immediately:

  • Huge transfer size: any single image that’s “surprisingly big” relative to the page (often hero images or banners).
  • Oversized dimensions: an image served at, say, 3000px wide but rendered at 900px.
  • Many medium images: a grid of thumbnails that are each “not terrible” but add up.

Write down the top 3 heaviest image requests. That’s usually your first round of wins.

Step 3: Confirm responsive images are working (srcset, sizes, and art direction)

This is where pages often look fine on your laptop but waste bandwidth everywhere else.

Check whether the page serves different image sizes for different viewports (and pixel densities).

In Elements, select the image and look for:

  • srcset (multiple candidate files)
  • sizes (rules that tell the browser what it will render at)
  • <picture> (different crops or formats depending on conditions)

Practical workflow:

  • Resize the Safari window narrower and reload.
  • In Network, check whether the downloaded image changes to a smaller file.
  • If it doesn’t change, you may be serving one “desktop” image to everyone.

If you’re using a CMS or image CDN, this step often translates into: “are we outputting responsive variants, or just one URL everywhere?”

Step 4: Validate format choices (AVIF/WebP/JPEG/PNG/SVG) without overthinking it

Formats matter, but the goal is simple: smallest file that still looks right.

Use this quick decision guide while you’re looking at the Network list:

  • Photos: prefer AVIF or WebP; otherwise optimized JPEG.
  • Flat graphics with transparency: WebP or SVG; avoid “giant PNG” unless truly necessary.
  • Icons and logos: SVG when possible (crisp, usually tiny).

Common flags:

  • PNG photos: often 3–10x bigger than they need to be.
  • SVG used as an image but shipped huge: sometimes an SVG contains embedded raster images.
  • Too-aggressive compression: banding in gradients, blocky artifacts, or text in images that becomes fuzzy.

If an image includes readable text, treat that as a design smell: it’s harder to localize, harder to scale, and often hurts accessibility.

Step 5: Check accessibility basics (alt text, decorative images, and lazy loading)

Image accessibility fixes are usually small, and they compound over time.

Alt text and decorative image accessibility flow

  • Meaningful images should have useful alt text: describe what the image contributes, not what it “is.”
  • Decorative images should be ignored by assistive tech: empty alt (alt="") is often correct for purely decorative visuals.
  • Avoid keyword-stuffing alt text: it helps nobody and makes screen readers worse.
  • Lazy loading: below-the-fold images can usually be lazy-loaded, but above-the-fold images should not be delayed unnecessarily.

A quick sanity check: if you removed all images, would the page still make sense? Alt text should help answer “yes” for content images.

Step 6: Turn findings into a reusable fix list (the checklist)

This is the part that makes the workflow reusable: you always exit with the same kind of action list.

  • Replace oversized sources: serve an image closer to its rendered dimensions.
  • Add/repair responsive markup: correct srcset/sizes so smaller screens download smaller files.
  • Switch format: PNG → WebP/AVIF for photos; raster icons → SVG.
  • Compress with a target: set a file-size budget (especially for heroes).
  • Fix alt text: meaningful, concise, and accurate; decorative images get empty alt.
  • Prioritize above-the-fold: ensure key images load early and don’t cause layout shifts.

If you keep a simple template, you can paste the same headings into every ticket: URL, image URL, current transfer size, rendered size, recommended change.

Takeaway: the 15-minute Safari image review loop

Inventory → find the heavy hitters → confirm responsive behavior → verify formats → check alt/lazy loading → write a consistent fix list.

Run that loop on one page per week and your site’s “image debt” stops piling up.