Web Development
Speed optimisation and Core Web Vitals
A slow site loses visitors before the content appears and rankings along with them. We find what actually makes your pages slow, fix it in order of impact, and verify with real-user data, not just lab scores.
Who it is for: Businesses failing Core Web Vitals, seeing high bounce on mobile, or watching a once-fast site get slower with every added plugin and script.
Everything in this service
- Full performance audit with prioritised findings
- Image, font and script optimisation
- Third-party script review, the usual hidden culprit
- Caching, compression and hosting configuration
- Before-and-after evidence from lab and field data
What to expect
- Core Web Vitals passing on mobile
- Fewer visitors lost to loading screens
- A speed budget that keeps the site fast after we leave
How speed optimization actually works
Largest Contentful Paint: what actually causes a poor score
LCP measures how long it takes for the largest piece of content in the opening view to appear. Usually that is a hero image, a heading, or a block of text. It is a proxy for the question a visitor is actually asking, which is when can I see what I came for.
Poor LCP almost always traces to one of four causes, and identifying which one you have matters more than any general advice. The first is a slow server response, where the browser waits before receiving any HTML at all. Nothing downstream can be fast if this is slow, and it points at hosting, an unoptimised database query, or an uncached page being rebuilt for every visitor. The second is render-blocking resources: stylesheets and scripts in the head that the browser must fetch and process before it draws anything. The third is the LCP element itself being slow to load, typically an oversized image, an image not discovered until late because it is applied by CSS or inserted by JavaScript, or a font that delays text from appearing. The fourth is client-side rendering, where the browser must download and run JavaScript before any content exists to paint.
The fix follows the cause. Caching and better hosting for the first. Inlining critical styles and deferring the rest for the second. Correctly sized images, an explicit priority hint on the hero image, and preloading for the third. Server rendering for the fourth. Applying image optimisation to a site whose real problem is a two-second server response wastes effort and money, which is why diagnosis comes before work.
- Check server response time first, everything else depends on it
- Remove or defer render-blocking scripts and stylesheets
- Make sure the hero image is discoverable early, not inserted by script
- Size and compress the LCP image properly and give it loading priority
- Server-render content rather than assembling it in the browser
Interaction to Next Paint: why a page feels unresponsive
INP measures how quickly the page responds visibly after a user interacts with it, across the whole visit rather than just the first tap. It replaced the older first-input measure precisely because responsiveness later in the visit matters too.
The cause is almost always JavaScript occupying the main thread. A browser does its work in one place, so while a long task is running, nothing else happens. Taps do not register, animations stall, and text does not appear in inputs. On a fast laptop this is invisible. On a mid-range phone, whose processor is several times slower, the same task can block the interface for a period the user definitely notices.
The usual culprits are large amounts of script executing at load, heavy work in event handlers, frameworks re-rendering more than they need to, and third-party tags doing work you never see. The fixes are: ship less JavaScript in the first place, break long tasks into smaller pieces so the browser can respond between them, move heavy computation off the main thread, and give immediate visual feedback so an action feels acknowledged even when the underlying work takes a moment. Test this on a real mid-range phone, because it is the one Core Web Vital that a desktop test will not honestly reveal.
- Reduce total JavaScript before optimising individual handlers
- Split long tasks so the browser can respond between them
- Audit third-party tags, they run work you did not write
- Give instant visual feedback on tap, even if the result takes longer
- Measure on a real mid-range Android, not a development machine
Cumulative Layout Shift: the jumping page problem
CLS measures how much visible content moves around unexpectedly while a page loads. It is the reason someone taps the wrong thing because a button moved a fraction of a second before their finger landed.
The causes are specific and easy to name. Images and videos without dimensions set, so the browser reserves no space and the layout reflows when the file arrives. Advertisements and embedded content inserted into a container that has no reserved height. Fonts that swap after loading, where the fallback and the final font have different metrics and text reflows. Content injected above existing content: a cookie banner, a promotion bar, a notification. And anything animated using properties that trigger layout rather than compositing.
The fixes are mostly one-line changes and are among the cheapest wins in performance work. Always set width and height, or an aspect ratio, on media. Reserve space for anything that will be inserted, including advertisement slots and embeds. Preload key fonts and choose a fallback whose metrics are close to the final font so the swap is less visible. Insert banners in a way that does not push existing content down. Animate transforms and opacity rather than position and size. One caution: layout shift is often worse for real users than for a lab test, because a test on a fast connection loads everything before much is drawn, while a real visitor on a slow connection watches the whole sequence happen.
- Set dimensions or an aspect ratio on every image, video and embed
- Reserve space for advertisements, banners and injected content
- Preload key fonts and match fallback metrics closely
- Animate transform and opacity, not top, left, width or height
- Test on a slow connection, that is where shift becomes visible
Images and fonts: the two usual culprits
On most sites, images are the largest share of page weight and fonts are the most common cause of delayed text. Between them they account for a large proportion of the total problem, and both are fixable without touching application code.
For images, the recurring faults are the same everywhere. A file far larger than the space it is displayed in, often a full-resolution photograph shown at a fraction of its size. An older format where a modern one would be substantially smaller at the same quality. No responsive sizes, so a phone downloads the desktop image. Everything loading at once, including images far below the visible area. And decorative images that could have been a background colour or a simple shape. Automating this at upload matters more than fixing it once, because otherwise the next person to add a page reintroduces the problem.
For fonts, the cost is both the file size and the behaviour while loading. Each additional weight and style is another file, and teams routinely load six variations when two are used. Subsetting to the characters you actually need cuts size substantially. Self-hosting rather than fetching from a third party removes an extra connection and a dependency. And the loading behaviour needs a decision: showing fallback text immediately and swapping means content is readable straight away at the cost of a visible change, while blocking text until the font arrives avoids the swap but leaves the visitor looking at nothing. Readable sooner is the right default for most content sites.
- Serve images sized to their display size, in modern formats
- Use responsive sizes so phones do not download desktop images
- Lazy load below the visible area, never the hero image
- Cut unused font weights and styles, and subset the characters
- Self-host fonts and choose the swap behaviour deliberately
The real cost of JavaScript and third-party scripts
JavaScript is more expensive than its file size suggests. A kilobyte of image is decoded and drawn. A kilobyte of JavaScript is downloaded, parsed, compiled and executed, and the execution can trigger further downloads and further work. On a mid-range phone that chain can take many times longer than the download itself.
Third-party scripts deserve separate attention because they are the part nobody owns. Analytics, tag managers, chat widgets, heatmaps, review platforms, advertising pixels, consent tools, personalisation. Each was added for a reason, usually by someone outside the development team, and they are almost never removed. They load code from other servers, so their performance is outside your control, they can change without warning, and a tag manager in particular can become a way for new scripts to arrive on the site with no review at all.
The remedy is an inventory and a policy. List every third-party script, name who uses the data it produces, and remove the ones nobody can account for. Load what remains after the page is usable rather than before. Where a tool exists for a rarely used feature, load it only where that feature appears. And set a budget so the question becomes what to remove when something new is added, rather than allowing steady accumulation until the page is slow again a year after it was optimised.
- Inventory every third-party tag and name its owner
- Remove anything nobody is actively using
- Load remaining scripts after the page is usable
- Restrict feature-specific tools to the pages that use them
- Set a budget so additions require a trade-off, not just approval
Caching and delivery: making the fast path the normal path
Much of speed work is about not doing work twice. Caching stores a result so the next request can be served without rebuilding it, and delivery is about serving that result from somewhere close to the visitor.
There are several layers and they solve different problems. Browser caching stops a returning visitor re-downloading files that have not changed, and it depends on sensible cache headers plus filenames that change when the content does. A content delivery network serves files from a location near the user, which removes a large part of the delay for anyone geographically distant from your server. Page caching stores whole rendered pages so the server does not rebuild them per request, which is often the single biggest gain on a database-driven site. Below that, database and object caching help applications that repeat expensive queries.
The complications are worth knowing in advance. Cached pages must be cleared when content changes, or editors update a page and see no difference. Anything personalised, a cart total or a signed-in name, needs handling separately so it does not defeat caching for everyone else. And compression should be enabled at the server, since it is close to free and reduces text-based files considerably. None of this is glamorous, and for a database-driven site it frequently outperforms every other optimisation combined.
- Cache whole pages where content is the same for every visitor
- Use a delivery network if visitors are geographically spread
- Set long cache lifetimes with filenames that change on update
- Clear caches automatically when content is published
- Enable compression, it is one of the cheapest improvements available
Field data and lab data: why the numbers disagree
Two kinds of performance data exist and they answer different questions. Lab data comes from a controlled test: one page, one simulated device, one simulated connection, run on demand. Field data comes from real visits by real people on their own devices and connections, collected over time.
They disagree constantly, and the disagreement is informative rather than a fault. Lab tests use one fixed set of conditions, while your actual audience spans new phones and five-year-old ones, fibre and patchy mobile signal. Lab tests usually measure a cold load, whereas many real visits benefit from cached files. Lab tests do not interact with the page, so they cannot measure responsiveness during a real session. And field data is aggregated over a period, so a fix made this week takes time to show up in it.
Use both for what each is good at. Lab tests diagnose: they show exactly which resource blocked rendering and which script occupied the main thread, and they can be run repeatedly while working. Field data judges: it tells you whether real users experienced an improvement, and it is what search ranking systems consider. The failure to avoid is optimising a lab score in isolation. A page can score well on a test and still be slow for a large share of your visitors, because your visitors are not using the test conditions. Fix causes, then confirm in field data.
- Lab data for diagnosis, field data for judgement
- Expect field data to lag several weeks behind a fix
- Segment field data by device and connection, averages hide the worst cases
- A good lab score does not prove real users are having a good time
- Keep monitoring after the work, sites slow down again gradually
A clear path, step by step
- 01
Measure
Lab tests plus real-user field data, so we fix what users feel, not just what tools score.
- 02
Diagnose
Every slowdown traced to its cause and ranked by impact against effort.
- 03
Fix
Images, scripts, fonts, caching and hosting, worked through in priority order.
- 04
Verify and hold
Field data confirms the gains, and a performance budget stops the slow creep back.
Why choose us for this
We fix causes, not scores, so gains show up for real users
Findings ranked by impact, so budget goes where it matters
Every claim backed by before-and-after data
Common questions
My PageSpeed score is low. How bad is that?
The score matters less than the field data behind it. Google ranks on real-user Core Web Vitals, and users leave slow pages regardless of any score. We look at both and tell you what actually needs fixing.
What usually makes a site slow?
Oversized images, too much JavaScript, third-party scripts like chat widgets and trackers, and cheap hosting. Most sites have two or three dominant causes, and fixing those delivers most of the gain.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase