What is website performance, and why does speed matter?

What is website performance?

Website performance is the experience your site delivers to a real visitor: how quickly pages appear, how fast they respond when tapped or clicked, how stable the layout is while loading, and whether all of that holds up when many people arrive at once. It is measured from the visitor’s side of the screen, not the server’s.

That definition has three faces, and it helps to name them early because the rest of this series keeps returning to them:

• Speed. How long until the visitor sees and can use the page. This is the face everyone means first.
• Stability. Whether the page behaves predictably while it loads: no buttons jumping away from a tap, no half-rendered layouts.
• Capacity. Whether speed and stability survive traffic. A page that is quick for one visitor and unusable for a crowd does not perform; it demos.

A site can do well on the first two on a quiet afternoon and still fail the third at its most valuable hour. Holding that thought is the single most useful habit a beginner can build, and it is where this guide is heading.

Why does website speed matter?

Website speed matters because visitors act on it with their wallets and their patience. The relationship between delay and lost business is not folklore; it is one of the most repeatedly measured effects in ecommerce, and the measurements are blunt.

Akamai’s retail performance study, built on roughly ten billion user visits, found that a 100-millisecond delay cut conversion rates by 7 percent, and that a two-second delay in load time drove bounce rates up 103 percent (2017). Portent’s later analysis of more than one hundred million page views found a site that loads in one second converts about 2.5 times better than one that loads in five, with B2C conversion falling roughly 0.3 percentage points for every additional second (2022).

The effect also runs in the happy direction. When Rakuten 24 optimised its user experience metrics and A/B tested the result, the faster version delivered a 53.37 percent increase in revenue per visitor and a 33.13 percent increase in conversion rate against the unoptimised page (2022).

It is worth doing this arithmetic once with plausible shop numbers, because the abstractions hide how blunt the effect is. Take a store with 50,000 sessions a month, a 2 percent conversion rate, and a 60 pound average order: that is 1,000 orders and 60,000 pounds a month. Apply Portent’s measured decay of roughly 0.3 percentage points per extra second, and a single second of added load time drags conversion toward 1.7 percent, about 850 orders and 51,000 pounds. One second, nine thousand pounds a month, and nothing else changed. Your own numbers will differ; the shape of the arithmetic will not.

There is also a human mechanism underneath the statistics, and it is mundane: waiting feels like friction, friction feels like doubt, and doubt has a back button. Nobody abandons a purchase because a spinner offended them. They abandon because the delay gave them a moment to reconsider, and the competitor’s tab was already open.

Numbers like these are why speed belongs in business conversations, not just engineering ones. A second is not a technical detail. At scale, it is a line in the revenue forecast.

Does website speed affect search rankings?

Yes, as one signal among many, and it is worth stating carefully because this question attracts overclaims. Google’s own documentation says that good Core Web Vitals, its three user experience metrics, align with what its core ranking systems seek to reward, and it recommends achieving them for success with Search.

Core Web Vitals are three specific measurements: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. We cover LCP in its own explainer; for now the useful fact is that most of the web still fails at least one of the three. The Web Almanac’s analysis of July 2025 field data found only 48 percent of mobile sites and 56 percent of desktop sites pass all three, with LCP the metric that fails most. By the January 2026 data, 55.7 percent of origins passed all three, improving but hardly universal.

Two honest cautions belong here. Google assesses page experience across its systems rather than as a single switch you flip, and no one outside Google can tell you the exact weight speed carries for a given query. Treat the vitals as a floor the web is slowly climbing toward, not a growth hack.

Read that as an opportunity rather than a threat. Speed will not rank a page whose content deserves to lose. But when half the field fails the experience bar, clearing it is a real, durable edge, and unlike most ranking factors, this one also pays you directly through conversion.

Speed and capacity are different problems

Here is the distinction most speed articles skip, and the one that matters most as your traffic grows: your site has two speeds. There is the speed a test tool sees on a quiet afternoon, and the speed your customers get at your busiest moment, when caches miss, databases queue, and third-party services are having their busiest moment too. The business only experiences the second one.

Both matter, and they fail independently. A heavy, sluggish page is slow at any traffic level. A lean, well-built page can still collapse at peak because checkout was never rehearsed with a crowd, which is exactly the failure the Black Friday countdown in part 1 exists to prevent. When you are ready for that second question, what load testing is is the natural next read; this is also the territory Evaluat works in, measuring pages in real browsers while realistic traffic runs. What users see, not what scripts pretend.

