AnyTool
Your files never leave your device. All processing happens locally in your browser.

How can I check a page’s performance from its HTML without uploading the page to a server?

Open AnyTool’s Page Speed Estimator, open your page and copy its HTML source (View Source / Ctrl+U), and paste it in. The tool parses the markup in your browser with the built-in DOMParser and flags the performance problems you CAN read from HTML: render-blocking <script> in the head without async/defer, render-blocking external stylesheets, too many scripts or third-party domains, <img> missing width/height (a Cumulative Layout Shift risk) or missing loading="lazy", heavy inline CSS/JS, a large DOM element count, a missing responsive viewport meta and missing preconnect/preload hints. You get a heuristic static optimization score + grade, a resource inventory and prioritized fixes grouped by area. Everything runs locally, so your page HTML is never uploaded — safe for staging or unreleased pages. Be clear about scope: this is a STATIC HTML check, NOT a real speed measurement — real Core Web Vitals (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1) and load time depend on the network, server, JavaScript execution, real image sizes, the CDN, the device and the rendered page, so use Google PageSpeed Insights (CrUX field data) and Lighthouse in Chrome DevTools for real numbers.

  • Paste your page’s HTML source — the tool inspects the markup for obvious performance problems
  • Flags render-blocking head scripts / stylesheets, too many scripts & third-party domains
  • Flags <img> missing width/height (CLS risk) or loading="lazy", large DOM, missing viewport meta
  • Heuristic static optimization score + grade, resource inventory and prioritized fixes
  • 100% client-side — page HTML never uploaded; honest that it is a static pre-check, NOT a real speed test

What is

Static page-speed check (HTML markup analysis)

A static page-speed check inspects a page’s HTML markup for the performance signals that are visible without loading or rendering the page — render-blocking scripts and stylesheets, resource counts, images missing dimensions or lazy-loading, inline CSS/JS weight, DOM element count, the mobile viewport meta and resource hints. It is distinct from a real speed measurement, which requires actually loading the page: Lighthouse (lab data) in Chrome DevTools runs a synthetic load, and Google PageSpeed Insights reports CrUX field data (real Chrome users over a 28-day rolling window, at the 75th percentile) which Google uses for ranking. Core Web Vitals — Largest Contentful Paint (LCP, target ≤ 2.5 s), Interaction to Next Paint (INP, ≤ 200 ms) and Cumulative Layout Shift (CLS, ≤ 0.1) — can only be measured from a loaded, rendered page, not from static HTML. A static check is therefore a quick pre-check for obvious markup issues, not a substitute for those tools.

SEO & Web

Related terms

Core Web VitalsLCPINPCLSRender-blocking resourcesLighthousePageSpeed InsightsCrUXLazy loadingDOM size

Frequently Asked Questions

No. It reads your HTML markup for obvious performance problems but does not load or run the page, so it cannot measure real speed, load time or Core Web Vitals. Use PageSpeed Insights and Lighthouse for real numbers.

This is a STATIC HTML check, not a real speed measurement. It inspects the markup for signals like render-blocking scripts, missing image dimensions and a large DOM, but real Largest Contentful Paint (target ≤ 2.5 s), Interaction to Next Paint (≤ 200 ms) and Cumulative Layout Shift (≤ 0.1) — and actual load time — depend on the network, the server, JavaScript execution, the real byte size of your images, the CDN, the user’s device and the fully rendered page, none of which is knowable from HTML alone. For real numbers, use Google PageSpeed Insights (which reports CrUX field data from real Chrome users) and Lighthouse in Chrome DevTools (lab data), plus WebPageTest. Treat this tool as a quick pre-check for markup issues, not a score to optimize toward.

Render-blocking head scripts/stylesheets, too many scripts and third-party domains, images missing width/height or lazy-loading, heavy inline CSS/JS, a large DOM, and a missing viewport meta or preconnect/preload hints.

Plenty of performance issues live in the markup. From HTML you can spot synchronous <script src> in the head without async/defer and render-blocking external stylesheets (the classic causes of a slow first paint and LCP), the sheer number of scripts, stylesheets, images, iframes and third-party script domains, <img> tags missing width/height (the No.1 cause of layout shift / CLS) or missing loading="lazy" on off-screen images, oversized inline <style> and <script> blocks, a large DOM element count (Lighthouse warns above ~800 nodes and errors near ~1,500), a missing responsive viewport meta, and missing preconnect/preload resource hints. This tool checks all of those and groups the findings by area with a specific fix for each.

Your browser can’t fetch most live URLs (cross-origin / CORS) and there is no server proxy, so paste the page source. That also keeps your page private and works for staging or unreleased pages.

