How to Accurately Measure First‑Screen Time with Rendering Density

Background and Current Situation

In modern front‑end development, performance evaluation has moved from load and DOMContentReady timings to user‑centric metrics such as First Paint, First Contentful Paint, and First Screen Time. While standards exist for FP and LCP, there is no industry‑wide definition for First Screen Time, leading teams to use varied proxies like UC's T2 metric or custom implementations.

Fundamental Theory

First Screen Time is abstract because it lacks clear boundaries like "first render" or "largest contentful paint". Instead of trying to define when the "main content" finishes rendering, the article proposes viewing the page as a visual process that stabilizes when rendering density drops to near zero, indicating visual stability within the first‑screen area.

Rendering Density Calculation

The approach quantifies each DOM update's contribution to the first‑screen area, recording the process until the density falls below a 5% threshold for three consecutive seconds. This termination condition reflects a stable visual state.

Continuity Judgment

Updates are aggregated in 200 ms windows, a duration perceived as continuous by users. A segment’s start time is the earliest DOM insertion/modification, and its end time is when all images (including CSS‑referenced ones) finish loading. Segments are merged based on three rules: containment, start before another segment ends, and start within 200 ms of another segment’s end.

Implementation Process

The algorithm excludes non‑critical rendering such as large CSS background images, millisecond‑level timers, carousel off‑screen images, delayed auxiliary elements, image placeholder swaps, and premature page exits. Remaining challenges are handled by heuristics or manual tagging.

CSS background images often occupy large visual areas but are not directly monitorable.

Frequent tiny DOM updates from timers or scrolling components.

Carousel images beyond the first frame.

Delayed auxiliary UI elements (e.g., app‑launch buttons).

Placeholder‑to‑real image swaps.

Unexpected page navigation before rendering completes.

Optimization Logic

The script runs primarily within a MutationObserver callback, processing roughly a hundred updates per page. Over 90 % of the overhead comes from area statistics and position checks, which are optimized by ignoring hidden nodes, nodes outside the first‑screen, and by using maximal bounding‑box area calculations.

Effect Validation

Validation against UC's T2 metric on 100 pages shows mean and median errors under 100 ms, with 80 % of samples within 500 ms. JS‑computed first‑screen times are typically ~20 ms faster than T2 due to image load vs. decode timing differences.

Other

First‑screen time is more than a performance metric; it defines a new lifecycle point from which additional health indicators—such as network utilization and low‑efficiency resource detection—can be derived. The presented method aims to provide a practical, low‑overhead solution that can be further refined for complex scenarios like SPA applications or game pages.