Want to run a website speed test? Open Google PageSpeed Insights, enter the full URL of a public page, and check the mobile and desktop reports. Then look beyond the score: understand the real-user measurements, read the Lighthouse diagnostics, and choose one problem you can verify and improve. You do not need a WordPress plugin to run the test.
This guide is for beginners, freelancers, and small organizations who want to run a website speed test before making changes. The practical examples use self-hosted WordPress, but Google PageSpeed Insights can test other public websites too. It does not change your website settings.
Key takeaways
- Test a specific page URL, then repeat the check for other important pages.
- Compare mobile and desktop separately; their testing conditions are not identical.
- Real-user field data covers a longer period, while Lighthouse lab data helps you investigate problems.
- Use Core Web Vitals to understand loading, responsiveness, and unexpected layout shifts.
- Save a baseline and fix one significant issue before testing again.
1. Run a website speed test with Google PageSpeed Insights
Start with the free Google PageSpeed Insights tool. It checks a public page and provides performance information without needing access to your WordPress admin dashboard. This first website speed test should help you decide what to investigate, not tempt you into installing multiple optimization plugins.
- Open PageSpeed Insights in your browser.
- Enter the complete URL of your homepage, including https://.
- Select Analyze to run the report.
- Read the Mobile results first, then switch to Desktop.
- Run the same test for an important service page, article, or contact page. Different templates and embedded features can produce different results.
- Record the date, URL, device category, and main warnings. Keep that record for your next test.
If a page is private, requires a login, or lives in a protected staging environment, a public PageSpeed Insights test may not work. Use an appropriate authenticated development tool instead of removing protection just to obtain a score.
2. Understand field data versus Lighthouse lab data
When you use Google PageSpeed Insights, you may see two kinds of results. Field data describes anonymized experiences from real Chrome users, where enough data is available. These measurements come from the Chrome User Experience Report (CrUX) and reflect the preceding 28-day period. Lab data comes from a simulated Lighthouse test and helps you debug specific page-load problems.
New or low-traffic websites may not have enough samples for page-level field data. The tool may show information for the whole origin or no real-user data at all. Neither outcome automatically means your site is broken. Google’s official PageSpeed Insights documentation explains the distinction and what missing data means.
What do the colored performance scores mean?
A website speed test using Lighthouse commonly uses these performance score ranges: 90–100 is good, 50–89 needs improvement, and 0–49 is poor. A score can vary across runs because the simulated conditions are not perfectly identical. Treat it as diagnostic guidance, not a promise that every real visitor experiences the same speed.
3. WordPress speed test: read the three Core Web Vitals
A useful website speed test explains more than how long a page takes to load. Core Web Vitals cover three distinct parts of the visitor experience. Google’s Web Vitals guidance recommends these good thresholds:
LCP (loading). Measures how long it takes for the largest visible content element to appear. Aim for 2.5 seconds or less.
INP (responsiveness). Measures how quickly the page responds to user interactions. Aim for 200 milliseconds or less.
CLS (visual stability). Measures how much visible content shifts unexpectedly. Aim for 0.1 or less.
The Core Web Vitals assessment in a website speed test is based on real-user measurements when enough data is available. A single laboratory run can help diagnose loading and layout behavior, but it cannot replace real-user interaction measurements. If your site has no field data yet, use the lab report carefully as a starting point.
4. Turn a warning into a sensible next step
Slow LCP: examine what loads first
If your website speed test shows that the main content appears late, inspect the largest image, hero background, fonts, and server response. An oversized hero image can be a clear problem, but a slow server or unnecessary render-blocking resources might be just as important. Fix what your report actually identifies.
Poor INP: check menus, forms, and heavy scripts
When a website speed test highlights slow interactions, demanding JavaScript or busy page components may be involved. Check widgets, analytics scripts, and other code running on the page. After a change, test real navigation and form submission rather than relying on the performance score alone.
High CLS: stop content jumping around
Images without reserved space, late-loading banners, and changing fonts can move content unexpectedly. Check the page on a phone and review which elements shift while it loads. Fix the cause rather than hiding the symptom with additional effects.
This guide helps you measure and interpret. After your website speed test, the separate WordPress speed optimization guide covers images, caching, plugins, hosting checks, and safer retesting in detail.
5. Retest fairly after one change
- Save your first website speed test results. Make a working backup before changing WordPress settings that could affect a live site.
- Choose one documented problem and make the smallest sensible adjustment. Use a private staging copy for changes that might affect checkout, forms, or navigation.
- Run the same URL on the same device category again. Repeat the laboratory test when possible to reduce the effect of an unusual run.
- Check that the page still works for real visitors: mobile menus, consent controls, forms, and any dynamic content.
- Record what changed, whether the warning improved, and whether functionality was preserved. Revert a harmful change.
Remember that field data reflects a rolling historical period. It will not instantly mirror an update made five minutes ago. Lighthouse lab results can react sooner but are more variable. Use consistent comparisons and meaningful user outcomes rather than chasing one perfect score.
Common mistakes when testing a website
- Testing only the homepage while an important landing page is much slower.
- Comparing a mobile result with a desktop result as if they used the same conditions.
- Treating a missing CrUX dataset as proof that the page is broken.
- Changing five optimization settings at once, then not knowing which change helped.
- Removing useful features merely to achieve a green number.
Frequently asked questions
Can I run a website speed test without installing a plugin?
Yes. PageSpeed Insights only needs a public URL. You can check a WordPress site without adding anything to its dashboard.
Why is my mobile score lower than desktop?
Mobile and desktop Lighthouse tests simulate different devices and network conditions. Compare each category to its own earlier results and inspect the actual warnings.
Why does my WordPress speed test show no real-user data?
Your WordPress speed test may have no field data because the page or domain lacks enough qualifying measurements in the CrUX dataset. The lab report can still help you identify possible bottlenecks.
Will a perfect PageSpeed score make my page rank first?
No. A fast, usable experience is valuable, but search rankings also depend on relevance, helpful information, and many other factors. Do not sacrifice a useful feature just to gain a few points.
Website speed test: start with one measurable improvement
Pick the page that matters most to your visitors. Run a baseline website speed test, investigate the clearest issue, and compare the result after a careful change. If the report feels confusing, contact WebMoxx about a free, no-obligation initial speed check. Share your website URL and what you noticed, but never send passwords or login codes.