Because the tool is 100% client-side with no server proxy — which is what keeps your page private — your browser can only fetch pages that explicitly allow cross-origin requests (CORS) or are on the same origin. Almost all live sites block that, so the reliable path is to open your page, use View Source (Ctrl+U), copy the HTML and paste it in. The optional “try to fetch” box is there for the rare CORS-enabled case; when it fails it tells you to paste the source instead. Nothing you paste is ever uploaded, so it is safe for staging, unreleased or internal pages.

It is a heuristic 0–100 grade of your markup only — it is NOT a Lighthouse or PageSpeed score. Use it to catch obvious markup problems, not as a number to chase.

The static optimization score starts at 100 and deducts points for each warning and each serious issue found in the markup, then maps to an A–F grade. It reflects only the HTML signals the tool can see — render-blocking resources, image dimensions, DOM size, inline weight, mobile viewport and so on — and deliberately says it is NOT a Lighthouse or PageSpeed Insights score. Two pages with identical HTML can have very different real Core Web Vitals depending on the network, server, images and device, so treat the score as a quick markup pre-check. For a number that reflects real user experience, run PageSpeed Insights and Lighthouse on the loaded page.

Detailed Explanation

How It Works

What the Page Speed Estimator Checks From HTML

The Page Speed Estimator is a STATIC HTML performance pre-check: the user pastes a whole page’s HTML source (View Source / Ctrl+U) and the tool parses it in the browser with the built-in DOMParser to flag the performance problems that are visible in the markup — without loading or running the page. It inspects: render-blocking <script src> in the <head> without async/defer (and non-module) and render-blocking external stylesheets, the classic causes of a slow first paint and Largest Contentful Paint; the number of scripts, stylesheets, images and iframes; the number of distinct third-party script domains (each adds DNS/TLS/connection cost); <img> tags missing width/height (the leading cause of Cumulative Layout Shift) or missing loading="lazy" on off-screen images; the byte size of inline <style> and <script> blocks (measured with TextEncoder) and of the whole HTML document; the total DOM element count (Lighthouse warns above ~800 nodes and flags near ~1,400–1,500); the responsive viewport meta; and preconnect / dns-prefetch resource hints. It returns a heuristic 0–100 static optimization score with an A–F grade, a resource inventory, and findings grouped by area (Render-blocking, Scripts, Images, Layout-stability, Assets, Mobile) with a specific fix for each. Everything runs on the user’s device — the pasted HTML is never uploaded.

  • Paste your page HTML source; parsed locally with the built-in DOMParser
  • Flags render-blocking head scripts (no async/defer) and render-blocking stylesheets
  • Flags <img> missing width/height (CLS) or loading="lazy"; counts scripts, styles, images, iframes, 3rd-party domains
  • Measures inline CSS/JS bytes (TextEncoder), HTML size and DOM element count
  • Heuristic static optimization score + grade with prioritized fixes grouped by area — no server, no CDN, no upload
Methodology

How the Static Optimization Score Is Computed

The engine (pageSpeedEngine.ts) parses the pasted HTML with a DOMParser and walks the document to build a resource inventory and a list of findings, each carrying a severity (good / warn / bad), an area, a short message, a representative count and a recommendation. Render-blocking is checked against the &lt;head&gt;: external scripts without async/defer (and not type="module") are blocking, and external stylesheets without a print/lazy media trick are blocking. Script and third-party-domain counts are graded against thresholds (e.g. >8 scripts warns, >15 fails; >4 third-party domains warns). Images are checked for explicit width/height (via attribute or inline style) — missing dimensions are graded as a layout-stability (CLS) risk — and for loading="lazy" when there are enough images. Inline CSS/JS and HTML byte sizes are measured with TextEncoder and graded against KB thresholds. The DOM element count is graded against Lighthouse’s ~800 (warn) and ~1,500 (error) guidance. The viewport meta and preconnect/dns-prefetch hints are checked for presence and correctness. The static optimization SCORE starts at 100 and deducts 12 points per serious (bad) finding and 6 per warning, clamped to 0–100, then maps to an A–F grade; findings are sorted bad → warn → good so the most important fixes surface first. The score reflects ONLY these markup signals — it is explicitly not a Lighthouse or PageSpeed Insights score.

  • DOMParser walks the document; each finding has severity, area, count and a fix
  • Render-blocking = head <script src> without async/defer/module, or blocking stylesheets
  • Thresholds grade script/third-party counts, inline & HTML bytes (TextEncoder), DOM size (Lighthouse ~800/~1,500)
  • Score starts at 100, −12 per bad, −6 per warn, clamped 0–100, mapped to an A–F grade
  • Findings ordered bad → warn → good; the score is NOT a Lighthouse / PageSpeed score
