Does website performance really matter?
Website performance is one of those things that's easy to overlook. If your website looks good and everything seems to work, it's tempting to assume that it's doing its job.
But how quickly your website loads can make a real difference to the experience people have with your business.
Most of us have little patience for a slow website. We expect pages to load quickly, images to appear when we need them and links to respond without hesitation. When that doesn't happen, it's easy to hit the back button and look somewhere else.
And it's not just about keeping visitors happy. Performance can affect conversions, usability, search visibility and how professional your business feels online.
After more than 20 years working in web development, it's something I take seriously. Our own website, Cloud Gray, scores 98 out of 100 for mobile performance and 99 out of 100 on desktop in Google PageSpeed Insights.
Getting those results took deliberate work, not just choosing a fast server and hoping for the best.
First impressions happen quickly
When someone visits your website, they're making judgements about your business almost immediately.
If the page loads quickly and the content appears where it's supposed to, the experience feels effortless. Visitors can get on with what they came to do.
But when a page takes too long to load, images appear slowly or the layout jumps around while the browser catches up, that experience changes. It can feel frustrating, unprofessional and, in some cases, unreliable.
A delay of a couple of seconds might not sound like much, but it can be enough to test someone's patience, particularly when they're browsing on a mobile phone or comparing several businesses.
Not every visitor will abandon a slow website, of course. It depends on what they're looking for, how motivated they are and what alternatives they have. But the longer you make people wait, the more opportunities you give them to leave.
For a business, that could mean a lost enquiry, an abandoned purchase or a potential customer choosing a competitor instead.
Your website doesn't need elaborate animations or impressive visual effects to make a good first impression. Sometimes, the most important thing it can do is simply load quickly and let people get on with what they came to do.
What actually makes a website slow?
There's rarely just one reason a website performs poorly. More often, it's a combination of decisions made during development, design and ongoing maintenance.
Some of the common culprits include:
- Oversized images. Uploading unnecessarily large images can add significant weight to a page, particularly on mobile connections. Choosing appropriate dimensions and using efficient formats such as WebP or AVIF can make a substantial difference.
- Too much JavaScript. Scripts can add processing overhead, delay interaction and compete with other resources the browser needs to load.
- Render-blocking CSS and JavaScript. Some resources can prevent the browser from displaying the page until they're downloaded and processed.
- Too many plugins and dependencies. Every additional component can introduce more code, requests or third-party services that need to be loaded.
- Third-party scripts. Analytics, advertising, chat widgets, embedded content and tracking tools can all affect performance, particularly when they're loaded unnecessarily or inefficiently.
- Poor hosting or server configuration. Even a well-built website can feel sluggish if the server takes too long to respond or isn't configured appropriately.
- Layout shifts. When images, fonts or other elements load without their space being accounted for, content can jump around as the page renders.
Some of these issues are relatively easy to fix. Others require a closer look at how the website has been built and how the browser loads its resources.
That's why simply upgrading your hosting doesn't always solve the problem. If the underlying website is bloated or inefficient, a faster server can only do so much.
The problem with website bloat
One of the things I often consider when assessing a website is how much it needs to load just to display a page.
Some websites carry a surprising amount of unnecessary weight. Large page-builder frameworks, multiple plugins, duplicated scripts and libraries that are barely used can all contribute to the problem.
WordPress is a good example of where this can happen.
WordPress itself isn't inherently slow. It can be used to build fast, well-optimised websites, and there are plenty of developers who do exactly that.
The problem is how some WordPress websites are put together.
A typical build might combine a theme, a page builder, several plugins and a collection of third-party integrations. Each component can bring its own CSS, JavaScript, dependencies and assumptions about how the page should work.
Over time, this can become difficult to manage. A seemingly small change might introduce another script, a plugin update might add more overhead, or a page builder might load resources that aren't needed on a particular page.
You can spend a considerable amount of time trying to optimise a website while working around decisions made by the tools used to build it in the first place.
Page builders can be convenient, particularly for people who want to create and edit layouts themselves. But convenience doesn't automatically translate into efficient output. The more layers involved, the harder it can be to control every aspect of what gets delivered to the browser.
This is one of the reasons I prefer custom development for projects where performance, flexibility and long-term maintainability matter. It gives us much greater control over the code, the assets and the way the page is assembled.
That doesn't mean every website needs to be custom-built, or that a WordPress website can't perform well. It means the underlying implementation matters, regardless of which platform you choose.
Does website performance help SEO?
Yes, performance can contribute to SEO, but it's worth understanding how.
Google uses Core Web Vitals as part of its page experience assessment. These metrics measure aspects of how a page loads, responds to interaction and maintains visual stability.
The three main metrics are:
- Largest Contentful Paint (LCP): how quickly the main content becomes visible.
- Interaction to Next Paint (INP): how quickly the page responds visually to user interactions.
- Cumulative Layout Shift (CLS): how much the page layout unexpectedly moves around.
Google's recommended thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS score of 0.1 or less. These are assessed at the 75th percentile of page visits, rather than simply from a single test.
You can read more about them in Google's Core Web Vitals documentation.
Performance is a ranking consideration, but a good score doesn't guarantee a higher position in search results. Google considers many factors, including the relevance and quality of the content, how well it meets the searcher's needs and the overall quality of the website.
A fast website with poor content isn't suddenly going to outrank a genuinely useful competitor just because it loads more quickly.
However, performance is still worth getting right. It helps remove friction from the experience, makes the website more usable and supports the other work you're doing to improve your search visibility.
It also makes sense to think about performance alongside SEO from the beginning, rather than treating it as a separate problem to solve later.
How we approach performance
Our own website is something I've spent a considerable amount of time optimising.
Cloud Gray scores 98 out of 100 for mobile performance and 99 out of 100 on desktop in PageSpeed Insights, alongside scores of 100 for accessibility, best practices and SEO on both.
Those numbers didn't happen by accident. They came from looking closely at what the browser needs to do to render the page and removing as much unnecessary work as possible.
There are a few things worth highlighting.
Inline critical CSS
One of the changes that made a difference was implementing inline critical CSS.
Normally, a browser needs to request and process external stylesheets before it can fully render a page. Depending on how those stylesheets are loaded, this can delay the initial display of content.
Critical CSS takes a different approach. The CSS required to render the initial view of the page is included directly in the HTML, allowing the browser to establish the basic appearance without waiting for a separate stylesheet request.
This means the page can display its essential layout and styling much earlier. It also helps avoid situations where visitors briefly see an unstyled page or the layout shifts as styles are applied.
The rest of the styles can then be loaded separately.
It's not simply a matter of copying all your CSS into the page. Critical CSS needs to be carefully selected, and the remaining styles need to load correctly. But when implemented well, it can improve the initial rendering experience and help reduce layout shifts.
Serving assets through a CDN
We also serve our stylesheets and images from a separate domain running through Cloudflare.
A content delivery network (CDN) distributes or caches resources across its network, allowing visitors to retrieve assets from an appropriate location rather than always fetching them directly from the origin server.
This can improve delivery times, particularly for visitors who are geographically distant from the server. It also helps with caching and reduces some of the work required from the origin infrastructure.
A CDN isn't a magic solution for a poorly built website, though. It doesn't remove unnecessary JavaScript or fix inefficient code. It works best as part of a broader performance strategy.
Keeping control of what loads
Perhaps the most important part is having control over how the website is built.
We can decide which resources a page needs, how they're loaded, how images are delivered and which scripts should run. We can avoid loading unnecessary dependencies and make deliberate decisions about what the browser needs to render the content.
That control makes it easier to optimise the website as a whole, rather than constantly working around the limitations of an assortment of tools and plugins.
It's also why performance shouldn't be left until the end of a project. The decisions that have the biggest impact are often made much earlier, when the structure and approach to development are being established.
Is a perfect PageSpeed score necessary?
No, and chasing a score of 100 at all costs can become counterproductive.
PageSpeed Insights is a useful diagnostic tool. It identifies potential issues and provides a repeatable way to test how a page performs under particular conditions.
But its performance score is based on a simulated test environment. It isn't a complete picture of how every visitor experiences the website in the real world.
Actual results vary depending on the device, network connection, browser, location and the page being visited. Real-user data, where available, provides another important perspective.
It's also possible to spend hours trying to gain a single additional point while making very little practical difference to the experience.
The goal shouldn't be to win a competition against a testing tool. It should be to build a website that loads quickly, responds well and remains stable for the people using it.
Our scores are something I'm proud of because I know the work behind them. But the more important outcome is having a website that delivers its content efficiently without unnecessary overhead.
Performance is part of building a good website
Website performance isn't just a technical detail for developers to worry about. It affects how people experience your business, how easily they can use your website and, potentially, whether they stay long enough to become a customer.
It can also support your SEO efforts, although it needs to sit alongside useful content, sound technical foundations and a website that meets the needs of its audience.
If your website is slow, the answer isn't necessarily to replace your hosting or rebuild everything from scratch. The first step is to understand what's causing the problem and which improvements are likely to make the biggest difference.
Sometimes, it's a matter of optimising images or removing unnecessary scripts. Other times, the underlying build needs a more substantial rethink.
At Cloud Gray, we believe performance should be considered from the beginning, not bolted on as an afterthought. A well-built website should do what it needs to do without making visitors wait for it.
If you're concerned about your website's performance, or you're not sure what's holding it back, we can help you identify the issues and work out what to do next.
Get in touch with Cloud Gray to discuss your website or arrange an audit.
