Your client opens PageSpeed Insights and asks about two numbers that are not in the Core Web Vitals row: First Contentful Paint (FCP) and Total Blocking Time (TBT). LCP, INP, and CLS are in the contract. FCP and TBT are not ranking signals on their own, yet they appear in every scheduled Lighthouse run and often change before the vitals do.
This guide explains what first contentful paint and total blocking time measure, how they relate to the three Core Web Vitals, and when to track them in performance budgets across a portfolio. For the vitals themselves, start with What Are Core Web Vitals? and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.
Are FCP and TBT Core Web Vitals?
No. Google's Core Web Vitals programme includes only three field metrics at the 75th percentile: LCP, INP, and CLS. FCP and TBT appear in Lighthouse and PageSpeed Insights lab output. They help you find causes, but they do not replace CrUX field scores for pass or fail in Search Console.
That distinction matters in client conversations. Sponsors sometimes treat every red Lighthouse metric as a ranking emergency. You can say plainly: vitals come from real Chrome users in the field; FCP and TBT come from lab runs and help explain why a template might fail LCP or INP after the next deploy.
What First Contentful Paint measures
First Contentful Paint records when the browser first paints any text, image, non-white canvas, or SVG from the DOM. It tells you the page has started to render, before the largest element (LCP) finishes.
FCP measures a different moment than LCP. LCP waits for the biggest visible content. FCP records the first visible paint. On a hero-image landing page, FCP might be a headline or skeleton while the image still loads; on a text-heavy article, FCP and LCP are often similar.
Lighthouse and PageSpeed Insights report FCP in milliseconds. Google's lab thresholds match the universal table in our Performance Budget Thresholds Template:
| Rating | FCP (lab) |
|---|---|
| Good | ≤ 1,800 ms |
| Needs improvement | 1,800–3,000 ms |
| Poor | > 3,000 ms |
CrUX does not report FCP the same way it reports LCP, INP, and CLS. You see FCP in lab runs, synthetic monitoring, and developer tools. Agencies track it because scheduled tests return FCP on every run, even when CrUX has little or no data for a new URL.
What Total Blocking Time measures
Total Blocking Time sums main-thread blocking time after First Contentful Paint and before Time to Interactive in a Lighthouse run. A "long task" is any main-thread task longer than 50 ms. TBT adds the portion of each long task above 50 ms during that window.
TBT is a lab metric. It estimates how much the main thread is blocked while the page is still loading and becoming interactive. It does not measure a specific user click; it measures blocking during load and early hydration.
Google's TBT documentation treats the metric as related to, but not the same as, Interaction to Next Paint (INP). INP is a field metric for responsiveness across the visit. TBT is main-thread blocking during load in a controlled lab test. Both often worsen when JavaScript blocks the main thread, especially on pages with many tags, but you can pass TBT in lab and still fail INP on post-load interactions (menus, carts, client-side routes). Our third-party scripts guide explains that difference with examples.
Lab thresholds (same source as the budget template):
| Rating | TBT (lab) |
|---|---|
| Good | ≤ 200 ms |
| Needs improvement | 200–600 ms |
| Poor | > 600 ms |
How FCP relates to LCP in diagnosis
LCP and FCP share parts of the loading path. Slow server response (TTFB), render-blocking CSS, and font loading can hurt both. They differ when the LCP element is a heavy image or video while something lighter renders first.
Typical patterns we see in agency audits:
- FCP poor and LCP poor: slow loading across the page (server, critical CSS, early JavaScript blocking render).
- FCP good, LCP poor: first paint is fast but the hero image or largest block is delayed (image weight, lazy-loading mistakes, CDN cache misses). See image optimisation for LCP.
- FCP good, LCP good, TBT poor: LCP and FCP pass but the main thread is busy; INP may still fail on interactions after load.
When you report to clients, show FCP and LCP for the same URL and device strategy. "FCP improved 400 ms" is useful context when LCP is still poor because the hero image loads slowly.
How TBT relates to INP in diagnosis
INP replaced First Input Delay in March 2024 as the responsiveness Core Web Vital. Teams use TBT in lab when CrUX INP is missing or when scheduled synthetic runs need a comparable number week to week.
Use TBT when:
- you are debugging main-thread JavaScript during load and early hydration;
- you want a budget on marketing sites that share one tag manager across dozens of clients;
- you are comparing lab runs week to week on the same URL and throttling profile.
Fixing TBT does not guarantee an INP pass. Post-load handlers, single-page transitions, and third-party scripts that run after load can hurt INP without changing TBT much. The INP guide covers that gap in detail.
For ecommerce and app-heavy flows, see e-commerce performance monitoring for how we prioritise INP, TBT, and LCP on checkout templates.
When agencies should track FCP and TBT in monitoring
Track vitals first. Add FCP and TBT when they help you catch regressions earlier or explain why LCP, INP, or CLS changed to non-technical sponsors.
Practical cases:
- Content and publishing sites: FCP on article templates shows when a CMS change added render-blocking CSS or a slow web font. LCP on the hero image may change later; FCP often changes first.
- Marketing sites with heavy tags: TBT increases when analytics, chat, or A/B scripts grow without review. One tag change can affect every page using the same container.
- Multi-site portfolios: the same third-party bundle on twelve clients means one regression can raise TBT on every property. Portfolio monitoring reports that without opening PageSpeed Insights for each site.
- Performance budgets in retainers: when clients ask for thresholds beyond LCP, INP, and CLS, FCP and TBT give lab numbers you can enforce on scheduled runs. Copy starter values from the budget thresholds template and mark them provisional for the first month.
In Apogee Watcher, site-level budgets can include FCP and TBT alongside vitals on mobile and desktop strategies. Alerts send when lab results exceed the thresholds you set. That supplements CrUX in test results; it does not replace field INP.
Common causes of poor FCP and TBT
FCP regressions
- Slow TTFB or cold cache on HTML.
- Render-blocking stylesheets and synchronous scripts in
<head>. - Web fonts that delay first text paint (FOIT).
- Large inline critical CSS or server-side work before first byte.
TBT regressions
- Large JavaScript bundles parsed on the main thread during load.
- Long tasks from tag managers loading many vendors at once.
- Framework hydration on top of marketing scripts.
- Synchronous layout or style work before load completes.
The same fixes often help vitals: reduce JavaScript, defer non-critical scripts, split code, and audit third parties. Poor FCP or TBT often means LCP or INP will slip next if you do not fix the underlying issue before CrUX updates.
Lab vs field: what to tell stakeholders
PageSpeed Insights shows lab Lighthouse data and CrUX field data when Google publishes it for the URL. FCP and TBT appear on the lab side only. LCP, INP, and CLS can appear in both, but only field percentiles count for Core Web Vitals pass rates in tools that use CrUX.
A clear client line: "We track FCP and TBT in scheduled lab tests to catch regressions early. We judge SEO page experience on field LCP, INP, and CLS." That matches Google's page experience documentation without treating lab metrics as ranking signals.
For setup across many sites, use the Core Web Vitals monitoring checklist for agencies and automated PageSpeed monitoring setup.
FAQ
Is First Contentful Paint a Core Web Vital?
No. FCP is a Lighthouse lab metric. It shows when the page first renders and often correlates with LCP, but Google does not include FCP in the Core Web Vitals set used for page experience evaluation.
Is Total Blocking Time the same as INP?
No. TBT is a lab metric for main-thread blocking after FCP during load. INP is a field metric for responsiveness across user interactions during the visit. Improving TBT often helps INP when JavaScript blocks the main thread early, but post-load interactions need separate testing.
What is a good FCP score?
In Lighthouse lab terms, FCP at or below 1,800 ms is "good", using the same bands as our performance budget template. Adjust thresholds per site after you record a baseline.
What is a good TBT score?
Lab TBT at or below 200 ms is "good" on the same scale. Sites with heavy JavaScript may need stricter internal budgets even when the public band says "good."
Should we add FCP and TBT to client reports?
Yes, as supporting metrics under the vitals summary, not as replacements. One line each on what changed and whether it points to loading (FCP) or main-thread JavaScript (TBT) is enough for most quarterly reviews.
Does CrUX show FCP and TBT?
CrUX reports Core Web Vitals and related field metrics. FCP and TBT come from lab and synthetic tests. Use scheduled PageSpeed or Lighthouse runs to track them over time.
Can we set performance budgets on FCP and TBT?
Yes. Many teams set provisional FCP and TBT limits per template alongside LCP, INP, and CLS. Tighten after a month of scheduled runs so alerts stay useful.
FCP and TBT are supporting lab metrics beside LCP, INP, and CLS: early render time and main-thread blocking during load. Add them to budgets when they help you explain score changes and catch regressions before CrUX field data updates.
Start a free Apogee Watcher account to schedule PageSpeed tests with vitals plus FCP and TBT budgets across client sites, or run a free domain check on a URL that scored worse in a recent Lighthouse run.
Top comments (0)