Enter a URL
Page Speed Checker performs a basic fetch-based analysis of a webpage. Enter a public URL to view the test time reported by the checker and the number of detected page references grouped as total, CSS, image, script, and other links.
This report is useful for a quick technical review, but it is not a Google PageSpeed Insights or Lighthouse audit. It does not provide a 0–100 performance score, mobile and desktop simulations, Core Web Vitals, real-user field data, or guaranteed optimisation recommendations.
After validating and fetching the submitted URL, the checker displays several summary values:
The reported time should not be treated as the complete loading experience of a visitor's browser. A real browser must resolve DNS, establish connections, download resources, execute JavaScript, calculate layout, paint content, load fonts, and respond to interactions. This checker provides a limited server-side snapshot instead.
Test important page types separately. A homepage, product page, article, category, account page, and interactive tool can load different resources and behave differently. One URL does not represent the performance of the entire website.
Page speed is not one universal measurement. Different tools may report server response timing, first content shown, largest content rendered, visual stability, time until scripts stop blocking the main thread, or complete loading of all resources. Two tools can therefore show different numbers without either result being automatically wrong.
Always identify what a measurement includes. A server-side fetch may finish before a browser has rendered the page. A browser lab test uses controlled device and network settings. Field data records the experiences of real visitors over time. Each perspective answers a different question.
Hosting load, database activity, routing, congestion, geographic distance, and temporary service issues can change response times. A single test is not enough to establish a reliable trend.
A cached request may be served faster than an uncached request. Page caches, object caches, browser caches, and CDN edge caches operate at different layers. First-time and repeat visitors can receive different performance.
HTTP-to-HTTPS, www, language, device, or campaign redirects add extra requests before the final page is reached. Test the preferred final URL directly and remove unnecessary redirect chains.
A fast data centre connection does not reproduce a visitor using a budget phone or a slow mobile network. Device processing power, bandwidth, latency, screen size, and browser state all influence the experience.
Advertising, analytics, consent tools, chat widgets, video players, social embeds, and external fonts can respond at different speeds. Their effect may not be represented fully by a simple page fetch.
Personalisation, rotating advertisements, live data, user location, cookies, and A/B tests can change the resources included on each visit. JavaScript may also request additional resources after the initial HTML is received.
A high link count does not automatically mean that a page is slow, and a low count does not guarantee speed. File size, compression, cacheability, connection reuse, loading priority, server response, script execution, and rendering cost all matter.
One large image can cause more delay than several small cached icons. A small script can still block interaction if it performs expensive work. Several stylesheet references may be harmless when optimised and cached, while one large render-blocking stylesheet may delay visible content.
Use the categories to identify what deserves further inspection. They are not a substitute for measuring transferred bytes, request waterfalls, main-thread tasks, rendering milestones, or real-user experiences.
Core Web Vitals are user-experience measurements separate from this checker's basic report. The current core metrics are:
These thresholds are evaluated at the 75th percentile of page visits when field data is used. First Input Delay is no longer the current Core Web Vitals responsiveness metric; INP replaced it. This Page Speed Checker does not calculate LCP, INP, or CLS.
Lab data is collected in a controlled test environment. It is useful for reproducing problems and evaluating changes before release. Lighthouse and browser developer tools are common sources of lab measurements.
Field data, also called real-user monitoring data, records actual visits. It captures the range of devices, connections, locations, and behaviours experienced by users. Lab and field results often differ because their conditions and measurement periods are different.
For a complete performance review, use both. Start with a reproducible lab test to diagnose problems, then confirm whether the improvements benefit real visitors.
Investigate slow database queries, heavy application processing, insufficient hosting resources, cache misses, and long redirect chains. Use page or object caching where appropriate and monitor errors or traffic spikes.
Serve images at suitable dimensions, compress them without unacceptable quality loss, and use efficient formats supported by the target browsers. Provide width and height attributes to reserve layout space. Lazy-load off-screen images, but do not delay the primary image when it is likely to be the largest visible content.
Remove unused code, split large bundles, delay non-critical scripts, and reduce expensive main-thread work. Review third-party scripts individually; a script that adds little user value may not justify its performance cost.
Remove unused styles, minimise blocking resources, and avoid loading unnecessary font families and weights. Preload only genuinely critical assets because excessive preloading can compete with more important downloads.
Configure sensible browser caching for versioned static assets. Enable appropriate response compression for text resources. A CDN may reduce latency for geographically distributed visitors, but its configuration and cache behaviour still need testing.
Reserve dimensions for images, videos, advertisements, and embedded components. Avoid inserting new content above existing content after it becomes visible unless the change is triggered by the user.
Google states that Core Web Vitals are used by its ranking systems, but good scores do not guarantee a top ranking. Search relevance, content quality, meaning, accessibility, and many other systems remain important. Improving performance should primarily make the site easier and more satisfying for users.
Do not promise a ranking, traffic, conversion, or advertising-cost increase from one speed change. Measure the business outcome after deployment and separate performance effects from content, campaign, seasonality, design, and tracking changes.
No. It does not use the PageSpeed Insights API or return a Lighthouse score from 0 to 100.
No. The controller performs a basic URL fetch and resource-link analysis. It does not emulate separate mobile and desktop devices.
No. Treat it as the duration reported for this checker's fetch and analysis. It does not reproduce all browser rendering, JavaScript execution, and user interaction stages.
No. It does not report LCP, INP, or CLS. Use a compatible browser performance or real-user monitoring tool for those metrics.
Hosting load, caching, routing, network latency, redirects, and dynamic resources can vary. Compare several tests and use field data for a broader view.
No. Quantity alone is not enough. Evaluate file size, loading priority, caching, compression, connection behaviour, script cost, and usefulness.
Page Speed Checker offers a quick overview of test timing and detected resource-link categories for one public URL. Use it to identify pages that need a deeper review, not as a final performance grade. For reliable optimisation, combine server monitoring, browser lab tests, request waterfalls, and real-user field data, then verify that changes improve the experience without breaking page functionality.