Is the host slow, or is the page heavy?

Rather than a single target, compare templates against each other and against previous measurements of the same site. A search results page doing inventory work will legitimately respond slower than a static page, and the useful signal is a template that is much slower than its siblings or than it was last month.

No, and confusing them is why two people can disagree about whether a site is slow. Server response time ends when the first byte arrives. Page load continues through stylesheets, photographs, scripts and rendering, all of which start after that first byte and are governed by what the page contains.

A content delivery network shortens the distance a file travels and can answer for static files without involving the origin. It does not make a slow application respond faster, and an inventory page usually has to be assembled per request, so the visitor still waits for that work. Distance and application speed are separate problems.

Not directly, which is exactly why measuring it matters. It belongs to the website platform provider, so the dealership's job is to establish the number per template, show that one template is unusually slow if it is, and take a specific question instead of a general complaint to the vendor.

Because it does more work per request: filtering stock, checking availability, applying pricing and incentives, often across more than one system. That is legitimate work instead of a defect, and it is still worth knowing, because it means the page shoppers filter on starts later than the one they land on.

Usually less, on a typical dealership website, but it matters first. The response happens before anything else can, so a slow one is added to every other delay on the page. The accumulated tool stack is normally the larger number; the response time is the one that cannot be optimized around.

Enough times, across different hours, that a single cold cache or deployment cannot produce the conclusion. One measurement of one page at one moment is not evidence about hosting, and it is the most common basis on which a dealership decides to change platforms.

Server response time is a component of the wait before the largest visible element appears, because a page cannot paint faster than it arrives. It is not reported as a metric of its own in the shopper-facing set, which is part of why it goes unexamined while everything downstream of it gets optimized.

Only after establishing the number across templates and over time, and after asking the current provider to explain a template that is unusually slow. A migration is the most expensive available response to any speed problem, and response time is the one measurement most often quoted from a single test.

A blank or unchanged screen after they tap. Nothing has arrived yet, so there is no partial page, no spinner from the site itself and nothing to read, which is why a slow response feels worse to a shopper than the same delay spent loading a page that has already started to appear.

Sometimes: caching, a content delivery network, or reducing what the server has to compute for each request can all help before a hosting change is necessary.

Look at Time to First Byte specifically, separate from full page load. A slow server shows up as a slow first byte even before any images or scripts are involved.

Inventory size can, particularly on search-results pages querying a large inventory: how that query is built and cached matters more than the raw number of vehicles.