Skip to content

CONCEPT Cited by 1 source

Highest Priority Content (HPC)

Definition

Highest Priority Content (HPC) is GitHub's internal client-side rendering metric that measures when the primary content on the page is first rendered — "the content users care about," anchored to a single browser-selected HTML element. (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

GitHub describes HPC as "closely aligned with Web Vitals LCP" — like LCP, HPC fires once per page load when the chosen primary element is rendered. On the issues#show route the chosen element is "most often the issue title or the issue body."

Operational thresholds

GitHub buckets navigations using HPC:

Bucket HPC range Description
Instant < 200 ms feels immediate in real workflows
Fast < 1000 ms acceptable but no longer invisible to users
Slow ≥ 1000 ms user-noticeable lag

The thresholds are explicitly chosen to be "a practical model for user-perceived speed, not just raw backend latency" — the <200 ms instant bucket maps to interactions that feel immediate; the <1000 ms fast bucket to interactions that are acceptable but visible. The thresholds are operational defaults, not abstract claims about psychology.

Relationship to LCP

LCP (Largest Contentful Paint) is the Core Web Vitals metric for when the largest contentful element renders, browser-selected per page. HPC differs in three small but meaningful ways:

  • Application-controlled selection of the priority element. HPC is anchored to the element "the browser selects" but on GitHub-defined criteria of which content is primary (the issue title or body, in issues#show's case). LCP uses the browser's heuristic for largest contentful element, which may not match the application's most important content.
  • Bucket-thresholded operational use. HPC is consumed primarily through the instant/fast/slow bucket model; Google's LCP guidance is also threshold-based (≤2500 ms good / ≤4000 ms needs improvement) but at different cutoffs.
  • Internal name + telemetry plumbing. HPC is a GitHub-internal metric emitted into GitHub's RUM stack, not the standardised browser API LCP is.

The two metrics are functionally analogous and the GitHub team explicitly anchors HPC to LCP — "closely aligned with Web Vitals LCP" — which is the load-bearing detail: HPC isn't a unique metric; it's GitHub's flavour of LCP.

Relationship to Visually Complete and UPL

The wiki's prior canonical metric for "the user has seen the content they came for" is Pinterest's Visually Complete, operationalised as UPL. Pinterest measures this per-surface with a custom done-state predicate per screen (Home Feed = "all the images rendered and videos playing," Search Auto Complete = "suggestions' text rendered along with the avatar images"). HPC takes a different cut at the same general goal:

Metric Anchored to Per-surface?
HPC (GitHub) single browser-selected HTML element uniform across pages
LCP (Web Vitals) largest contentful element uniform
UPL / VC (Pinterest) per-surface application-defined done predicate yes

HPC trades per-surface fidelity for deployability — because it's anchored to a generic browser-selected element, it can be deployed across all pages without per-surface instrumentation work, which Pinterest disclosed as a "two engineer-weeks per surface" tax. The cost is that on pages where the browser-selected element doesn't match the content the user actually came for, HPC will be miscalibrated.

Distribution-quality posture

HPC is consumed not as a percentile but as a bucket-share distribution — what fraction of navigations land in instant vs fast vs slow? This is a deliberate departure from the historical p90/p99 framing; see concepts/distribution-quality-vs-p99-tail for the measurement-philosophy axis. GitHub's framing: "It is possible to enhance the p99 of the HPC while still leaving the median experience feeling sluggish… we shifted focus toward distribution quality: how many navigations land in our fast and instant buckets across the whole population? The goal is not just fewer terrible outliers. It's to make speed the default path for the majority of sessions."

Seen in

Last updated · 542 distilled / 1,571 read