Page Speed Test

Free SEO Utility

Page Speed Test

Run a free page speed test on any URL: real server response time (TTFB), total page weight across HTML/CSS/JS/images/fonts, request count, gzip compression, browser caching, and render-blocking resources - rolled into a 0-100 speed score so you know exactly what to fix first.

Real TTFB & Page Weight
Measured, not estimated
8-Signal Speed Score
0-100 with a letter grade
Every Linked Resource
CSS, JS, images & fonts sized up
SSRF-Hardened & Rate-Limited
10 free tests/day

Enter a Page URL to Test

We'll fetch the live page and every resource it links to
Try it:
10 of 10 tests left today

Enter a page URL above and click "Run Page Speed Test" to see its live response time, page weight, and full speed score.

A page speed test measures how quickly a specific URL responds and how much it costs a browser to load - not by rendering pixels, but by making the same request a browser makes and inspecting the real response and every resource it links to. Enter a URL above and this tool runs that test directly: it times the server's response, downloads the HTML, then checks every stylesheet, script, image, and font the page references for its real transferred size. What comes back is a full breakdown - response time, total page weight, request count, compression, caching, render-blocking resources, image handling, and minification - plus a 0-100 score so you know exactly where the page stands and what to fix first.

Who This Page Speed Test Is For

This tool is built for anyone who needs a fast, concrete read on a page's speed without installing anything: SEO consultants running a technical audit, developers checking a page before and after a performance fix, agencies including a speed test in client QA, and site owners trying to figure out why a page feels slow. It's one of AudEsto's free SEO utilities - no account is needed to test page loading speed.

