Pagespeed Checker Free Tool

Enter a URL

About Pagespeed Checker

What This Tool Actually Does

The Pagespeed Checker on limitlessreferrals.info is a small form with one job. You give it a URL, it sends that address to Google's PageSpeed Insights API, and it shows you the report Google's Lighthouse returns for a desktop run. The tool asks Google to do the measuring, then it formats Google's answer into two tables you can read at a glance.

The request goes to the PageSpeed Insights API v5 endpoint, the same service that powers the public Google PageSpeed Insights page you may have used before. The tool asks for the desktop strategy only. There is no mobile toggle, no choice of device, and no second run. Every check this page performs is a desktop check. The response comes back with a Lighthouse report, and the tool pulls out the parts its template was built to show. Those parts are the final URL after redirects, the Chrome UX Report loading experience for the origin, the Lighthouse performance score, any warnings Google's run produced, the user agent string of the headless Chrome Google used, a screenshot of the rendered page, and a details table of every numeric audit in the report.

A page named "Pagespeed Checker" uses Google's testing infrastructure. The tool runs a single test. A real speed test needs a real browser engine, a controlled network, and a consistent device profile. Building and maintaining that is a large project. Google already runs Lighthouse at scale and exposes the results through a public API. This tool is a thin client for that API. It sends your URL with a few parameters, waits for the JSON response, and renders a readable summary. The heavy lifting happens inside Google's infrastructure, on hardware this site does not own.

The whole exchange takes a few seconds. A live test run for this rewrite used example.com and finished in about seven seconds end to end. That time includes the network round trip to Google, the Lighthouse run itself, and the rendering of the page you see. The tool shows a "Processing..." spinner while it waits, so you know the request is still alive. If the API takes longer than thirty seconds, the connection is dropped and you get an empty result.

What you will not find here is a long list of metrics from other testing tools. There is no TTFB chart, no waterfall of resource requests, no comparison against competitors, no historical trend line. The tool shows exactly what Google's desktop Lighthouse report contains for the numeric audits, nothing more. That narrowness gives you a quick second opinion on a page's performance score. It is a limitation if you expected a full web performance lab.

The output carries its source clearly. The user agent row tells you which headless Chrome version Google used for the run, and the warnings row surfaces anything Lighthouse noticed during the test. The screenshot is the final frame of the rendered page, embedded directly in the result. You can see what Google's browser saw when it finished loading.

How to Use This Tool

1. Open the tool page. Find the input box above this article, on the Pagespeed Checker page itself.
2. Enter a full URL. Type or paste the address you want to test, including the protocol. If you leave off http:// or https://, the tool adds http:// for you.
3. Submit the form. Click the button and wait for the "Processing..." spinner to finish. The request usually takes several seconds.
4. Read the summary table. Look at the final URL, loading experience, performance score, warnings, tested mode, user agent, and screenshot.
5. Scan the details table. Each row is one numeric Lighthouse audit with its title, description, score, and the suggested value such as "0.2 s" or "20 ms".
6. Interpret the results. Compare the performance score against the loading experience, and check the details table for the specific metrics that matter for your page.

Correcting the Old Description of This Tool

The previous version of this page described capabilities this tool does not have. That older copy claimed the tool reported Interaction to Next Paint (INP) as a field metric. It does not. The current output contains no INP field data at all. The older copy also described field data per metric and invited comparisons between a "mobile score" and a "desktop score." This tool requests only the desktop strategy from Google's API. There is no mobile run, no mobile score, and no way to compare the two within this page.

The old FAQ answered a question about why a desktop score might look great while a mobile score looks poor. That question has no answer here because the tool never asks Google for a mobile result. The old FAQ also said you could test a password-protected page. You cannot. Google's fetcher cannot authenticate, and the API returns an error that this tool swallows, leaving you with empty cells.

