Imagyc›Articles

How to find images that are slowing down your website

Published October 11, 2026 · 8 min read

The banner appears after the text. Product photos take time to fill the grid. Everything seems fine on your computer, but the page keeps visitors waiting on a phone. Before compressing every file, find out what happens to the images the browser actually receives.

To diagnose slow images, identify the file used on the page, check how much data it transfers, when loading starts and how long it takes to appear. Then test a change and compare the results under the same conditions.

You can begin without writing code. PageSpeed Insights helps locate issues; Chrome lets you investigate individual files. The goal is to turn “I think it is the photos” into a decision you can verify.

For the background on visitors and data use, read why image optimization matters. This guide focuses on diagnosis.

1. Choose a page and describe the problem

Start with the URL where the difficulty occurs: a product, landing page or article. Testing only the homepage can miss the actual issue.

Write down what you see and where: “the main photo is slow on mobile,” “the gallery stalls when opened,” or “the text moves when the banner appears.” That observation helps you choose a test and check whether the change addresses the symptom.

Record the URL, date, device and whether the browser already had the files cached. Save a screenshot of the page and the initial results without personal or customer information.

Begin with one page and a clearly defined problem. The same correction may help other pages, but that conclusion follows the first check.

2. Use PageSpeed to locate areas worth investigating

Open PageSpeed Insights, enter the published URL and run the analysis. Check mobile and desktop separately. The report combines a lab test with real-user data when available.¹

In the diagnostics, look for image delivery, LCP and layout-shift information. Labels can change with the tool's version and language. Expand the details rather than relying on the overall score.

The Improve image delivery insight highlights potential data savings. Those savings are estimates, not a guaranteed output file size or a prediction of seconds saved.²

Create a short list of flagged files. Record each URL, estimated savings and role on the page. A main photo and an image at the end of an article can deserve different priorities despite having the same file size.

Check whether field data covers the page or the origin

Field data covers the preceding 28 days and requires enough samples.³ PageSpeed can show origin-level information instead of URL data, or no field data.¹ Check the label; missing data does not demonstrate good performance.

A lab test helps investigate an immediate change. Field data helps assess visitors' experience over time. Keep each result with its context.

3. Find the files Chrome is downloading

Open the page in Chrome and follow these steps:

1. Right-click and select Inspect.
2. Open Network.
3. Reload with the panel open.
4. Select the image filter, usually Img.
5. Sort by Size to find the largest transfers.⁴

Hover over the filename to check the full URL. Select the request and examine its preview. This connects the report entry to the banner, thumbnail or photo on the page.

The delivered file may differ from the one you uploaded. A site can generate sizes, convert formats or use a CDN. Investigate the actual request URL before deciding which original to change.

Compare visits with and without browser cache

In Network, Disable cache turns off browser caching while DevTools is open. Reload and record that test. Then uncheck it and observe a cached visit. Keep the results separate.⁵

A Service Worker or application cache can still provide the resource. Check the request's indicated source. Disabling browser cache does not, by itself, prove that all caching layers have been removed.⁶

File size, request time and transfer are different measurements

Size helps distinguish transferred bytes and resource size; Time describes request duration. Timing breaks that duration into stages such as waiting for a response and receiving content. A long request does not, by itself, identify poor image compression.⁵

Do not add every photo's request time to predict page load time: requests can overlap. Identify the images delaying the content you are investigating, not just those with the biggest number in a column.

4. Compare file dimensions with the display area

A catalog photo might be 3,000 pixels wide while appearing in a 300-CSS-pixel card. Investigate that difference, especially if the card uses the file intended for zooming.

Check the element's displayed width in Elements. Then obtain the actual delivered file's pixel dimensions from its preview or the saved image's properties. Do not rely only on the original in your media library.

Account for screen density. An image displayed at 400 CSS pixels wide may benefit from an 800-pixel file on a 2x screen. A site can offer candidates using srcset and sizes so the browser chooses according to the context.⁷

