A large photograph can make a service page feel credible and help customers understand what you offer. It can also leave them waiting for the first screen to finish appearing.
If your website’s hero image loads slowly, start by finding where the delay happens. The file might be too large, the mobile page might request an unsuitable version, or the browser might discover the image late. Sometimes the image has already downloaded and other page code is keeping it hidden.
For a UK business, the useful outcome is a clear, usable page that appears promptly on customers’ phones. This guide explains what to check yourself, what to ask your developer and how to confirm that a change has helped.
What does LCP tell you about a slow hero image?
Largest Contentful Paint, or LCP, measures when the largest eligible image, text block or video becomes visible in the viewport. A hero image is the prominent image near the top of a page; it can be the LCP element, but you need to check the actual page.
Google’s LCP guidance sets a good threshold at 2.5 seconds or less, assessed at the 75th percentile and separately for mobile and desktop. In practical terms, the target should be met for at least three quarters of the measured page loads.
Use that as a performance target. If your main heading is the LCP element, investigate what delays that heading rather than assuming the photograph is responsible.
Start with the pages customers actually arrive on
Choose a short list: your homepage, an important service page and a landing page receiving paid traffic. Record the exact URLs. A tidy homepage result tells you little about a different template with a large background photograph.
Run each URL through PageSpeed Insights and review both mobile and desktop. Look for the LCP result, the identified element in the lab diagnostics and the relevant image insights.
Google distinguishes real-user data from lab diagnostics. Real-user results cover the previous 28 days. When there are too few samples for an individual URL, the report may show results for the whole website origin instead. It may have no real-user data at all.
Note which scope you are looking at. Use the lab test to investigate a specific page, and use available real-user data to understand the experience visitors have had. Missing field data is a reason to use other evidence, not a clean bill of health.
Find the part of loading that needs attention
Ask your developer for the LCP breakdown from a performance recording. For an image, the loading journey has four measurable parts:
| Part | What it means | What to investigate |
|---|---|---|
| Time to first byte | Waiting for the first byte of the page’s HTML response. | Redirects, server response and page caching. |
| Resource load delay | The gap before the image request starts. | Late discovery, lazy loading and request priority. |
| Resource load duration | The time spent downloading the image. | Image dimensions, compression and delivery. |
| Element render delay | The gap between the completed download and the visible image. | Blocking styles, scripts and reveal effects. |
The breakdown prevents a familiar waste of effort: repeatedly compressing an image when the page is waiting on something else. Google’s LCP optimisation guide explains how savings in image download time can be absorbed by a remaining rendering delay.
Request a recommendation tied to the largest observed bottleneck. A useful diagnosis names the affected page, the image requested and the reason it appears late.
Prepare a suitable image file
Resize and compress while checking the result
Keep the original photograph as your master, then create versions for the website. Uploading the largest file available makes the original convenient to store, but says nothing about whether it is suitable for delivery to a customer.
Compare the image’s pixel dimensions with the space it occupies, allowing for sharper displays. Then compare compressed exports at the size customers will actually see. Look at faces, fine edges, gradients and product detail before accepting a smaller file.
Chrome’s image delivery guidance recommends appropriate dimensions, compression and modern formats such as WebP and AVIF. Try these formats for photographs and compare the resulting files. Avoid choosing a format solely by its name.
There is no useful universal file-size target for every hero image. Agree a budget for the particular page, considering its visual purpose and measured loading behaviour. Keep enough quality to show the work, product or setting clearly.
Check which version the phone downloads
A photograph that looks smaller on a phone can still be the same large file used on desktop. Ask your developer to inspect the actual image request on a fresh mobile-sized load.
For responsive images, srcset supplies alternative files and sizes describes the expected display width when width-based candidates are used. The browser can select a suitable resource using this information and the device’s display characteristics. MDN’s responsive image guide explains both resolution selection and different crops through the picture element.
These solve related design questions. A smaller-resolution version reduces unnecessary image data; a different mobile crop can keep the subject recognisable on a narrow screen.
Check both. If a landscape team photograph turns into a tiny row of faces on mobile, the composition needs attention as well as the download size. Keep the people or detail that make the picture useful within the mobile crop.
Let the browser find the main image promptly
Chrome’s current LCP request discovery guidance recommends making the image discoverable in the initial HTML, prioritising it and avoiding lazy loading for that image.
Ask your developer to check the rendered page output, including anything added by the page builder or optimisation plugin. Is the image URL available in the initial HTML? Does the main image have loading="lazy"? Would fetchpriority="high" help the browser prioritise the identified LCP image?
Keep priority changes selective. Google’s optimisation guidance warns that giving high priority to more than one or two images reduces its usefulness. Choose the image that matters for the first view.
Background photographs or images inserted by scripts may need a different approach. The responsive preload guidance, updated in July 2026, recommends avoiding unnecessary preloads when the browser can already discover the image promptly. Where a preload is justified, it must match the responsive image selection. Preloading several supported formats can cause multiple downloads.
Have the developer confirm the requests after the change. A preload should address a demonstrated delay and fetch the resource the page will use.
Keep useful lazy loading and a stable layout
Images further down the page can still benefit from lazy loading. Google’s browser-level lazy loading guide recommends it for images outside the initial viewport, while images visible at the start should load eagerly.
The same guide recommends image width and height attributes so the browser can reserve space before the file arrives. This helps prevent content jumping as images appear.
Check the page on a phone while it loads and as you scroll. Does the main photograph appear promptly? Do lower images arrive before they are needed? Does the enquiry button stay in place? Treat these as part of the acceptance check.
Investigate delays beyond the photograph
If the HTML response arrives late, ask about redirects, server work and the caching approach. If the file arrives promptly but remains invisible, investigate rendering delays.
The LCP optimisation guide identifies blocking stylesheets, scripts and long browser tasks as possible causes. It also describes content being hidden while other code runs. Ask whether an entrance animation, slider or other component is postponing the first useful view.
Choose changes that preserve the page’s purpose and customer journey. After any optimisation, check navigation, enquiry forms and booking links. For plugin changes, our guide to testing WordPress updates and planning recovery provides a practical preparation process.
Confirm the improvement and keep it
Compare before and after results for the same URLs under equivalent device, network and cache conditions. Run several comparable lab checks because individual results vary. Record the selected image file and the LCP timing, then check the page’s appearance on an actual phone.
Use a fresh load to inspect first-visit behaviour. A warm browser cache can be useful to test returning visits, but it answers a different question.
Review available field results as the following weeks accumulate. The 28-day reporting window includes earlier visits, so it cannot immediately show only the new implementation.
Give whoever publishes website content a short image checklist: retain the master, prepare suitable dimensions and formats, check desktop and mobile crops, and confirm the main image’s loading behaviour on the published page. Include this check when replacing hero photographs or changing templates.
Core Web Vitals are used by Google’s ranking systems, but Google says good scores do not guarantee top rankings. Judge this work by a clearer, faster customer experience alongside your wider content and marketing priorities.
Get a clear diagnosis before commissioning changes
A useful brief asks for the affected pages, the confirmed LCP element, the main delay, the proposed repair and comparable evidence afterwards. That makes the work reviewable and helps you avoid paying for changes that miss the bottleneck.
If your business website is slow to show its main content, talk to BuzzBoost about the pages that matter to your customers. We can discuss the next step across web design and development, with the image quality and customer journey considered together.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
