Website Load Time: Measure It Correctly

Load time is a family of measurements. Define the user event, collect it under repeatable conditions, and keep lab diagnostics separate from real-user trends.

Start with a baseline: Use the free Page Speed Checker for a Lighthouse run and conditional URL-level CrUX data. Save the raw values and test context before changing the page.

Define the event before measuring it

A browser can receive the first response byte, paint text, render the main content, respond to an interaction, and finish late network work at different times. Calling every event "load time" hides the actual failure.

Metric	Represents	Boundary
TTFB	Navigation request to first response byte	Foundational, outside the Core Web Vitals set
FCP	The browser's first DOM content paint	Can occur well before the main content
LCP	The largest visible content element	A field Core Web Vital for loading experience
INP	Interaction latency across the visit	Needs real interactions; Lighthouse uses lab diagnostics such as Total Blocking Time
CLS	Unexpected visual movement	Measures stability rather than elapsed load time
Load event	Completion of load-dependent resources	Late resources can extend it after the page is usable

Use current field thresholds

Google evaluates Core Web Vitals at the 75th percentile of page visits. Good means LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less. PageSpeed Insights also reports experimental field TTFB with 0.8 seconds or less in the Good bucket. web.dev describes that TTFB value as a rough guide because delivery architecture changes the tradeoff.

These thresholds classify specific field metrics. They do not create a universal target for total load time, and one green value cannot compensate for a separate failing vital.

Build a repeatable lab protocol

Select representative URLs. Cover a content template, a high-intent landing page, and the critical application journey.
Pin conditions. Record device mode, network profile, region, tool version, cache state, authentication, and consent.
Run several samples. Store each result and compare the median plus spread.
Keep cold and warm paths distinct. A cached repeat visit answers a different question from a first navigation.
Save raw evidence. Keep the Lighthouse artifact, commit SHA, and release annotation.

Pair lab tests with a real-user baseline

PageSpeed Insights uses CrUX for eligible experiences over the previous 28 days. It reports URL-level data when enough samples exist, can fall back to the origin, and may show no field data when coverage is insufficient. That window moves more slowly than a lab result after deployment.

Layer	Cadence	Store	Decision
Release lab check	Performance-sensitive deploys	Raw metrics, diagnostics, environment, commit	Investigate a reproducible regression
CrUX trend	Regular operating review	28-day p75 LCP, INP, CLS, and coverage level	Prioritize templates affecting real users
First-party RUM	Continuous when instrumented	Distributions by device, region, template, and release	Find segments hidden by aggregate data
Synthetic journey	Business-risk dependent	Availability and critical-path step timing	Detect a degraded transaction

Diagnose the layer that owns the delay

High TTFB: inspect redirects, cache behavior, server work, geographic distance, and document delivery.
High LCP with acceptable TTFB: inspect resource discovery, images, render-blocking work, fonts, and main-content rendering.
High INP: inspect long main-thread tasks, event handlers, rendering work, and third-party JavaScript.
High CLS: inspect media dimensions, ads, embeds, font swaps, and late content insertion.

Use the page speed test guide for interpretation. Use the site speed optimization guide after the evidence identifies a layer.

Keep Search and AI outcomes separate

Google says Core Web Vitals are used by ranking systems, while relevance can outweigh page experience and strong tool results do not guarantee high rankings. No cited first-party source establishes a page-speed threshold that causes an AI engine to cite a page. Use an AI Visibility Check for prompt-level mentions and citations.

Frequently asked questions

What is a good website load time?

Start by naming the metric. Google classifies field LCP of 2.5 seconds or less at the 75th percentile as good. That threshold does not describe total load time, TTFB, or every point in the journey. Track the metric that represents the user-visible problem.

Is TTFB a Core Web Vital?

No. TTFB is a foundational metric that precedes later rendering work. web.dev gives 0.8 seconds or less as a rough good guide and stresses that delivery architecture matters. A server-rendered page can have a different TTFB tradeoff from a client-rendered application.

How do I measure load time consistently?

Fix the URL, device profile, network conditions, test region, cache state, and tool version. Run several lab tests and compare a median or distribution. Keep field data separate because PageSpeed Insights summarizes eligible CrUX experiences over the previous 28 days.

How often should I review website performance?

Run lab checks when releases change performance-sensitive code or assets. Review field trends on a cadence that matches release volume and business risk. Annotate deploys and incidents so a shift can be connected to evidence.

Does a faster page guarantee more AI citations?

No measured speed threshold guarantees a mention or citation from an AI engine. Speed testing finds user-experience and delivery defects. Prompt-level AI Visibility monitoring measures mentions, citations, sentiment, competitors, and share of voice.

Sources & Further Reading

Fundamentals: Learn about GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) (the two frameworks for optimizing your content for AI search engines).