A complete website performance test goes far beyond a single load time number to measure every aspect of how efficiently your page loads, renders, and becomes interactive.
Loading Website Speed Test…
Lighthouse-based performance score
Core Web Vitals (LCP, CLS, FID/INP)
Resource size and request analysis
No sign-up required
Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Website Speed Test by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
A website performance test encompasses far more than a single speed number. Modern performance testing tools including Google Lighthouse, which powers FixTools' speed test, evaluate five distinct categories: Performance (speed metrics), Accessibility (WCAG compliance), Best Practices (code quality and security), SEO (crawlability and meta tag completeness), and Progressive Web App compliance. Each category produces a 0 to 100 score, and the combination provides a holistic picture of your site's technical health. The Performance score itself is a weighted composite of six Lighthouse metrics: FCP weighted at 10%, Speed Index at 10%, LCP at 25%, Time to Interactive at 10%, Total Blocking Time at 30%, and CLS at 15%. Understanding this weighting explains why a single optimisation can dramatically shift the score in some areas more than others depending on which metric it targets.
Performance testing should be conducted at three distinct levels for a complete picture of real-world behaviour. Page-level testing, running a test on individual URLs, identifies issues on specific pages and is the typical starting point for any audit. Synthetic monitoring through scheduled automated tests tracks performance over time and alerts you to regressions caused by deployments, plugin updates, or new third-party integrations. Real User Monitoring (RUM) collects performance data from actual visitors using their real devices and network conditions. Google's Chrome User Experience Report (CrUX) provides RUM data aggregated from real Chrome users and is the source of the field data shown in Google Search Console's Core Web Vitals report. Lab data (Lighthouse scores) and field data (CrUX) often differ significantly, and a well-optimised lab score with poor field data usually indicates performance degradation from third-party scripts that run in production but not in lab conditions.
When conducting a performance audit, test your most critical pages and not just the homepage. For e-commerce sites, test product listing pages, individual product pages, and checkout flows because these are where conversion happens and where slow performance translates most directly into lost revenue. For SaaS sites, test the signup and onboarding pages where new users decide whether to continue or abandon. For content sites, test your top 10 articles by organic traffic since these are the pages users actually arrive on from search. These pages are where slow performance has the greatest direct business impact, and they are the pages Google's crawler visits most frequently to update CrUX scores. Optimising the homepage while ignoring deep pages is a common but costly mistake.
A robust performance audit also accounts for variability in the testing environment itself. Single runs of Lighthouse have inherent variance of plus or minus five points caused by random fluctuations in CPU scheduling, network conditions, and CDN cache states even when nothing about the page has changed. Treat any single result as directional rather than definitive. Run at least three tests per URL and take the median value as your headline figure. When evaluating an optimisation, run three tests before and three after, then compare medians to confirm the change exceeded the noise floor of measurement variance. This discipline prevents the common mistake of celebrating or panicking over score changes that are actually within the expected fluctuation range and have no real significance.
Enter your URL for a comprehensive performance analysis covering all major metrics.
Step-by-step guide to website performance test:
Enter the URL to test
Paste your page URL into the tool. Test your most important pages first: the homepage, key landing pages, and any conversion-critical pages such as checkout, signup, or product detail templates. Avoid spending early effort testing pages with negligible traffic because optimisations there deliver minimal business value compared with the same work on a high-traffic page.
Review the overall performance score
Check the overall score on the 0 to 100 scale and note which category the score falls into: Good at 90 or higher, Needs Improvement between 50 and 89, or Poor under 50. Treat the score as one of several signals rather than the only thing that matters. The individual metric breakdowns often tell a more useful story than the composite when planning specific optimisation work.
Review Core Web Vitals
Check LCP with a target under 2.5 seconds, CLS with a target under 0.1, and FID or INP with a target under 200 milliseconds. These are Google's key page experience metrics and directly influence search rankings. Any metric in the failing range deserves immediate attention because Google uses these specific thresholds to determine whether your site qualifies for the Page Experience ranking boost or sits at a disadvantage.
Review resource and opportunity recommendations
Check the resource list for oversized images, render-blocking scripts, uncached resources, or unused JavaScript. Prioritise the highest-impact fixes first based on the estimated savings Lighthouse calculates for each opportunity. Tackle the items at the top of the opportunities list before working down to minor improvements that may not justify the engineering time required to implement them.
Common situations where this approach makes a real difference:
Website redesign quality gate
A development agency runs performance tests on every page template before a new website goes live for a client. Pages must score 85 or higher on mobile to pass the quality gate and proceed to client handover. This policy forces optimisation to happen during development rather than as an awkward post-launch project, and it gives the client a documented baseline showing the site shipped at a competitive performance level. The team includes the screenshots in their handover deliverable as proof of meeting the contracted performance commitment.
Monthly performance monitoring
An e-commerce manager runs a performance test on the homepage and top five product pages monthly as a standing operational check. A sudden score drop in one month reveals a new third-party chat widget that the customer support team added without consulting engineering, contributing 800KB of JavaScript and pushing LCP past three seconds. The manager works with support to switch the widget to load asynchronously only after the page becomes interactive, restoring performance without removing the support tool entirely.
Developer interview technical task
A candidate for a front-end developer role is given a failing performance test report and asked to identify the issues and propose their solutions, using the FixTools report as the basis for the exercise. The exercise reveals not just technical knowledge but also prioritisation skills: a strong candidate fixes TTFB and image weight before chasing minor CSS optimisations, while a weaker candidate dives into superficial tweaks that move the score by only a point or two without addressing the root causes.
Use this for a comprehensive performance audit, when you want a full picture of performance beyond just load time, including Core Web Vitals and resource analysis.
Get better results with these expert suggestions:
Compare lab scores with field data
Your Lighthouse lab score and your Google Search Console Core Web Vitals field data can differ significantly and the gap itself is informative. Field data reflects real user experiences including third-party scripts, slow networks, and older devices that lab tests do not simulate accurately. Always check your Search Console CWV report alongside lab testing to understand real-world performance. A high lab score paired with poor field data usually means production conditions trigger something the lab does not capture.
Test after clearing all caches
Browser caching can make repeat page loads appear much faster than first-visit loads and create a misleadingly rosy view of how new visitors actually experience your site. Most visitors arriving from search are first-time visitors. When running performance tests, always use an incognito or private browser window, or force-clear caches between runs, to simulate the experience of a new visitor rather than a returning one. The cold cache result is the number that should drive optimisation decisions.
Audit third-party scripts specifically
Third-party scripts including analytics, chat widgets, ad tags, and heatmaps are often the hidden cause of poor performance and lab versus field data gaps. Use Chrome DevTools' Network tab filtered by third-party domains to measure exactly how much time each script adds to your page. Remove or defer any script that adds more than 50 milliseconds and cannot justify that cost through a clear business contribution. Audit this list quarterly because new scripts tend to accumulate quietly over time.
Use Lighthouse CI in your deployment pipeline
Lighthouse CI is a free open-source tool that runs automated Lighthouse audits in your CI/CD pipeline and fails the build if performance falls below your defined thresholds. This prevents performance regressions from reaching production at all rather than discovering them after deployment when the damage has already been done. Configure budgets for the metrics that matter most to your business and treat any breach as a build failure that must be addressed before merging.
Use the resource breakdown to find the biggest wins
Performance audits consistently show that image optimisation delivers the biggest load time improvement for most websites. Start with the resource size report and fix the largest assets first.
Prioritise LCP over overall score
Largest Contentful Paint (LCP) is the Core Web Vital most closely correlated with user perception of page speed. A good LCP score (under 2.5 seconds) matters more than a high overall score for user experience.
Test the pages users actually visit, not just the homepage
The homepage is often the most optimised page on a site. Test your highest-traffic landing pages and most important conversion pages, these are where performance issues cost you real business.
More use-case guides for the same tool:
Open the full Website Speed Test — free, no account needed, works on any device.
Open Website Speed Test →Free · No account needed · Works on any device