The short answer
A slow website can get in the way of reading about a service, browsing projects or sending an enquiry. A performance score alone cannot show where that friction occurs or how many enquiries it costs you. Combine technical measurements with practical checks of the tasks visitors need to complete. On a phone, for example, check how long the main information takes to appear and what happens after someone presses the form's submit button.
A fast-loading page can still attract few enquiries if visitors cannot understand the service. Another page may explain the service clearly but leave visitors waiting after they submit a form. The solutions to these two problems are not the same. Start by finding where visitors have to wait.
This guide explains what site speed means to business owners and how to prioritise improvement work. The goal is not to memorise technical terms, but to relate the measurement report to the customer experience. This helps you spend the budget on obstacles visitors encounter and check whether the changes make their tasks easier.
Site speed is not a single number
The first text appearing, a large image loading and a button becoming responsive are different moments in the page experience. Visitors need to find the information they came for and continue without unnecessary delays. Even if visitors do not need to wait for every resource to load, they may still have to wait for the menu to respond.
So ask what the phrase “site loads in two seconds” measures. Which page, which device, which connection and what test conditions were used? The same site can provide different experiences for different users. A fast connection on a powerful computer does not represent all visitors.
Don't limit the review to the home page. The visitor coming from the advertisement can directly reach the service page. The person requesting a quote can use a file upload area. Check where delays occur during each important customer task so you can target the cause.
What do Core Web Vitals mean for your business?
Google's Core Web Vitals metrics focus on loading, responsiveness and visual stability. Current measurements are LCP, INP and CLS. Good experience thresholds are defined as no more than 2.5 seconds, 200 milliseconds, and 0.1, respectively. The 75th percentile of actual visits is used in the evaluation.
From a business perspective, you can relate these concepts to tasks. The late appearance of the main content delays the visitor's review of the service. No response for a long time after pressing the menu makes interaction difficult. Shifting the page layout may direct the user to the wrong item.
These measurements are not a guarantee of commercial results. A page with good values may still appeal to the wrong audience. Following performance improvement, service clarity, form reliability and the nature of incoming enquiries should also be examined. Technical quality is an important but not the only part of the customer journey.
Why are lab testing and real user data different?
Laboratory testing provides an examination that can be repeated under certain conditions. Testing under the same conditions before and after the change makes it easier to investigate problems. However, no single test is representative of all visitors' different devices and connections.
Field data reflects the experiences of people visiting the site under different conditions. This data may depend on sufficient volume and observation period. It's possible for a new or low-traffic site to have no data available. Don't automatically interpret the absence of data as good or bad performance.
Use both approaches together. Use lab tests to diagnose and fix a specific problem; monitor the overall experience when appropriate real user data becomes available. When presenting a report, indicate which result came from which measurement. Thus, the comparison is made between the same type of data.
What problems do large images and videos create?
Images may be necessary for the content, but their display dimensions and file sizes should suit their purpose. Using a very large source file on a small card may result in data downloading for details the visitor does not see. Separate the visual production process from the web publishing process.
Make a similar evaluation for the video in the main section. Does the video add to the understanding of the service or does it just add movement? Could an alternative image be sufficient for mobile use? The decision should be made based on the contribution of the visual preference to the user task.
Do not completely sacrifice image quality when optimising. A project screen with unreadable text or a distorted product photo becomes another problem. Check samples of different sizes and establish a publishing workflow that preserves the required quality.
How do external tools affect the page experience?
Chat tools, maps, video players, and analytics tags can add additional load to the page. Each can be useful from a business perspective; but it may not be necessary to load them all on all pages. For each tool, check what it does and which pages need it.
First list what external tools are available on the site. Tags from unused accounts or old campaigns may still be loading. Before removing a tool, verify which functionality it supports; don't disrupt essential business processes to gain speed.
If external tools load slowly, the base page should continue to operate. When the map is not opened, the address can be found as text. The contact form or email path may be visible when the chat tool is not available. Not having the customer depend on a single external service makes the experience more resilient.
Also review form performance
Just because the page containing the form opens quickly does not indicate that the submission process is working well. The user must understand that the process is in progress when they press the button. Indefinite waiting may result in the same request being sent again or the person leaving the page.
Try successful and unsuccessful cases separately. What happens when the connection slows down? Is the written message preserved when the server fails? Can the user try again? A speed test of the homepage alone may not reveal these problems.
Also verify delivery of the message to the business. There should be consistency between the on-screen confirmation and the email or record in the customer management system. Skipping verification and reliable delivery steps in order to speed up the submission process is not the right solution.
How do you investigate the effect of speed problems on lost enquiries?
Compare similar visits first. If the source of mobile and desktop traffic to the same service page is different, you can't attribute the conversion difference solely to device performance. Traffic source, period and page purpose should be considered together.
Track both enquiry numbers and conversion rates. If there are a small number of visits or applications in a week, small changes can add up to large percentages. In this case, repeatable usage errors and customer feedback can lead the way sooner than statistical comparison.
Keep a change log. If the advertising campaign and service text also changed on the day you performed visual optimisation, it becomes difficult to distinguish which change produced the result. Whenever possible, implement significant changes in a controlled manner and record the evaluation conditions.
Which pages should you choose for the first review?
Select commercially critical pages along with the most visited pages. The main service, project example and contact journey can be a good start. Fixing the score of a very rarely used page should not take precedence over a problem with a form used every day.
Write a task for each page. For example, “read the scope of service and open the quote request form” or “find the relevant project and access contact information.” Try the task again under the same conditions. You can also use observations from people outside your team to understand users' different behaviours.
Don't just write "slow" when recording the problem. Specify which step, on which device, and what kind of wait. Repeatable observation makes it easier for the development team to find and subsequently validate the solution.
How should you prioritise improvements?
When prioritising, consider impact, frequency and effort required to fix the issue together. A minor fix that affects a large number of users may be worth addressing first. Larger infrastructure changes should only be brought to the agenda when it is shown that the problem cannot be solved in the current structure.
| Observation | Initial research | Success check |
|---|---|---|
| Main content appears late | Initial resources and server response | Check when content appears under the same conditions |
| Menu reacts slowly | Tasks that block interaction | Using the menu on the real device |
| Button shifting | Items that subsequently take up space | Complete the task without unexpected layout shifts |
| Form waiting for long time | Submission process and connected systems | Clear status message and verified delivery |
| Only one page slow | Page specific widgets | Retest of the relevant page |
Is it necessary to rebuild the entire site for speed?
It's not always necessary. If the issue is caused by large images, unused widgets, or a specific page component, targeted fixes may be sufficient. Diagnose the cause before deciding how much work is needed. The new technology name alone is not evidence of faster experience.
If limitations in the current system consistently hinder improvement, more comprehensive change may be considered. In this case, take into account not only the speed of the new site, but also the cost of content migration, management and maintenance. Be careful not to make other tasks difficult while solving a problem.
Pixel's site refresh guide further addresses the scope of this decision. You can use the findings of the speed review as input into the renewal decision; do not make the score alone the deciding factor.
Example: a focused performance review
Imagine that a business with two service pages has seen fewer enquiries from mobile visitors. Doing well in the homepage test does not prove that the problem is unrelated to performance. First, the page and form path that visitors actually use should be determined. Maybe the newly added external tool is only being loaded on the service page.
In the first review, read the service description on the same phone and open the form. Is the wait only on the menu, on form submission, or on the initial content? Then relate the technical measurement to the observation. This way, you can focus on a specific component rather than rewriting the entire site.
After the fix, try the same task again. Look for the successful completion of the affected task rather than an increase in the homepage score. While evaluating the number of enquiries, also record whether the advertisement or campaign has changed during the same period. This example shows that performance work requires diagnosis and verification; it does not predict a specific rate of increase.
Keep performance gains when adding content
Performance gains can be lost when new files are added to the site. The team adding content must know what image sizes to use and how to publish videos. If the rules that remain with the technical team are not transferred to the daily content work, the same problem may occur again.
Prepare a simple publishing checklist. Check that the new image is the correct size, the text reads on mobile, and the added tool works where it should. Not every blog post requires extensive technical auditing; monitoring a short list of known risks may be sufficient.
For larger changes, keep the initial measurement. When a new design section or external service is added, you can compare with previous experience. In this way, performance becomes a part of content and design production, not a cleaning job remembered later. Once the problem is noticed, it becomes easier to find out which change it started with.
Determine who is responsible for this follow-up within the business. The person adding content should know who to notify if they see a problem, and the technical team should understand which pages are commercially important. Shared responsibility prevents reports from simply remaining in a technical folder.
When sharing the performance report, write down the observed customer task as well as the technical score. Phrases like “mobile menu opens at first touch” or “form explains pending status” help non-technical teams understand the outcome. If the problem is not completely resolved, clearly state the unresolved issue. This way, the next review does not start by reinterpreting the previous report. If the measurement and usage observation are found in the same record, both the developer and the business can evaluate the same result.
Address performance through customer tasks
Select a service page and a contact path for initial review. Complete this path on the real phone and record the waits. Create a priority list by combining technical measurements with your observations.
You can share with Pixel the problems you are experiencing on your current site, and review the experience approach in our web design service. Starting with a specific usability problem makes it easier to determine what improvement is truly needed.
Frequently asked questions
Does my website need a perfect performance score?
A full score does not indicate that the business meets all user needs. It makes more sense to troubleshoot critical issues, complete tasks on real devices, and monitor appropriate field data. Use the score to investigate problems, alongside evidence of how visitors use the site.
Will more expensive hosting solve the problem?
It might help if the issue is server capacity or response time. However, it alone may not fix large images, heavy external tools, or buggy interactions. First find the bottleneck, then determine what problem you expect the hosting change to solve.
Should we remove all animations?
No. Meaningful and well-implemented animations can be preserved. Effects that delay user tasks, hide content, or strain the device should be reviewed. Decide based on how the effect helps or hinders visitors, rather than removing it simply because it is animated.
Will there be more enquiries immediately after the improvement?
There is no such guarantee. The visitors you attract, the relevance of your offer and how you handle enquiries also affect the outcome. First verify that the corrected problem has actually gone away, then review business results over a period suited to your traffic and sales cycle.
