How to Test Website Speed and Find Image Performance Issues

To test website speed and find image performance issues, run the page URL through PageSpeed Insights (PSI), read its Core Web Vitals and separate field data from Lighthouse lab results, then use Chrome DevTools Performance Insights to inspect image delivery and the Largest Contentful Paint (LCP) request. Use Search Console to see whether the same issue affects groups of similar URLs. An image can be the visible LCP element without its file size being the only cause of delay.

1. Run a page-level speed test

1. Open PageSpeed Insights and enter the full URL of the page you want to investigate.
2. Review the field data and note whether it describes the specific URL or the whole origin. PSI may have no URL-level Chrome User Experience Report (CrUX) data and show origin-level data instead; the origin result does not describe precisely the same page scope.
3. Review the Lighthouse lab results separately. Treat them as a controlled diagnostic run that can point to causes and opportunities, not as a replacement for real-user experience data.
4. Record the URL and the test conditions you care about, such as mobile or desktop. When comparing later runs, use the same page and comparable conditions.

PSI combines Lighthouse audits with CrUX data: the former provides a controlled test, while CrUX represents real-user experiences from the field. The distinction matters because a lab run describes a test setup; field data aggregates user experience. Chrome for Developers explains PageSpeed Insights and its data sources.

2. Read Core Web Vitals before chasing a score

Start with the reported metrics, not a single overall score. Google documents these good ranges:

Metric	What it indicates	Good	Needs improvement	Poor
LCP	When the main content, often a hero image or heading, appears	0–2.5 seconds	Over 2.5 to 4 seconds	4 seconds or more
INP	Interaction latency	0–200 ms	Over 200 to 500 ms	500 ms or more
CLS	Unexpected layout movement	0.00–0.10	Over 0.10 to 0.25	0.25 or more

These thresholds help identify which user experience dimension needs attention. LCP is the metric most directly connected to a large image, but INP and CLS can also expose issues around the page where that image appears. A page with acceptable image delivery can still have interaction or layout problems. See the official PSI guide for the documented thresholds.

3. Determine whether the image is actually delaying LCP

In Lighthouse, identify the LCP element and compare the field result, when available, with the lab result. Google’s LCP guidance recommends checking whether lab behavior broadly aligns with field data. A large gap between First Contentful Paint (FCP) and LCP can mean the LCP resource is not available early enough—for example, an image is introduced by JavaScript—or browser work delays rendering. It does not prove that image compression is the fix. Google’s LCP guidance explains the metric and its subparts.

In Chrome, open DevTools, select the Performance panel, and inspect the available Performance Insights for the page recording. Look for:

• Improve image delivery: identifies image delivery opportunities, which may include modern formats such as AVIF or WebP and correctly sized images.
• LCP breakdown: separates parts of the LCP timeline so you can see whether the delay is before the request, during the request, or after it.
• LCP request discovery: highlights why the browser took longer than expected to discover or request the LCP image.
• Document request latency and rendering insights: help distinguish a slow initial document or browser rendering work from image transfer time.

Use the reported subparts to choose the next investigation. If discovery is late, investigate how the resource is exposed to the browser. If transfer dominates, check the delivered file format, dimensions, and delivery. If rendering dominates, inspect browser work and layout. Chrome documents these diagnostics in Performance Insights.

4. Inspect image delivery and rendering causes

For the LCP image and other large visible images, work through this checklist:

• Confirm which element Lighthouse identifies as LCP; do not assume the largest-looking image is the one that determines LCP.
• Check whether the image request is discoverable early or only starts after JavaScript runs.
• Compare the image’s delivered dimensions with the space it occupies. Correctly sized assets avoid sending more pixels than the display needs.
• Review the image delivery suggestion for a modern format such as AVIF or WebP where appropriate.
• Check whether the delay is in the document response, image request, or browser rendering before deciding that image bytes are responsible.
• After changing delivery or markup, repeat the page-level diagnostics under comparable conditions and inspect field evidence as it updates.

