See what slows your site
and what to fix first.
A free website speed test: a Lighthouse lab test on mobile or desktop and the assets your site ships, kept apart and turned into a fix plan you can hand to your coding assistant. Real-user data from Chrome is temporarily unavailable here.
How the speed test works
Three sources, each labelled, none blended into a score of ours.
Real users
The Chrome UX Report: how eligible Chrome visitors experienced the page over the last 28 days, at the 75th percentile, with the Core Web Vitals assessment and its basis.
Limit: Pages without enough visits have no data, which is said, never scored. Temporarily unavailable on xlogs right now.
Lab test
One Lighthouse run from PageSpeed Insights on the device you choose: Performance, Accessibility, Best practices and SEO, the audits Lighthouse returned for the run, each in its own state, and the conditions the response states.
Limit: One run on a simulated device; the same page can score differently next time.
Assets
What xlogs fetched and weighed itself: the decoded size of the page's HTML and its own JavaScript, the transfer size of the same responses, and the heaviest files.
Limit: Scripts from other sites are named, not downloaded or sized; that limits the xlogs asset total, not Lighthouse's measurements.
Fix plan
A suggested fix order from Lighthouse's own estimates and weights: speed fixes for the metrics this run found slow, then accessibility and other issues, then smaller speed gains, each with its evidence and how to verify it.
Limit: Savings are Lighthouse's estimates; they overlap and are never added together.
Speed test questions
Where do these numbers come from?
Three places, kept apart. Real-user data comes from the Chrome UX Report: how real Chrome visitors experienced the page over the last 28 days. The lab test is one Lighthouse run from Google's PageSpeed Insights, on the device you choose. The asset figures are what xlogs fetched and weighed itself: the page's HTML and its own JavaScript. None of them is blended into an xlogs score.
Why do real users look fine when the lab test looks slow?
They measure different things. The lab test loads the page once on a simulated mid-range phone or desktop with a throttled connection, and real visitors use whatever devices and networks they have, often faster ones. Real-user data says what people experienced; the lab test is a controlled, repeatable way to find what to fix. Both can be right at once.
Why does the lab score change between runs?
A Lighthouse run depends on the network, the server and the test machine at that moment, so the same page can score a few points differently without any code change. The report shows the device, the time, the Lighthouse version and the test conditions, so you can tell whether two runs are comparable.
What does "not enough real-user data" mean?
Chrome only reports pages and sites with enough eligible visits over 28 days. New or low-traffic pages often have none, and that is neither a pass nor a fail. When the page itself has too little data but the whole site has enough, the report shows the site's figures and labels them as the site's.
Does a test change anything on my site?
xlogs itself only fetches the page and its own scripts, the way a browser does, and writes nothing. The lab test is different: Google loads the page in a real browser, which runs the page's JavaScript like any visitor would, so anything your page does on load happens once.
How is this different from PageSpeed Insights?
It reads the same two Google sources: a Lighthouse run from the PageSpeed Insights API and Chrome's real-user data from the Chrome UX Report API. It is not a copy of PageSpeed Insights, and some of its views, such as the script treemap and element screenshots, are not shown here. What it adds is a suggested order to fix things in, the evidence for each, the assets your site ships, and a fix plan or a JSON export you can take away. Missing data stays missing, and estimates are labelled as estimates.
Can I compare before and after a change?
Yes. In the Compare tab, save this run as a baseline, make your change, test again, and the two runs sit side by side with each one's date, address, device, Lighthouse version and test settings: the scores, the lab metrics, and which audits are new, still present or not observed in this run. Baselines are saved in your browser and never sent to xlogs; clearing site data may remove them, so you can download a baseline, or export the report, and load it in another browser. Two runs on different devices or of different addresses are marked as not comparable, and an audit that no longer fails is called not observed in this run, not fixed, because one lab run can miss a problem.