To reduce the weight of a mobile image, first check which file the browser actually loads. Making an image narrower with CSS does not make that file smaller. Export variants suited to the display area, confirm the selected source, then compare the page under matching conditions. A smaller image file is a measurable result; a faster page still needs to be demonstrated.
This approach suits a small business whose home page, service or product photo seems to arrive late on a phone. It also gives the person maintaining the website a specific issue to investigate, with the file URL and observations they can reproduce.
Identify the symptom before blaming the image
A photo may remain blank briefly, appear after the heading or push a quote-request button down the page. These are symptoms, not a confirmed cause. A slow server, late resource discovery or JavaScript work can also delay the result. The web.dev guide to optimizing LCP separates these parts of the delay.
Record the page, viewport size, browser and network conditions. Inspect the image request in developer tools: its URL, HTTP status, size and timing. An HTTP error or server wait calls for the relevant logs; compression will not fix every cause. One screenshot is not enough to diagnose an outage.
Prepare a change you can reverse
- Keep the original file, its usage rights and a copy of the page before editing.
- Work in a preview or test environment, with access to the template or the person maintaining it.
- Use an image exporter that lets you choose dimensions and quality, then compare the result visually.
- Record the intended display width and the details that must remain in the crop: a product, face, technical feature or essential text.
Browser developer tools and a free image editor may be sufficient. CMS integration, testing and any photo licence can still require time or a budget. You do not need an optimization subscription to start this investigation. The right compression setting depends on the image and its purpose, rather than a universal target number.
Check the file that is actually requested
- Open the Network panel, leave developer tools open and reload the page. Filter image requests to locate the photo.
- For a test without reusing the browser cache, select
Disable cachewhile the tools are open. Reload again after selecting it. Record that setting and the network profile; a CDN cache remains a separate variable. - Record the response URL and size. Distinguish file weight, resource size and observed transferred bytes: a cached response can make a comparison misleading.
- Measure the image’s display area. A photo shown at 360 CSS pixels does not necessarily need a file that is 6,000 pixels wide.
The Chrome Network panel documentation describes these controls. If the image has several variants, currentSrc identifies the selected URL. That alone does not prove a successful download: check the rendered result and image decoding too. See MDN’s currentSrc reference.
Export variants and match them to the layout
Crop a copy first, then export useful widths. In the example below, the files are exactly 640 × 360 and 1,280 × 720 pixels. The image fills the viewport minus 32 pixels, up to a maximum of 640 CSS pixels. The paths are illustrative; replace them with the locations of your actual files.
<img class="photo"
src="/img/photo-1280.webp"
srcset="
/img/photo-640.webp 640w,
/img/photo-1280.webp 1280w"
sizes="
(max-width: 672px)
calc(100vw - 32px),
640px"
width="1280" height="720"
alt="Phone and laptop">img.photo {
width: calc(100vw - 32px);
max-width: 640px;
height: auto;
}The first block belongs in the HTML template and the second in its stylesheet. srcset lists available files and their actual widths. sizes describes the expected display width in this layout. The browser selects a source based on its context, including screen density. A phone therefore does not always receive the 640-pixel file. The MDN responsive images guide explains this selection.
The width and height attributes supply the aspect ratio; CSS keeps the height proportional. This helps reserve space before the photo appears. Adjust the dimensions, ratio and sizes together if your layout changes. See the MDN img element reference. With WordPress, inspect the HTML ultimately rendered by your theme or application: uploading variants to the media library does not guarantee that the public site uses them.
Avoid delaying the main home-page image
If the photo is the LCP element—the largest visible content selected for that metric—do not give it loading="lazy". fetchpriority="high" can signal higher priority for an identified important image; applying it everywhere defeats its purpose. The web.dev LCP guide also recommends making that resource discoverable early. The small example above does not force high priority: establish the image’s role in your page first.
Illustrative example: a café photo tested locally
Imagine a café showing its space on its home page. This is an illustrative scenario, not a client engagement. We used a real licensed photograph and ran a local test on October 31, 2026. The source JPEG was cropped to a bottom-aligned 16:9 frame, resized and exported as WebP at quality 82. The original was displayed with the same visible crop. No AI generation or retouching was used.
| File | Dimensions | Measured size |
|---|---|---|
| Original JPEG | 6,720 × 4,480 | 4,863,903 bytes |
| Compact WebP | 640 × 360 | 40,126 bytes |
| Large WebP | 1,280 × 720 | 100,536 bytes |
In Chrome, a viewport of 390 CSS pixels with a simulated pixel ratio of 1 selected the 640-pixel WebP, displayed at 358 pixels wide. In the 1,272-pixel desktop viewport, with a pixel ratio of 2, the browser selected the 1,280-pixel WebP for a 640-pixel display area. Decoding succeeded in both cases, and the crop was visually inspected.
These numbers describe file sizes and the sources selected in this test. No network transfer volume, loading time or LCP was measured. Browser caching was not controlled, no network throttling was applied and no physical phone was tested. The reduction combines cropping, resizing and compression; it cannot be attributed to WebP alone.
Verify the page and decide whether the fix is enough
Repeat the before-and-after test using the same viewport, pixel ratio, network profile and cache policy. Take several measurements so an exceptional run does not determine the conclusion. If comparing LCP, also record which element triggers it: another resource may become the limiting factor. Visitor data and laboratory tests answer different questions; a local check does not replace monitoring real visits.
Inspect sharpness, useful details, cropping and content shifts at several widths. After integration, also check contact buttons, links and the consent journey without changing tracking settings to improve a score. User acceptance testing with clear criteria can help make that review repeatable.
If the browser still loads the old file, first inspect its URL and the rendered HTML, then the relevant caches. If the file is smaller but still appears late, examine the timing rather than compressing it again. Restore the previous version if a detail customers need has become unreadable.
Pre-publication checklist
- Original retained and usage rights verified.
- Actual dimensions, aspect ratio and crop aligned.
- Selected source and successful loading checked at small and large widths.
- File sizes recorded without an unmeasured speed claim.
- Main home-page image free of inappropriate lazy loading.
- Sharpness, links, contact and consent checked, with a rollback available.
For an image review in the context of your whole website, our Greater Montréal website design and improvement service connects optimization work to the pages and enquiries that matter to your customers.