How is website performance measured?

Website performance is measured three ways, in increasing order of realism: lab tests that load one page in a controlled tool, field data collected from real visitors, and load testing that simulates the traffic you expect. Each answers a different question, and each catches problems the other two miss, which is why a complete picture uses all three rather than crowning one.

The metrics themselves are shared across all three methods. Google’s thresholds for its Core Web Vitals give beginners a usable frame: LCP within 2.5 seconds, INP within 200 milliseconds, and CLS at 0.1 or below, each judged at the 75th percentile of visits, meaning most visitors, not the average one, must have a good experience for the page to pass.

Lab tests load one page, once, in a controlled tool, and report metrics plus advice. They are repeatable and free, which makes them the right first step; a free real-browser speed test will show you LCP and CLS along with a video of the load. Their limit is the word “once”: one page, one visitor, one moment.

Field data is collected from real visitors as they browse, and answers what people actually experienced across devices and networks. It is the truth, but it is backward-looking: it can only report on traffic you already had, after they already felt it.

Testing under load simulates the traffic you have not had yet, the launch, the sale, the campaign, and measures what pages feel like while it runs. This is the only way to see the capacity face of performance before your customers do. Our explainer on Core Web Vitals under load covers why quiet-day metrics and peak metrics can be different numbers entirely.

Beginners often stop at the first tool because it gives a satisfying score. The score is real, but it grades one face of a three-faced thing.

Why do websites get slow?

Websites get slow for two distinct families of reasons, and it pays to keep them separate in your head, because the diagnosis and the fix are different for each.

On a quiet day: weight and distance

Everyday slowness is mostly about how much the page carries and how far it travels. Pages have grown relentlessly: the median mobile page now weighs 2.6 MB and makes 72 requests, up 8.4 percent in a year (Web Almanac, 2025). Every one of those requests, images, fonts, stylesheets, and above all scripts, is something the visitor’s browser must fetch and process before the page settles.

Third-party scripts deserve a special mention because nobody feels responsible for them: analytics tags, chat widgets, ad pixels, and review embeds are each pasted in for a good reason, and collectively they are often the heaviest thing on the page. Add a server that is far from the visitor or slow to respond, and delay stacks up before your own code even runs. Later parts of this guide take these apart one at a time.

Under traffic: contention and queues

At peak, the causes change shape entirely. A cache, the mechanism that keeps a ready-made copy of a page so it can be served instantly, makes product pages fast for everyone. But carts, logins, and checkouts cannot be served from a copy; they are personal, so they land on your origin systems at full force. Databases that answered in milliseconds start to queue requests. The payment and search services you depend on slow down at exactly the moment everyone else is leaning on them too.

None of this is visible on a quiet-day test, which is why the two-speeds distinction above keeps mattering, and why the later parts of this series treat capacity as its own subject rather than a footnote to speed.

The encouraging part: these causes are diagnosable and fixable, one at a time, and the rest of this beginner’s guide works through them in order, from metrics to test types to bottlenecks.

Common mistakes when thinking about performance

The mistakes beginners make with performance are rarely technical. They are framing mistakes: measuring the wrong thing, or the right thing at the wrong moment, and then trusting the number. These five cover most of the trouble, and each has a one-line correction.

• Treating a speed score as the goal. A score summarises one lab load of one page. Chase the visitor experience it approximates, not the number itself.
• Testing only the homepage. Money paths, search, cart, checkout, are usually slower and always less cacheable. Test what earns revenue.
• Assuming quiet-day speed survives traffic. Capacity is its own property, provable only under load. Fast at one visitor says little about fast at a thousand.
• Averaging away the pain. An average response time hides the slow tail where abandonment lives. Distributions and percentiles tell the truth; averages keep secrets.
• Optimising once and moving on. Pages regain weight the way desks regain clutter, one small addition at a time. Performance is a habit with a review date, not a project with an end date.

Website performance, then: the experience real visitors get, in three faces, speed, stability, and capacity, measured three ways, and paid for in conversion whether you measure it or not. Start with a free test of your busiest page today, and when the question becomes “will this hold on our biggest day”, graduate to testing under load.

Test in real browsers. Debug in real sessions. Book a demo to see your own pages measured with realistic traffic on them.