Definitions of every performance metric Google uses to evaluate page experience — with scoring thresholds, common causes, and how to fix each one. AuditJet measures all of these metrics automatically using Google Lighthouse and Google PageSpeed Insights.
LCP measures how long the browser takes to render the largest visible element in the viewport — typically a hero image or above-the-fold heading. It is one of Google's three Core Web Vitals and a direct search ranking signal.
Good
≤ 2.5s
Needs Improvement
2.5s – 4s
Poor
> 4s
Impact: AuditJet measures LCP automatically on every scheduled audit, alerting your team when a regression pushes your score above the 2.5s threshold and estimating the revenue impact per hour.
What is a good LCP score?
Google considers an LCP of 2.5 seconds or less as "Good". Scores between 2.5s and 4s are "Needs Improvement", and anything above 4s is "Poor". For competitive rankings, aim for under 1.8s on mobile.
Does LCP affect SEO rankings?
Yes. LCP is one of Google's Core Web Vitals and is used as a ranking factor in the Page Experience signal. Pages with "Good" LCP scores may rank higher than equivalent pages with "Poor" LCP, all else being equal.
INP measures the latency of all interactions a user makes with a page — clicks, taps, and keyboard inputs — and reports the worst-case delay observed across the session. It replaced FID as a Core Web Vitals ranking signal in March 2024.
Good
≤ 200ms
Needs Improvement
200ms – 500ms
Poor
> 500ms
Impact: AuditJet tracks Total Blocking Time — Lighthouse's closest lab-based proxy for INP — on every scan, and surfaces Google PageSpeed Insights field data so you can compare lab and real-user INP scores side by side.
What replaced FID in Core Web Vitals?
INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only captured the delay of the first interaction; INP captures all interactions across the session and reports the worst-case delay.
What is a good INP score?
Google considers an INP score of 200ms or less as "Good". Scores between 200ms and 500ms are "Needs Improvement", and anything above 500ms is "Poor". At 500ms+, users notice the lag and may abandon interactions.
CLS measures visual instability — how much page content unexpectedly moves during and after loading. It is one of Google's three Core Web Vitals and a direct ranking signal that also causes real user harm: misclicks, accidental purchases, and abandoned checkouts.
Good
≤ 0.1
Needs Improvement
0.1 – 0.25
Poor
> 0.25
Impact: AuditJet detects CLS regressions as soon as they appear — caused by newly injected banners, missing image dimensions, or font swaps — and sends alerts before the shift causes ranking drops or checkout mis-taps.
What is a good CLS score?
Google considers a CLS score of 0.1 or less as "Good". Scores between 0.1 and 0.25 are "Needs Improvement", and above 0.25 is "Poor". Aim for 0.05 or below on revenue-critical pages to keep shifts imperceptible to users.
What are the most common causes of CLS?
The most common causes are: images loaded without explicit width and height attributes (the browser reserves zero space until the image loads), dynamically injected content such as banners or promotional badges, and web fonts that cause text to reflow when they swap in.
TTFB measures how long the browser waits from making a request to receiving the first byte of the server's response. It is the foundation metric that all other load performance sits on — a slow TTFB adds directly to LCP and every subsequent paint.
Good
≤ 800ms
Needs Improvement
800ms – 1.8s
Poor
> 1.8s
Impact: AuditJet tracks TTFB on every scheduled scan from a fixed test region, giving you a consistent trend line — and flags TTFB regressions that indicate a slow deploy, a new database query, or a caching misconfiguration before they compound into LCP failures.
What is a good TTFB score?
Google considers a TTFB of 800ms or less as "Good". For pages served with edge caching, sub-50ms is achievable. For dynamic server-rendered pages, target under 200ms. Above 1.8s is "Poor" and will directly prevent a passing LCP score.
How does TTFB affect LCP?
TTFB sets the floor for LCP. The browser cannot begin parsing HTML, discovering images, or loading fonts until the first byte arrives. A 600ms TTFB means at minimum 600ms of your LCP score is pure server wait — regardless of how well your frontend is optimised.
FCP measures when the browser renders the first piece of content visible to the user — any text, image, or SVG. It is the earliest signal that the page is loading and a strong predictor of LCP and overall perceived speed.
Good
≤ 1.8s
Needs Improvement
1.8s – 3s
Poor
> 3s
Impact: AuditJet includes FCP in every automated Lighthouse audit and surfaces the waterfall opportunities — render-blocking resources, slow TTFB, and font loading delays — that explain a slow FCP score so you know exactly what to fix.
What is a good FCP score?
Google considers an FCP score of 1.8 seconds or less as "Good". Scores between 1.8s and 3s are "Needs Improvement", and above 3s is "Poor". Targeting under 1s on desktop and under 1.5s on mobile is achievable with proper optimisation.
What is the difference between FCP and LCP?
FCP fires when any content first appears — even a small spinner counts. LCP fires when the largest visible content element finishes rendering. FCP is an early signal; LCP tells you when the page looks meaningfully loaded. LCP is the Core Web Vital and ranking factor; FCP is a supporting diagnostic.
TBT sums the main-thread blocking time caused by long JavaScript tasks between First Contentful Paint and Time to Interactive. It is Lighthouse's primary proxy for interactivity and directly correlates with INP in real-user sessions.
Good
≤ 200ms
Needs Improvement
200ms – 600ms
Poor
> 600ms
Impact: AuditJet reports TBT on every Lighthouse audit as Google's best lab-based predictor of INP, highlighting the specific long tasks and third-party scripts driving the regression so your team can prioritise which bundles to split or defer.
What is a good TBT score?
Google Lighthouse considers a TBT of 200ms or less as "Good". Scores between 200ms and 600ms are "Needs Improvement", and above 600ms is "Poor". For interactive apps with complex state, targeting under 100ms TBT is achievable with proper code splitting.
Is TBT the same as INP?
No. TBT is a Lighthouse lab metric that estimates main thread blocking during page load. INP is a field metric that measures real user interaction latency throughout the session. TBT is a useful predictor of poor INP, but they are different measurements. High TBT usually causes high INP, but reducing TBT alone does not guarantee good INP.
Google's Core Web Vitals are the three metrics used as ranking signals in the Page Experience update: LCP (loading), INP (interactivity), and CLS (visual stability). The other metrics on this page — TTFB, FCP, TBT — are diagnostic tools that help you understand and fix poor Core Web Vitals scores, but are not themselves ranking factors. AuditJet tracks all six metrics across your sites on a schedule, alerting you the moment any Core Web Vital regresses.