These corrections matter because the old text promised a breadth of analysis the tool's code does not deliver. The form has one field, one submit button, and one API call with strategy=desktop hardcoded into the request. There is no parameter for mobile, no checkbox for field data, no toggle for categories. The template that renders the results has no branch that would display an INP value or a per-metric field comparison. The claims in the old copy described a different product than the one running on this page.

The tool shows a performance score, which is the Lighthouse performance category score multiplied by one hundred. That score comes from a lab test, meaning a synthetic run in a controlled headless Chrome environment. It is a measure of how the page performed under test conditions. The loading experience row, when it has a value, comes from the Chrome UX Report, which is field data collected from real Chrome users. Those two numbers answer different questions. The performance score asks how fast the page is under test conditions. The loading experience asks how fast the page has been for actual visitors over the past month. The old copy blurred that line.

What the Summary Table Shows

The summary table is the first thing you see after the tool finishes. It condenses Google's large JSON response into six rows plus a screenshot. Each row has a label and a value. The labels are Final URL, Loading Experience, Performance Score, Warnings, Tested Mode, and User Agent. The screenshot appears in its own row of the summary table.

The Final URL row shows where the page actually ended up after any redirects. If you submitted a URL that bounces through three redirects, this row tells you the last address in the chain. Google's Lighthouse follows redirects during its run, and the finalUrl field in the response records the destination. This is useful for spotting redirect chains that add latency. A page that redirects to a different domain, or to a trailing-slash version of itself, will show that here.

The Loading Experience row draws from the originLoadingExperience object in Google's response. That object comes from the Chrome UX Report, often abbreviated CrUX. CrUX is Google's public dataset of real user experience metrics, collected from Chrome browsers that have opted into syncing their browsing history. The dataset covers millions of origins and updates monthly. For each origin, Google buckets the loading experience into one of three categories. Those categories are FAST, AVERAGE, and SLOW. The tool displays whichever category Google assigned to the origin of your tested URL.

The loading experience is per origin. It reflects the aggregate experience across all pages on that origin, as measured from real Chrome users. It is also not always available. Google only has CrUX data for origins with enough traffic to meet its privacy thresholds. A small site, a new site, or a site with few Chrome visitors may have no entry in the dataset. In that case, the Loading Experience row is blank. The tool does not invent a value and does not show an error. The cell is simply empty.

The Performance Score row shows the Lighthouse performance category score, scaled to a zero-to-one-hundred range. Lighthouse calculates this score from a weighted combination of several performance metrics. The weights change between Lighthouse versions, so a score of ninety from one version may not mean the same as a score of ninety from another. The score is a lab measurement. It tells you how the page performed in Google's test environment on the day you ran the check.

The Warnings row displays any runWarnings from the Lighthouse report. These are messages Google attaches when something about the run was unusual. A common warning appears when the page did not have enough data for certain metrics, or when the run encountered conditions that make the results less reliable. With no warnings the row is empty.

The Tested Mode row always says Desktop. This tool never sends a mobile request. The User Agent row shows the exact user agent string of the headless Chrome that Google used. In the live test with example.com, that string included HeadlessChrome/151.0.7922.71. This row is a fingerprint of the test environment. If you compare results across time and the user agent changes, you know Google updated its Chrome version, which can shift metric values.

The screenshot is the final rendered frame of the page, captured by Lighthouse at the end of its load. It is embedded as a base64 image directly in the HTML response. The screenshot gives you a visual confirmation that Google's browser reached the page and rendered it. A blank or broken screenshot can indicate the page did not load properly.

The summary table is the quick answer to the question "how fast is this page?" The performance score and loading experience together give you a lab number and a field number. When they agree, you have a clear picture. When they disagree, you have a puzzle worth investigating.

Reading the Details Table of Numeric Audits

Below the summary, the tool renders a second table. This one lists every audit in the Lighthouse report whose scoreDisplayMode is numeric. Each row has four columns. The Title column names the metric or diagnostic. The Description column carries Google's own explanatory text, including markdown links shown in their raw form like [text](url) because the tool does not render markdown. The Score column shows the audit's score on a zero-to-one-hundred scale. The Suggestion column shows the displayValue, which is the human-readable measurement such as "0.2 s" or "20 ms".

