Skip to content

CONCEPT Cited by 2 sources

User Perceived Latency

Definition

User Perceived Latency (UPL) — sometimes shortened to perceived latency — is the time from when a user performs an action until they see the resulting content. Pinterest's operational definition: "how much time the user spends since they perform an action until they see the content. This is also called Visually Complete." (Source: sources/2026-04-08-pinterest-performance-for-everyone).

UPL is the user-facing, product-level latency metric — distinct from wire latency, server processing latency, or first-byte latency. It's the number that maps to the user's experience of whether an app feels fast.

Why UPL ≠ any single system-level latency

No single technical timing corresponds to UPL:

  • Network round-trip time ignores local rendering costs.
  • Server p99 ignores client-side layout, image decoding, video buffering, JS hydration.
  • Time to first byte measures when bytes arrive, not when content is visible.
  • Time to first paint measures when something renders, not when the content the user came for is rendered.

UPL requires a per-surface definition of "the user has seen the content they came for" — what Pinterest operationalises as Visually Complete. Examples from the 2026-04-08 post:

  • Video Pin Closeup → Visually Complete = "the full-screen video starts playing."
  • Home Feed → Visually Complete = "all the images rendered and videos playing."
  • Search Auto Complete → Visually Complete = "the search autocompleted suggestions' text rendered along with the avatar images."

Measurement is per-surface — and that is the problem

Because UPL's done-state is surface-specific, measurement historically required per-surface instrumentation. Pinterest disclosed: "on average, it takes two engineer-weeks to implement a User Perceived Latency metric on the Android Client and wire it up to all the toolsets for production usage." (Source: sources/2026-04-08-pinterest-performance-for-everyone). This instrumentation engineering cost gates coverage — short-shelf-life surfaces never get instrumented because the cost doesn't justify the benefit.

The pattern-level solution is base-class automatic instrumentation: move the work from N surfaces to the UI framework once, via a mechanism like Pinterest's BaseSurface + PerfView interfaces combination.

Relationship to web performance vocabulary

  • Interaction to Next Paint (INP) (web) — Core Web Vitals metric; closest web equivalent to UPL at the per-interaction level.
  • Largest Contentful Paint (LCP) (web) — heuristic for when the "main content" has rendered; a browser-level proxy for Visually Complete on web.
  • Time to Interactive (TTI) (web) — when the page stops blocking input; responsiveness metric distinct from UPL.
  • Real User Measurement (RUM) — the data-collection pattern UPL typically feeds; Pinterest's Visually Complete timestamps emit into its RUM toolsets.

Why UPL is "the default feature"

Pinterest frames performance as a product contract, not a nice-to-have: "For mobile apps, performance is considered as the default feature, which means apps are expected to run fast and be responsive. It's just as if we expect a watch to show the time. With no exceptions at Pinterest, we measure, protect and improve performance for all of our key user experiences' surfaces." (Source: sources/2026-04-08-pinterest-performance-for-everyone). Canonical wiki framing of performance as an always-on, always-measured product attribute.

Seen in

  • 2026-04-08 Pinterest — Performance for Everyone (sources/2026-04-08-pinterest-performance-for-everyone) — canonical definition; UPL = Visually Complete; two-engineer-weeks-per-surface instrumentation tax; base-class automation; 60+ Android surfaces continuously measured.
  • 2026-05-14 GitHub Engineering — From latency to instant: Modernizing GitHub Issues navigation performance (sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance) — canonical web-altitude UPL instance via the internal HPC (Highest Priority Content) metric, "closely aligned with Web Vitals LCP." Distinct from Pinterest's per-surface Visually Complete predicate: HPC is anchored to a single browser-selected element across all pages, trading per-surface fidelity for deployability without two-engineer-weeks-per-surface instrumentation. Consumed through the Instant (<200 ms) / Fast (<1000 ms) / Slow (≥1000 ms) bucket-share lens — a distribution-quality posture rather than a p99-control posture. See concepts/highest-priority-content-hpc.
Last updated · 542 distilled / 1,571 read