A faster hero starts with the image the visitor actually sees

A landing page can feel slow even when its layout is simple. The first large image may be a multi-megabyte export, a background discovered late through CSS, or a carousel slide the visitor never requested. The result is a blank or incomplete first screen while the browser does extra work. Before changing the whole design, I look at what the first visitor actually has to download.

Find the element that is late

Open the page on a phone-sized viewport and reload it with the browser's network panel visible. Watch the first screen as it renders. Then run Lighthouse and note its Largest Contentful Paint, or LCP, element. LCP records when the largest visible image or text block finishes rendering; it is a useful starting signal, not a complete measure of whether the page communicates well. Lighthouse's lab result can vary, so I also inspect the actual element and request waterfall before deciding on a fix.

If the LCP element is the hero image, check its delivered dimensions, format, size, and when its request starts. A 3000-pixel image delivered to a 375-pixel viewport is an obvious place to investigate. A small file can still appear late if the browser discovers it only after loading styles or scripts. If the LCP element is text, an image compression task will not solve the measured delay; font loading, server response, or blocking resources may matter more.

Fix the asset, not the score alone

Export an image for the size at which it is actually displayed and provide responsive variants when the design spans phone and desktop widths. Choose a format that suits the asset and verify the result visually. A photograph and a crisp logo have different needs. Keep the subject and text legible after compression; an ugly first impression is not a useful performance win.

For a hero image that is needed immediately, make sure the browser can discover it early. The web.dev LCP guidance explains why delaying the request delays the moment the visitor sees it. Conversely, media far below the first screen is a better candidate for lazy loading than the primary hero. I avoid applying one loading attribute to every image without checking its position and role.

Often the cheapest improvement is editorial. A page may show a huge decorative scene where a clear headline, short proof point, and visible action would do more useful work. Removing that asset can simplify the page and reduce transfer at the same time. But I would test that decision with the product team: some images explain the offering, and removing them could make the message harder to understand.

Check the whole first screen again

After changing the image or loading order, repeat the same viewport and network conditions. Compare the LCP element and timing, look for layout movement, and check whether the call to action is visible and usable. A smaller image can still create a bad experience if its dimensions were not reserved and the button jumps as it loads. The improvement should be apparent in the rendered page, not only in one green score.

Record the before and after evidence: URL, viewport, date, screenshots, and the specific changed asset. If the page is live, field data will eventually tell a fuller story than one local Lighthouse run. Until then, describe the measured lab improvement accurately and avoid promising a conversion lift.

My rule for a landing-page audit is simple: identify the slow visible element, explain its cause, make the smallest sensible change, then test the first screen again. That keeps the work tied to the visitor's experience instead of turning performance into an abstract number.