The set of numeric audits changes over time because Lighthouse itself changes. Google releases new versions of Lighthouse periodically, and each version can add, remove, or rename audits. The tool does not curate this list. It simply iterates over whatever numeric audits Google returned in the JSON and prints them all. If Google adds a new metric next year, this tool will show it without any code change. If Google removes an audit, it will disappear from the table.

In the live test with example.com, the details table included seven metric rows. Cumulative Layout Shift scored zero, which is perfect. Time to Interactive came in at a fraction of a second. Max Potential First Input Delay was 20 milliseconds. Speed Index was a fraction of a second. Largest Contentful Paint was a fraction of a second. Total Blocking Time was 0 milliseconds. First Contentful Paint was a fraction of a second. The table also carried several diagnostic rows with numeric scores, including Network dependency tree, Forced reflow, Layout shift culprits, Optimize DOM size, 3rd parties, and Optimize viewport for mobile.

Those diagnostic rows are not Core Web Vitals. They are additional checks Lighthouse performs to find optimization opportunities. The "Optimize viewport for mobile" row might look odd in a desktop-only report, but Lighthouse includes it regardless of strategy. The row comes from Google's desktop Lighthouse report; the tool never runs a mobile test.

The metric rows in the details table are the ones you will most likely recognize from discussions of web performance. Largest Contentful Paint measures when the largest visible element finishes rendering. First Contentful Paint measures when the first piece of content appears. Cumulative Layout Shift measures how much the page layout moves after elements load. Total Blocking Time measures how long the main thread was blocked from responding to user input. Speed Index measures how quickly the page visually fills in. Time to Interactive measures when the page is fully interactive. Max Potential First Input Delay estimates the worst-case delay for a user's first interaction.

Each of these is a lab metric. Google's Lighthouse runs the page in a simulated desktop environment with a throttled network and CPU. The values you see are what that specific run produced. Real-world conditions vary with device hardware, connection speed, browser version, and network congestion. The lab numbers are useful for finding regressions and comparing changes, but they are not promises about real user experience.

The table's descriptions come straight from Google. They are the same paragraphs you would read on the public PageSpeed Insights page. Because the tool does not render markdown, any links inside those descriptions appear as raw text. You will see something like [Learn more](https://web.dev/articles/lcp). That is a cosmetic limitation. The text is intact, just not hyperlinked.

Lab Data Versus Field Data

The distinction between lab data and field data is the single most important concept for reading this tool's output. Lab data comes from a controlled test. Field data comes from real users. This tool shows both in specific places. The performance score and every row in the details table are lab data. The loading experience row is field data, when it exists.

Lab data is reproducible. Run the same page through the same Lighthouse version on the same day, and you will get nearly the same numbers. That reproducibility makes lab data suitable for regression testing. You can change a line of code, rerun the test, and see whether the performance score moved. Lab data is also synthetic. It does not capture the chaos of the real internet, where users have slow connections, old phones, and browser extensions that block resources.

Field data is the opposite. It is messy, real, and aggregated. The Chrome UX Report collects metrics from actual Chrome users who visited the origin. Those metrics include Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, and others. Google aggregates them into percentiles and buckets them into the FAST, AVERAGE, and SLOW categories. The loading experience row shows the overall category for the origin.

Field data answers the question "how fast is this site for the people who actually visit it?" Lab data answers the question "how fast is this page under Google's test conditions?" A page can score one hundred in the lab while real users experience slow loads, if those users are on slow connections or old devices. A page can score poorly in the lab while real users have a fine experience, if the lab's simulated throttling is harsher than what your audience faces.

The Core Web Vitals are a specific set of three metrics Google uses to judge user experience. They are Largest Contentful Paint, Cumulative Layout Shift, and a third metric that has changed over time. For a long period, that third metric was First Input Delay. Google announced in May 2022 that Interaction to Next Paint (INP) would replace First Input Delay as a Core Web Vital, and the replacement took effect in March 2024. INP measures the longest delay between a user interaction and the next paint. It is a field metric calculated from real user observations.

