Visible and operable are two different moments
Aliases: TTI · INP · FCP · LCP · time to interactive · first paint
What it is
Pixels appearing on screen, and that appearance already responding to input within budget, are two clocks. First paint (and later LCP) marks "visible". Interactive — the readiness TTI tried to name, and INP as measured in the field — marks "operable". In the gap, a button can already look final while the main thread is still running script and hydration has not attached listeners; clicks vanish. Seeing first paint does not stand in for "it can be clicked".
This is why the two moments are not one probe — not which device class a budget should bind to, and not whether a missing budget means nobody will run the work.
Why it happens
Paint needs layout, the paint tree, and this frame's pixels. Event handling needs the main thread idle enough to run listeners, update state, and paint the next frame. Modern front ends paint first-screen HTML early (visible) and ship behaviour in later JavaScript (operable later). Hydration rebinds framework events onto existing DOM; clicks before it finishes are dropped or queued into an unready tree. TTI tries to mark when the main thread stays idle enough for stable interaction; INP measures the delay from a real click / key / tap to the next frame. Neither is a paint timestamp. The instant a large image becomes LCP, INP can still be poor — the user sees the biggest element and then waits hundreds of milliseconds on tap.
So a "first screen" that only reports paint pulls optimisation toward images and fonts while script still blocks input. The two moments use different probes because they sit at different stages of the pipeline: pixels versus input handling. Using one as the other stops work at the wrong stage.
Where it stops holding
Mostly static documents can have the two moments close together; splitting the report gains little, but they are still not the same quantity. Game loops, canvas, and native clients do not use web TTI/INP; they need their own "first frame" and "first input". Prerender and bfcache restore can paint extremely early; interactivity then depends on whether events still exist after restore. Lab-only TTI misses sporadic long tasks in the field; INP alone cannot answer "in which second could they first click". Controls that look disabled (grey, skeleton) are a deliberate way to align the two moments, not a misuse of "visible equals operable".
Applying it
- Split "visible" and "operable" into two goals: paint via LCP / first paint, interaction via field INP and lab TTI or TBT. Do not let one first-screen number cover both.
- On the main path, do not paint clickable controls in their final affordance before listeners are attached; skeleton or disabled states align the two moments.
- Drop or explicitly queue clicks until hydration finishes, then give visible feedback so gap-clicks do not disappear.
- How to check: slow 3G plus CPU throttle, record, and align taps. Report both the time pixels appear and the time the first tap gets a response. If paint is green and the tap still waits, only "visible" was optimised.