Do not treat a screenshot, a single lab result, or a high score as proof that every user experiences the same speed. A screenshot shows a rendered state at a point in time; it does not replace CrUX field data or the LCP timing breakdown.

5. Check whether the problem affects many pages

Use the Search Console Core Web Vitals report to see patterns across groups of similar URLs. It groups pages by status—Poor, Need improvement, or Good—and by metric (LCP, INP, or CLS). A group-level report helps prioritize a template or class of pages; it does not replace a detailed test of an individual URL. Choose representative URLs from an affected group and investigate each with PSI or Lighthouse. See Google Search Console’s Core Web Vitals report documentation.

6. Recheck after a change

1. Repeat the same page-level test for the same URL under comparable test conditions.
2. Compare the relevant LCP breakdown and image request evidence, not just the overall score.
3. Check field data again as it updates. Field data is aggregated real-user experience and will not necessarily change in lockstep with one lab run.
4. If multiple URLs share a template, check the Search Console group and representative pages to see whether the pattern holds.

Keep the scope visible in any notes or report: the URL tested, whether field data was URL-level or origin-level, and the conditions of the lab run. A single controlled run is useful for diagnosis, while field data answers a different question about aggregate real-user experience.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A screenshot does not replace PSI, Lighthouse, or CrUX measurements, but it can give you a rendered page capture without setting up browser automation. Its clean-shot steps accept cookie consent and remove 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be disabled. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

Make a one-request screenshot with 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 equivalent:

import requests

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

Node.js equivalent:

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}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Replace the example target URL and provide your API key. See the ScreenshotNeo API documentation for request options. One thousand screenshots per month are free with no card; paid plans start at $5 for 3,000. Sign up for the free plan.

Troubleshooting

Symptom	Likely cause	What to do
PSI shows origin data instead of URL data	CrUX does not have URL-level coverage for the page	Label it as origin-level data and use Lighthouse to diagnose the individual URL.
Lab LCP is poor but field LCP looks better, or the reverse	The controlled run and aggregated real-user experience reflect different conditions and scopes	Keep both results, check field-data scope, and use the lab breakdown to investigate causes.
The LCP image looks small but LCP is still late	Request discovery, document latency, or rendering work may dominate rather than transfer size	Inspect LCP request discovery and the LCP breakdown in Performance Insights.
An image delivery suggestion does not improve the observed result	The suggested format or dimensions may not be the largest delay component	Check whether the delay occurs before the request or after transfer, and inspect the rendering and document insights.
One URL looks healthy while a Search Console group is poor	The selected URL may not represent the affected group or template	Test representative URLs from the group and compare their LCP, INP, or CLS evidence.
A retest differs from the previous lab run	Lab measurements are controlled runs, not a guarantee of identical results in every run	Repeat with comparable conditions and look for a consistent pattern; use field data for aggregate user experience.

Performance, reliability, and cost notes

• Performance: diagnose the LCP subpart that is slow before changing image encoding or dimensions. Image payload is only one possible part of the path.
• Reliability: keep field and lab evidence distinct, record whether CrUX coverage is URL-level or origin-level, and retest representative pages after a change.
• Cost: this workflow uses Google’s PSI, Lighthouse, Chrome DevTools, and Search Console. No specific physical device or paid accessory is required by the documented workflow. For screenshot captures through ScreenshotNeo, the free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 and every feature is on every plan.

Frequently asked questions

Does a screenshot tell me whether my site is fast?

No. It shows a rendered state, while speed diagnosis requires timing data. Use PSI and DevTools for metrics and diagnostic evidence.

Should I optimize every image flagged by a tool?

Prioritize the image and request path connected to the page’s actual LCP evidence, then confirm the change with comparable diagnostics.

Can Search Console tell me exactly which image to fix?

Its Core Web Vitals report shows patterns across URL groups. Inspect representative individual pages in PSI or Lighthouse to identify page-level causes.