Limitations

A Static Markup Check — Not a Real Speed Measurement

The tool is emphatic about its scope. It is a STATIC HTML check, NOT a real speed measurement: it reads the markup but does not load, render or run the page, so it CANNOT measure real load time or Core Web Vitals. Real Largest Contentful Paint (target ≤ 2.5 s), Interaction to Next Paint (≤ 200 ms) and Cumulative Layout Shift (≤ 0.1) — and true load time — depend on the network, the server, JavaScript execution, the real byte size of the images (which HTML does not reveal), the CDN, the user’s device and the fully rendered page, none of which is knowable from HTML alone. The static optimization score is therefore a heuristic based only on markup signals and is deliberately labelled NOT a Lighthouse or PageSpeed Insights score — two pages with identical HTML can have very different real Core Web Vitals. For REAL numbers the tool points to Google PageSpeed Insights (which reports CrUX FIELD data — real Chrome users over a 28-day rolling window at the 75th percentile, the data Google actually uses for ranking), Lighthouse in Chrome DevTools (LAB data from a synthetic load) and WebPageTest. It is also honest about fetching: because the tool is 100% client-side with no server proxy (which keeps your page private), the browser can only fetch CORS-enabled or same-origin URLs, so the reliable path is to paste the page source. In short: use this as a quick pre-check for obvious markup issues, not a score to optimize toward.

  • Static markup check — does NOT load/render the page, so it cannot measure real speed or Core Web Vitals
  • Real LCP (≤2.5s) / INP (≤200ms) / CLS (≤0.1) need a loaded page; image real sizes aren’t in HTML
  • Score is a heuristic, explicitly NOT a Lighthouse / PageSpeed Insights score
  • For real numbers: PageSpeed Insights (CrUX field data, P75), Lighthouse (lab), WebPageTest
  • No server proxy → browser can’t fetch most live URLs (CORS); paste your page source
Privacy & Security

Why a Client-Side Speed Pre-Check Is a Privacy Win

Online speed tools send your page — or a URL they crawl server-side — to a remote service. The Page Speed Estimator instead runs entirely on the user’s device: the pasted page HTML is parsed with the built-in DOMParser and inspected with plain JavaScript, nothing is fetched, uploaded, logged or stored, and no page is crawled (there is deliberately no server proxy). That makes it safe to pre-check STAGING, UNRELEASED or INTERNAL pages whose source you do not want to expose to a third-party service before launch. It works offline once cached as a PWA, and closing the tab discards everything entered. It adds no new dependency: all logic lives in a small, pure, well-typed engine (pageSpeedEngine.ts) that uses only DOMParser and TextEncoder, with a matching page component that provides a static-optimization-score gauge, a resource inventory, grouped findings and a copyable report, dark mode and mobile support with a sticky analyze / copy bar.

  • Page HTML is parsed locally with DOMParser and never uploaded — no server, no CDN, no crawl, no proxy
  • Safe for staging / unreleased / internal pages, unlike online speed tools
  • Works offline once cached; closing the tab discards your data
  • No new dependency — engine uses only DOMParser + TextEncoder (pageSpeedEngine.ts)
  • Dark mode and mobile support with a sticky analyze / copy bar and a copyable report
Static HTML speed pre-check: in-browser (AnyTool) vs online speed tools
CapabilityAnyToolTypical online speed tools
ProcessingRuns entirely in your browserSends your page / URL to a server
Your pageHTML never uploaded, works offlinePage or URL crawled server-side
Staging / unreleased pagesSafe — nothing leaves the deviceExposed to a third-party service
InputPaste your page HTML source (View Source)Usually a live URL the tool loads
What it measuresStatic markup signals only (a pre-check)Real load + Core Web Vitals (lab / field)
ChecksRender-blocking, images/CLS, scripts, DOM, mobileFull lab run + often field data
HonestyClear it is NOT a real speed test — use PSI/LighthouseReports a real (or implied-authoritative) score
Cost / signupFree, no signupOften gated or rate-limited

AnyTool checks a page’s markup for obvious performance problems locally from pasted HTML and uploads nothing, which is safe for staging or unreleased pages. It is a STATIC pre-check, NOT a real speed measurement — real Core Web Vitals (LCP/INP/CLS) and load time need a loaded, rendered page and are only measured by Google PageSpeed Insights (CrUX field data), Lighthouse (lab data) and WebPageTest, so confirm there. Comparison as of July 2026.