How to Test Your Website Speed for Free
A step-by-step way to test website speed for free, understand the evidence and avoid making decisions from one score or one unusually good run.
Part of our guide: The Complete Guide to Website Speed for Business Owners
You can test your website speed for free by running several important pages through Google PageSpeed Insights, checking both mobile and desktop results, and then repeating the key journeys on a real phone. Record field data separately from laboratory diagnostics and compare patterns across several runs rather than treating one score as a verdict.
Look for delays that stop visitors from reading, navigating or enquiring. Give the person maintaining the site evidence they can use to investigate.
Prepare a small, representative test list
Do not test only the homepage. Choose five to eight URLs that represent the work your website does: a main service page, a popular search landing page, an article, a gallery or case study, and the contact or booking route. Include any page with video, maps, chat, reviews or another third-party tool.
Write down the device, browser, date and whether you were signed in. If you plan to compare before and after a change, keep the same URLs and conditions. This simple record prevents an attractive homepage result from hiding a poor customer journey elsewhere.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Start with Google PageSpeed Insights
Open PageSpeed Insights, paste a full page URL and select Analyse. The report has mobile and desktop views. Read both, but give particular attention to mobile because phones, processors and mobile networks often create more demanding conditions.
The report can contain two different kinds of evidence. Field data, when available, comes from the Chrome User Experience Report and summarises eligible real-user visits over a rolling 28-day period. Lab data is a Lighthouse simulation run for that test. The official PageSpeed Insights documentation explains this distinction.
If the report says there is not enough real-user data, do not interpret that as a pass or failure. Smaller and newer sites often lack a sufficient sample. Use the lab diagnostics, real-device checks and any analytics or monitoring you control.
Read the Core Web Vitals assessment correctly
The field section may report Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. A good result currently means LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1 at the 75th percentile.
Each describes a different part of the experience. LCP concerns when the largest relevant content element renders. INP concerns responsiveness to interactions. CLS concerns unexpected movement. A pass does not prove that a form works, the offer is clear or the page is accessible.
Read what Core Web Vitals mean for business owners for a plain-English explanation of every metric.
Treat the Lighthouse score as a diagnostic summary
The laboratory performance score is a weighted summary derived from several metrics under simulated conditions. Ninety or above is labelled good, but it is not the same as a real-user Core Web Vitals pass.
Run the same page at least three times. Server load, network variation and background conditions can move the result. Look for recurring findings: a very large main image, render-blocking resources, unused JavaScript or long main-thread tasks. Our guide to what counts as a good PageSpeed Insights score explains why the colour alone is not a business objective.
Do not compare a cached desktop visit on fast broadband with a simulated mobile test and conclude that one tool is wrong. They are describing different conditions.
Use Chrome DevTools for a closer look
Chrome DevTools includes Lighthouse, Network and Performance panels. The official Lighthouse guide explains how to run an audit from the browser.
In the Network panel, reload the page and look for unusually large files, requests that wait a long time, and third-party domains that dominate the waterfall. Sort by size to spot oversized photographs or video. Disable the cache when you want to model a first visit, then repeat with normal caching to understand a return visit.
The Performance panel can show long work on the browser’s main thread. You do not need to diagnose every technical entry yourself. Capture the recording or screenshots and ask a developer to explain which work blocks visible content or interaction.
Test on a real phone as well
Open each priority page on an ordinary phone, preferably on mobile data as well as Wi-Fi. Start with a private tab so an old cache does not make every page appear unusually quick.
Try to complete realistic tasks:
- identify the service and location;
- open and close the navigation;
- follow a call-to-action;
- use a filter, calculator or booking tool;
- complete the contact form without submitting test data unless appropriate;
- rotate the device and increase text size;
- return with the browser back button.
Notice blank screens, late-loading fonts, images that push text down and taps that appear ignored. These observations connect the metrics to customer friction.
If desktop looks fast while mobile struggles, use our guide to why websites can be faster on desktop than mobile to narrow down the causes.
Check throttled conditions without overclaiming
Browser simulations deliberately model constrained networks and processors. They are valuable because many customers do not use your office computer and connection, but they are still models rather than recordings of every visitor.
Use throttling to reproduce a problem and compare revisions. Keep the same preset when measuring before and after. Avoid quoting a single simulated result as the precise experience of all mobile users.
For businesses serving rural areas, travellers or customers inside large buildings, test under those realistic conditions where possible. A resilient page should still reveal its purpose and main next step while secondary media finishes loading.
Review the most useful diagnostics first
Large images
Check whether the main photograph is much larger than its displayed dimensions. Responsive source sizes, modern formats and sensible compression often reduce transfer without a noticeable loss of quality. Give the main image appropriate priority and lazy-load images below the fold where suitable.
Slow initial response
If the document waits before downloading, hosting, database work, application processing or geographic distance may be involved. Front-end image tweaks cannot fully compensate for a consistently slow server response.
Blocking scripts and styles
Large scripts can delay rendering and interaction. Remove unused code, split work sensibly and load non-essential integrations later. Essential styling should arrive efficiently enough to avoid a flash of broken or unstyled content.
Third-party services
Maps, analytics, consent tools, advertising, chat and booking widgets can add network requests and processing outside your control. Measure the value of each service and its cost. Do not remove legally or operationally necessary tools simply to improve a score.
Layout movement
Images and embeds should reserve their intended space. Banners or late content inserted above what someone is reading can cause accidental taps and frustration.
Turn results into an action list
For each issue, record the URL, device view, observed symptom, relevant diagnostic and customer task affected. Rank work by severity and reach. A broken contact button deserves attention before a minor score difference on an obscure article.
A practical action might read: “On the mobile service page, the 2.8 MB hero image delays the main heading and LCP; serve an appropriately sized image, then retest the same URL three times.” That is more useful than “make the site faster”.
Our complete website speed guide places testing within a longer-term performance process.
Compare changes fairly
Test the same page, tool, device category and conditions. Record several runs and use the stable pattern or median rather than selecting the best result. Check that the change did not damage image quality, accessibility, analytics, consent or functionality.
Field data will not change immediately because it covers a rolling period. Lab results and manual checks can reveal an immediate improvement, while real-user evidence takes time to accumulate.
When optimising, read how to make a website faster without losing its design before replacing every visual feature with an empty layout.
Common testing mistakes
- Testing only one URL or one run.
- Reporting desktop results as though they represent mobile.
- Confusing field evidence with a lab simulation.
- Chasing 100 while ignoring a broken form or unclear page.
- Comparing different pages before and after a redesign.
- Removing useful or required functionality without checking consequences.
- Assuming a fast result guarantees higher rankings or more enquiries.
Speed contributes to page experience, but relevant content, trust and usability still matter. Read how website speed relates to Google rankings for the limits of that connection.
A repeatable free testing routine
Run your selected URLs monthly and after meaningful changes. Save the results in a simple table. Add the page owner and the date an issue was resolved. Test again after new campaigns, images, plugins or integrations are introduced.
For a small site, this can take less than an hour and is more useful than checking the homepage score every morning. Larger or frequently changing sites may benefit from automated monitoring, but the same principles apply: representative pages, comparable conditions and customer tasks.
Frequently asked questions
Can I test a website before it is live?
Yes, Lighthouse and DevTools can assess a staging page, but PageSpeed Insights needs a publicly reachable URL and real-user field data will normally be absent. Ensure the staging version contains realistic images, fonts, consent tools and integrations.
Why does my score change every time?
Network, server and test variability affect lab runs. Repeat the test and focus on persistent bottlenecks rather than reacting to a few points.
Is PageSpeed Insights completely free?
The public tool is free to use. DevTools is included with Chrome. Your own monitoring platform, developer time or remediation work may have costs.
Should I test competitors?
Public pages can be tested, but you do not know their analytics, audience, infrastructure or business outcomes. Use comparisons for broad context, not as proof that copying a feature will help you.
Use the test findings to choose repairs
A useful speed test shows where visitors face delay and what the team should investigate. Combine free tools with real-device journeys, keep a repeatable record and improve the highest-impact problems first.
If recurring platform constraints make those fixes difficult, Afterworks can prepare a lightweight replacement for you to inspect before you decide. Explore our website rebuild service or contact us with your test findings.
