Core/Dash Dimension: Device & Client Capability

What these dimensions measure

CoreDash exposes two dimensions under the Device & Client Capability category. They answer different questions but complement each other directly.

Device Memory (group code m) reports the RAM bucket the browser returns from navigator.deviceMemory. The spec deliberately rounds down to the nearest power of two and clamps the result, so you will see values of 0.25, 0.5, 1, 2, 4, or 8+ GB rather than exact figures. This rounding is intentional: it limits the precision available to fingerprinting scripts while still giving developers a usable signal.

Client Capability Score (group code ccs) is a composite computed by CoreDash from three browser-exposed signals: device memory, navigator.hardwareConcurrency (logical CPU cores), and the effective connection type from the Network Information API. The result is one of six buckets:

The composite score is more useful than any single signal in isolation. A device with 4 GB RAM on a 2G connection behaves very differently from the same device on Wi-Fi. Combining memory, cores, and connection type into one ordinal scale lets you filter and compare performance data without running a separate breakdown for each variable.

Browser support and data coverage

navigator.deviceMemory is a Chromium-only API. Firefox and Safari do not expose it, which means those browsers always report Unknown (CCS 0) for the memory component. In practice, Chrome and Chrome-based browsers account for the majority of Android traffic, and Android devices are where low-memory conditions concentrate. So the signal is most available precisely where it matters most.

The Device Memory HTTP header (Device-Memory) is a separate mechanism that allows a server to read the same value from an Accept-CH negotiated request. CoreDash uses the JavaScript API collected at page load time, so the value travels with the RUM beacon rather than requiring server-side header configuration.

Why device capability matters for Core Web Vitals

LCP is primarily a network and render problem. INP is primarily a CPU and memory problem. That distinction is why the CCS dimension shows up most clearly in INP data.

Long tasks on the main thread block input response. On a device with 1 GB RAM, the browser is already under memory pressure before your JavaScript even runs: more aggressive garbage collection, more frequent tab discards, and less headroom for JIT compilation all translate directly into longer task durations. A site that passes INP on a modern phone at 180 ms can easily sit at 400 ms on a Constrained device.

The 2025 Web Almanac Performance chapter confirms the trend: mobile INP pass rates reach 77% overall, but the gap between high-powered and low-end devices in that figure is wide. Roughly 29% of mobile web users are on devices three times less powerful than a current flagship. Those users are not outliers in most global markets; they are the median visitor.

CLS is less sensitive to hardware class than INP, but devices with slow CPUs can still produce layout shifts when fonts or late-loading images cause reflows that complete after the browser has already committed a frame.

How to use CCS and Device Memory in CoreDash

The most productive workflow is to start with CCS as a filter and then use Device Memory to confirm your hypothesis.

First, open your INP breakdown by CCS. If your 75th-percentile INP is good for Very Capable (CCS 1) and Capable (CCS 2) visitors but fails for Limited (CCS 3) and below, you have a CPU or memory bottleneck rather than a network bottleneck. That rules out a whole category of fixes (preloading, connection hints, CDN tuning) and focuses your attention on JavaScript execution time: long tasks, input handler weight, and third-party scripts that run on every interaction.

Then filter by Device Memory to see which RAM buckets drive the worst results. If 1 GB devices account for a disproportionate share of poor INP scores, you know the threshold. Scripts that are acceptable at 4 GB can be candidates for deferral or removal based on that data alone.

For sites with global audiences, pair CCS with the Country dimension. South and Southeast Asian markets, sub-Saharan Africa, and parts of Latin America have high concentrations of Constrained and Very Limited devices. A CCS breakdown filtered by country will show you where the gap is largest and help you prioritize which market to address first.

The Unknown bucket (CCS 0) covers all Firefox and Safari traffic plus any session where the APIs returned no value. Do not ignore it. On sites with significant Firefox or Safari share, Unknown can represent a quarter or more of all sessions. It does not mean those users have bad devices; it means the signal was unavailable. Treat Unknown as a separate segment rather than folding it into your baseline.

What to do with the data

If CCS 3, 4, or 5 visitors make up more than 15% of your traffic and their INP is consistently above 200 ms, the fix set is specific:

• Profile your longest tasks on a throttled device in Chrome DevTools. Task Attribution in the Performance panel will show which scripts are responsible.
• Move non-critical third-party scripts behind an interaction or visibility trigger so they do not compete for the main thread during the initial load window.
• Reduce JavaScript bundle size on critical paths. Every kilobyte parsed on a low-memory device costs more than on a flagship because the JIT compiler has less room to cache compiled code.
• Use scheduler.yield() or setTimeout(0) to break up long tasks and give the browser a chance to process input events between chunks.

CoreDash surfaces the CCS and Device Memory dimensions alongside every Core Web Vitals metric so you can confirm whether a fix that improved INP on high-end devices also moved the numbers for your Constrained visitors, not just your best-case users.