Largest Contentful Paint is the Core Web Vital that most directly correlates with conversion on commerce sites, and it is also the one Hyvä is supposed to be naturally good at. When a Hyvä-themed Adobe Commerce store is still posting LCP in the 2.5-4.0 second range, the problem is almost never the theme; it is one of three categories of issue that practitioners learn to look for in a specific order. Fixing them is mechanical work once you know where the time is going.
The pattern below is what Bemeir’s Hyvä performance team consistently uses to move mid-market Adobe Commerce stores from 3.5s LCP into the 1.4-1.8s range. None of it is novel; what is missing on most stores is the discipline to apply the patterns in the right order.
Step 1: Find where the LCP time is going
Before touching any code, capture an honest breakdown of where the LCP time is actually being spent. The three sources, from server to screen:
Time to First Byte (TTFB). From the user’s request to the first byte of HTML arriving. Server work: PHP execution, database queries, full page cache hit or miss, Varnish behavior.
HTML parse and resource discovery. From the first byte arriving to the LCP candidate resource being discovered by the browser. Render-blocking resources in the head, late-discovered images, JavaScript that delays parsing.
Resource fetch and render. From the LCP candidate being discovered to it actually painting. Image transfer time, font blocking, render path.
The Chrome User Experience Report gives you real-user data on this. Lighthouse gives you a synthetic breakdown. WebPageTest’s “filmstrip” view shows you exactly when each stage happens. Run all three, compare, and you will have a clear picture of where the time is going.
Step 2: TTFB optimizations (server side)
If TTFB is above 600ms, server-side work is your biggest opportunity. The patterns that actually move the number on Adobe Commerce + Hyvä:
Verify full page cache (FPC) is actually serving. The single most common cause of bad TTFB on Magento is FPC misses on pages that should be cached. Check the X-Magento-Cache-Debug header on category and product pages; it should read HIT. If it reads MISS consistently, something in your custom code is invalidating the cache. Common culprits: customer-segment-driven content blocks, A/B test code injected in the layout, custom block types that do not declare their cache tags.
Verify Varnish (or the CDN equivalent) is in front of FPC. Magento’s built-in FPC is fine but Varnish in front is faster and offloads PHP entirely. Confirm the X-Varnish header is present on cacheable responses.
Database query review on category pages. Hyvä reduces client-side complexity but does not change the server-side query profile. A category page with 60+ products that runs slow on TTFB is usually a database problem: missing indexes, EAV table joins with the wrong query plan, custom attributes pulling more data than needed. The Adobe Commerce performance toolkit ships database tuning guidance that is worth re-reading.
PHP-OPcache and Realpath cache. Both should be configured for production loads. The defaults are conservative; the recommended Adobe Commerce values are public.
Image generation pipeline. Magento’s default image resize is slow and not cached aggressively enough. Either move to an image CDN like Cloudflare or Fastly or to an Adobe Commerce extension that handles WebP/AVIF generation and CDN-fronted delivery. Inline image generation in PHP on cache miss will demolish TTFB.
Step 3: HTML parse and resource discovery
After TTFB is under 400ms, the next opportunity is making sure the browser can discover and fetch the LCP resource as early as possible.
Preload the LCP image. On product detail pages, the hero image is the LCP candidate. Adding a `<link rel=”preload” as=”image” href=”…”>` in the head section, with the correct srcset for the device, lets the browser start fetching it during HTML parsing instead of after parsing the body. On Hyvä product pages this single change often moves LCP by 300-500ms.
Eliminate render-blocking resources in the head. Every CSS file the browser parses before rendering delays LCP. Hyvä ships compiled, minimal CSS by default; the place this regresses is when third-party tags inject their own stylesheets. Klaviyo, OneTrust, Trustpilot, and live chat widgets are common offenders. Move them to async loading and verify nothing in the head is unnecessarily render-blocking.
Font loading strategy. Web fonts cause two LCP failure modes: blocking text rendering and triggering layout shifts. The right pattern for Hyvä is `font-display: swap` on every web font, with system fonts as the fallback stack matched to similar metrics. This lets the page render with system fonts and swap to web fonts when they arrive, avoiding both blocking and major reflow.
Reduce critical request chain depth. If your LCP image is being loaded by JavaScript that runs after a font that loads after a stylesheet that loads after the HTML, you have a 4-link chain. Every additional link adds latency. The goal is for the LCP image request to be in the first wave of requests the browser makes.
Step 4: Resource fetch and render
Once the LCP candidate is being discovered early and the server is responding quickly, the final category is making the resource itself as small and as fast as possible.
Modern image formats with proper srcset. AVIF first, WebP fallback, JPEG/PNG last. The image extension you ship for an Adobe Commerce store should handle the format negotiation transparently. Hyvä’s image rendering supports srcset properly; the failure mode is not configuring multiple breakpoints, so mobile users download the desktop hero image.
Right-size for the breakpoint. The single most common waste is shipping a 2400px hero image to a 375px-wide mobile viewport. Srcset and sizes should be configured so each breakpoint gets an image close to its actual rendered size.
Aggressive compression for above-the-fold images. Quality 75-80 for AVIF, 80-85 for WebP, 85 for JPEG. The visual difference is invisible to users and the byte savings are 30-50%. Below-the-fold images can compress harder.
CDN closer to the user. If you are not on a global CDN for image delivery, the bytes are traveling from your origin server to the user. Even with optimal compression, that distance is hundreds of milliseconds for users far from your hosting region.
How the patterns stack in practice
| Layer | Typical baseline LCP impact | Typical post-optimization |
|---|---|---|
| TTFB at 800ms with FPC misses | 0.8-1.0s on the LCP clock | 0.2-0.3s |
| LCP image not preloaded | +300-500ms | Eliminated with preload |
| Render-blocking 3P stylesheets | +200-400ms | Eliminated with async loading |
| Font blocking | +100-300ms | Eliminated with font-display: swap |
| Oversized images (no srcset) | +200-600ms | Eliminated with right-sized AVIF/WebP |
| No CDN or distant origin | +100-300ms | Eliminated with global CDN |
A store starting at 3.8s LCP and applying every layer above lands at 1.4-1.8s. The order matters: there is no point preloading the LCP image if the server is taking 1.2 seconds to start sending HTML.
Where to look first on your store
For most Hyvä-themed Adobe Commerce stores, the diagnostic order that finds the most gain in the least time:
- Check FPC hit rate on product and category pages. If misses are common, fix that first.
- Run WebPageTest filmstrip. If TTFB is above 600ms, focus there before touching the frontend.
- Check whether the LCP image is preloaded. If not, add the preload tag.
- Audit third-party scripts in the head. Move everything you can to async loading.
- Verify srcset is generating right-sized images for mobile.
- Confirm the image CDN is doing AVIF or WebP delivery with proper format negotiation.
This sequence consistently finds 60-70% of available LCP improvement in the first half-day of work. The remaining gains come from store-specific issues that surface once the standard patterns are in place.
What good looks like
A well-tuned Hyvä-themed Adobe Commerce store should be hitting:
- Mobile LCP at p75: under 2.0s, ideally under 1.6s
- TTFB at p75: under 400ms
- Mobile homepage and category page LCP: under 1.8s with CDN
- Mobile product detail page LCP: under 1.6s with preloaded hero image
Bemeir has gotten clients consistently into this range with the patterns above. The stores that struggle are usually the ones where one or two of the patterns are not in place, not the ones with mysterious performance problems. Performance work on Hyvä is mostly the patient application of well-understood patterns; the merchants who treat it that way get the predictable wins.
