Cloudflare LCP and INP breakdowns: microseconds and missing values

Start with your site: move from a score to a delay

Cloudflare’s October 13, 2026 update announces LCP and INP sub-parts in Web Analytics Real User Monitoring, or RUM, along with separate TCP connection and TLS handshake timings. RUM records performance experienced in visitors’ browsers. It serves a different purpose from periodically probing whether a node is online.

Largest Contentful Paint, or LCP, describes how soon a page’s main content appears. Interaction to Next Paint, or INP, describes responsiveness after a click, tap or key press. A total value flags a slow experience; sub-parts help you decide where to investigate. They do not repair a page or establish that an optimization worked.

Open Web Analytics in the Cloudflare dashboard, select your site and go to Core Web Vitals. Fix the date range and URL first, then inspect the breakdown and tooltips with appropriate browser, operating-system or country filters. Preserve comparable filters before and after a change, rather than treating different visitor groups as one experience.

The four LCP phases: slow download or late appearance?

Time to First Byte is the browser’s wait for the HTML document, exposed as timeToFirstByte. Resource load delay is the time needed to discover the LCP resource after the document starts arriving, exposed as lcpResourceLoadDelay. Receiving HTML and discovering a critical image promptly are separate stages.

Resource load duration is the resource’s download time, exposed as lcpResourceLoadTime. Element render delay is the gap between its arrival and its appearance on screen, exposed as lcpElementRenderDelay. A finished download does not mean the visitor can already see the element.

Suppose a page’s main content is an image. A large discovery delay suggests investigating why the browser finds it late; a large render delay suggests investigating why it is not displayed promptly after arrival. This is a hypothetical triage example, not a measurement on this site or proof of a single root cause.

The three INP phases: waiting, handling or painting?

Input delay, exposed as inpInputDelay, is the time an interaction is blocked before processing can begin. Processing duration, inpProcessingDuration, is the time your event handlers run. Presentation delay, inpPresentationDelay, is the time the browser takes to render the next frame after those handlers finish.

An unresponsive click therefore does not necessarily mean the event handler itself ran for too long. Distinguish an interaction waiting to run, expensive handling and a late next frame before directing frontend investigation. INP is not simply a network round-trip measurement.

The Core Web Vitals Debug View lists the top five elements negatively affecting each metric. Tables initially show P75, with more percentiles available when expanded. Use the element, URL and browser context to identify the investigation target, rather than relying on one site-wide average.

The API uses microseconds. Negative does not mean fast

The new sub-parts are percentiles on rumWebVitalsEventsAdaptiveGroups, such as lcpResourceLoadDelayP50 or inpInputDelayP50. Available percentiles are P25, P50, P75, P90, P95, P99 and P999. P50 is the median; P75 marks roughly the boundary reached by 75% of ordered observations, rather than an average.

The announcement explicitly states that these GraphQL values use microseconds. A hypothetical response of 150000 microseconds equals 150 milliseconds. This is a unit example, with no account query performed. The Core Web Vitals documentation uses milliseconds for the LCP/INP Value, so check the field and unit before comparing dashboard and API values.

A negative value means data is unavailable. Preserve it as missing and use an explicit handling method in your analysis, instead of replacing it with zero or ranking it among the fastest observations. Adding each sub-part’s separate P75 also does not establish the total LCP’s P75: those percentiles need not describe the same observation.

TCP and TLS are separate. Is the old field still valid?

Yes. connectionTimeWithoutTLS measures connection establishment excluding TLS, while tlsTime measures the TLS handshake. Cloudflare explicitly retains the combined connectionTime in GraphQL; this announcement does not deprecate it.

The split is on rumPerformanceEventsAdaptiveGroups, for example connectionTimeWithoutTLSP50 and tlsTimeP50. Identify whether you need connection timings or Core Web Vitals sub-parts, then use comparable filters and percentiles. Do not interchange the two datasets’ fields or assume a proxy will resolve a slow handshake.

Missing data? Check how collection works first

Web Analytics requires a Cloudflare account and a JavaScript beacon on the page. It does not require changing DNS or using Cloudflare’s proxy. The beacon loads from static.cloudflareinsights.com/beacon.min.js; an existing Content Security Policy can block it. An authorized maintainer should check collection configuration and requests before treating missing data as zero.

For proxied sites, data goes to /cdn-cgi/rum on your domain. For non-proxied sites, it goes to cloudflareinsights.com/cdn-cgi/rum. Cloudflare says Core Web Vitals are reported when visibilityState first becomes hidden after the page-load event. A missing record immediately after opening a page does not establish that the visit never happened.

Browser support needs to be checked per metric. The current documentation says CLS is Chromium-only; that scope should not be copied onto LCP/INP. Broad Performance API availability also does not guarantee every new sub-part is present. This announcement provides no comprehensive guarantee of per-browser coverage, display in each account or historical backfill.

Free has limits: preserve the site and comparison context

The About page calls Web Analytics free, and the overview lists availability on all plans. This does not make every Cloudflare service free. Current limits allow 10 non-proxied sites, with no site-count limit for proxied sites. The dashboard can aggregate at most 1,000 sites at once; select specific sites or use GraphQL as the documentation suggests.

Web Analytics rules apply only to proxied sites: Free allows 0, Pro 5, Business 20 and Enterprise 100. Zero means no rules, rather than no Web Analytics. The documentation says plans with zero rules inject the JavaScript snippet on all subdomains. Keep rule allowances separate from site limits.

Charts and tables use adaptive resolution, with presentation depending on data volume, date range and other factors. Record URL, dates, filters, percentile and unit for comparisons. The sources reviewed here do not establish historical backfill for new fields, a fixed sampling rate, retention or API request allowances; leave those unspecified.