The line sits at the Core Web Vitals thresholds. Below it, slowness is a user-experience problem; at or past it, slowness becomes a ranking cost. Treating any sluggishness as a ranking issue gets the boundary wrong, because a page that is a little slow but still passing is costing you patience and conversions, not position. The pivot is whether the page fails the thresholds, measured the way Google measures them.
Those thresholds are evaluated on real-user field data at the seventy-fifth percentile, meaning three quarters of visits have to clear the bar for the page to pass. The current guidance puts a good Largest Contentful Paint at roughly two and a half seconds or under, Interaction to Next Paint under two hundred milliseconds, and Cumulative Layout Shift under one tenth, with the caveat that Google has been nudging these tighter over time, so they are worth confirming against the current numbers. A page sitting in the Needs Improvement or Poor band has crossed into territory where speed can drag on rankings; a page in the Good band has not, however much faster it could theoretically be.
There is a second route across the line that does not require failing a metric outright. If a page is slow enough to drive measurable abandonment, that behavior feeds back through engagement signals, and the bounce and short dwell start to read as a weaker page. In practice that indirect channel is often the larger one, which is why a page can pass the thresholds and still lose ground if it frustrates people enough to leave.
So the reader checks the page’s Core Web Vitals status in the field data before deciding anything, using which side of the threshold the page sits on to tell whether speed is costing rankings or only annoying users.