// PERFORMANCE

Why your website is slow — and why ours scores 54.

An agency article about site speed normally ends with a screenshot of a perfect score. This one starts with our own failing one, because that is where the useful part is.

On 9 September 2026 we ran Lighthouse against our own home page, on the mobile profile, and it scored 54 out of 100 for performance.

We are a web studio. We sell, among other things, fast websites. So before anything else, here is the whole result, unedited:

PageScoreBlocking timeLargest paintLayout shift
getweblabs.uk home page542,900 ms4.0 s0
Our Nord Dental demo99100 ms1.4 s0

Same studio. Same hand-written HTML, same server, same week. One page scores 54 and the other scores 99, and the entire difference is what each one loads and runs.

The score you should actually care about

Most people look at the big number. The big number is a weighted average, and it moves for reasons that are not always about your visitors. The one worth watching is Total Blocking Time.

Blocking time measures how long the browser's main thread was too busy to respond. During that window the page is on screen and looks finished, but a tap does nothing. The button does not depress. The menu does not open. Your visitor taps again, harder, and then leaves.

Our home page has 2,900 milliseconds of it on a mid-range phone. Nearly three seconds where the site looks ready and is not. The demo has 100 milliseconds. That is the difference between a page that works and a page that appears to be broken.

What is costing us those three seconds

Four things, and none of them are images:

Every one of those was a deliberate choice and every one of them makes the page nicer on a laptop. Together they cost about three seconds of responsiveness on a phone, which is most of our visitors. That is the trade, written down plainly, and we are working through it rather than quietly deleting the paragraph.

The pattern to take away: slow sites are rarely slow because of big pictures any more. Images got solved — modern formats and lazy loading are close to automatic. Sites are slow because of JavaScript that runs before anybody has asked for anything.

The five things that actually make a site slow

1. Scripts that run before they are needed

Chat widgets, analytics, heat maps, cookie banners, A/B testing, review widgets, a font loader, a pop-up that offers 10% off. Each one is small. Eight of them is a second of blocking time, and no single vendor is at fault.

The test: open your site, disable JavaScript entirely, and reload. If the page still shows its content and its links still work, your JavaScript is decoration and can be deferred. If the page is blank, the JavaScript is your site, and that is a much bigger conversation.

2. A theme built to be sold, not to be used

A commercial theme has to demo well for every possible buyer, so it ships a slider, a portfolio grid, a booking widget, four fonts and six icon sets — and loads most of them whether your page uses them or not. This is the single most common cause of a slow small-business site, and it is invisible from the outside because the site looks fine on the designer's laptop.

3. Fonts that arrive late

A web font that loads after the text either hides the words until it arrives or swaps them mid-read and shoves the layout down the page. Self-host the fonts, load only the weights you actually use, and set font-display: swap. We self-host three families here and the whole set is 168 kB.

4. Images without dimensions

Not the file size — the missing width and height. Without them the browser does not know how much room to leave, so everything below jumps when the picture arrives. That is Cumulative Layout Shift, and it is the reason you have tapped the wrong link on a news site. Ours is 0, and it is 0 because every image has its dimensions written on it. This one is free.

5. A server that thinks about it first

If your host takes 800 ms to send the first byte, nothing you do in the page can win that back. This is usually a shared host, or a database doing work on every single request that could have been done once. Static files do not have this problem at all, which is why our demos do not have it.

How to measure it yourself, properly

Two rules, because most people's first measurement is wrong.

Measure the mobile profile, not desktop. Lighthouse's mobile run simulates a mid-range phone on a slower connection. It is harsher, and it is what most of your visitors have. Our own desktop score is 62 against 54 on mobile — the same page, eight points apart, and the desktop number is the one that flatters.

Measure the page people land on. Not the home page, if your traffic arrives on a product page or a blog post. They are different pages with different scripts.

Then go to PageSpeed Insights, put your URL in, and read Total Blocking Time before you read the score.

Why we published our own bad number

Because we found it while auditing our own site, and the alternative was to fix it quietly and keep telling people we build fast websites.

The claim on our about page used to read "100/100 Lighthouse Performance". That number was real — it had been measured on the demos, which do score in the high nineties — and then it was written on the home page, which is a different page carrying four things the demos do not. Nobody lied. A true sentence drifted away from the thing it described, which is how most wrong numbers on websites get there.

It now says what is actually 100 on both mobile and desktop: SEO, best practices and accessibility. The performance work is next, and when it is done you will be able to check it yourself rather than take our word for it.

Want to know what your site scores?

Send us the URL. We will run it, send you the numbers with the three things costing you the most, and there is nothing to buy at the end of it.

Ask for a speed check