This tool does not show INP. The old page copy claimed it did, but the current code has no field for it. The details table may include Max Potential First Input Delay, which is a lab estimate related to the older First Input Delay metric. That is not INP. If you need INP field data for your site, you must look elsewhere, such as the CrUX dataset in Google BigQuery or the PageSpeed Insights API's full response, which this tool does not expose.

The loading experience category in the summary table is a field-based judgment. When Google has enough CrUX data for the origin, it assigns FAST, AVERAGE, or SLOW based on how the origin's field metrics compare against Google's thresholds. When Google lacks data, the cell is blank. That blankness is common for new sites, low-traffic sites, and sites whose visitors mostly use non-Chrome browsers.

The Empty-Cells Failure Mode

Every tool has failure modes, and this one has a distinctive way of failing. When Google's API returns an error, the tool does not show an error message. It shows the same two tables with every cell empty. A nonexistent domain produces this result. A page behind a login wall produces this result. A page that blocks Google's fetcher produces this result. A page that times out produces this result. An exhausted API quota produces this result.

The reason is in the code. The tool calls Google's API and receives a response. If that response contains an error, the tool swallows it. The template then renders with empty values because there is no data to fill the cells. The user sees a page that looks broken, with no explanation of what went wrong. This is a poor experience, and you should know about it before you run a test.

You can work around this failure mode by testing a page you know is publicly accessible. If you submit your own site and get empty cells, the first suspect is your site's configuration. Check whether your site blocks known bots, whether it requires authentication, and whether it responds quickly to requests from unfamiliar user agents. Google's Lighthouse fetcher uses a headless Chrome user agent, and some sites block that string. If your site works in a normal browser but returns empty cells here, a bot block is a likely cause.

The empty-cells result can also appear when Google's API quota for the day is exhausted. The API key embedded in this site's code has its own daily limit, set by Google. When that limit is reached, every request until the next quota reset returns an error. The tool cannot distinguish that error from a page-loading error, so it shows empty cells either way. If you get empty cells on a page you know is public and fast, wait a day and try again.

The tool also applies a site-wide rate limit that is separate from Google's quota. This site runs a distributed denial-of-service check on every page. If one visitor address makes roughly fifteen requests within a single second, that address is blocked for the rest of the day. This is a shared throttle across the whole site, not a limit specific to the Pagespeed Checker. There is no CAPTCHA on this tool and no tool-specific request cap. Normal use, meaning a handful of tests spread over minutes, will never trip the throttle.

What This Tool Does Not Include

The list of exclusions is as important as the list of features. This tool does not run a mobile test. It does not show field data for individual metrics. It does not show INP. It does not show the other Lighthouse categories, which are Accessibility, Best Practices, and SEO. It does not show opportunities with estimated savings. It does not keep history or allow comparisons between runs. It does not test pages that require login.

The mobile exclusion is structural. The API call hardcodes strategy=desktop. There is no code path that would request strategy=mobile. If you want a mobile score, you must use Google's own PageSpeed Insights page or another tool. The old copy's FAQ about mobile-versus-desktop score differences was describing a comparison this tool cannot make.

The INP exclusion is also structural. The template has no field for INP, and the details table only shows what Google returns for numeric audits. INP is a field metric, and Google's API v5 does include INP in the originLoadingExperience object when data exists. But this tool only reads the overall_category from that object, not the individual metric breakdowns. The INP value, if present in the JSON, is never displayed.

The category exclusions mean you cannot use this tool to check whether your page meets accessibility guidelines or follows SEO best practices. Those categories exist in every Lighthouse report, and the API returns them, but this tool's template only renders the performance-related summary and the numeric audits. The JSON response from Google is large and contains far more than what this page shows. The tool deliberately extracts a small subset.

