scan.now
Premium Scan a site

Measure Website Response Time and HTML Delivery

Enter a public page. Scan.now measures its response time, HTML size and render-blocking scripts to provide a fast initial-delivery baseline.

Enter the exact public page to inspect. No form is submitted and no data is modified.

A registered account is required to run this test. Finding status, evidence, affected locations and remediation are Premium-only. How active scanning works · Acceptable use

What an initial-delivery baseline tells a webmaster

Before a browser can render a page, the server must answer, the HTML must transfer, and parser-blocking scripts in the document head must run or download. Slow initial response, oversized HTML and too many blocking scripts make every later optimisation start from behind.

Scan.now records the server response time observed by its scanner, the returned HTML byte size and the number of external head scripts without async or defer. It is deliberately a server-delivery baseline, not a synthetic-browser Core Web Vitals test, so the report does not pretend to measure LCP, INP or CLS.

Put this result in context

This scanner answers one part of the review. Continue with SEO Audit for crawl, titles, links, speed, structured data, then Accessibility Scanner for language, alternative text, labels, names and headings. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.

For the background behind these signals, read Website Security: What a Vulnerability Scan Looks For and How to Fix It and What Is a Vulnerability Scan? Types, Limits and What the Results Mean. The Web performance baseline check reference explains the exact test, evidence and remediation used in the report. The Scan.now methodology explains request limits, scan boundaries and what the scanner deliberately does not attempt.

Response time, HTML size and blocking scripts

The check is deliberately bounded to the signals below.

Coverage areaWhat the scanner examines
Initial response timeThe elapsed time for the entered HTML request is compared with a practical baseline threshold.
HTML transfer sizeThe response body size highlights pages shipping unusually large documents before images, CSS and scripts are considered.
Parser-blocking scriptsExternal scripts in the head without async or defer are counted as potential render blockers.

Threshold results and measurement variability

A scan result is evidence with a boundary, not a guarantee about every route.

Threshold exceeded

At least one baseline is high: response over 800 ms, HTML over 2.5 MB or more than five parser-blocking scripts.

Within baseline

The initial delivery measurements are within those broad thresholds. Browser rendering and real-user responsiveness may still be poor.

One observation

Network route, cache state and server load affect the result. Confirm trends with repeated regional and real-user measurements.

Faster server work and a leaner critical path

Use the recommendations below to address confirmed findings and strengthen the surrounding control.

  1. Measure server work first

    Trace application, database and upstream timings; cache stable output and remove serial calls on the critical request path.

  2. Keep HTML purposeful

    Paginate large lists, avoid duplicated inline state and move non-critical data behind later requests.

  3. Defer non-critical scripts

    Use defer for ordered application scripts, async for independent scripts and remove third parties that do not justify their cost.

  4. Use CDN and compression correctly

    Cache public responses near users and enable Brotli or gzip while varying safely by the headers that change content.

  5. Add real-user monitoring

    Collect Core Web Vitals by page type and device so optimisation follows actual user delay rather than a single lab number.

How it works

  1. Enter the page

    Use a representative URL and repeat across the templates that matter to users.

  2. Initial delivery is measured

    Response time, HTML bytes and parser-blocking head scripts are collected from one bounded request.

  3. Confirm with field data

    Use the baseline to find obvious server and document costs, then validate browser experience with Core Web Vitals.

What this tool checks

1 checks across 1 areas. Each links to its reference page with the test, the risk and the fix.

Full reference

Page content and JavaScript

1 check

The ones that most often decide the grade:

Medium Web performance baselineThe initial response is slow, oversized or contains many parser-blocking scripts.

Related tools

Continue the review with four checks that cover adjacent parts of the same attack surface.

All tools
Websites SEO & Site Health Audit

Crawl, titles, links, speed, structured data
Active Security Website Accessibility Scanner

Language, alternative text, labels, names and headings
Websites Website Vulnerability Scanner

Headers, TLS, cookies, exposed files
Websites JavaScript Library Vulnerability Scanner

Outdated libraries with known CVEs

Guides for this tool

Background reading written to go with these results.

13 min read · Updated Sep 13, 2026 Website Security: What a Vulnerability Scan Looks For and How to Fix It

A website vulnerability scan checks the parts of a site an attacker can reach without logging in: Transport security, HTTP headers,...

Read the guide
8 min read · Updated Sep 12, 2026 What Is a Vulnerability Scan? Types, Limits and What the Results Mean

A vulnerability scan checks a system against a list of known weaknesses and reports what matches. The types of scan, the difference...

Read the guide
8 min read · Updated Sep 14, 2026 Passive vs Active Scanning: What Each Can Find and When Each Is Appropriate

Passive scanning observes normal responses; active scanning sends crafted requests to trigger flaws. The boundary, why it matters...

Read the guide
9 min read · Updated Sep 18, 2026 How to Read a Security Scan Report: Severity, False Positives and What to Fix First

A scan report is a list of findings with severities, and the hard part is deciding what matters. How severities are assigned, how to...

Read the guide

Frequently asked questions

Is this a Core Web Vitals test?

No. It does not render the page, so it cannot measure LCP, INP or CLS. It measures three earlier delivery conditions that strongly influence how quickly rendering can begin.

Why might my response time change between scans?

Cache state, deployment load, upstream services and the network route all vary. Treat one run as a diagnostic and repeated runs as the beginning of a trend.

Are all scripts in the head bad?

No. Small critical scripts can belong there. The concern is external parser-blocking work that delays HTML parsing without being necessary for the first view.

Does a CDN always make a site faster?

Only when responses are cacheable and the CDN can serve them near users. Uncacheable dynamic HTML still depends on origin and application time.