If the requested URL still points to an oversized version on a narrow screen, inspect the responsive setup. A larger file may serve higher density or zoom; establish the purpose before reducing resolution.

See the desktop and mobile image resolution guide for more detail. A useful diagnosis connects pixel dimensions, display space and image purpose.

5. Check whether an image delays the main content

In Chrome, open Performance, record a page reload and inspect the LCP event and associated insights. When the measured element is an image, match it to the URL found in Network.⁸

LCP tracks the appearance of the largest eligible content in the viewport. Depending on the page and screen, that element may be text or other content. Poor LCP does not establish that every photo is too large.⁹

The breakdown separates these stages:

These stages are defined in the LCP documentation. An image can suffer from a late request, slow resource loading or delayed display after loading.¹⁰

If image loading starts late

Check whether it uses loading="lazy", relies on JavaScript to enter the page or is not discovered early. The LCP image should be available to the browser from the start; a high-priority hint may be appropriate for that resource.¹¹

If the request takes a long time

Inspect bytes and Timing. Is there a lot of content to receive, or is most time spent waiting for the response? The former supports comparing dimensions and compression; the latter calls for a delivery investigation. More than one issue can coexist.

If the file has arrived but the image remains invisible

Examine render delay. Code, styles or display conditions can keep content waiting. Reducing file size may save data without resolving that delay.⁹

6. Turn observations into priorities

The following table is an editorial investigation example. The values are hypothetical, not Imagyc measurements or Google limits.

Reserving image space helps prevent layout shifts, but other causes can move a page too. Establish which element caused the movement.¹²

A practical order is to investigate the image tied to the main content, then large transfers already present in the first screen, followed by galleries. Adjust that order to the problem recorded at the beginning.

7. Test a correction and verify the published file

When evidence points to excessive data, copy the file and test compression or conversion with Imagyc. Compare dimensions, file size and important details such as lettering, texture and product finish.

The JPEG, PNG, WebP, AVIF and JXL format guide helps choose candidates. A smaller version is useful only if the destination accepts its format and the image still serves its purpose.

After publishing, return to Network and confirm the new URL and received bytes. If the site still serves the old version, investigate caches and page references before deciding optimization failed.

Renaming also requires updating the places that use the file. See how to name images for SEO to organize exports without leaving broken references.

8. Compare before and after consistently

As a practical protocol, run three tests before and three after, keeping the URL, device profile, simulated network and cache condition consistent. Record the results and compare the median and variation. Three tests do not represent the whole audience, but help avoid relying on one run.

Do not directly compare a fast reload on your computer with PageSpeed's simulated mobile test. Pick a tool and preserve its conditions within each comparison.

Chrome device mode approximates screen, network and processing conditions, but does not completely reproduce a phone. Check on a real device too.¹³

Lighthouse scores depend on metrics and can vary. Saving bytes does not assure a proportional score increase. Compare the measurement associated with the issue and the page's appearance as well.¹⁴

Frequently asked questions

Is every image larger than 100 KB a problem?

No. A thumbnail and a zoomable photo serve different purposes. Evaluate size alongside dimensions, quality and loading behavior. A standalone limit cannot diagnose the issue.

Why did compression barely change LCP?

First confirm that the page serves the new file. Then examine the LCP stages: the bottleneck may precede downloading or occur during display. Treat data savings separately from timing improvements.

Can I rely on the PageSpeed score alone?

Use the details to decide what to fix. The overall score helps track the broader picture but cannot, alone, identify the photo causing your observed symptom.

Do WebP and AVIF images need investigation too?

Yes. The extension does not establish appropriate dimensions, export settings or request timing.

How do I know when I am done?

Return to the original observation. Does important content appear more effectively? Is the intended file delivered? Did data use fall when that was the goal? Is quality still suitable? Keep your record and check again when changing banners, layouts or tools.

Start with an important page and an identifiable file. Diagnosis becomes useful when each change addresses a concrete observation and can be checked on the published site.