A Lighthouse report tells you two things at once, and most Magento teams read the wrong one. The score is a lab estimate; the audits below it are a to-do list. On a Hyva storefront the score is usually high, so the real work is knowing which failing audits touch pages that make money.
That distinction matters more on Hyva than on a legacy Luma theme. Luma stores fail almost everything, so any fix helps. Hyva ships with the render pipeline already cleaned up: no RequireJS, no Knockout, no jQuery, inline Alpine.js instead of a heavy bundle. A well built Hyva store often scores 90 or above in the lab on a simple page, which means the remaining red audits are specific and worth targeting rather than a wall of generic warnings. This guide is how we read those reports at Bemeir when a client asks why a fast theme still has failing checks.
The score and the audits are not the same thing
The number at the top of a Lighthouse performance report is a weighted average of five lab metrics. In Lighthouse 10 and later the weights are Total Blocking Time at 30 percent, Largest Contentful Paint at 25 percent, Cumulative Layout Shift at 25 percent, First Contentful Paint at 10 percent, and Speed Index at 10 percent, per Google’s Lighthouse scoring documentation. The color bands are fixed: 0 to 49 is red, 50 to 89 is orange, and 90 to 100 is green.
Total Blocking Time carries the most weight, and it is the lab proxy for interactivity. This is where Hyva earns its reputation, because the whole point of replacing Knockout and RequireJS with Alpine.js is less JavaScript on the main thread. A Hyva store that scores below 90 usually has something specific fighting that advantage: a tag manager loading a dozen scripts, a chat widget, or a personalization tool that injects work after the page paints.
The audits below the score are the actionable part. Lighthouse groups them into failed audits, passed audits, and diagnostics. The failed audits at the top are ranked by estimated savings, but that ranking is a lab estimate on the single URL you tested, not a measure of business impact. A 300 millisecond saving on a blog post matters far less than a 100 millisecond saving on your product page, and Lighthouse cannot tell the difference. You have to.
Lab data versus field data: read the field first
The single most common mistake is treating the lab score as the truth. Lighthouse runs on simulated hardware, historically a mid-range mobile profile on a throttled connection. Your customers use a spread of real devices and networks. Only field data, collected from real Chrome users, affects Google rankings.
The three Core Web Vitals are the field metrics that count, measured at the 75th percentile of real page loads across a 28 day window:
| Metric | What it measures | Good threshold | Lab proxy in Lighthouse |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less | LCP (25 percent weight) |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less | Total Blocking Time (30 percent weight) |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | CLS (25 percent weight) |
INP became a stable Core Web Vital in 2024, replacing First Input Delay, and it is the metric where a busy Hyva page can still disappoint even with a high lab score, because real taps on a real phone expose Alpine components that do too much work on click. That is why a store can post a lab score of 40 and still pass Core Web Vitals in the field, or the reverse. Neither situation is a success or a failure on its own. When lab and field disagree, the field number is the one your rankings and your revenue follow. For a fuller treatment of that gap during a theme change, see our guide to measuring a Hyva migration with lab and field data.
The audits that actually move conversion on Hyva
Because Hyva has already solved the baseline, the failing audits that remain tend to cluster in four areas. These are the ones we chase first.
Largest Contentful Paint element and discovery
On a product or category page the LCP element is almost always the hero or the main product image. Two audits matter here: whether the browser discovers that image early, and whether the image itself is heavy. A Hyva store that lazy loads its LCP image, or hides it behind a slider that boots up in JavaScript, delays the paint no matter how light the theme is. The fix is boring and effective: mark the main image with fetchpriority="high", do not lazy load anything above the fold, and preload the hero. Our playbook for reducing LCP on a Hyva storefront walks through the exact template changes.
Total Blocking Time from third parties
This is the audit that most often drags a Hyva score down, and it is rarely the theme’s fault. Tag managers, analytics, A/B testing tools, chat, and marketing pixels all execute JavaScript on the main thread. Lighthouse surfaces this as high Total Blocking Time and in the third-party summary diagnostic. The number to watch is main thread time attributed to scripts you did not write. A single tag container can add hundreds of milliseconds. Auditing and deferring these is usually the highest impact work on an otherwise healthy store, which is why we wrote a dedicated guide to third-party script bloat on a Hyva storefront.
Cumulative Layout Shift on real content
Hyva’s layout is stable by default, but CLS creeps back in through the things merchants add: banners without reserved height, web fonts that swap and reflow text, cookie consent bars, and dynamically injected promotions. On checkout this is not a cosmetic problem. A shift under a finger causes a misclick, and a misclick during payment causes an abandoned order. The fixes are dimension attributes on images, font-display handling, and reserving space for anything injected after load. Our notes on the common CLS layout-shift killers on Hyva list the usual culprits.
Interaction to Next Paint on add to cart
INP is the field metric, and Total Blocking Time is its lab shadow. On Hyva the offenders are Alpine components that run expensive logic on a click: rebuilding a cart section, recalculating totals, or triggering a large re-render. The add to cart button is the interaction that matters most commercially, so it is the one to profile. Keeping handlers small and deferring non-urgent work is the pattern; our guide to reducing Magento INP with Alpine patterns covers the specifics.
The audits you can usually ignore
Not every red or orange audit deserves a ticket. On a Hyva store the following are frequently noise:
- Reduce unused JavaScript flagged against Tailwind or a vendor library that is already purged and cached. Lighthouse cannot always see that the bytes are gzipped and served once.
- Serve static assets with an efficient cache policy pointing at third-party domains you do not control, such as a payment provider or a font host.
- Avoid enormous network payloads on a heavily merchandised homepage, where the payload is a business decision about how many products to show, not a bug.
- Reduce the impact of third-party code when the third party is a required payment or fraud tool. You cannot remove it, so the action is to load it well, not to fail the audit forever.
The test for whether an audit matters is simple. Does it touch a Core Web Vital in the field, on a page that converts? If not, log it and move on.
The 2025 insight audits change the report you are reading
Google has restructured Lighthouse, and if you have run a report recently the layout looks different. Through 2025 the classic opportunity and diagnostic audits were replaced by consolidated “insight” audits, the same insights that already existed in Chrome DevTools. Per Chrome’s announcement of the move to insight audits, the timeline ran from Lighthouse 12.6 introducing insights as an option, to 12.7 switching them on by default in mid 2025, to Lighthouse 13 removing the old audit data in October 2025.
The practical effect is that several audits you may have bookmarked are now merged:
| New insight audit | Old audits it replaces |
|---|---|
lcp-phases-insight and lcp-discovery-insight |
Largest Contentful Paint element, preload LCP image |
image-delivery-insight |
Modern image formats, efficiently encode images, responsive images, offscreen images |
cls-culprits-insight |
Layout shift elements, non-composited animations, unsized images |
interaction-to-next-paint-insight |
Work during interaction, minimize main thread work for INP |
render-blocking-insight |
Eliminate render-blocking resources |
third-parties-insight |
Reduce the impact of third-party code |
Six audits were removed entirely as no longer useful, including first-meaningful-paint, offscreen-images as a standalone check, and third-party-facades. The reading strategy does not change: the insights still map to LCP, INP, and CLS, and you still prioritize the ones that touch converting pages. But the names are new, so an internal runbook written before mid 2025 needs updating.
A repeatable reading order
When we open a Lighthouse report on a client’s Hyva store, we read it in this order, and you can too:
- Ignore the score for a moment. Note the color, then look past it.
- Check field data first. Open the Core Web Vitals assessment. If the field passes on your key templates, the lab is a debugging tool, not an emergency.
- Identify the page type. A product page, a category page, and a CMS page have different jobs. Test the templates that carry revenue.
- Find the LCP element in the LCP insight. Confirm it is discovered early and served at the right size.
- Read the third-party summary. Attribute main thread time. This is usually the biggest lever on Hyva.
- Scan CLS culprits on checkout and product pages specifically.
- Profile one real interaction, normally add to cart, for INP.
- Triage the rest. Anything not touching a field metric on a converting page goes to the backlog.
This order works because it puts the business context, which the tool lacks, back into a report that ranks everything by lab savings alone.
Where the platform fits
A high Lighthouse score is a means, not the goal. The goal is a store that loads fast for real customers on the pages that sell, and that is a function of the theme, the hosting, the extensions, and the integrations together. Hyva gives you a clean starting point, which is why it is the frontend we build on for Hyva development projects, on top of full Magento and Adobe Commerce development. The same audit categories apply if you run Shopify, Shopware, or BigCommerce; the difference is how much control you have over the render path and the third-party layer.
Much of the third-party weight in a Lighthouse report comes from tools chosen for good reasons: payments, personalization, analytics, and fraud. Loading them well without losing their value is an integration problem, and it is why our technology partner ecosystem exists. If you want to know who does this work, about Bemeir covers our background as the first US-based Hyva Gold Partner.
Frequently asked questions
Why does my Hyva store score lower than the demo I saw?
Hyva demos are clean pages with no tag managers, no chat, no A/B testing, and few third-party scripts. Your production store has all of those, and they run JavaScript on the main thread. The theme is the same; the difference is everything you added on top. Audit the third-party layer before you question the theme.
Is a Lighthouse score of 100 worth chasing?
No. Google itself notes that a perfect 100 is extremely challenging and unnecessary. A field-passing store in the 90s is a better use of budget than the last few lab points, which often require trade-offs that hurt merchandising or conversion. Optimize for the field, not the lab number.
Lab and field disagree on my store. Which do I trust?
Trust the field. Lab data is a controlled estimate on one device profile; field data is real customers at the 75th percentile and is what Google uses for rankings. Use the lab report to find and fix the cause, then confirm the fix in field data over the following weeks.
Do the 2025 insight audits mean my old fixes are wrong?
No. The underlying work is the same. Google merged and renamed audits into insights but did not change what makes a page fast. If your LCP image is preloaded and your third parties are deferred, those fixes still count; you will just find them under new insight names.
How much does page speed really affect ecommerce revenue?
Deloitte’s Milliseconds Make Millions study reported that a 0.1 second improvement in mobile site speed increased retail conversion rates by 8.4 percent. The exact figure varies by store, but the direction is consistent across studies: faster converting pages sell more, which is why LCP and INP on product and checkout pages are the audits to prioritize.
