Image Optimization Checklist for Faster Websites
14 specific checks covering format, compression, dimensions, lazy loading, CLS prevention, alt text, and SEO. Work through it once on your existing pages, then use it every time you publish.

Most image optimization guides tell you what to do in theory. This one is a working checklist: specific checks, specific fixes, and specific tools for each one. Work through it once on your existing pages, then use it as a reference every time you publish new content.
Images are 48% of average page weight according to the 2025 HTTP Archive Web Almanac. They are the LCP element on roughly 85% of desktop pages and 76% of mobile pages. No other single category of optimization moves page speed numbers as reliably as getting images right. The checklist below covers every dimension of that: format, compression, dimensions, loading behavior, layout stability, file naming, alt text, metadata, and delivery.
Before You Upload: The File Preparation Checks
These happen on your computer before an image ever touches your CMS or hosting.
Check 1: Convert from HEIC if you shot on an iPhone
HEIC is the default camera format on iPhones since iOS 11. Browsers do not render HEIC natively. CMS platforms reject it. If your image file ends in .heic or .HEIC, convert it before anything else. The HEIC to JPG converter handles this in the browser with nothing uploaded. Ten seconds. Do this first.
Check 2: Choose the right format for the image type
The format decision matters more than any compression setting. The rule is simple:
For photographs and product images: AVIF as primary, WebP as fallback. AVIF produces files roughly 40-50% smaller than JPEG at equivalent visual quality. WebP produces 25-35% smaller files than JPEG. Both are supported in all current browsers.
For logos, icons, and simple illustrations: SVG if the image is vector-based. A logo that is 45KB as PNG is typically 3-5KB as SVG.
For screenshots and images with text: PNG or WebP lossless. Text edges need pixel-perfect sharpness and lossy compression creates visible artifacts at those edges.
For everything else going on a web page: WebP at minimum. JPEG should be the fallback format served to the approximately 4% of browsers that cannot render WebP, not the primary format.
The guide on best image formats for SEO in 2026 covers the reasoning behind each of these choices with browser support data if you want the full picture.
Check 3: Resize to the actual display dimensions before uploading
This is the most impactful single step and the most frequently skipped. Your camera produces images at 4000 to 6000 pixels wide. Your blog content column is probably 800 to 1200 pixels wide. Uploading the full-resolution original and letting the browser scale it down means every visitor downloads 4-12 times as many pixels as they need.
File size scales roughly with the square of the dimensions. Halving the width and height quarters the pixel count and reduces file size to approximately one quarter before you have touched a compression setting. A 3MB photo resized to match a 1200px content column typically compresses to under 200KB with no visible quality difference at display size.
The resize image tool handles exact pixel dimensions. For common targets, the specific tools save time: 1920x1080 for hero images, 1280x720 for standard wide images, 1080x1080 for square crops. Resize first. Compress second. Always in that order.
The guide on best image sizes for blogs and websites has a full reference for each image type: hero images, featured images, thumbnails, Open Graph, product photos.
Check 4: Compress to the right file size target
After resizing, compress. The targets depend on the image type:
Hero and banner images at 1920x1080: under 200KB as WebP or AVIF. Featured blog images at 1200x630: under 100KB. Inline content images at column width: under 150KB. Thumbnails at 300-400px: under 30KB.
If you are compressing to a specific KB target for a form, portal, or size constraint, the target-specific tools handle this directly: compress to 100KB, compress to 200KB, compress to 500KB. For tighter requirements, compress to 50KB or compress to 20KB.
The quality floor for JPEG and WebP compression is around 75-80% for photographs displayed at screen size. Below that, compression artifacts become visible at normal viewing distances. For AVIF you can go slightly lower. The guide on lossy versus lossless compression covers where the quality tradeoff sits for each format.
Check 5: Strip EXIF metadata
Every photo taken on a smartphone carries invisible EXIF data: GPS coordinates, device model, timestamp, camera settings. For a web image, this metadata serves no purpose and adds 10-20% to file size. A 95KB image with metadata can come down to 80KB after stripping.
More importantly, EXIF data includes GPS coordinates that identify exactly where a photo was taken. Sharing photos without stripping that data means the location travels with every download. All compression tools at ImgTweak strip EXIF automatically during processing. If you are using a different tool, verify it handles metadata removal. The guide on what EXIF data contains explains exactly what is inside that metadata and why removing it matters.
Check 6: Name the file descriptively before uploading
File names are a ranking signal in Google Images. Every IMG_0238.jpg is a missed opportunity. Rename to a descriptive, hyphenated slug that tells Google what the image contains: blue-trail-running-shoes-mens.webp, homemade-sourdough-bread-loaf.avif, london-eye-view-from-south-bank.webp.
Rules for filenames: lowercase only, hyphens not underscores, no spaces, no special characters, no numbers-only names. The extension should match the actual format. A file renamed to .jpg but still containing PNG data will fail format validators on many upload systems. Use a converter to change format, not a rename.
In Your HTML: The Markup Checks
These live in your page code and affect how the browser requests, prioritizes, and renders images.
Check 7: Never lazy load the LCP image
Lazy loading is a browser instruction to defer loading an image until it is near the viewport. For images below the fold, this is correct and recommended. For the hero image, it is a performance error that directly increases your LCP time.
The LCP image is already in the viewport. Adding loading="lazy" to it tells the browser to deprioritize it until after layout completes, which delays the largest visible element. On constrained mobile connections, this can add hundreds of milliseconds to LCP. Google's engineers measured test cases where removing lazy loading from the LCP image improved LCP from 2.6 seconds to 1.9 seconds.
The specific mistake to watch for: WordPress and many page builders apply loading="lazy" to all images by default, including hero images. Check your rendered HTML. If your hero <img> tag has loading="lazy", remove it.
For all other images below the fold, loading="lazy" is correct and reduces initial page load weight by deferring images the visitor has not scrolled to yet.
Check 8: Add fetchpriority="high" to your LCP image
fetchpriority="high" tells the browser to request this specific image at the highest network priority. Combined with removing loading="lazy", it ensures the browser starts fetching the hero image as early as possible during page load. Google documented a 200-700ms LCP improvement from adding this single attribute to the LCP image.
Use it on exactly one image per page. Marking every image as high priority defeats the purpose because the browser has nothing to deprioritize. One image, one fetchpriority="high".
<img
src="hero.webp"
alt="Descriptive alt text"
width="1920"
height="1080"
fetchpriority="high"
/>Check 9: Always set explicit width and height attributes
Missing width and height attributes on <img> tags cause Cumulative Layout Shift. When a browser starts rendering a page, it reads the HTML to determine where to place elements. Without explicit dimensions, it does not know how much vertical space to reserve for an image before it loads. When the image arrives, it pushes surrounding content down. That content jump is a CLS event.
The width and height values in the HTML do not need to match the exact display size in CSS. The browser uses them to calculate the aspect ratio and reserve the correct proportional space. What matters is that the ratio is correct:
<!-- Correct: aspect ratio lets browser reserve space -->
<img src="product.webp" alt="..." width="800" height="600" loading="lazy" />
<!-- Wrong: browser can't reserve space, causes CLS -->
<img src="product.webp" alt="..." loading="lazy" />Check 10: Use the picture element with format fallbacks
Serving AVIF or WebP with JPEG fallback requires no server-side logic. The HTML <picture> element handles it natively:
<picture>
<source srcset="image.avif" type="image/avif" />
<source srcset="image.webp" type="image/webp" />
<img src="image.jpg" alt="Descriptive alt text" width="1200" height="630" />
</picture>Modern browsers request AVIF. Browsers that support WebP but not AVIF request WebP. Older browsers fall through to JPEG. Every visitor gets the smallest file their browser can render. For the LCP image, add fetchpriority="high" to the <img> tag inside the <picture> element.
Check 11: Use srcset for responsive images
If your layout serves different image widths on mobile versus desktop, srcset tells the browser which file to download for each viewport:
<img
srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 1200px"
src="image-1200.webp"
alt="..."
width="1200"
height="800"
/>A mobile visitor downloading a 1200px image displayed at 400px is downloading nine times as many pixels as necessary. Responsive images solve this at the HTML level with no JavaScript.
The SEO Checks
Check 12: Write meaningful alt text for every image
Alt text is the primary signal Google uses to understand what an image depicts. John Mueller confirmed this directly: alt text "is essentially shown when the images are turned off in most browsers so that's something that we would count as part of the on-page text."
Effective alt text describes what is in the image accurately and naturally. A photo of a black leather notebook on a wooden desk: alt="Black leather notebook on wooden desk". Not alt="notebook notebook leather desk buy notebook". Not alt="". Not alt="image".
Decorative images that add no informational value can use alt="", which tells screen readers to skip them. Every image that conveys information needs descriptive alt text.
Check 13: Verify images are in your sitemap
Google discovers images during crawls, but images embedded in JavaScript components may be missed. An image sitemap, or including image tags in your existing XML sitemap, ensures Google can find and index images that are not in static HTML.
If you use Next.js, WordPress, or another framework where images are rendered client-side, check your sitemap configuration to confirm images are included. Google Search Console shows which images from your site have been indexed under the Coverage report. If pages with important images show no image impressions in the Images tab, the images may not be indexed.
Check 14: Check for images blocking crawl
Images hosted on domains or subdomains not covered by your robots.txt allowed rules will not be indexed. Images behind authentication or served from localhost references in production will not be indexed. Images referenced in CSS background properties rather than <img> tags may not be discovered.
Run your key pages through Google's URL Inspection tool in Search Console and check that the rendered HTML shows the actual image src attributes, not JavaScript variables or data attributes that have not been evaluated yet.
The Audit: How to Find Problems on Existing Pages
Once you know what to check, running the audit against your existing content is the practical step.
PageSpeed Insights (free, at pagespeed.web.dev) runs a full Lighthouse audit on any URL and flags specific images by filename under "Properly size images," "Serve images in next-gen formats," and "Efficiently encode images." It tells you exactly which files are the problem and estimates the potential savings in kilobytes for each one.
The Images tab in Google Search Console shows which images are generating impressions in Google Images, which have clicks, and which have been indexed at all. If a page with many images shows no image impressions, that is a signal that indexing, alt text, or format issues need attention.
The image info tool shows the metadata inside any image file before you upload it: dimensions, format, file size, EXIF data, and GPS status. Use it to verify that compression and metadata stripping worked correctly on an output file before publishing.
For a broader look at how image weight connects to actual ranking outcomes, the guide on how image compression affects SEO and page speed covers the Core Web Vitals connection with specific data on what the performance thresholds mean in practice.
The One-Page Reference
If you want a single quick reference to keep alongside your CMS, here is the full checklist compressed:
Before upload: convert HEIC to JPEG, choose the right format for the image type, resize to display dimensions, compress to the file size target, strip EXIF metadata, and name the file descriptively.
In HTML: no loading="lazy" on the LCP image, add fetchpriority="high" to the LCP image, set explicit width and height on every <img>, use <picture> with AVIF and WebP sources, use srcset for responsive variants.
For SEO: write descriptive alt text for every informational image, verify images appear in your sitemap, check that no robots rules are blocking image crawling.
None of these steps is technically complex. Collectively, they represent the difference between a site where images help performance and rankings and one where images are the primary bottleneck for both. The tools to handle the file preparation steps are free, run in the browser, and require no software installation. The HTML attributes take minutes to add. The SEO checks take one session in Search Console.
Run through it once and the habit takes a few minutes per image going forward.