TTFB
The TTFB page of RUM Monitoring shows how fast your server starts to answer real visitors, and where the wait for the first byte goes.
The TTFB page of RUM Monitoring shows how long your server takes to start its answer for real visitors. It also splits the wait into phases, from redirects to the first byte of the page.
What TTFB means
TTFB (Time to First Byte) is how long your server takes to start answering a page request. It is the wait before the first byte of the page arrives. Nothing else on the page can load before this, so a slow TTFB makes every other metric slower.
TTFB is not a Core Web Vital. Google does not judge it, but it is the first phase of LCP. A high TTFB usually points to hosting or caching, not to the design of the page.
TTFB thresholds
| Band | TTFB value |
|---|---|
| Good | 800 ms or less |
| Needs improvement | 1.8 s or less |
| Poor | More than 1.8 s |
The headline value is the value of a typical visit: 3 out of 4 page loads were this fast or faster. See Metrics and thresholds.
Before you start
- RUM Monitoring needs the RUM script on your pages. See Install the RUM script.
- In the sidebar, open Web performance > RUM Monitoring > TTFB.
- Select Phone or Desktop in the filter dock. Every card on the TTFB page shows the selected device only.
You can also filter by date, URL Path, Country and Browser, and compare with an earlier period. See Filters and the device.
The TTFB verdict
The verdict is one sentence at the top of the TTFB page. It shows only when it says something new:
- "On Phone, TTFB needs work" when the typical TTFB is not Good. If the value is only a little over the limit, it adds "Just over the limit."
- "On Phone, TTFB passes but is close to the limit" when the typical TTFB is Good, but within 10% of 800 ms.
- "On Phone, TTFB got 20% slower" or "got 20% better" when compare is on and TTFB changed by 15% or more.
The verdict needs 30 visits or more. If TTFB passes with room to spare, the TTFB page shows no verdict. The TTFB page has no Site Health Monitoring banner, because TTFB is not a Core Web Vital.
Time to First Byte card
The Time to First Byte on Phone card (or on Desktop) has two tiles and one chart. Click a tile to show its chart.
- Time to First Byte: the typical TTFB in the period, colored by its band.
- Good visits: the share of visits with a Good TTFB. The tile is green at 75% or more, orange at 50% or more, and red below 50%.
A tile from fewer than 30 visits is gray, with a note such as Only 12 visits. A tile without data shows Not measured for this period.
The TTFB chart
For Time to First Byte, the chart shows the typical TTFB over time. Two lines mark the Good limit (800 ms) and the Poor limit (1.8 s). With compare on, a dashed line shows the earlier period.
For Good visits, the chart shows the share of Good, Needs improvement and Poor visits over time, stacked to 100%. This chart has no pass line, because Google does not judge TTFB.
Use the Hour, Day, Week or Month control to group the chart. A note on a day of the chart tells you that VitalSentinel changed what RUM Monitoring measures, or calculated stored data again, on that day.
Google and your own visitors
The Google and your own visitors card compares your TTFB with the TTFB that Google publishes for your site. It has four tiles:
| Tile | What it covers |
|---|---|
| Google, Phone and Google, Desktop | Chrome visits to the whole site, last 28 days |
| Your visitors, Phone and Your visitors, Desktop | All visits in the selected period and filters |
Google rates your site from Chrome visits only. RUM Monitoring measures all of your visitors, so the two can differ. Click Open CrUX Monitoring to see Google's data. See CrUX Monitoring.
If CrUX Monitoring is not set up for the domain, the card shows Set up CrUX Monitoring instead. A tile without a figure says "Google has not published enough visits for this device yet." or "Too few visits measured this yet."
Where it is slow
The Where it is slow card lists your pages for the selected device. By default, the pages with the most visits that were not Good come first.
| Column | What it shows |
|---|---|
| Page | The page address. The menu opens the page in other modules. |
| Visits | The visits to the page in the period |
| Google clicks | The clicks from Google web search, from Google Search Console |
| TTFB | The typical TTFB of the page, with its change when compare is on |
| Good visits | The share of visits with a Good TTFB |
| Visits affected | The visits on the page that had a TTFB above the Good limit |
Click a header to sort. A page with fewer than 30 visits shows a dash in TTFB. Owners and admins can click Watch in Page Monitoring on a row. A slow page that others do not share often has no cache.
Countries
The Countries card shows a world map for the selected device. Each country has the color of its typical TTFB: Good, Needs improvement or Poor. Low sample means too few visits to rate, and No data means no visits.
Hover a country to see its visits, its figures, the change from the earlier period and the visits affected. A slow country usually means a long distance to your server. A CDN (content delivery network) puts copies of your pages near the visitor.
Where the time goes
The Where the time goes on Phone card (or on Desktop) shows the average time in each phase of TTFB over time, one line for each phase. Four phases add up to TTFB:
| Phase | What it is |
|---|---|
| Waiting | Time in redirects and the browser cache before the request starts |
| DNS time | Finding your server on the internet |
| Connection time | Opening a connection to your server |
| Request time | Sending the request and waiting for your server to start its answer |
Waiting also includes the end of the previous page and the start of a service worker. A long Request time points to a slow server or no cache.
The two context lines
The chart shows two more lines. They help you find the cause, but they are not part of the TTFB sum:
- TLS (within connection): the secure handshake. It is part of the Connection time, so it is already counted.
- Response (after first byte): the download of the page itself. It starts at the first byte, so it comes after TTFB.
If a phase was not measured for a point, its line has a gap, not a zero. Older data can have no Waiting value. Across a gap, the four phases do not add up to TTFB.
How to improve TTFB
Use the Where the time goes card to find the long phase, then act on it:
- Waiting is long: remove redirects. Link to the final address of each page.
- DNS time is long: use a fast DNS provider.
- Connection time is long: use a CDN, so that the server is near the visitor. Use HTTP/2 or HTTP/3.
- Request time is long: make your server faster. Cache pages, so that the server does not build each page again. Make slow database queries faster.
Troubleshooting
Why is TTFB high only in some countries?
The server is far from visitors in those countries. Each request must travel a long distance. Use a CDN to serve your pages from a location near the visitor.
Why do the TTFB phases not add up to TTFB?
TLS (within connection) is already part of Connection time, and Response (after first byte) comes after TTFB. Do not add these two lines. Also, a gap in Waiting means that the phases cannot add up at that point.
Why does the TTFB page say "No Time to First Byte data for this period"?
There were no visits on the selected device in these dates and filters. Select the other device in the dock, select a longer date range, or remove a filter.
Why is the TTFB of my server logs lower than in RUM Monitoring?
RUM Monitoring measures TTFB in the visitor's browser. It includes redirects, DNS, the connection and the network distance. A server log measures only the time inside your server.
Related
- Overview - all Core Web Vitals, filters and page-view limits
- LCP - TTFB is the first phase of LCP
- FCP - the first paint after the server wait
- Page Views - the TTFB phases of one visit
- Uptime Monitoring - the response time of your server from outside
- Metrics and thresholds - the limits of every metric
