CONCEPT Cited by 1 source

Client-side performance instrumentation¶

Definition¶

Client-side performance instrumentation is the practice of emitting performance timestamps and metrics from inside the user's device — the mobile app, browser, or other client runtime — rather than from the server. It is the data-collection layer underneath Real User Measurement (RUM), and it's where metrics like User Perceived Latency and Visually Complete are actually produced.

Why client-side and not server-side¶

A large fraction of user-perceived latency happens on the device after the last server response:

Image decoding — JPEGs/PNGs/WebPs must be decoded and rendered by the GPU.
Layout + paint — the UI framework must compute final layout, measure text, apply styles, rasterise.
Video buffering — "start playing" is a client-side event, not a server event.
JS hydration — for web apps, interactive state must be restored before the page feels responsive.
GPU scheduling, vsync, frame deadline — frame-pacing effects that are invisible to the server.

Server-side timings (p99 backend, TTFB) are necessary but not sufficient to characterise UPL. Client-side instrumentation closes the gap.

Per-surface vs platform-level instrumentation¶

The naive approach is per-surface instrumentation: each feature screen writes its own measurement code — observe the right views, decide when they're all ready, emit a timestamp. Pinterest disclosed this cost: two engineer-weeks per surface on Android to implement User Perceived Latency measurement and wire it to production toolsets (Source: sources/2026-04-08-pinterest-performance-for-everyone). See concepts/instrumentation-engineering-cost.

The platform approach lifts the work into the UI substrate — typically via base-class automatic instrumentation. Pinterest's Android implementation: BaseSurface walks the view tree and inspects PerfImageView / PerfTextView / PerfVideoView marker interfaces to produce a timestamp automatically for every surface.

Substrate anchors per platform¶

The hooks available for client instrumentation differ by platform:

Android — view tree traversal from ViewGroup; onDraw + ViewTreeObserver.OnPreDrawListener; Choreographer frame callbacks; FragmentManager lifecycle.
iOS — UIKit view hierarchy + viewDidAppear; SwiftUI .onAppear + view-identity; CADisplayLink frame callbacks.
Web — DOM tree traversal; IntersectionObserver; Web Performance APIs (Navigation Timing, Resource Timing, Paint Timing, Layout Instability, Largest Contentful Paint, Interaction to Next Paint); requestAnimationFrame.

Pinterest notes without detail that the pattern was extended from Android to iOS and Web (Source: sources/2026-04-08-pinterest-performance-for-everyone).

Relationship to server-side observability¶

Server-side observability (logs + metrics + traces) covers the backend-of-request story — what the server did, how long each hop took.
Client-side performance instrumentation covers the client-of-request story — what the device did after receiving the response, and the user-perceivable outcome.
RUM (see concepts/real-user-measurement) aggregates client-side instrumentation from real users into population-level distributions.
APM correlates client-side timestamps with server-side traces for end-to-end attribution.

Caveats¶

Instrumentation itself has cost — emitting timestamps, sampling, buffering, and shipping to a RUM backend consumes CPU, memory, and network. Client-side instrumentation must minimise its own perturbation of the latency it's measuring.
Tagging / opt-in correctness — any selective instrumentation scheme (Pinterest's PerfView interfaces are one example) depends on product engineers labelling the right views. Missed tags → false-early timestamps; stuck-pending tags → never-fires completion.
Device + network diversity — mobile instrumentation data spans chipsets, GPU capabilities, network qualities, OS versions, background state. Percentile reporting must account for these covariates.
Privacy constraints — client-side measurement must not leak PII or user-specific identifiers in timestamps / attributes.

Seen in¶

2026-04-08 Pinterest — Performance for Everyone (sources/2026-04-08-pinterest-performance-for-everyone) — Pinterest Android client; view-tree walk + base-class + opt-in interfaces as the platform mechanism; two-engineer-weeks-per-surface as the pre-platform cost; 60+ Android surfaces continuously measured post-platform.