How to Test Your Page Loading Speed

  1. Enter the URL. Paste the full address of the page you want to test, including the protocol (https://).
  2. Verify you're human. Click Run Page Speed Test and complete the quick reCAPTCHA check - this keeps the tool from being scripted and abused, so it stays free and fast for everyone.
  3. Read the score. The score ring shows the 0-100 result and letter grade, with response time, page weight, and request count summarized right beside it.
  4. Work through the opportunities. Each flagged signal is explained in plain language and ranked by how many points it's costing, so you fix the highest-impact issue first - then run the test again to confirm it worked.

Each browser or IP gets a set number of tests per day. That's enough to test a handful of key pages in one sitting - usually the homepage, top landing pages, and any template that generates many URLs at once, since a fix on one template page typically applies to every page built from it.

How the Test Works

Under the hood, the test requests the page directly - explicitly asking for gzip/deflate compression, since a plain request without that header often gets an uncompressed response even from a server that fully supports compression, which would otherwise produce a false "not compressed" reading. It times the connection precisely: how long until the first byte of the response comes back (TTFB) versus how long the rest of the body takes to download. It then parses the HTML for every <link rel="stylesheet">, <script src>, <img>, and font resource, and sends a lightweight HEAD request to each one (up to 40 resources per test) to read its real size from the Content-Length header, without downloading the full file.

Honest limitation: this test measures the same resources a server-side fetch can see - it does not render the page in a browser engine, so it can't report paint or layout-shift timings the way Google PageSpeed Insights does. What it does report - response time, transferred weight, request count, compression, and caching - comes from a real request/response pair, not an estimate.

What Each Result Means

  • The score ring shows the 0-100 total and letter grade, with a one-line summary of how many opportunities were found versus checks passed - use it to confirm a change actually moved the number after you test again.
  • The stat row surfaces server response time, download time, total page weight, request count, redirects, and DOM element count - the numbers most people ask about first.
  • Opportunities lists every signal that isn't scoring full points, sorted so the highest-impact fix appears first, each with a plain-language explanation of what to change.
  • Passed checks are collapsed by default to keep the page focused on what's actionable - expand the panel to confirm what's already working well.
  • The resource breakdown shows how much of the page's weight comes from the HTML document itself versus stylesheets, scripts, images, and fonts, so you can see exactly where the bytes are going.

Why Web Page Loading Speed Matters for SEO

Google confirmed page speed as a desktop ranking signal in 2010 and extended it to mobile search in 2018, and Core Web Vitals - metrics like Largest Contentful Paint that are directly influenced by server response time and page weight - are now a documented part of Google's Page Experience factors. That's a direct ranking effect. Separately, and often more consequential in practice, is the indirect effect: slower pages measurably increase bounce rate and reduce conversion rate, which shapes user behavior regardless of what any algorithm rewards. Some of what this test measures is diagnostic rather than either of those - a missing Cache-Control header, for example, doesn't move rankings by itself, but it's a reliable signal that a server's configuration hasn't been tuned, which is usually worth fixing on its own merits.

How to Speed Up Web Page Loading Time

Work through fixes roughly in the order this test weights them:

  • Server response time (20 points). An overloaded host, no server-side caching, or a database query running on every request are the usual causes. A CDN, a caching layer, or a faster host are the typical fixes - and none of them touch the page's design.
  • Page weight (20 points). Compress and correctly size images first; they're the most common source of a heavy page. Trim unused CSS/JS after that.
  • Render-blocking resources (15 points). Add async or defer to non-critical scripts (analytics, chat widgets, ad tags) sitting in <head>.
  • Request count, compression, caching, images, minification (35 points combined). Turning on gzip/Brotli compression and setting Cache-Control headers are usually one-line server config changes with an outsized return.

How to Improve Page Loading Speed: A Worked Example

Example: a mid-size blog post URL
Result

Score of 58/100 (D): TTFB came back at 950ms (11/20), page weight measured 3.1MB (6/20) driven almost entirely by four uncompressed PNG hero images, and 6 render-blocking scripts sat in <head> with no async/defer (2/15).

What it means

The single biggest fix is the images - converting those four PNGs to WebP and adding proper width/height attributes would likely move page weight from "heavy" to "reasonable" in one change, and cut the image-optimization penalty too.

Recommended action

Compress and convert the hero images first (highest points for the least effort), then add defer to non-critical scripts in <head>, then address server response time separately - it likely needs server-side caching or a lighter backend, a different fix entirely from the other two.

Real-World Use Cases

  • Pre-launch and post-migration checks. Confirm a redesign or CMS migration didn't quietly regress response time or page weight on key templates.
  • Agency QA checklists. Add a page speed test alongside meta tag, heading, and broken-link checks before a client site goes live.
  • Before/after verification. Test, make one change - compress images, enable compression, add caching headers - and test again to see the score move.
  • Template and theme validation. Test one representative page from a template; a fix there (like adding defer to a shared script) usually applies to every page built from it.
  • Host and CDN comparisons. Test the same page's speed before and after switching hosting providers or CDN configuration to see the real, measured difference.

Common Mistakes to Avoid

  • Chasing the score instead of the cause. A 20-point jump in page weight from compressing one image is a real fix; padding the score without addressing the underlying cause (a still-overloaded server, still-uncompressed responses) doesn't hold up under real traffic.
  • Fixing images but ignoring the server. A beautifully optimized page still loads slowly if the server itself takes a second or more to respond - the two are independent problems with independent fixes.
  • Adding defer/async everywhere without testing. Deferring a script that other code depends on running first can break functionality - test the page after each change, not just re-run the speed test.
  • Assuming one URL represents the whole site. A homepage and a deep product page on the same site can have very different weight profiles - test more than one page type before drawing conclusions about the site as a whole.

Expert Recommendations

Fix in the order the score weights things: server response time and page weight first (20 points each), then render-blocking resources (15), then the smaller signals. A page that's fast to first byte and lean in weight will usually feel fast even before every last render-blocking script is cleaned up - diminishing returns set in past that point, so don't over-invest in the last few points at the expense of content and functionality.

Re-run the test after every meaningful change rather than batching several fixes and testing once - it's the only way to know which specific change actually moved the number, especially when a hosting provider or CDN's own caching can make a change look effective before you've confirmed it's your fix and not a cache warming up.

Related SEO Concepts

Page speed sits alongside a few other technical fundamentals worth checking together: image optimization specifically (since images are usually the largest share of page weight), broken links and redirect chains (which add unnecessary requests and hops), and overall site security configuration (HTTPS, headers). None of these fix each other automatically - a fast page with broken links still has a broken-links problem, and vice versa.

Related Tool
Image SEO Analyzer
Score every image's alt text, file name, format, and dimensions - the biggest lever behind most heavy pages.
Related Tool
Bulk HTTP Status Code Checker
Check up to 50 URLs at once for live status codes, redirect chains, and response times.

Limitations of This Page Speed Test

  • It measures a single live fetch from one location, not a multi-region or repeat-visit average - results can vary test to test, especially behind a CDN with cold-cache edges.
  • It doesn't render the page in a browser engine, so it can't report paint or layout-shift timings the way Google PageSpeed Insights does.
  • Minification is detected from filenames (a .min.css/.min.js naming convention), not by inspecting file contents.
  • Up to 40 discovered resources are probed for size per test - a page with far more than that still gets an accurate weight for its heaviest, most common assets, with the remainder flagged as unmeasured rather than silently ignored.

Run the page speed test above against any live URL to see its full score in a few seconds - it's free, and no account is required.

Frequently Asked Questions

A page speed test measures how a specific URL performs when a real request is made to it - how long the server takes to respond, how much data the page and its linked resources weigh, how many separate requests it takes, and whether basic performance settings like compression and caching are turned on. This tool runs that test directly against a live URL and returns a 0-100 score built from eight of those measured signals.

Paste the page's URL into the box above and run the test. It fetches the live page the way a browser would, times the server's response separately from the download itself, then checks every linked stylesheet, script, image, and font to size up the full page - no browser extension, plugin, or command line needed.

A server response time (TTFB) under 200ms is considered excellent, and a total page weight under 1MB with fewer than 30 requests loads comfortably fast on most connections. Google's Core Web Vitals guidance targets a Largest Contentful Paint under 2.5 seconds, which depends heavily on the same two things - server response time and page weight - that this test weights most heavily.

In roughly the order this test checks them: a slow server response (an overloaded host, no server-side caching, a database query on every request), a heavy page (large uncompressed images, unminified CSS/JS, too many fonts), too many separate HTTP requests, missing gzip/Brotli compression, no browser caching headers, and render-blocking scripts or stylesheets sitting in the page's <head>.

Start with whichever signal this test scores lowest, since that's usually the biggest lever: compress and correctly size images if page weight is heavy, move to a faster host or add server-side caching if response time is slow, add async or defer to non-critical scripts if render-blocking resources are flagged, and turn on gzip/Brotli compression and Cache-Control headers if either shows as missing - both are usually quick server-config changes rather than a redesign.

The fixes with the best effort-to-impact ratio are almost never a redesign: enabling gzip/Brotli compression, adding Cache-Control headers, compressing and correctly sizing images, and adding defer to non-essential third-party scripts (analytics, chat widgets, ad tags) can all be done without touching a page's layout or content, and they're exactly what this test's compression, caching, image, and render-blocking checks are built to catch.

Yes, directly and indirectly. Google has used page speed as a confirmed ranking signal since 2010 on desktop and 2018 on mobile, and Core Web Vitals - influenced heavily by server response time and page weight - are part of Google's Page Experience factors today. Indirectly, slower pages measurably increase bounce rate and reduce conversions, which is often the stronger business argument even before rankings enter the conversation.

PageSpeed Insights renders your page in real (headless) Chrome and reports paint/interaction timings like Largest Contentful Paint and Cumulative Layout Shift. This test fetches your page's real HTML and every linked resource directly - the way a server-side audit does - and scores concrete, verifiable signals (response time, transferred weight, request count, compression, caching, render-blocking resources) without rendering the page in a browser engine. The two are complementary: this test is faster for a first pass or a quick spot check; a rendering-based tool adds visual paint timing on top.

TTFB (Time To First Byte) is the time between sending a request and receiving the first byte of the response - covering DNS lookup, connection setup, and how long the server itself takes to start responding, before any part of the page has begun downloading. A high TTFB delays everything that happens afterward, which is why it carries the most weight (20 of 100 points) in this test's score.

Each test requires a quick reCAPTCHA verification, and there's a daily limit per browser/IP so the tool stays free and available for everyone. The remaining count for the day is shown next to the test button after your first run.