The no-history exclusion means every test is a fresh snapshot. You cannot ask the tool to compare today's score against last month's score. You cannot see a trend line. If you want to track performance over time, you need to run tests yourself and record the results, or use a service that stores them for you.

The no-login exclusion follows from Google's architecture. Google's Lighthouse runs in Google's infrastructure, not on your network. It cannot enter credentials, click through multi-factor authentication, or access pages behind a corporate VPN. Any page that requires a session will fail the test. The old copy claimed you could test password-protected pages. You cannot, and the empty-cells result is what you will get if you try.

Understanding the Performance Score

The performance score is a single number from zero to one hundred. Google's Lighthouse computes it by taking the measured values of several performance metrics and mapping each to a score using a logarithmic curve. The curves are defined in Lighthouse's source code and change between versions. The overall performance score is a weighted average of the individual metric scores.

The weights have shifted over the years. In Lighthouse 10, released in 2023, the weights were twenty-five percent for Largest Contentful Paint, thirty percent for Total Blocking Time, twenty-five percent for Cumulative Layout Shift, ten percent for Speed Index, and ten percent for First Contentful Paint. The exact weights matter less than the general shape. Largest Contentful Paint and Total Blocking Time dominate the score. If those two metrics are good, your performance score will likely be good.

A score of one hundred means every measured metric fell within the ranges Google rates as good. A trivial page like example.com, which is a single small HTML document with no images, no scripts, and no stylesheets, will score one hundred almost every time. The live test confirmed this. Example.com returned a performance score of one hundred with every metric in the details table at its best possible value.

A low score does not necessarily mean your page is broken. One or more metrics landed in a range Google rates as poor. The most common culprit is Largest Contentful Paint, which can be slow when the largest element on the page depends on a large image or a slow API response. Total Blocking Time can be high when JavaScript blocks the main thread during load. Cumulative Layout Shift can be high when images or ads load without reserved space.

The performance score is a lab measurement. It reflects the test environment Google used, including the simulated network throttling and CPU slowdown. The score can vary between runs on the same page, especially for pages with many third-party scripts or dynamic content. A five to ten point swing between runs is usually measurement noise.

The Role of the Screenshot

The screenshot in the summary table is the final frame of the page as rendered by Google's headless Chrome. It is captured after the page finishes loading and after any post-load JavaScript settles. The screenshot serves as visual proof that the page rendered correctly during the test.

A screenshot that shows a blank white page, a broken layout, or an error message tells you something the metrics cannot. It tells you the page did not render as intended in Google's test environment. This can happen when the page relies on browser features that headless Chrome handles differently, when the page blocks the test user agent, or when the page requires cookies or local storage that the test browser does not have.

The screenshot is embedded as a base64-encoded image directly in the HTML. This means the result page is self-contained. You do not need an external image host to view the screenshot. The tradeoff is page size. A screenshot can add hundreds of kilobytes to the result page, which is fine for a single test but worth knowing if you are saving many result pages.

The screenshot shows the final state. You cannot see the loading sequence, the order in which elements appeared, or the moments of layout shift. You see only the end state. For diagnosing a slow Largest Contentful Paint, the screenshot helps only if the largest element never appears or appears in the wrong place. For most performance work, the numeric metrics are more useful than the screenshot.

How the Request Is Made

When you submit the form, the tool performs several steps before it contacts Google. It takes the URL you entered and trims whitespace. If the URL does not start with http:// or https://, the tool prepends http://. This means a bare domain like example.com becomes http://example.com. If you enter a URL with https://, the tool keeps it as HTTPS. This behavior differs from some other tools on this site, which force HTTP regardless.

The tool then validates the URL using PHP's FILTER_VALIDATE_URL filter. An input that fails URL validation is rejected before any call to Google, with the message 'Input Site is not valid!'. A valid URL must include a scheme and a host. Something like not a url will fail validation.

Once the URL passes validation, the tool constructs a request to Google's PageSpeed Insights API. The endpoint is https://www.googleapis.com/pagespeedonline/v5/runPagespeed. The request includes the URL, strategy=desktop, locale=en_US, and screenshot=true. The API key is stored in the site's code and sent with the request. The tool uses a helper function that performs a GET request with a thirty-second timeout.

