Why Your Website Loads Slowly and What It Can Cost You

A website loads slowly almost always for one of three reasons: images heavier than they need to be, too much third-party code (plugins, scripts, visual builders) or a server that is slow to respond. What that costs you has no honest figure that holds for every business. There are documented cases from big companies, and there is a simple way to measure it on your own site. Here are both.

What "slow" means according to Google

Google sums up the experience of a page in three indicators called Core Web Vitals. Each one measures something your customer notices without knowing its name:

• LCP: how soon the main content appears. It counts as good if it happens within the first 2.5 seconds of loading.
• INP: how quickly the page responds when you tap something. It is good at 200 milliseconds or less.
• CLS: how much the content jumps around without warning while you load it. It is good at 0.1 or less.

Google's recommendation is to evaluate the 75th percentile of visits, which means three out of four visits meet the threshold, not just the perfect visit. And when measuring, it helps to separate two kinds of data: lab data, a simulated test with a fixed device and network that is good for finding problems, and field data, which comes from real users with their own phones and connections. Google warns that the two can differ.

The three most common causes

1. Images that weigh too much

The 2025 Web Almanac from HTTP Archive, which analyzes millions of sites, found that images contribute the most bytes to a page, ahead of JavaScript and fonts. On the median mobile home page, about 911 KB was images, against 632 KB of JavaScript. web.dev's guidance for improving LCP asks you to serve each image at the size it is actually shown, use modern formats such as AVIF or WebP, compress it, and never lazy-load the main image on the page, because that delays exactly what the visitor is waiting to see.

2. Accumulated third-party code

For content management systems that are extended with add-ons, the same Web Almanac says page weight depends less on the core and more on the accumulated effect of themes, plugins, page builders and third-party tools; page builders often generate more complex markup and larger CSS and JavaScript bundles. Don't jump to simplistic conclusions: the study also says that, on WordPress, the variation in performance comes more from configuration than from the core. On mobile in 2025, 45% of WordPress sites passed Core Web Vitals, against 74% of Wix sites. That gap is an average, not the destiny of your site.

3. A server that takes a long time to answer

Before the browser can draw anything, the server has to respond. That time is called TTFB, and web.dev considers it good at 0.8 seconds or less and poor above 1.8. In its LCP guide, web.dev treats this wait as roughly 40% of an ideal load, a big slice of the time budget. If your site builds every page from scratch on each visit using a database, or sits on an overloaded host, that is where time is lost, and no amount of image optimization gets it back.

What it costs you: what is actually known

The best-documented case we found is Vodafone's, published on web.dev. They tested two versions of a sales page, with ad traffic split in half. The version optimized for Web Vitals had a 31% better LCP in field data and, compared with the other, 8% more sales, a 15% improvement in the lead-to-visit rate and 11% in the cart-to-visit rate. Each page received around 100,000 clicks and 34,000 visits a day.

It is a real result, but from a huge company with a lot of paid traffic. It doesn't transfer as-is to a clinic or a law office, and we include it as proof that speed can move sales, not as a figure for your case.

On Google Search, the official documentation says Core Web Vitals are used by its ranking systems, but that good scores don't guarantee a top position and that relevance of content comes first: Google may show relevant content even when the page experience is sub-par. A slow page is not a sure penalty, and a fast one is not a guaranteed reward.

What you can do this week

When you run PageSpeed Insights, read its two kinds of data separately. Google says lab data is useful for debugging because it is collected in a controlled environment, but that it may not capture real-world bottlenecks. Lab tools also can't measure INP, since a simulated load has no user input, so field data, when it is available, is the closer picture of what your visitors live through. TTFB, for its part, isn't one of the three Core Web Vitals, and web.dev says that it isn't strictly necessary to hit its "good" threshold: treat it as a rough guide to where the time is going.

• Measure three times your home page in PageSpeed Insights and write the numbers down with the date. A single run misleads.
• Check your biggest images. If a background photo weighs several megabytes, that is where the work starts.
• List the plugins and scripts that load on your page and remove the ones you don't use.
• Ask your provider for your site's TTFB and whether there is caching. If they can't answer, that is information too.
• Measure again and compare messages per visit, not just the score.

At Byte and Brand, sites are published as ready-made files, with no plugins to keep updated and nothing assembled from a database on every visit, and photos are prepared so they don't weigh more than they need to. If you are comparing against Wix or WordPress, the full comparison is in another article.

In short

The most common causes are heavy images, accumulated third-party code and a slow server. The cost in customers has no universal figure: there are cases from large companies, but yours is measured by comparing messages per visit. Measure before you spend, and be wary of anyone who promises you a perfect score.