What a slow website is costing you

Everyone knows a slow website is bad. Almost nobody knows what theirs costs them, which is why it never gets fixed.

Here is how to work out your own number, and what to do about it.

Test it properly first

Go to PageSpeed Insights. Free, no account, and it is Google's own tool, which matters because it reports the same data Google uses when speed feeds into ranking.

Paste your homepage URL in and press Analyse. It takes about 30 seconds.

Read the mobile tab, not desktop

The tabs sit at the top of the report. Mobile is the one that counts. Most of your visitors are on a phone, the mobile test simulates a mid-range Android on a throttled 4G connection, and the score usually lands 20 to 40 points below desktop. People check desktop, feel fine, and close the tab.

The two halves of the report

The top section is field data, headed "Discover what your real users are experiencing". That is anonymised measurement from real Chrome users over the last 28 days, pulled from the Chrome UX Report. It is the truth.

If you see "does not have sufficient real-world speed data", your site does not get enough traffic to qualify. That is common below roughly 1,000 visits a month, and it is not a fault.

The bottom section is lab data, headed "Diagnose performance issues". One simulated load on Google's hardware. Repeatable, which makes it good for testing a fix, but it is not what your visitors lived through.

Judge with field data. Debug with lab data.

The three numbers, with the actual thresholds

These are the Core Web Vitals. Google publishes the exact cut-offs, so there is no need to guess.

Metric	Good	Needs work	Poor
Largest Contentful Paint	under 2.5s	2.5s to 4.0s	over 4.0s
Interaction to Next Paint	under 200ms	200ms to 500ms	over 500ms
Cumulative Layout Shift	under 0.1	0.1 to 0.25	over 0.25

Largest Contentful Paint is the time until the biggest thing in the viewport finishes rendering. On most sites that is the hero image or the headline. The report names it: open "Diagnose performance issues" and find the "Largest Contentful Paint element" row. That single line usually tells you what to fix first.

Interaction to Next Paint is how long the page takes to respond visually after a tap. High INP nearly always means too much JavaScript blocking the main thread.

Cumulative Layout Shift is covered in its own section below.

To pass, the 75th percentile of your visitors has to be in the good band on all three. Not the average. A quarter of your visitors can still have a bad time while you pass, which is a lower bar than it sounds.

Run it three times and take the middle result. A single run swings by 10 points or more.

Turning slowness into money

The number people quote is that each extra second costs around 7 percent of conversions. It traces back to a 2016 Akamai retail study and gets repeated without its caveats.

Treat it as an order of magnitude, not a forecast. The real figure depends on what you sell and how badly the buyer wants it. Somebody buying a 20 dollar item on a phone at a bus stop gives up far quicker than a procurement manager comparing three agencies from a desk.

The direction is not in doubt though. Google's own case study library collects published before-and-after numbers from dozens of companies, and they all point the same way.

Do the sum with your own numbers.

Say you get 2,000 visitors a month. Two percent enquire, so 40 enquiries. You close one in five, so 8 clients. Your average project is 5,000 dollars.

That is 40,000 dollars a month.

Now say your site takes 5 seconds to load on mobile and you get it to 2. Three seconds saved, at roughly 7 percent each, is about 21 percent more conversions.

Same traffic. Around 48 enquiries instead of 40. Around 9 or 10 clients instead of 8. Somewhere near 8,000 dollars a month you were leaving on the table.

Put your own figures in. The number is usually bigger than people expect, and it repeats every month.

Layout shift, and why it makes a site feel cheap

Cumulative Layout Shift measures how much the page jumps while loading. You go to tap a button, an image loads above it, everything moves down, and you tap the wrong thing.

The score is not seconds. It is the share of the screen that moved multiplied by how far it moved, summed across the load. 0.1 means roughly a tenth of the viewport shifted. Google's full definition is here.

Four causes, in the order we usually find them.

Images with no dimensions. If an image tag carries no width and height, the browser cannot reserve space, so everything below jumps when the file lands. Put the real pixel dimensions on every image tag. It does not change how the image displays, CSS still controls that. The attributes only tell the browser the aspect ratio in advance.

Embeds and iframes. A YouTube player or a booking widget that loads late shoves the page down. Give its container a fixed height or an aspect-ratio before the thing inside arrives.

Fonts swapping. The browser paints a fallback, then swaps to your font, and the text reflows because the two have different letter widths. Reduce it with font-display: swap and a fallback picked to match, or use size-adjust in your @font-face rule.

Anything injected at the top. Cookie banners, announcement bars, "you seem to be in India" strips. Reserve the space or render them server-side.

Layout shift rarely comes up in a speed conversation, because the page may load quickly. It still makes a site feel cheap, and people trust cheap-feeling sites less with their money.

Layout shift rarely shows up in a conversation about speed, because the page may technically load fast. It still makes a site feel cheap, and people trust cheap feeling sites less with their money.

Speed and Google rankings

Speed is a ranking factor. It is a small one, and it is often oversold.

What is true: Google uses Core Web Vitals as a signal. Between two pages of similar quality, the faster one has an edge.

What is not true: that a fast site outranks a better page. Content and links still do most of the work. A very fast page about nothing ranks nowhere.

The bigger SEO effect is indirect. A slow site gets more people bouncing back to the results page, fewer pages read per visit, and fewer links earned because fewer people finish reading. Those add up over months.

So fix speed for the conversion gain, and take the ranking benefit as a bonus.

Where the time actually goes

In our experience it is nearly always the same short list.

Images. The biggest cause by a distance. Someone uploads a photo straight off a camera at 4,000 pixels wide and the browser downloads all of it to show a 600 pixel thumbnail.

We hit this ourselves recently. A screenshot for one of our case studies came in at 33MB. Converted properly it was 392KB. Same picture on screen, 98 percent less to download.

Too many scripts. Analytics, chat widget, heatmaps, two pixels, a popup tool, a cookie banner. Each one is small. Twelve of them is not.

Fonts. Loading six weights of three families when the design uses two.

Plugins. On a plugin heavy site, a lot of them load code on every page whether that page needs it or not. This is usually a platform decision rather than a page decision, which is why choosing a CMS is partly a performance question.

Cheap hosting. Sometimes the server itself is just slow to answer.

What to do, in order

Cheapest and most effective first.

Fix your images

Resize them to the largest size they are actually shown at. Save them as WebP. Turn on lazy loading so images below the fold wait until someone scrolls.

This is often half the problem and it costs nothing but an afternoon.

Doing it properly takes four steps.

1. Find the size it is actually displayed at. Right click the image, choose Inspect, and hover the element in the panel. Chrome shows two numbers: the rendered size and, in brackets, the intrinsic file size. If it says 600 x 400 (4032 x 3024) you are shipping 20 times more pixels than the screen uses.

2. Resize to twice the displayed width. Twice, not once, so it stays sharp on retina screens. A 600 pixel card wants a 1200 pixel file. Free tools that do this: Squoosh in the browser, sips on macOS, or ImageMagick anywhere.

sips --resampleWidth 1200 hero.jpg --out hero-1200.jpg

3. Convert to WebP. Roughly 25 to 35 percent smaller than JPEG at the same visible quality, and supported by every current browser. Install cwebp from Google's libwebp tools, then:

cwebp -q 75 hero-1200.jpg -o hero-1200.webp

Quality 75 is the sweet spot for photographs. Illustrations and screenshots survive 65 without visible loss. Below 60 you start seeing it.

4. Lazy load everything below the fold. One attribute, no library:

<img src="hero.webp" width="1200" height="630" loading="lazy" alt="...">

One important exception. Never lazy load your LCP image. The hero at the top of the page should load as early as possible, so give it loading="eager" and fetchpriority="high" instead. Lazy loading the hero is one of the most common ways people accidentally make LCP worse while trying to improve it.

If your site serves many screen sizes, add srcset so the browser picks the right file rather than downloading the biggest and scaling it down. Most modern frameworks and CMS platforms generate this for you; check whether yours does before doing it by hand.

A concrete example from our own work. A full-page screenshot came off the capture at 2940 pixels wide and 33MB. Resized to 1200 and converted to WebP at quality 68, it landed at 392KB. Identical on screen, 98.8 percent smaller. That one file was heavier than the entire rest of the page put together.

Audit your scripts

You cannot delete what you cannot see, so start by listing them.

Open your site, press F12 for DevTools, go to the Network tab, tick "Disable cache", and reload. Click the JS filter, then click the Transfer column header to sort biggest first. Everything not served from your own domain is a third party.

For a second view, open the Coverage tab (Cmd+Shift+P, type "coverage") and reload. It shows how much of each file is actually used. Seeing that a 240KB script is 92 percent unused makes the decision for you.

Then for each one, ask a single question: has anyone looked at this tool's data in the last three months?

The usual suspects, and what they typically cost you:

Tool	Typical weight	Worth keeping?
Google Analytics 4	~50KB	Yes, if anyone reads it
Google Tag Manager	~90KB plus whatever it loads	Only if actively managed
Live chat widget	150 to 400KB	Only if staffed
Heatmap or session recording	100 to 300KB	Run it for a month, then remove
Second and third ad pixels	30 to 80KB each	Only for campaigns actually running

Most sites we look at can drop two or three immediately. Tag Manager is the one to check hardest, because it hides everything loaded through it.

Cut your fonts

Two families, two weights each, is enough for almost any site. Every extra weight is another file the browser waits on, and each one is typically 15 to 40KB.

Three fixes worth making at the same time:

Serve WOFF2 only. It is 30 percent smaller than WOFF and every browser in use supports it. If your font files include TTF or EOT, they are being served for browsers that no longer exist.

Add font-display: swap. Text renders immediately in a fallback rather than staying invisible while the font downloads. Without it you can get up to three seconds of blank text, which Chrome calls FOIT.

Preload the one font used above the fold.

<link rel="preload" href="/fonts/heading.woff2" as="font" type="font/woff2" crossorigin>

Preload exactly one or two. Preloading everything just moves the queue around.

Then look at the build

If you have done the three above and mobile is still under 50, the problem is structural. That is a bigger conversation about platform and hosting.

For reference, the site we built for Jay Yang scores 100 on performance, 96 on accessibility, 100 on best practices and 100 on SEO. That is not because of a trick. It is because the pages are built ahead of time and there is nothing loading that does not need to.

Hosting and where your visitors are

One cause people miss entirely: distance.

If your server sits in one country and your visitors are in another, every request makes a round trip. That adds real time before the page even starts loading. We see this constantly with Indian businesses on US hosting, and with UK businesses on cheap shared plans in whatever data centre was cheapest.

Two fixes.

Use a CDN. It keeps copies of your files in many locations and serves from the closest one. Most modern hosts include this. If yours does not, that is a reason to move.

Check your server response time. PageSpeed reports it as Time to First Byte, under "Reduce initial server response time". Google's threshold is 800 milliseconds; under 200ms is excellent, over 1.8 seconds is poor.

You can also check it in one line from a terminal:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s

" https://yoursite.com

Run it five times. If it is consistently over a second, no amount of image work will save you. The server is the problem and you need to move.

Cheap shared hosting is the most common cause of a slow site that has already had its images fixed. It is also the easiest thing to change, and usually the cheapest line in the whole project. If you are budgeting a rebuild, what a website actually costs breaks down where hosting sits against everything else.

What good looks like

Metric	Aim for	Fix it if
Mobile performance score	Over 90	Under 50
Largest Contentful Paint	Under 2.5s	Over 4s
Total page weight	Under 1MB	Over 3MB
Third party scripts	Under 5	Over 10

Keeping it fast after launch

Sites get slower on their own. Almost every one we come back to a year later has drifted.

It happens the same way every time. Marketing adds a tracking pixel for a campaign and never removes it. Someone uploads a hero image straight from a stock site. A new plugin arrives for one page and loads on all of them.

Three habits stop the drift.

Check the score monthly. Two minutes. Put a reminder in a calendar. If it has dropped ten points, find out what changed.

Make image sizing somebody's job. Either the CMS does it automatically on upload, or one person is responsible. Hope is not a process.

Review third party scripts quarterly. Anything nobody has looked at in three months comes off.

If you want to be stricter, a performance budget works well. Write down a maximum page weight and a minimum score, and treat breaking it like breaking the build. It turns a vague preference into a rule people can point at.

Two honest caveats

A perfect score does not sell anything. We have seen fast sites that convert badly because the message is wrong. Speed removes a reason to leave. It does not give anyone a reason to stay. If your site is quick and the enquiries still are not coming, the problem is further up: we wrote about why a site gets traffic and no enquiries separately.

And chasing the last few points is rarely worth it. Going from 45 to 85 changes your business. Going from 92 to 97 is a hobby.

Get out of the danger zone, then spend your effort on what the page actually says.