A website can feel fast on your own computer and still be frustratingly slow for your visitors.
Your browser may already have files cached. You may have a fast connection. You might be physically close to the server. Your visitors could be using a slower phone, a mobile connection or browsing from another country.
That is why website performance testing matters.
Rather than guessing what is slowing a website down, you can measure how it performs, identify the biggest bottlenecks and compare the results after making changes.
This guide explains how to test website performance properly, which metrics matter and how to turn the results into useful next steps.
Why Test Website Performance Before Optimising?
Performance tools can reveal problems that are difficult to spot simply by browsing a website yourself.
Testing gives you a baseline.
That baseline helps you answer questions such as:
- How quickly does the main content appear?
- How responsive does the page feel?
- Does content move around while loading?
- Is the server slow to respond?
- Are large images increasing the page weight?
- Is JavaScript keeping the browser busy?
- Are third-party services affecting performance?
- Does the experience differ between mobile and desktop?
Most importantly, a baseline lets you measure whether your optimisation work actually helped.
Without one, it is easy to install plugins, change caching settings or remove features without knowing whether the website became meaningfully faster.
Performance testing should therefore come before optimisation and continue after each significant change.
Understand Field Data and Lab Data
One of the most important things to understand about modern website performance testing is the difference between field data and lab data.
They measure different things.
Field data
Field data comes from real visitors using a website under real conditions.
Google’s Chrome User Experience Report, commonly called CrUX, collects eligible performance data from Chrome users and aggregates it over time.
This can reflect visitors using:
- Different devices
- Different network connections
- Different geographical locations
- Cached and uncached resources
- Different levels of device performance
PageSpeed Insights can display this real-user information when enough data is available.
Because field data represents actual visitors, it is particularly useful for answering the question:
What experience are real users having?
Lab data
Lab data is generated by running a controlled performance test.
Lighthouse, which powers the lab section of PageSpeed Insights, loads the page under predefined conditions and records what happens.
Lab tests are useful because they are repeatable and provide detailed diagnostics.
They help answer a different question:
What appears to be causing the performance problem?
You need both perspectives.
Field data can reveal that real visitors are experiencing a problem. Lab data can help you investigate why.
Why Field and Lab Results Can Be Different
Do not be surprised if field and lab results disagree.
That does not necessarily mean one of them is wrong.
A Lighthouse test represents one simulated visit under a specific set of conditions. Field data represents many real visits collected over time.
Differences can be caused by:
- Device performance
- Connection speed
- Visitor location
- Server load
- Caching
- Browser extensions
- Logged-in versus logged-out experiences
- Cookie banners
- Personalised content
- Third-party services
- Traffic patterns
A website could therefore perform well during one Lighthouse test while some real users continue to experience poor performance.
The reverse is also possible.
Use lab tests for diagnosis and repeatable comparisons. Use field data to understand the experience visitors are actually receiving.
Core Web Vitals to Watch
Core Web Vitals focus on three important parts of the user experience: loading, responsiveness and visual stability.
Largest Contentful Paint
Largest Contentful Paint, or LCP, measures how long it takes for the main visible content to appear.
For a good experience, LCP should be 2.5 seconds or less.
The LCP element may be:
- A hero image
- A banner
- A large heading
- A featured image
- A prominent block of text
If LCP is poor, the problem may involve the server, images, CSS, JavaScript, caching or the way an important resource is discovered by the browser.
Interaction to Next Paint
Interaction to Next Paint, or INP, measures how responsive a page is when someone interacts with it.
For a good experience, INP should be 200 milliseconds or less.
This can expose pages where buttons, menus, forms or other controls respond slowly because the browser is busy doing other work.
JavaScript is often involved when INP is poor.
Cumulative Layout Shift
Cumulative Layout Shift, or CLS, measures unexpected movement while a page is loading.
For a good experience, CLS should be 0.1 or less.
Examples include:
- Text moving after a font loads
- An image pushing content down
- A banner appearing above content
- An advert changing size
- An embedded element loading without reserved space
These shifts can be particularly frustrating when someone is about to click or tap something and the page suddenly moves.
Look beyond a single visit
Core Web Vitals field data is intended to represent a range of real visitor experiences rather than the result of one test.
This is why one fast Lighthouse result does not prove that everyone has a fast experience.
Use the field results where available and then use lab testing to investigate the individual pages that need attention.
Other Performance Metrics Worth Understanding
Core Web Vitals are important, but they are not the only useful measurements.
Time to First Byte
Time to First Byte, or TTFB, measures how long it takes before the browser starts receiving a response.
A slow TTFB can point towards areas such as:
- Hosting
- Server processing
- Database work
- Network latency
- Redirects
- Caching
Be careful about treating TTFB as a pure measurement of hosting speed, particularly with real-user data. The result can also be affected by network conditions, redirects, caching and other parts of the request.
First Contentful Paint
First Contentful Paint, or FCP, measures when the browser first displays something from the page.
This might be text, an image or another visible element.
It does not tell you when the most important content is ready, but it can help you understand how quickly the page begins to respond visually.
Page weight
Page weight is the amount of data needed to load a page.
Large pages can contain:
- Oversized images
- Video
- Large JavaScript files
- Fonts
- CSS
- Third-party resources
A heavier page is not automatically slow, but transferring unnecessary data can be particularly noticeable on mobile connections.
Number of requests
Each page may request dozens or even hundreds of resources.
These can include:
- Images
- Stylesheets
- JavaScript
- Fonts
- Analytics
- Advertising
- Tracking scripts
- Embedded services
Request count can help with diagnosis, but it should not be treated as a target by itself.
Modern browsers and protocols can handle multiple requests efficiently. One extremely large or slow resource may matter more than several small ones.
Main-thread work
JavaScript and other browser tasks can keep the main thread busy.
When that happens, a page may appear to have loaded but still respond slowly when the visitor tries to interact with it.
This is particularly important when investigating poor INP or sluggish menus, filters and forms.
How to Use PageSpeed Insights
PageSpeed Insights is a useful starting point because it brings field and lab information together.
Enter the URL you want to test and review the results for both mobile and desktop.
Start with the real-user section
Where enough information is available, PageSpeed Insights shows data from the Chrome User Experience Report.
This data reflects a rolling period of real-user experiences rather than one test performed at that moment.
Look first at:
- LCP
- INP
- CLS
You may also see supporting metrics such as FCP and TTFB.
Sometimes there is not enough real-user data for a specific URL.
In those cases, PageSpeed Insights may have less information available or may be able to show broader origin-level data instead.
Do not treat the absence of field data as a performance failure. It can simply mean that the page does not have enough eligible traffic for a useful sample.
Then review the Lighthouse test
The Lighthouse section provides a controlled lab test and diagnostics.
This is where you can start investigating why the page behaves the way it does.
The report may identify areas involving:
- Images
- JavaScript
- CSS
- Fonts
- Server response
- Third-party scripts
- Cache policies
- Render-blocking resources
Do not assume every recommendation deserves equal attention.
Look for the issues that have the greatest effect on the visitor experience.
Do Not Chase a Perfect Lighthouse Score
A score of 100 can feel satisfying, but it should not be the goal of performance work.
A website can score highly in one laboratory test while still having problems for real users.
Similarly, an otherwise excellent website can lose points because it includes a third-party service that is important to the business.
Performance decisions often involve trade-offs.
For example, you may genuinely need:
- Analytics
- A payment system
- Live chat
- Marketing tracking
- An embedded booking tool
- Consent management
- Video
The useful question is not simply:
How do I reach 100?
It is:
What is making the experience worse, and is there a sensible way to improve it?
How to Use WebPageTest
WebPageTest is useful when you want greater control over test conditions or need to investigate individual network requests.
Depending on the available testing options, you can choose factors such as:
- Location
- Device
- Browser
- Connection type
This helps you test scenarios that better resemble your actual visitors.
For example, a UK business serving mainly UK customers may get more useful results from an appropriate European test location than from testing only from another continent.
Likewise, a mobile-focused website should not be judged solely from a fast desktop connection.
Use the Waterfall to See What Is Loading
One of the most valuable parts of WebPageTest is the request waterfall.
The waterfall shows the resources requested while the page loads and how long they take.
This can help you spot:
- Slow server responses
- Large images
- Third-party scripts
- Fonts loading late
- Redirect chains
- Resources waiting on other resources
- Slow external domains
- Large JavaScript or CSS files
Instead of simply being told that the page is slow, you can start to see where the time is going.
That makes the waterfall particularly useful when a page has an obvious performance problem but the cause is not clear.
Run More Than One Test
Performance varies.
Server load changes. Networks fluctuate. Third-party services respond at different speeds.
For that reason, do not make an important decision based on one isolated test.
Run several tests under the same conditions and look for a consistent pattern.
If one result is dramatically different from the others, it may be an outlier rather than a reliable baseline.
You do not necessarily need dozens of tests for an ordinary website.
The aim is simply to avoid treating one result as absolute truth.
Keep Test Conditions Consistent
If you want to compare before and after results, use the same testing conditions.
Try to keep these consistent:
- URL
- Device
- Browser
- Test location
- Connection
- Logged-in or logged-out state
- Cookie state where relevant
- Testing tool
Otherwise, you may think an optimisation caused an improvement when the difference actually came from the test setup.
Record the important conditions with your baseline so you can recreate the test later.
Test More Than Your Homepage
The homepage is not the whole website.
Different templates can have completely different performance characteristics.
A useful test set might include:
- Homepage
- Main service page
- Blog article
- Landing page
- Contact page
- Product page
- Product category
- Basket
- Checkout
- Account area
You do not need to test every URL individually.
Choose representative pages from the important templates and journeys on the website.
For a WooCommerce site, the product and checkout experience may matter much more commercially than the homepage.
For a publisher, individual articles may be the pages receiving most organic traffic.
Test what your visitors actually use.
Test Mobile and Desktop Separately
A page can perform very differently on a phone compared with a desktop computer.
Mobile visitors may face:
- Less processing power
- Slower connections
- Higher network latency
- Smaller screens
- Different responsive layouts
- Different images
- Different navigation
Do not assume that a fast desktop result means the mobile experience is equally good.
For many websites, mobile performance should receive at least as much attention as desktop performance.
Test from Relevant Locations
The physical distance between visitors and infrastructure can affect performance.
If most of your customers are in the UK, test from a location that gives you a useful picture of the UK experience.
If you have an international audience, test from several important regions.
Large geographical differences may point towards the value of:
- Better hosting placement
- A CDN
- Improved caching
- Optimising external dependencies
Testing from locations your visitors never use may produce technically valid results but less useful business information.
When to Use Lighthouse Directly
PageSpeed Insights is convenient, but sometimes you want to run Lighthouse directly.
Chrome DevTools lets you run Lighthouse against a page while you are investigating it.
This can be useful during development and troubleshooting because you can make a change, rerun the audit and compare the result.
Lighthouse also checks areas beyond raw speed, including accessibility and best practices.
If you want to explore Lighthouse in more detail, see our guide on how to use Google Lighthouse.
For general performance testing, however, do not rely on Lighthouse alone. Combine controlled tests with real-user information where it is available.
How to Interpret the Results
Performance reports can contain a long list of warnings and recommendations.
Do not try to fix everything at once.
Start by looking for patterns.
Slow response before the page starts loading
Investigate:
- Hosting
- PHP processing
- Database performance
- Caching
- Redirects
- Server load
Main content appears slowly
Investigate:
- LCP element
- Large hero images
- Server response
- CSS
- Resource priority
- Fonts
- JavaScript
Page feels unresponsive
Investigate:
- JavaScript execution
- Third-party scripts
- Page builders
- Interactive plugins
- Main-thread work
Page moves while loading
Investigate:
- Image dimensions
- Fonts
- Banners
- Embedded content
- Advertising
- Dynamically inserted elements
Page is unusually heavy
Investigate:
- Images
- Video
- Fonts
- JavaScript bundles
- Third-party resources
The report is evidence. Use it to narrow down the likely cause before making changes.
Common Website Performance Testing Mistakes
Testing only once
One run can be unusually fast or unusually slow.
Repeat important tests and look for consistent results.
Comparing different test conditions
Changing the device, network or location can make before and after comparisons misleading.
Keep the conditions consistent.
Focusing only on the score
The score is a summary.
The metrics and diagnostics underneath it are usually more useful.
Treating every recommendation as equally important
Some improvements may save substantial time. Others may produce a tiny theoretical gain.
Prioritise the problems visitors are most likely to notice.
Testing only the homepage
Important templates and customer journeys can behave very differently.
Test representative pages.
Ignoring real-user data
A laboratory test can help diagnose a problem, but field data can tell you whether real visitors are experiencing it.
Use both where possible.
Making several changes at once
If you change caching, images, scripts and plugins all at the same time, you will not know which change caused the result.
Make controlled changes and retest.
Assuming faster always means better
Removing an important feature might make a page lighter, but that does not automatically make the website more useful.
Performance should support the purpose of the website.
A Simple Website Performance Testing Process
You do not need a complicated testing programme to make better decisions.
A practical process is:
- Choose representative pages.
- Run PageSpeed Insights for mobile and desktop.
- Record available field data.
- Record the main Lighthouse metrics and problems.
- Run repeatable tests in WebPageTest where deeper investigation is needed.
- Review the request waterfall for obvious bottlenecks.
- Identify the biggest issue worth addressing first.
- Make one controlled improvement.
- Clear the relevant caches.
- Repeat the same tests under the same conditions.
- Check that the website still works correctly.
- Record the result.
Continue with the next most important problem rather than trying to optimise everything at once.
Test Performance Throughout the Life of the Website
Performance testing should not be something you do only when a website becomes obviously slow.
Websites change.
Over time you may add:
- New plugins
- Larger images
- Tracking services
- Marketing tools
- Fonts
- Page-builder features
- Advertising
- Videos
- Integrations
- New templates
A site that was fast when it launched can gradually become heavier.
Testing during development and after significant changes makes it easier to spot regressions before they become larger problems.
For teams, it also encourages designers, developers, marketers and website owners to consider the performance cost of new features before they are added.
What to Do After You Find a Performance Problem
Testing tells you where to look. The next step is fixing the underlying cause.
That might involve:
- Improving hosting
- Configuring caching
- Optimising images
- Reducing unnecessary JavaScript
- Reviewing plugins
- Removing unused resources
- Improving fonts
- Addressing third-party scripts
- Fixing layout shifts
- Investigating database or server issues
For a practical walkthrough of those improvements, see our guide on how to speed up WordPress.
Then retest.
The most useful performance optimisation process is a cycle:
Measure, investigate, improve and measure again.
Final Website Performance Testing Checklist
When testing a website, remember to:
- Establish a baseline before making changes
- Check field and lab data separately
- Review LCP, INP and CLS
- Look at supporting metrics such as TTFB and FCP
- Test mobile and desktop
- Test representative pages
- Use relevant geographical locations
- Run important tests more than once
- Keep before and after conditions consistent
- Review waterfalls when you need deeper diagnostics
- Prioritise meaningful bottlenecks over perfect scores
- Make controlled changes
- Retest after each significant improvement
- Keep testing as the website evolves
Good website performance testing is not about collecting as many scores as possible.
It is about building a reliable picture of what visitors experience, identifying where time is being lost and using that evidence to make better decisions.
If you would rather not diagnose the results yourself, Newt Labs can investigate the performance problems and make the appropriate fixes through our one-off WordPress support service.
