Docs

Play Console's New Memory Core Vital: What to Track

Google Play Console now scores memory usage as a core vital — track per-screen memory before an unseen threshold breach throttles your app's visibility.

Performance

Google Play Console has added memory usage to its core vitals — the small set of technical quality metrics that can affect how an app is surfaced on the Play Store, alongside crash rate and excessive wake locks. Unlike a crash, which is loud and immediate, high memory usage is a slow, largely invisible failure mode: the app doesn’t stop working, it just runs worse on the low- and mid-tier Android devices that make up most of the global install base, until Play’s own aggregate metric flags it. Teams that have spent the last year optimising crash-free rate and startup time can find themselves with a new vital in the red without a single new bug report.

The core vital reports an aggregate across all sessions and devices, which is exactly the level at which it’s least useful for fixing anything. A memory spike on one screen, triggered by one specific user flow, can pull the whole app’s aggregate score down without Play Console telling you where to look. Without your own screen-level and flow-level memory instrumentation, “reduce memory usage” becomes a guess rather than a targeted fix, and teams end up shipping broad, low-confidence changes (image compression, cache limits) that may not even touch the screen actually causing the breach.

Data Points to Track

  • Peak and average memory usage per screen or route, not just app-wide, so a single memory-heavy screen doesn’t hide behind a healthy average everywhere else
  • Memory usage by device RAM tier, since the same screen can be comfortably within budget on a flagship device and dangerously close to the threshold on a 3GB-RAM device that represents a large share of your Play Store install base
  • Memory usage at the moment of specific actions — opening a media-heavy screen, returning from background, running a background sync — logged as discrete events rather than only sampled periodically
  • Out-of-memory kills and low-memory-killer events, which often precede a core vital breach and give an earlier, more actionable signal than the aggregate metric itself
  • Session length and feature usage on flagged low-RAM devices, to see whether memory pressure is actually shortening sessions or driving uninstalls on the hardware tier most exposed to it

Setup Steps

  1. Pull the current core vitals breakdown in Play Console to confirm whether memory usage is already flagged, and note the specific device and Android version segments it’s being measured against.
  2. Instrument per-screen memory sampling using Android’s own memory profiling APIs, tagging each sample with the current screen name and device RAM tier, rather than relying only on Play Console’s app-wide aggregate.
  3. Add event logging around known memory-heavy flows — image/video-heavy screens, large list views, background sync — so spikes can be tied back to a specific user action rather than discovered after the fact.
  4. Set an internal alert threshold below Play Console’s own core vital threshold, so the team gets warned while there’s still room to fix the issue before it affects Play Store visibility.
  5. Re-test on a genuinely low-RAM device, not just an emulator profile, since real low-tier hardware often surfaces memory pressure that a high-spec test device or emulator won’t reproduce.

Actionable Insights

If the app-wide core vital is flagged but per-screen data shows one screen consistently near the ceiling on low-RAM devices, that screen is almost certainly the fix, not a general memory-reduction sweep across the whole app. A rise in low-memory-killer events that isn’t yet reflected in the core vital score is a leading indicator worth acting on immediately, since Play’s own aggregate lags the underlying behaviour. And if session length on low-RAM devices is dropping while memory samples on those same devices climb, that’s a stronger signal of user-visible harm than the core vital threshold alone, and justifies prioritising the fix even before Play Console formally flags it.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert