How to Analyze Website Images to Improve Page Speed

To find out whether images are slowing a page, combine real-user field data with a lab diagnostic, identify the page’s Largest Contentful Paint (LCP) element, and inspect that element’s image request in the browser’s network waterfall. Then test a targeted change—such as right-sizing, changing format, or adjusting when the image loads—and measure again. An image can be the LCP element without its download size being the main cause of a late LCP.

Start with the exact page in PageSpeed Insights. Read its field data and Lighthouse lab diagnostics as different kinds of evidence. Field data describes real visits; a lab run is a diagnostic under a particular test setup. Check mobile and desktop separately. A good LCP target is 2.5 seconds or less at the 75th percentile for each device segment. That target describes user experience; it does not, by itself, prove an image is responsible. Google’s LCP guidance explains the metric and threshold.

1. Establish a representative baseline

Enter the exact page URL in PageSpeed Insights and note whether field data is available for that URL.
If the report uses origin-level data, treat it as context for the site, not a measurement of the specific page. Page behavior can differ across URLs.
Record mobile and desktop results separately. The same page may behave differently at different viewport sizes and under different network conditions.
Keep the report’s field data separate from the Lighthouse lab results. Use field data to understand users’ experience and lab diagnostics to investigate likely causes.
Repeat lab runs under comparable conditions before and after a change. A single score can vary; look at the metric and its diagnostic evidence.

PageSpeed Insights is a convenient starting point because it presents CrUX field data alongside Lighthouse diagnostics. For local investigation, Chrome DevTools can show a Performance trace and Network waterfall. Lighthouse is useful for repeatable lab audits, while WebPageTest is another lab option for measuring LCP. These tools answer different questions; do not assume a local lab run represents every user’s experience. See web.dev’s Web Vitals overview and its LCP guide.

2. Identify the LCP element and its request

First verify what the browser recorded as LCP. It may be an image, a text block, or a video poster in the visible viewport. Use the LCP element diagnostic in PageSpeed Insights or Lighthouse, or record the page in Chrome DevTools’ Performance panel and inspect the LCP event. Do not optimize images just because the page contains large files; confirm that an image is relevant to the observed LCP or another measured issue.

If the LCP element is an image, note its URL and find the matching request in the Network panel or trace. Inspect when the request starts, how long it takes, when it finishes, and when the element renders. LCP includes more than image transfer: late discovery, request scheduling, server response, and rendering can all contribute. If the image downloads promptly but LCP occurs much later, repeated compression may not address the cause. The LCP optimization guide describes the metric’s timing breakdown.

3. Inspect the image the browser actually receives

Dimensions: Compare the resource’s intrinsic pixel dimensions with its rendered dimensions and the viewport/device needs. An image substantially larger than its display size may be a candidate for responsive variants. Inspect the selected network resource; CMS settings or source files do not always tell you what the browser received.
Format: Consider WebP or AVIF where the site’s delivery path and browser support allow it. Modern formats can compress more efficiently than older JPEG or PNG alternatives, but results depend on the image and encoding settings. Web.dev reports that AVIF tests have shown savings greater than 50% compared with JPEG in some cases; treat that as a possible result, not a guarantee. Check current browser support and test representative assets.
Compression: Choose lossy or lossless compression based on the image and the quality bar. Lossy compression can work well for detailed photos; sharp edges, text, and flat artwork may show artifacts. Compare the output visually at realistic display sizes.
Loading behavior: Check whether below-the-fold images are being fetched before they are needed. Deferring appropriate offscreen images can help, but avoid delaying an image needed for the initial viewport or LCP.

For responsive delivery, use width-appropriate candidates and let the browser select among them based on the rendered layout and device. Verify the selected candidate in the Network panel at representative viewport sizes. The web.dev image learning guide covers responsive images and formats. Its image optimization guide recommends experimenting with compression levels and inspecting the quality-size tradeoff.

4. Change one cause, then measure again

Write down the suspected bottleneck: oversized transfer, late request start, slow response, delayed render, or unnecessary early loading of offscreen assets.
Make one relevant change, such as adding right-sized responsive candidates, trying a modern format, adjusting compression, or deferring suitable below-the-fold images.
Check the image at its actual rendered size for artifacts, cropping changes, and layout shifts.
Repeat the lab measurement with the same page, viewport, and comparable conditions. Compare LCP and the relevant request timing, not only the overall score.
After release, monitor field performance where possible. Lab checks can help catch regressions during development; field data shows what visitors experience.

