Page Speed Analyzer
Enter any web page and get a real server side speed check: response time, page weight, compression, render blocking scripts, and a plain English list of what is actually slowing it down. No account, no signup, no limits.
What this page speed analyzer actually measures, and what it is honest about not measuring
Say this plainly up front, because it matters: this tool is not a Google PageSpeed Insights or Lighthouse clone. It does not open a real browser engine, render your page, execute its JavaScript, or measure Core Web Vitals such as Largest Contentful Paint or Cumulative Layout Shift the way Google’s own Core Web Vitals definitions require, which need an actual rendering pass to observe. What it does is fetch your page’s raw HTML and headers, inspect the structural signals that reliably predict speed problems, and score them. Think of it as a fast, honest first pass, not a replacement for a full audit.
Why this runs on our server, not your browser
Reading the response of a request to a site you do not control is blocked by cross origin resource sharing rules for any script running in a browser. There is no setting a visitor can change to fix that, it is enforced by the browser itself. So this tool routes the request through our own WordPress backend at /wp-json/convertnow/v1/, which is not bound by CORS because the fetch happens server to server. The URL you submit, along with the URLs of scripts, stylesheets, and images found on that page, is sent to and processed by our server to complete the analysis.
/wp-json/convertnow/v1/fetch?url=... retrieves the page’s HTML plus response timing and headers, including time to first byte and the Content-Encoding and Cache-Control headers.
DOMParser to count scripts, stylesheets, and images, flag which scripts and stylesheets in the head lack async or defer and would therefore block rendering, and check for a title tag, meta description, and viewport tag.
/wp-json/convertnow/v1/check-batch, which fetches each one server side and reads its Content-Length header to estimate total page weight without downloading the full page in the browser.
Scoring reference
| Check | Points | What passes |
|---|---|---|
| Server response time | 20 | Time to first byte under 600ms |
| Response compression | 15 | Content-Encoding header shows gzip, brotli, or deflate |
| Total page weight | 15 | 500KB or less across HTML plus measured resources |
| Render blocking resources | 15 | No head scripts or stylesheets without async, defer, or a non screen media query |
| Image attributes | 15 | Width, height, and alt text set on images, which prevents layout shift |
| Basic head tags | 10 | Title tag (4), meta description (3), viewport tag (3) |
| Caching headers | 10 | A Cache-Control header present on the main response |
The gap between this and a full Lighthouse audit
What this catches well
Missing compression, missing cache headers, oversized unoptimized pages, render blocking script placement, and missing SEO fundamentals are all structural and show up reliably in raw HTML and headers.
What only a real browser audit catches
Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint, and actual JavaScript execution time all require a rendering engine measuring real paint events, which is exactly what Lighthouse and Chrome’s User Experience Report provide and this tool does not attempt to replicate.
- web.dev Core Web Vitals is Google’s own definition of LCP, INP, and CLS, the metrics this tool does not measure.
- PageSpeed Insights runs actual Lighthouse audits against real Chrome rendering and field data, worth pairing with this tool for a fuller picture.
- RFC 9111 defines the Cache-Control header this tool checks for.
- RFC 9110 covers the Content-Encoding and Content-Length headers used in the weight and compression checks.
Performance work this guides
A quick pre launch sanity check before pointing a real Lighthouse audit at a site, catching a missing Cache-Control header or forgotten compression setting after a server migration, comparing two candidate hosting configurations by their raw response headers, and a fast first look at a competitor’s or client’s site structure without waiting on a full browser based audit tool to spin up.
FAQ: Page Speed Analyzer
No, and this tool does not claim to be. It checks server response time, compression, page weight, and HTML structure from our server. It does not render the page in a real browser or execute JavaScript, which is a meaningful part of what Google’s tool measures, so treat this as a fast, focused first check rather than a replacement.
Browsers block a page from reading another site’s content directly for security reasons. Fetching from our server also gives a more consistent result, one that reflects the target page rather than your own connection speed or browser setup.
Check the individual checks below the score. Common causes are missing compression, render blocking scripts sitting in the head without async or defer, images without width and height attributes, or a slow server response time.
It checks up to the first 40 scripts, stylesheets, and images referenced in the HTML. That is enough to estimate total page weight and resource counts accurately for almost any page without slowing the check down.
No. The tool fetches pages the same way an anonymous visitor would, so anything behind a login wall will not return meaningful results.
From the blog
How the web actually moves
DNS, TLS, headers and the hops between a click and a page.
