WEBSITE & CONVERSION

Website Performance & UX Signals Score

Paste any public page. We measure the real time-to-first-byte and payload size for that exact request, then run deterministic checks for render-blocking resources, layout-shift risk, and third-party weight — not a simulated Lighthouse score.

Performance Signals Guide

What This Actually Measures

Real Core Web Vitals (LCP, INP, CLS) require rendering a page in an actual browser and simulating a real session - that's what Lighthouse and Chrome's CrUX dataset do, and it isn't something a public, rate-limited tool can run per request without becoming an abuse vector. Instead, this measures what a single real HTTP request can honestly tell you.

Network & Delivery

The one category built from real measured numbers: the actual time-to-first-byte and payload size for this exact fetch, plus whether the response is compressed and carries a Cache-Control header - all read directly off the real HTTP response.

Render-Blocking Resources

Counts <script> tags in <head> with no async/defer/type="module" (each one pauses HTML parsing until it downloads and executes), render-blocking stylesheets, and whether preconnect/dns-prefetch hints exist for third-party origins the page depends on.

Layout Stability Risk

Checks whether images and iframes declare width/height or aspect-ratio (letting the browser reserve their space before they load - the single most common cause of layout shift) and whether web fonts use font-display: swap so text doesn't stay invisible while a font downloads.

Third-Party Weight

Counts third-party <script> tags and the distinct external origins they come from - each one is a DNS lookup, a connection, and a chunk of JavaScript the browser has to fetch and run before the page is fully interactive.

Known Limitations

This is an honest boundary, not a hidden one:

  • This does not measure real LCP, INP, or CLS - those require rendering the page and timing actual paint/input events, which this tool deliberately doesn't do. Use PageSpeed Insights for lab/field Core Web Vitals data.
  • The measured TTFB reflects the network path from our server to yours for one request, not a real visitor's device, connection, or geography - it's a real number, just not necessarily representative of every visitor.
  • Subresource load time (images, CSS, JS, fonts actually downloading) isn't measured - only the initial HTML response and what its markup implies about likely bottlenecks.

Frequently Asked Questions

Why isn't this the same score as Google PageSpeed Insights?

PageSpeed Insights renders your page in real Chrome and measures actual paint/input timing (lab data) plus real visitor data (CrUX field data). This tool measures one real network request plus deterministic static-HTML proxies for the same underlying problems - a different, narrower kind of signal, not a replacement.

Why does TTFB matter so much?

Everything else - parsing, rendering, script execution - can only start after the first byte arrives. A slow TTFB delays every other performance metric by the same amount, no matter how optimized the rest of the page is.

Is my URL stored anywhere?

No. The URL is fetched, analyzed in memory, and the result is returned to your browser - nothing is written to a database.

Why can't I check a localhost or internal URL?

Allowing arbitrary internal addresses would let anyone use this tool to probe private networks from our server (a class of vulnerability called SSRF). Only URLs that resolve to public IP addresses are accepted.

UI Pirate Ecosystem

Suggested Tools for Your Stack

Explore related utilities in this workflow or discover cross-category tools.

View All Tools →