Written by Nemanja Falb — founder and developer of TinySharp, working on WordPress image optimization, browser-based image workflows and practical website performance tooling.
Landing pages often fail image performance in a predictable way: the visual design is treated as one export task. A 2400-pixel hero, six browser screenshots, a logo strip, testimonial portraits and an Open Graph image are all dropped into the page with the same workflow.
Those assets do not have the same job. The hero may determine Largest Contentful Paint. A screenshot may contain tiny interface text. A logo can often be vector. A social preview image may never need to download during a normal page view.
The right optimization strategy is therefore placement-specific, not format-specific.
Start with the asset that controls the first impression
On a visual landing page, the hero image is often one of the largest above-the-fold elements. If it becomes the LCP element, its loading path matters more than saving another 8 KB from a footer icon.
Check four things first:
- Is the hero discoverable directly from the initial HTML?
- Is it accidentally lazy-loaded?
- Is the browser downloading a file much wider than the rendered layout needs?
- Is the critical hero competing with multiple other high-priority images?
The official web.dev LCP guidance emphasizes resource discovery and loading priority. The practical takeaway is simple: make the important above-the-fold image easy to find and avoid treating every image as equally urgent.
Use an image element when the hero is meaningful content
CSS background images are useful for decorative visuals, but they can complicate responsive behavior, accessibility and resource discovery when the image is actually core page content.
If the hero visually explains the product, demonstrates the interface or communicates an essential message, an HTML <img> or <picture> element often gives you better control over:
- responsive sources;
- intrinsic dimensions;
- alt text when the image needs a text alternative;
- loading priority;
- format fallbacks and art direction.
Decorative textures and background flourishes can remain CSS backgrounds. The distinction should follow meaning, not convenience.
Mobile hero images often need art direction, not only resizing
A desktop hero can be 16:9 with a person, product or interface positioned on the right side because the headline sits on the left. Shrinking the same image to a narrow mobile viewport may crop out the subject or force the browser to download unnecessary pixels.
That is where art direction helps. Use a mobile-specific crop when composition changes materially. The goal is not to create a different marketing concept; it is to preserve the same message in a different aspect ratio.
A practical test:
- Does the subject remain visible at 360–430 CSS pixels?
- Does important text inside the image remain readable?
- Is the mobile file actually smaller, or did you only crop it with CSS?
- Does the browser select the intended mobile candidate?
Reserve the hero’s space before it loads
Landing pages often combine large media with animated copy, sticky headers and conversion buttons. If the browser does not know the hero’s aspect ratio, the page can shift as the image arrives.
Provide intrinsic width and height attributes or reserve the same space with CSS. Google’s CLS guidance explicitly recommends reserving image dimensions.
Do not use the hero’s optimization settings for screenshots
Product screenshots contain high-contrast edges, small labels and interface text. A quality setting that looks fine on a photograph can make a screenshot look soft.
For screenshots:
- crop away empty browser chrome when it adds no value;
- resize to the largest real display size before compression;
- inspect small text at 100% zoom;
- compare PNG, WebP and other suitable outputs rather than assuming one format always wins;
- avoid uploading a 4K screenshot into a 720-pixel content column.
When a screenshot is used inside a device mockup, remember that the mockup itself may add large transparent areas. Optimize the composed asset, not only the screenshot placed inside it.
Logo strips should not become a hidden performance tax
“Trusted by” sections are visually simple but can contain ten or more separate requests. A few rules keep them lightweight:
- prefer SVG for genuine vector logos when allowed by your publishing stack;
- do not upload enormous raster logos and shrink them with CSS;
- normalize display height so one logo does not force oversized exports for all others;
- avoid loading multiple color variants when only one is visible;
- reserve dimensions to prevent the strip from shifting.
Testimonial images need consistency more than resolution
Small testimonial portraits rarely need large source dimensions. What matters is a consistent crop, sharp face detail and stable layout.
A common mistake is to use the original uploaded profile photo, sometimes several megabytes, inside a 64-pixel circular avatar. Resize the delivery asset close to the real need and let high-density displays use an appropriate higher-resolution candidate rather than the untouched original.
Social preview images are a separate publishing asset
An Open Graph or social sharing image has a different job from an on-page hero. It may use embedded text, a different crop and a platform-friendly aspect ratio.
Do not force the browser to download the social preview image on every page view simply because it exists in page metadata. The page can reference it for sharing without rendering it in the visible layout.
Google’s March 2026 documentation update clarified that image metadata such as schema.org image markup and og:image can help indicate preferred image candidates in Search and Discover contexts. That makes it even more important that preview images are intentional, crawlable and relevant—not random leftovers from the design process.
Use a landing-page asset budget
There is no universal byte limit that fits every campaign, but a budget forces prioritization. Instead of asking “Is 300 KB okay?”, ask “What does this file contribute to the total initial experience?”
| Asset | Loading approach | Optimization focus |
|---|---|---|
| Primary hero / LCP image | Early and discoverable | Correct dimensions, responsive source, strong quality |
| Below-fold screenshots | Lazy-load | Readable UI text, right dimensions |
| Logo strip | Normal or deferred by position | Vector/raster discipline, small files |
| Testimonial avatars | Usually below fold | Small consistent crops |
| Social preview | Metadata only unless visibly used | Share quality and correct crop |
Verify the page after optimization
Optimization is not complete when the converter finishes. Check the live page:
- Reload with the Network panel open.
- Confirm which image became LCP in performance tooling.
- Check the exact file selected on mobile and desktop.
- Confirm the hero is not lazy-loaded.
- Verify below-fold images are not all requested immediately.
- Check layout shifts around media sections.
- Compare visual quality at real display sizes.
If you only inspect the Media Library or build folder, you can miss CDN rewrites, old cached HTML, incorrect srcset choices or a background image still pointing to the original file.
For a deeper frontend check, see How to Audit Page Images With a Chrome Extension. For WordPress sites, read Why WordPress Image Optimizers Need Frontend WebP Delivery.
Frequently asked questions
Should I lazy-load a landing page hero image?
Not when it is the primary above-the-fold image and likely to be the LCP element. Lazy-loading is useful for offscreen media, but it can delay a critical hero.
Is WebP always the best format for a landing page hero?
No. WebP is a strong modern option, but the correct result depends on the source content, visual quality, dimensions and delivery stack. Compare the actual outputs.
Should mobile use the same hero image as desktop?
Sometimes. When the desktop composition crops poorly on mobile, a separate mobile crop can preserve the subject and reduce unnecessary pixels.
Do social sharing images affect page load speed?
They should not need to be part of the visible page download unless the same file is also rendered on the page. Referencing an image in metadata is different from displaying it in the layout.
How do I know whether a screenshot is over-compressed?
Inspect the smallest text, thin borders and high-contrast UI edges at the real display size. Those areas reveal compression damage before large flat regions do.
Continue the workflow
Optimize campaign assets with the TinySharp Image Compressor, process repeated exports with the Bulk Image Converter, and verify the final page with the TinySharp Chrome Extension.
