Website Speed: What to Check, What a Fix Costs, and Why It Is a Sales Question, Not an IT One

Website speed sounds like a developer topic. It is not. Google's data on millions of sites shows the same thing: as mobile load time grows from 1 to 3 seconds, the chance a visitor leaves without doing anything rises by a third; at 5 seconds it nearly doubles. If your website brings enquiries or orders, every second is money. Here is how to measure it, what we usually find, and what it costs to fix.

Measure it in 5 minutes

Open pagespeed.web.dev, enter your address, choose "Mobile". You get a score from 0 to 100 and four metrics. The three that matter most are called Core Web Vitals, and Google ranks by them:

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	seconds until the main content is visible	≤ 2.5 s	> 4 s
INP (Interaction to Next Paint)	how long the site takes to react to a tap	≤ 200 ms	> 500 ms
CLS (Cumulative Layout Shift)	how much elements "jump" while loading (the button escapes from under your finger)	≤ 0.1	> 0.25

Measure in mobile mode, not desktop — 60–80 % of visitors come from phones, and the gap between the two scores is often 30–40 points. And measure more than the home page: the service page or product page people land on from Google is often slower.

A score of 90+ is good. 50–89 means there is work to do, but nothing is on fire. Below 50 you are losing visitors every day.

The three causes that slow down 80 % of websites

1. Images straight from the camera

The most common cause and the cheapest to fix. A 4,000 × 3,000 pixel photo, 3.5 MB, uploaded straight from a phone, displayed in a 400-pixel-wide box. The phone downloads 3.5 MB to show 40 KB. Ten such photos make a 35 MB page that takes 10–20 seconds on mobile data.

The fix: resize to the size actually needed, convert to WebP (3–5 times smaller than JPEG with no visible difference), and load only the images on screen (lazy loading). The result: a 35 MB page becomes 1–2 MB. In WordPress a plugin or a one-off script handles existing photos; on a coded site it happens automatically at build time. Cost: €100–250 for a whole site.

2. Plugins nobody uses any more

A WordPress site with 30 plugins loads 30 sets of scripts and styles for every visitor — a slider that no longer exists, a form plugin replaced by another, three SEO plugins at once. Each adds 50–500 KB and tens of milliseconds.

The fix: an audit of what is actually used; disable and delete the rest; swap heavy ones for light ones. Often 30 becomes 10 and the score rises 15–25 points. Cost: €150–300, half a day to a day of work, with a backup before and testing after.

3. Hosting at €2 a month

Cheap shared hosting means hundreds of websites on one server; your page waits in line while the server serves the others. The first byte (TTFB) arrives after 1–2 seconds before any content at all — nothing you do with images helps if the server is silent for two seconds.

The fix: caching (the page is generated once, not for every visitor) and a CDN (Cloudflare's free plan serves content from the nearest server). If that is not enough, move to decent hosting (€5–10/month) or, for a static site, to Cloudflare Pages / Vercel for free. Cost: caching + Cloudflare — €100–200; migration — €200–400.

Why not "just install a speed plugin"

Caching plugins help when the site is already in order. On top of 30 plugins and 35 MB of photos they add another layer, which sometimes breaks forms and the cart. The order is: images and plugins first, then caching — not the other way round.

How much it really improves

A typical case of ours: a WordPress service website, PageSpeed mobile 38, LCP 6.1 s. After the three fixes above (two days of work, ~€450): 84, LCP 2.2 s. The share of visitors who reached the contact form rose from 11 % to 16 % over a month — not speed magic, simply people who stopped leaving while waiting.

From 84 to 100 is harder work: fonts, third-party scripts (Facebook Pixel, chat widgets, maps), server response. Often not worth it: 85–95 and 100 are indistinguishable to a visitor, and to Google too. A coded website has that score from day one — one of the arguments in WordPress vs a custom-coded website.

Before the season — the order of work

If the holiday traffic is a few weeks away:

1. Measure the home page and your three most popular pages in mobile mode. Write down the scores — without "before" there is no "after".
2. Images — always first. The biggest effect for the lowest cost.
3. Plugins or unused scripts.
4. Cloudflare in front of the site — for speed and for protection against traffic spikes.
5. No major changes (hosting migration, rebuild) before the season — the risk of breaking what works in the middle of trading is too high.

What to do tomorrow

Measure three pages and save screenshots. Open any of your photos in a new tab and check its size — if it is over 500 KB, you know where to start. If your score is under 50 and you want a number for what that costs: monthly visitors × 15 % × your average enquiry value.

Frequently asked questions

Does speed really affect Google rankings?

Yes, but not as strongly as content and links. Core Web Vitals is one ranking signal; between two similar sites the faster one wins. The bigger effect is indirect: a slow site loses visitors who go back to Google, and Google sees that.

My score is 95 on desktop and 45 on mobile — why?

A phone has a slower processor and connection, and the test simulates that. Images and scripts a desktop does not notice become seconds on a phone. Always look at the mobile score.

Can I fix it myself?

Images — yes: resize before uploading (Squoosh is free), enable WebP in WordPress. The plugin audit — partly, but with a backup and carefully. Hosting and caching — better with a specialist: this is where forms and the cart break most easily.