If the request starts late, investigate how the browser discovers and prioritizes it. If transfer dominates, test dimensions, format, and compression. If the file arrives quickly but LCP remains late, investigate the remaining timing stages and page or server work. For sites that need to generate and deliver many responsive variants, compare building the pipeline in-house with a managed image optimization service or image CDN; choose based on operational needs and validate the delivered assets in the browser.

5. Use browser tools to inspect a page visually

A screenshot can help review what was visible at a given viewport and whether a proposed image change affected the composition. It does not replace PageSpeed Insights, a Performance trace, or the Network waterfall: an image alone cannot tell you request start time, transfer duration, or LCP timing. For a local page, Chrome DevTools can capture a screenshot while you inspect its Performance recording. For repeatable visual captures of a public page, use a screenshot tool alongside the performance measurements.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single GET request can return a screenshot or PDF; the API accepts parameters used by other screenshot APIs to make switching easier. For a screenshot of the page you are inspecting:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

For the full parameter list and options, see the ScreenshotNeo API documentation. ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses report the page verdict and billing status in headers. Its MCP server gives AI agents tools named take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.

Runnable API examples

Use an API key from your ScreenshotNeo account. Keep it server-side or in a secret manager; do not expose it in a public page or committed source file. The examples capture the same sample page. Change the target URL to the page you are reviewing. A screenshot shows appearance, not performance timings, so use it with the diagnostic workflow above.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
    f.write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

See the API documentation for capture parameters and response details. ScreenshotNeo supports full-page captures, CSS element capture, device presets and custom viewports, dark mode, retina scale, custom CSS and JavaScript, selector or delay waits, network-idle waits, request and resource blocking, headers, cookies, user agent, timezone, geolocation, transparent backgrounds, resizing, caching with a chosen TTL, signed image links, asynchronous jobs, signed webhooks, bulk capture, usage information, and PDF options. Check the documentation for exact parameter names and combinations before adding options to a request.

Troubleshooting image analysis

What you see	Likely cause	What to do
PageSpeed Insights has no page-level field data	There may not be enough URL-level CrUX data; the report can show origin-level data instead.	Label the result as origin data and use page-specific lab diagnostics for the URL. Do not treat the origin value as the page’s field result.
The LCP element is not an image	A text block or video poster is the largest eligible visible element.	Follow the recorded LCP element and its timing. Do not assume image optimization will improve that LCP.
The LCP image request starts late	The browser may discover or schedule the resource late, or other page work may delay it.	Inspect the trace and request waterfall, then investigate discovery and priority. Compression only helps transfer time.
The image downloads quickly, but LCP is still late	The delay may occur before the request, after transfer, or during rendering.	Use the LCP timing breakdown and trace to find the delayed stage before changing image quality again.
A new format does not improve the page	The asset may not compress better in that format, another stage may dominate, or the browser may receive a different resource than expected.	Inspect the actual selected request and compare transfer size and quality under the same conditions.
The optimized image looks visibly degraded	Compression is too aggressive for the image’s details or sharp edges.	Raise quality or use a more suitable encoding approach; compare at the real display size.
A screenshot differs from the expected page	The page may need time or a selector to load, may vary by viewport, or may show consent UI or dynamic content.	Use documented wait, viewport, and consent options, and compare like-for-like captures. A screenshot cannot establish network timing or field performance.

Performance, reliability, and cost considerations

Performance: Prioritize the measured bottleneck. Smaller files help when image transfer contributes materially; they do not fix late discovery, server delays, or unrelated rendering work. Avoid lazy-loading the initial LCP image.
Reliability: Re-run lab comparisons under comparable conditions and keep device segments distinct. Field and lab results can differ because they represent different populations and conditions. Confirm visual quality and the actual delivered resource after each change.
Cost: Browser diagnostics such as PageSpeed Insights, Lighthouse, and DevTools provide a practical baseline without requiring an image CDN. A managed image service can reduce the work of generating and serving variants, but compare its operational fit and pricing directly before adopting it. ScreenshotNeo’s free allowance and paid tiers are described above; screenshots are useful for visual review, not a substitute for performance metrics.

FAQ

Does a large image always make LCP worse?

No. It may be the LCP element, but the request can start late or the element can render late for reasons beyond transfer size. Inspect the timing stages before deciding what to change.

Should every image be AVIF?

No single format is best for every asset and delivery setup. Test representative images, check browser support, and compare both visual quality and the resource the browser actually receives.

Can a screenshot tell me whether an image is hurting page speed?

No. A screenshot helps inspect appearance. Use field data, lab diagnostics, and request timing to determine performance impact.

Should I optimize mobile and desktop separately?

Yes. Their viewport sizes, selected responsive image candidates, and measured performance can differ. Review each device segment independently.