Image optimization for faster pages: a practical checklist
Reviewed July 28, 2026
Boltpic
Each guide describes the current Boltpic tools and links to relevant technical references. Results that depend on the image, browser, or device are identified as variable.
Images can dominate page weight and strongly affect LCP. A large above-the-fold image that is oversized or discovered late can delay the moment a visitor sees the main content.
The following checks are ordered by a typical workflow. Measure the page before and after each change because the largest benefit depends on the layout and traffic.
1. Serve images at the size they're displayed
The most common waste on the web is a 4,000-pixel photo squeezed into a 400-pixel slot — the browser downloads ten times the pixels it can show. Resize files to roughly the display size (doubled for high-DPI screens), and for layouts that vary, let the browser pick from several sizes:
<img
src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
sizes="(max-width: 600px) 100vw, 800px"
alt="Harbor at dusk"
/>This markup lets the browser choose a candidate for the viewport and pixel density. Smaller screens avoid downloading needlessly large files; the actual saving depends on the candidates and the layout.
2. Give every image a width and height
When the browser does not know an image's dimensions in advance, nearby content can move when the file arrives. That movement contributes to Cumulative Layout Shift (CLS). Add width and height attributes, or reserve the aspect ratio in CSS, so the layout can allocate space before the image loads.
3. Apply lazy loading based on visibility
loading="lazy" asks the browser to defer images that are far from the viewport. It can reduce initial requests on long pages and is supported by current major browsers.
Do not apply lazy loading automatically to the main above-the-fold image. If that image becomes the LCP element, deferring it can delay the metric. Load a confirmed LCP image eagerly and consider fetchpriority="high" when testing shows that it should be prioritized.
4. Set a byte budget and pick formats to meet it
Set a byte budget around the page's speed target and the image's role. For a first audit, 200 KB for a hero, 100 KB for an article image, and 30 KB for a thumbnail can be useful starting points, not universal limits. Export photos as WebP or JPG, keep PNG for graphics where text or transparency matters, and inspect the result on the real page.
5. Set a cache policy
For versioned image assets, choose a cache lifetime that matches how updates are deployed. A content hash in the filename — photo.a1b2c3.webp, for example — lets you publish a new URL when the image changes. A CDN can reduce transfer latency for static images, but the benefit depends on audience location, cache hit rate, and the rest of the delivery setup.
A short image check in DevTools
- Open the page with DevTools → Network, filter “Img”, reload, and sort by transferred size. Start by inspecting the largest files.
- If a top file is much larger than its rendered size, resize it and compare WebP or JPG exports for quality and weight. Boltpic's resize, compress, and convert tools handle this in the browser.
- Check the biggest visible image on mobile: is it lazy-loaded by mistake? Does it have width/height set?
- Run Lighthouse once after the fixes — the “Properly size images” and “Serve images in next-gen formats” audits will confirm what's left.
Repeat the audit after deployment. Network conditions, responsive candidates, and page composition determine how much each change improves the real experience.