The choice of locale=en_US means Google's descriptions and audit titles come back in American English. The screenshot=true parameter tells Google to include the final screenshot in the response. The strategy=desktop parameter is the one that fixes the device profile. Google's API also accepts strategy=mobile, but this tool never sends it.

The thirty-second timeout is a hard limit. If Google's API does not respond within thirty seconds, the request is abandoned. Given that a typical Lighthouse run takes five to fifteen seconds, thirty seconds is usually enough. Pages that are extremely slow, or Google's API itself when it is overloaded, can exceed the limit.

The Chrome UX Report and Loading Experience

The Chrome UX Report is Google's public dataset of real user experience metrics. It is built from anonymous field data collected from Chrome browsers. The dataset covers millions of origins and is updated monthly. Web developers and performance researchers use it to understand how real users experience the web.

The CrUX dataset includes several metrics. The most prominent are Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, and, since March 2024, Interaction to Next Paint as a Core Web Vital. For each origin, Google aggregates these metrics into distributions and buckets them against performance thresholds. The buckets are good, needs improvement, and poor. The overall category for an origin is determined by the worst-performing of the Core Web Vitals at the seventy-fifth percentile.

The Loading Experience row in the summary table shows this overall category. It is one of three values. FAST means the origin's field data meets Google's good thresholds. AVERAGE means at least one metric falls in the needs improvement range. SLOW means at least one metric falls in the poor range. The category is per origin, not per page. A single page on a large origin inherits the origin's category.

The category can be blank. Google only publishes CrUX data for origins that meet a minimum traffic threshold, which protects user privacy by ensuring no individual can be identified from the aggregate data. The exact threshold is not public, but it is high enough that many small and medium sites have no CrUX entry. A new site will almost certainly have no data until it accumulates several weeks of traffic. A site whose visitors predominantly use Safari or Firefox may also have little or no Chrome data.

A blank Loading Experience row means Google has no field data for that origin. The performance score in the same table is still valid as a lab measurement. You can have a blank loading experience and a perfect performance score. That combination simply means Google's lab test found the page fast, but Google has not collected enough real-user data to judge the origin's field experience.

The old page copy described field data per metric and suggested the tool could show you how your Largest Contentful Paint compared against field thresholds. This tool does not do that. It shows only the overall category. The individual metric breakdowns exist in Google's API response, but the tool does not render them.

Related Tools

If you need a broader look at a page's loading behavior, the Website Speed Checker runs a different kind of measurement that can complement the Lighthouse score you get here.

When you want to know how heavy a page is before you test its speed, the Website Size Checker reports the total download size, which is a useful context for interpreting a performance score.

For pages that are slow because of excessive HTML, the Code to Text Ratio Checker helps you see whether your markup outweighs your content, a factor that can affect render time.

Practical Workflows for Using This Tool

A single test is the simplest workflow. You paste a URL, submit, and read the result. That tells you how the page performed at that moment. For a more useful picture, run the test a few times across different days and at different times of day. Performance scores can vary with Google's infrastructure load and with your page's own variability, especially if it serves dynamic content or relies on third-party services.

A second workflow is regression testing. Before you change your page, run a test and record the performance score and the key metrics from the details table. Make your change. Run the test again. Compare the numbers. If the Largest Contentful Paint went from 2.5 seconds to 1.8 seconds, your change helped. If it went the other way, your change hurt. This before-and-after pattern is the core of performance work, and this tool supports it as long as you keep your own records.

A third workflow is competitive comparison. Test your page and a competitor's page on the same day. The lab conditions are identical because both runs use the same Google infrastructure and the same Lighthouse version. The comparison is fair in a way that comparing results from different days may not be. The tool does not store results, so you will need to keep the output open or save it yourself.

