A Magento Core Web Vitals expert is a senior performance engineer specialised in tuning Adobe Commerce and Magento Open Source storefronts against Google's three field-data metrics - Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Below is what that looks like in practice, what realistic targets are on Magento 2, and what the deliverable I hand over actually contains.

What is a Magento Core Web Vitals expert?

The job title sounds vague, so I will be specific. A Magento Core Web Vitals expert does four things, in this order:

1. Measures the current state from Chrome UX Report (CrUX) field data - not Lighthouse on a dev laptop. Lighthouse is a smoke test. CrUX is what Google ranks on.
2. Attributes each metric to a concrete cause. LCP is not "slow images"; it is "the hero image waits 1,400ms because preload header is missing and CDN cache is cold". INP is not "too much JS"; it is "this jquery-ui autocomplete handler blocks the main thread for 380ms on the search input".
3. Fixes the highest-leverage cause first. Most Magento sites have three or four 80/20 fixes that move the dial; the rest are noise.
4. Verifies the fix in field data, not the dev environment. A 28-day CrUX delta is the only proof that holds up to Google.

That is the cycle. I have run it more than 40 times on Magento 2 stores between 2017 and now, on Luma, Hyvä, and PWA Studio frontends, and on stores ranging from 200 SKUs to 80,000 SKUs.

How do you measure Core Web Vitals on a real Magento store?

I measure five sources and weight them in this order - field data first, synthetic last.

What are realistic LCP, INP, and CLS targets for Magento 2?

Google publishes universal thresholds - but "realistic on Magento" is a different conversation. Here is what I aim for on a typical Magento 2.4.4 - 2.4.9 store, broken into Luma vs Hyvä.

Metric	Google "Good"	Realistic on Luma	Realistic on Hyvä
LCP (75th pctile)	< 2.5s	2.5 - 3.5s	1.4 - 2.2s
INP (75th pctile)	< 200ms	200 - 400ms	80 - 160ms
CLS (75th pctile)	< 0.1	0.05 - 0.15	0.00 - 0.05
TTFB (helper)	< 800ms	500ms - 1.5s	200 - 600ms

If your store is outside these bands, the path back inside them is usually three or four well-chosen fixes, not a rewrite. For deeper reading, see the LCP / INP / CLS recipe and the related TTFB optimization case study where I documented a real fix from 1.8s to 180ms.

What is the Core Web Vitals audit deliverable?

The flagship engagement is a $499 (~20h @ $25/hr) fixed-fee Core Web Vitals audit. You get a 20-page PDF, a 1-hour walkthrough call, and a follow-up action list. The PDF is structured around your actual top URLs.

The audit covers, per URL group:

• Field-data baseline (CrUX 28-day at 75th percentile) for LCP, INP, CLS, FCP, TTFB.
• Synthetic baseline (Lighthouse mobile, throttled) for the same metrics with attribution waterfall.
• LCP element identified with screenshot and DOM path.
• Top three INP-causing scripts with execution trace and main-thread block duration.
• CLS shifts ranked by impact, each with its DOM target and shift score.
• A prioritized fix list - fix, estimated impact, estimated hours, suggested sprint.

After the audit, you decide what to do next. Most clients book a $2,499 sprint to ship the top fixes; some hand the report to their in-house team and run it themselves. Either is fine - the audit is the deliverable, not a sales pitch.

If you want the broader performance picture beyond Core Web Vitals (caching, indexers, queue throughput, admin response time), look at my Magento performance optimization service.

Which Magento extensions hurt Core Web Vitals the most?

After 40+ Magento performance engagements, the same modules show up in the "INP and CLS killer" column over and over again. I will not name vendors here - most have a Hyvä-compatible rewrite or a configurable "lite" mode now - but the categories are consistent.

• Layered-navigation extensions that fire AJAX on every filter click without server-side rendering. INP spike on every interaction.
• Live-search / autocomplete modules that bundle their own jQuery UI, Lodash, and Select2. 200KB+ of JS for one input.
• Mega-menu extensions that ship 30 - 60KB of CSS and JS into the critical path, blocking LCP.
• Personalization / GDPR consent modules that inject DOM late, causing CLS spikes above the fold.
• Marketing tag managers that load before consent, before hyva-checkout, and before the LCP element.
• Page-builder content sliders that auto-rotate every 3 seconds and trip the "animation-driven LCP" rule.

The audit lists the offenders specific to your store, ranked by their CWV cost. The recipe to replace them is in the published case study above.

Hyvä vs Luma - what changes when you migrate, and what does not?

Migrating from Luma to Hyvä is the single largest CWV move available to a Magento merchant - but it is not magic. It fixes some metrics by an order of magnitude and leaves others exactly where they were. Here is the honest split.

Metric	What changes	What does not
LCP	Image preload and font preload are first-class in Hyvä's app/design/frontend/Hyva/default. Typical 40 - 60% LCP improvement.	Hosting, CDN, and image storage are unchanged. A slow origin is still a slow origin.
INP	The biggest win. Knockout.js + RequireJS are gone. Alpine.js is ~10KB. Typical INP improvement is 3 - 5x.	Third-party scripts (tag managers, chat widgets) are still under your control - Hyvä cannot remove them for you.
CLS	Tailwind utility classes make explicit width/height reservations the default. Major reduction in unbounded shifts.	Image dimensions in CMS content still need to be authored correctly.
TTFB	No change. TTFB is a backend metric - Hyvä is purely frontend.	Magento full-page cache, Varnish, and OPcache config still drive TTFB.

If your CWV problem is INP, migrate to Hyvä. If it is TTFB, fix the backend first. The audit makes this decision concrete with your actual numbers. For the full migration playbook see the Luma to Hyvä migration playbook.

Frequently asked questions

Do I need to be on Hyvä to hire you for Core Web Vitals work?

No. About half my CWV engagements are on Luma stores that are not migrating any time soon. Hyvä helps, but it is not a prerequisite.

How long until I see field-data improvement?

CrUX is a 28-day rolling window, so the full delta shows up at the 28-day mark after the fix ships. Search Console's CWV report lags by another ~7 days.

Can you guarantee a Lighthouse score above 90?

No, and you should be wary of anyone who does. Lighthouse is a synthetic test on a fixed device profile. I guarantee field-data improvement against your CrUX baseline, which is what Google ranks on.

What is INP, and why does it matter now?

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. It measures the 75th-percentile latency of user interactions across the whole session - not just the first one. Magento's Knockout.js and UI Component layer is notoriously bad at INP, which is why Hyvä's Alpine-based stack helps.

Do you work on Adobe Commerce Cloud as well?

Yes. The CWV optimizations are the same; the deploy pipeline is different. I have shipped fixes through Magento Cloud's magento-cloud CLI and Fastly VCL on multiple engagements.

Can you fix Core Web Vitals on a store I built myself?

Yes. Most of my CWV work is on stores I did not build. I read your code, your composer.lock, and your CrUX data and tell you what to fix.

How does this differ from your general Magento performance service?

The Core Web Vitals audit is laser-focused on LCP, INP, CLS - the three metrics Google ranks on. The general performance service covers caching, indexing, queue throughput, admin response time, and other non-CWV concerns. They overlap but are not the same product.

What tools do you use?

web.dev's web-vitals.js, Chrome DevTools Performance panel, PageSpeed Insights API, CrUX API, Search Console CWV report, Lighthouse CI, WebPageTest, and a handful of Panth_* internal tools I have built for Magento-specific attribution.