Your portfolio probably mixes responsive sites, hybrid apps with WebViews, and native iOS or Android products. Sponsors ask for "mobile vitals" in one breath. The metrics behind that phrase depend on where the user actually loads content.
Google's Core Web Vitals apply to pages in Chrome. Native apps use different instrumentation, different release cycles, and different failure modes. Embrace and SpeedCurve are now promoting Core Mobile Vitals as a user-focused framework for native experiences.
Web performance teams need a clear split: what is settled on mobile web, what is still forming for native apps, and what you can monitor this quarter without inventing thresholds that do not exist yet.
What are Core Mobile Vitals?
Core Mobile Vitals (CMV) is an initiative led by Tammy Everts (SpeedCurve) and Embrace. The goal is a shared vocabulary for mobile app experience quality, similar to what Core Web Vitals did for the web.
Embrace describes CMV as user-focused and tied to business outcomes, not developer-only timings. The framework is still taking shape. Embrace publishes posts on Core Mobile Vitals and why mobile deserves an equivalent to CWV. There is no Google-style public threshold table for CMV yet.
That matters for planning. You cannot copy LCP or INP pass bands into a native app RFP and call it done. CMV starts with experience pillars and goals. Metrics follow as the community agrees on definitions and field collection.
Web teams should follow the conversation, especially when clients ship both a marketing site and a store app. CMV is not a replacement for CrUX on URLs.
Do not confuse CMV with mobile Core Web Vitals. Mobile CWV means LCP, INP, and CLS on phone form factors in Chrome: field data from CrUX, lab data from Lighthouse mobile emulation. Same three metrics, different device profile.
This post uses "Core Mobile Vitals" for the native-app framework and "mobile CWV" for vitals on mobile web unless the context is obvious.
Why Core Web Vitals gave web teams a shared language
Before CWV consolidated around LCP, INP, and CLS, performance meetings drifted. One week it was Time to Interactive. The next it was Speed Index, custom RUM percentiles, or whichever Lighthouse score someone ran that morning. Sponsors could not compare templates. Agencies could not write one monitoring clause.
CWV fixed the vocabulary problem for public web content:
- Three field metrics at the 75th percentile, reported in CrUX and Search Console.
- Lab companions in Lighthouse for debugging, not for ranking pass/fail on their own.
- A clear split between SEO page experience (field vitals) and engineering diagnostics (lab output).
That shared language is why mobile vs desktop CWV monitoring is a portfolio question, not a philosophical one. You still monitor LCP, INP, and CLS. You run paired mobile and desktop strategies because the numbers diverge.
Our LCP, INP, and CLS guide stays the technical anchor for fixes once monitoring shows a regression.
Native mobile never inherited that consolidation. App teams still juggle cold start, frame drops, ANRs, crash-free sessions, and screen-level traces from their APM or RUM vendor. Product and engineering can agree that "the checkout screen feels slow" without agreeing on which metric proved it.
CMV is an attempt to standardise that vocabulary for apps, not for websites.
Why native mobile apps still lack an equivalent framework
Several structural differences slow a single "mobile vitals" standard for native apps.
Platforms and runtimes differ
iOS and Android expose different lifecycle hooks, threading models, and GPU behaviour. A metric that is straightforward on UIKit may need a different definition on Jetpack Compose. Web CWV benefits from one rendering pipeline in Chrome. Native apps do not.
Session shape differs
Users background apps, resume mid-flow, and move through stacks of screens rather than linear page loads. Screen Load in CMV language maps to view-controller timing, not to a single HTML document. Responsiveness includes gestures, animations, and offline queues that INP on a URL never sees.
Distribution and measurement differ
CrUX samples real Chrome users at scale. Native RUM depends on SDK instrumentation, sampling rates, and privacy rules in each store ecosystem. You can standardise definitions. You cannot assume a free public dataset like CrUX for every app's screens.
Ownership differs on mixed portfolios
Agencies often own the WordPress or headless storefront but only advise on the companion app. Web retainers cite Search Console. App work sits with mobile engineering and a different vendor contract. Without a shared framework, quarterly reviews compare incomparable charts.
CMV does not remove those splits. It gives native teams a shared target for measurement conversations. Web teams still need an explicit lane for mobile web.
Embrace's four experience pillars for native apps
Embrace groups early CMV thinking around four experience pillars. Treat these as goals, not final published metrics with universal thresholds. Embrace and partners are still defining how each pillar maps to field measurements across iOS and Android.
Screen Load
How quickly a user sees meaningful content after navigating to a screen: view loading, first render, and time until the screen is usable. Native SDKs can instrument UIViewController lifecycle stages (for example viewDidLoad through viewDidAppear) and correlate slow screens with abandonment.
This is the app analogue to caring about LCP on web. It is screen-scoped, not URL-scoped.
Smoothness
Frame pacing and jank: scrolls, transitions, and animations that drop frames or hitch. Web CLS captures layout shift. Native smoothness is closer to GPU and main-thread frame budgets during motion. Teams already using mobile RUM often have jank or slow-frame reports under different names.
Responsiveness
Tap-to-feedback latency across the session, not only the first interaction. It parallels INP in intent (did the app feel slow after I touched it?) but must cover native controls, gestures, and offline retries. Hybrid apps may need both INP on WebView URLs and native responsiveness on shell screens.
Stability
Crashes, hangs, and broken flows that end the session or block completion. Web CLS and vitals do not replace crash-free rate or ANR counts. Sponsors still ask for stability even when LCP is green.
In our experience, the useful takeaway for web-led teams is directional. When a client cites CMV in a workshop, ask which pillar they mean and whether the pain is on a native screen, a WebView, or the mobile browser site. Do not invent CMV "good" bands in contracts until Embrace and the community publish them.
Core Web Vitals on mobile web: what to monitor today
For responsive sites and mobile-browser traffic, mobile CWV is the settled standard. Monitor LCP, INP, and CLS on a mobile strategy alongside desktop on priority URLs.
Use field data when CrUX has volume. Use scheduled lab runs when a URL is new, low-traffic, or you need week-to-week comparability.
Practical checks we see in agency portfolios:
- Home, category, and article templates on mobile and desktop with the same cadence.
- Checkout or logged-in flows where INP on phones often fails first.
- Third-party and tag weight that hurts mobile LCP before desktop moves (supporting lab metrics like FCP and TBT often shift on mobile first).
- CMS-driven properties where plugins defer assets differently per breakpoint; WordPress performance monitoring is a common example.
PageSpeed Insights and CrUX both expose mobile form factor data where Google publishes it. Your monitoring tool should store strategy per URL (mobile vs desktop), apply budgets per strategy, and alert when either side regresses.
Many "core mobile vitals" searches actually mean mobile web. That is the operational baseline above.
How web performance teams should combine web monitoring and native RUM
Think in three layers rather than one blended score:
| Layer | What the user opens | What to use today |
|---|---|---|
| Mobile web | Chrome (or in-app browser) on a URL | CWV field + lab on mobile strategy; CrUX in PSI |
| Hybrid WebView | App shell loads your URL | Mobile CWV on the URL plus native traces for shell navigation |
| Native screens | Swift/Kotlin UI | Vendor RUM/APM (Embrace, etc.); watch CMV pillar definitions as they mature |
Apogee Watcher fits the web and mobile-web layer: scheduled PageSpeed tests, LCP/INP/CLS and optional FCP/TBT budgets, multi-tenant sites and pages, portfolio alerts, and CrUX in test results where available.
We do not ship a native app SDK or CMV dashboards in-product. Layer Watcher beside native observability. Do not replace an app RUM stack because a web monitor covers marketing URLs.
For mixed retainers, split the report. Show mobile CWV trends for public URLs and native pillar notes from the app team's vendor. Call out when a WebView URL fails mobile INP while the native shell scores well on Screen Load. Clients trust that honesty more than a single blended "mobile score."
What agencies should document in retainers
Until CMV thresholds exist, write contracts in plain terms:
- Mobile web: field LCP, INP, and CLS at agreed percentiles on a mobile test strategy; reference Search Console where SEO is in scope.
- Native app: reference the client's chosen RUM vendor and CMV pillar goals when the mobile team adopts them; avoid copying CWV numbers into app SLAs.
- Hybrid: list which URLs are monitored as web properties and which screens stay with the app team.
Revisit the doc when Embrace publishes firmer CMV metric definitions. Link internally to your Core Web Vitals monitoring checklist and onboarding guides so delivery teams configure both strategies on day one.
FAQ
Are Core Mobile Vitals the same as Core Web Vitals on phones?
No. Mobile Core Web Vitals are still LCP, INP, and CLS, measured on mobile form factors in Chrome. Core Mobile Vitals is a separate, emerging framework for native app experiences from Embrace and SpeedCurve. Hybrid products may need both.
Does Google rank native apps on Core Mobile Vitals?
No. CMV is not a Google Search ranking programme. Google's page experience signals apply to web content in Search. Native app discovery and store policies use different signals.
What mobile app performance metrics should we track while CMV matures?
Keep your existing native stack: cold start, screen timing, crash-free sessions, ANR rate, and key funnel completion. Map them informally to Screen Load, Smoothness, Responsiveness, and Stability when talking to sponsors. Do not rename vendor metrics to CMV in contracts until definitions stabilise.
Should we monitor mobile and desktop Core Web Vitals separately?
Yes. Run paired strategies on priority URLs. Mobile often fails first on LCP and INP even when desktop looks healthy. See our mobile vs desktop CWV guide.
Can Apogee Watcher monitor Core Mobile Vitals in native apps?
No. Watcher monitors web and mobile-web URLs via scheduled PageSpeed tests and supports vitals plus optional FCP/TBT budgets per mobile or desktop strategy. Use native RUM for app screens; use Watcher for URL portfolios and client sites.
Where can we read more about Core Mobile Vitals?
Start with Embrace's posts on Core Mobile Vitals and their broader mobile performance guides. Pair that with our Core Web Vitals primer and supporting lab metrics guide for the web side.
Web teams already have a standard for mobile browser experience: Core Web Vitals on a mobile strategy, monitored beside desktop. Core Mobile Vitals is the parallel conversation for native apps, organised around Screen Load, Smoothness, Responsiveness, and Stability until shared metrics and thresholds catch up.
Monitor what is defined today. Layer tools instead of forcing one score across web and app.
Start a free Apogee Watcher account to schedule mobile and desktop PageSpeed tests with vitals budgets across client URLs, or run a free domain check on a mobile strategy that regressed after the last release.
Top comments (0)