A fourth workflow is origin health checking. Test the homepage of a site you manage, then test a few key landing pages. The performance score will vary between pages because different pages have different content and resources. The loading experience row will likely be the same across pages on the same origin, because that row is origin-level. If you see different loading experience values for different pages on the same origin, that would be unexpected and worth investigating.

The tool is not suited for continuous monitoring. It has no scheduler, no alerting, and no storage. If you need to know the moment your performance score drops below a threshold, you need a dedicated monitoring service. This tool is a manual check, best used when you are actively working on a page or investigating a reported issue.

Limitations

The most significant limitation is the desktop-only strategy. Google's Lighthouse runs a page twice when you use the public PageSpeed Insights page, once for mobile and once for desktop. The mobile run uses a different device profile, different network throttling, and different CPU slowdown. Mobile performance often differs dramatically from desktop performance because mobile devices have less processing power and mobile networks have higher latency. This tool shows you only the desktop side of that story.

The second limitation is the absence of field data per metric. The loading experience row gives you an origin-level category, but it does not tell you the seventy-fifth percentile Largest Contentful Paint for your origin, nor the percentage of loads that met the good threshold. Those numbers are useful for understanding how close an origin is to the boundary between FAST and AVERAGE. This tool hides them.

The third limitation is the lack of other Lighthouse categories. A page can score one hundred on performance and fail every accessibility check. This tool will not tell you. If you need accessibility, SEO, or best practices scores, you must use a different tool or Google's own PageSpeed Insights page.

The fourth limitation is the empty-cells failure mode. When Google's API returns an error, the tool shows no error message. You are left to guess whether the page is down, the page blocks bots, the API quota is exhausted, or the request timed out. This is a genuine usability flaw.

The fifth limitation is the lack of history. Every test is a fresh snapshot. You cannot see trends, compare against last week, or detect gradual degradation. The tool has no memory.

The sixth limitation is the dependence on Google's API quota. The API key embedded in this site's code has a daily limit set by Google. When that limit is reached, all tests return empty cells until the quota resets. The tool does not tell you when the quota is exhausted.

The tool's output shows exactly what it shows. The old page copy was inaccurate, which is why this article corrects it. The current tool does not pretend to offer mobile scores or INP field data. It offers a desktop Lighthouse performance score, an origin loading experience category when available, a screenshot, and a table of numeric audits. That is the whole product.

Frequently Asked Questions

Why does the Loading Experience row come back blank?

The Loading Experience row draws from the Chrome UX Report, which only contains data for origins with enough Chrome traffic to meet Google's privacy thresholds. If your origin is new, low-traffic, or mostly visited through non-Chrome browsers, Google may have no field data for it. A blank row means no data, not a slow page.

Does this tool test mobile performance?

No. The tool sends a single request to Google's PageSpeed Insights API with the desktop strategy hardcoded. There is no mobile run, no mobile toggle, and no way to get a mobile score from this page. The old description of this tool claimed mobile comparisons were possible, but the current code does not support that.

What is the difference between the Performance Score and the Loading Experience?

The Performance Score is a lab measurement from a single Lighthouse run in Google's test environment. The Loading Experience is a field measurement from the Chrome UX Report, aggregated from real Chrome users over the past month. The two can disagree because real users have different devices and connections than Google's test environment.

Why do I see empty tables instead of an error message?

The tool does not display errors from Google's API. When the API returns an error, whether because the domain does not exist, the page blocks Google's fetcher, the page requires login, or the request timed out, the tool swallows the error and renders empty tables. Test a known-public page to confirm the tool is working.

Does this tool show Interaction to Next Paint (INP)?

No. The tool does not display INP field data. The details table may include Max Potential First Input Delay, which is a lab estimate related to the older First Input Delay metric, but that is not INP. The old page copy claimed INP was reported, which was incorrect.

Can I test a page that requires a password or login?

No. Google's Lighthouse runs in Google's infrastructure and cannot authenticate to your site. Any page behind a login wall will fail the test, and the tool will show empty tables. The old FAQ claimed password-protected pages could be tested, which was incorrect.