Website Performance Optimisation

Speed is a commercial issue

Performance work is often filed under "technical tidying". It is not: it is one of the few changes to a website with a direct, measurable effect on the number of enquiries you receive.

The reason is behavioural. Someone searching on a phone, between jobs or on a train, has no investment in your business yet. If the page is blank for three seconds they go back to the results and try the next company. They are not annoyed with you; they simply never became a visitor. You will never see them in your analytics as a lost enquiry, which is precisely why the problem persists.

The same visitors are the ones search engines are most careful about. Core Web Vitals are part of how Google assesses page experience, and while they will not lift thin content up the rankings, poor ones will hold good content back.

What we measure

Core Web Vitals, from real visitors

Three metrics describe most of what a visitor experiences:

Largest Contentful Paint (LCP) — how long until the main content appears. Should be under 2.5 seconds. Usually delayed by an unoptimised hero image, a render-blocking stylesheet, a slow font, or a server that has to think before responding.

Cumulative Layout Shift (CLS) — how much the page jumps about while loading. Should be under 0.1. Almost always caused by images without dimensions, ads or embeds injected after paint, or a web font that changes the line height when it swaps in.

Interaction to Next Paint (INP) — how quickly the page responds when someone taps or types. Should be under 200 milliseconds. Caused by too much JavaScript competing for the main thread, frequently from third-party scripts.

We start with field data — what your actual visitors experienced on their actual devices — because that is the only measurement that reflects reality. Lab testing then reproduces the problem so it can be diagnosed.

The full waterfall

A score does not tell you what to fix. A request waterfall does. We look at what is requested, in what order, how large each response is, what is blocking rendering, and where the time actually goes.

This is where the real causes surface: a 4MB photograph scaled down in the browser rather than on the server, a font file that blocks text from appearing, an analytics tag loaded synchronously in the head, six variants of the same stylesheet, a chat widget pulling in 400KB of JavaScript before anybody has asked a question.

Where the time usually goes

Images

Images are the largest single cause of slow business websites, and the easiest to fix. Typical findings:

• Photographs uploaded at camera resolution and resized by CSS, so a phone downloads a 4,000-pixel image to display it at 400
• JPEG and PNG where AVIF or WebP would be a fraction of the size at the same visual quality
• No width and height, so the layout jumps as each one arrives
• Everything loaded eagerly, including images four screens below the fold
• Decorative images given descriptive alt text, or meaningful images given none

We build an image pipeline that generates the right sizes and formats automatically, reserves space to prevent layout shift, and lazy-loads anything below the fold while prioritising the one image that is the largest contentful paint.

Fonts

Web fonts routinely cost a second or more of delay when handled carelessly. We self-host fonts rather than requesting them from a third-party origin, subset them to the characters actually used, preload the one file needed for the first paint, and set font-display: swap so text is never invisible while a font downloads. Fallback metrics are matched so the swap does not shift the layout.

JavaScript

Most brochure websites ship several times more JavaScript than they use — a framework loaded for one carousel, three animation libraries, a date picker on a page with no dates.

We audit what is genuinely needed, remove what is not, and defer what can wait. On the sites we build, most pages are static HTML with interactivity only where there is genuinely something to interact with, which is why they respond immediately on modest phones.

Third-party scripts

Tag managers, chat widgets, review badges, heat-mapping tools, social embeds. Each one is a request to a server you do not control, executing code you have not audited, on your visitor's main thread.

We measure what each one costs in milliseconds and put the figure in front of you. Sometimes the answer is that a chat widget earning enquiries is worth 300 milliseconds. Sometimes it is that a review badge nobody clicks is costing a second. Either way, it becomes a decision rather than an accident. It is also a security and privacy question, since every third-party script can see your visitors.

Delivery and caching

Finally, the plumbing: compression enabled with a modern algorithm, correct cache headers so returning visitors re-download nothing, static assets served with long-lived immutable caching, HTML served from an edge location near the visitor rather than a single origin server.

Making it stick

Performance decays. Six months after the work, someone uploads an uncompressed photograph or adds a tracking script, and the gains quietly evaporate.

So the engagement ends with defences rather than a certificate:

• Performance budgets — agreed limits for page weight, image size and script count
• Monitoring — Core Web Vitals watched over time so drift is visible early
• A short editor's guide — practical rules for whoever adds content, in plain English
• An automated image pipeline where possible, so oversized uploads are handled for you

For clients on a managed plan or maintenance, monitoring is included and drift is dealt with as part of the monthly work.

What results look like

We do not publish guaranteed percentages, because the honest answer depends entirely on the starting point. A site built on a page builder with unoptimised images has enormous headroom. A site already built carefully has less.

What we do commit to is measurement. You get a before-and-after for each key template, using both field and lab data, on the device profiles that match your actual audience. If a change does not measurably help, we say so and undo it.

To find out where you stand, send us your website address or call 01420 446331. We will run the numbers and tell you what is costing you the most time, what it would take to fix, and whether it is worth doing.