Seconds to Milliseconds

Two Units on the Same Performance Report

Open any page-speed report and the units change halfway down. Largest Contentful Paint is written as 2.5 seconds, Interaction to Next Paint as 200 milliseconds, and the raw entries behind both of them come out of the browser as fractional milliseconds. Nothing is inconsistent — the numbers simply sit at different magnitudes, and the convention follows what reads well. The conversion is the small tax you pay for that, every time a threshold in seconds has to be compared against a dashboard column in milliseconds.

Conversion factor: 1 s = 1 000 ms, so multiply seconds by 1 000. The "good" limit for Largest Contentful Paint is 2.5 s, which is 2 500 ms, and the "poor" boundary of 4 s is 4 000 ms — the figures a monitoring rule needs if it is written in milliseconds.

Why the Units Split the Way They Do

Loading is talked about in seconds

Paint and byte-arrival milestones land in the thousands of milliseconds, so seconds keep them short and comparable. "2.5 s" also matches how a visitor would describe the wait.

Responsiveness is talked about in milliseconds

The gap between a tap and the next painted frame is tens to hundreds of milliseconds. Expressed in seconds it would be a string of leading zeros, which is why interaction budgets stayed on the smaller unit.

One metric is not a duration at all

Cumulative Layout Shift scores instability, not time. Its 0.1 and 0.25 boundaries carry no unit and never convert — the one row in a vitals report that this page cannot help with.

The judgement happens at the 75th percentile

Field assessment takes the 75th percentile of real visits over a rolling 28 days, so a threshold is a promise about three visits in four — not about the median and not about your own laptop.

Turning a Target in Seconds Into Millisecond Budgets

A performance target only becomes useful once it is broken into pieces that individual teams can own, and those pieces are always small enough to be counted in milliseconds.

Enter the threshold as it is published

Type 2.5, 1.8 or 0.8 into the left field and read the millisecond equivalent straight away. A comma instead of a full stop is accepted, which saves editing a figure pasted from a European report.

Carve the total into named slices

Assign the milliseconds to the stages that actually consume them — server response, blocking scripts, image decode, font swap — and keep a reserve. Slices that add up to exactly the threshold leave nothing for a slow network day.

Reverse it for numbers coming out of tooling

Exported field data and browser timings arrive in milliseconds. The swap button (↔) turns the page into ms → s so a measured 3 180 ms can be reported as 3.18 s next to a published limit.

Copy the plain figure into the alert rule

The copy control gives the digits alone, no unit and no separator, which is what a monitoring threshold field or a spreadsheet cell wants. Ctrl + C inside a field does the same.

Convert the threshold, not the score: layout-shift figures are dimensionless and a Lighthouse score out of 100 is a rating, not a duration. Only the timing rows in a vitals report belong in a converter at all.

Vitals Thresholds Written Both Ways

The published boundaries, each shown in the unit the documentation uses and in the unit a dashboard is likely to store. The first three are the Core Web Vitals themselves; the rest are the diagnostics people reach for when one of the three goes red.

Metric	Good at or below (s)	Good at or below (ms)	Poor above (s)	Poor above (ms)
Largest Contentful Paint	2.5 s	2 500 ms	4 s	4 000 ms
Interaction to Next Paint	0.2 s	200 ms	0.5 s	500 ms
Cumulative Layout Shift	0.1, no unit	—	0.25, no unit	—
Time to First Byte	0.8 s	800 ms	1.8 s	1 800 ms
First Contentful Paint	1.8 s	1 800 ms	3 s	3 000 ms
Total Blocking Time (lab)	0.2 s	200 ms	0.6 s	600 ms
Long task on the main thread	0.05 s	50 ms	—	—

Laid out together the spread is stark: the whole responsiveness allowance, 200 ms, is smaller than a quarter of the paint allowance, and a single long task can eat a quarter of it before any of your own code has responded. That is the practical argument for chasing main-thread work rather than shaving bytes once loading is already inside its limit.

What This Page Does During a Performance Review

Split a budget while you talk

Type in either box and the other keeps up, so 2.5, 1.8 and 0.8 can be turned into millisecond slices in the middle of a meeting without opening anything else.

Exported timings run backwards

Swap the pair and millisecond values from a field export become the seconds a stakeholder-facing summary is written in, without a second tool in the loop.

Fractions of a millisecond survive

Results keep up to eight decimals, so a 0.0005 s render step still reads as 0.5 ms instead of being rounded away to nothing.

Threshold fields get clean digits

Copying hands over the number with no unit attached, ready to paste into an alert condition or a budget file that would reject "2 500 ms" as text.

Questions From the Performance Review

My tooling reports LCP in milliseconds — what counts as good?

2 500 ms or less, and anything above 4 000 ms is classed as poor, with the band between the two counting as needing improvement. The comparison only means what it is supposed to mean if the number is the 75th percentile of real visits rather than a single run: one measurement of 2 450 ms on a fast connection proves very little about the three-quarters of visitors the assessment actually covers.

Why is INP published in milliseconds while LCP is published in seconds?

It is presentation, not measurement. Both values reach the page as high-resolution timestamps in milliseconds, fractions included, and the documentation then picks whichever unit keeps the printed figure legible. An interaction budget of 0.2 s would be written with a leading zero and read badly; a paint target of 2 500 ms is four digits where two would do. Trouble starts only when a dashboard mixes the two conventions in one column, which is exactly when a conversion is worth doing carefully.

How do I divide a 300 ms server-response allowance between stages?

Give each stage a number and leave a margin. A workable split of 0.3 s is roughly 40 ms for routing and middleware, 130 ms for application logic, 100 ms for the slowest database round trip and 30 ms for rendering the response. That sits comfortably inside an 800 ms first-byte target, leaving around 500 ms for redirects, connection setup and the trip across the network — which on a mobile connection is not generous. Any stage that regularly overruns its slice is the one to profile first.

What makes a task "long" at exactly 50 ms?

The number comes from the goal of answering a user within about 100 ms. Work on the main thread cannot be interrupted, so if the longest task runs 50 ms, an interaction arriving at the worst possible moment waits 50 ms and still has 50 ms left to be handled inside the goal. Anything over that threshold is reported as a long task, and blocking time totals only the excess — a 120 ms task contributes 70 ms, not 120 ms. Breaking one long function into several shorter ones improves the score even though the total work is unchanged.

Why do lab and field figures for the same page disagree?

They are measuring different things. A lab run is one synthetic load on a throttled processor and network with an empty cache and nobody touching the screen. Field data pools real visits across 28 days on whatever hardware and connections your audience owns, then reports the 75th percentile. Responsiveness cannot even exist in a lab without someone interacting, which is why lab tooling substitutes blocking time as a proxy. Treat the lab as a repeatable place to test a change, and the field as the only verdict that counts.