Web Development
Website Speed Optimisation
The engineering fix. Diagnosing what speed is costing you in rankings is Core Web Vitals for SEO, and the two are usually bought together.
Website speed optimisation is the engineering work behind a fast site: JavaScript bundles, image handling, caching, hosting and database queries. The Nexclick measures on real user data, fixes the causes in order of effect, and verifies the result rather than declaring it.
Is this you?
What usually prompts the call
- The site feels fine on your laptop and customers on mobile say otherwise.
- You have been told it is "the hosting" for two years and nobody has proved it.
- A caching plugin was installed, nothing measurably changed, and everyone moved on.
- Pages got slower as the site grew and nobody can point at what caused it.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Profile before changing anything
- Performance traces on throttled mid-range mobile hardware, plus real user field data. Testing on a fast laptop on office broadband is how sites pass in the lab and fail for customers.
- JavaScript and CSS reduction
- Bundle analysis, code splitting, removing what is loaded on pages that never use it. Usually the largest single win on a modern site.
- Image pipeline
- AVIF and WebP, responsive sizes, explicit dimensions, lazy loading below the fold and priority on the hero. Images are the most common cause of a slow largest contentful paint.
- Caching and CDN configuration
- Page, object and edge caching configured to work together rather than against each other. Multiple overlapping caching layers is a common and self-defeating setup.
- Server and database work
- Slow queries, missing indexes, and post or order table bloat. On older sites this is frequently the real cause and front-end work alone will not touch it.
- Third-party script control
- Every tag, widget and pixel measured for its cost, then deferred, replaced or removed. Tag managers accumulate scripts nobody has audited in years.
- Regression protection
- Lighthouse CI in your deployment pipeline so a future release cannot silently undo the work. Speed work without guardrails degrades within a year.
Checklist
Speed fixes ordered by return on effort
Work down this list and stop when you have hit your target. The top six account for most of the achievable improvement on most sites, and the bottom half is where budgets get spent for very little.
- 01Add fetchpriority="high" to the hero image and remove lazy loading above the fold.
- 02Serve images in AVIF or WebP at the size they are displayed, not the size they were uploaded.
- 03Add explicit width and height to every image — this fixes layout shift at almost no cost.
- 04Audit the tag manager and remove scripts nobody can justify.
- 05Defer or async every non-critical script.
- 06Enable page caching properly, and make sure only one layer is doing it.
- 07Self-host fonts, subset them, and use font-display: swap.
- 08Inline critical CSS and defer the rest.
- 09Reserve space for cookie banners and promo bars rather than letting them push content.
- 10Split JavaScript bundles so pages load only what they use.
- 11Add a CDN if you do not have one and your audience is geographically spread.
- 12Profile database queries and add missing indexes.
- 13Clean up post meta or order table bloat on older CMS and ecommerce sites.
- 14Review hosting — if TTFB exceeds 600ms consistently, front-end work will not save you.
- 15Add Lighthouse CI so none of the above quietly regresses.
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Measure
Field data by template and device, plus lab traces. Establishes which templates actually fail rather than which page you happened to test.
- 02Week 2–5
Fix in order of effect
Largest causes first, one change at a time where possible so the effect of each is attributable.
- 03Week 5–9
Verify
Lab immediately, field data at 28 days because that is the rolling window. Anyone reporting a field improvement a week after deployment is misreading lab data.
- 04Week 5–6
Protect
Performance budgets and CI checks added, so a regression fails the build rather than being discovered in a quarterly audit.
What you get
Reporting and ownership
- A per-template diagnosis, because fixing "the site" is not actionable but fixing the product template is.
- Before-and-after field data at 28 days, so the result is evidenced rather than asserted.
- A third-party script inventory with each one’s measured cost, ready for a business decision.
- Performance budgets and CI checks so regressions fail the build.
- A written note of anything constrained by hosting, with what changing it would cost.
Tools and platforms
- Chrome DevTools performance profiler
- WebPageTest
- PageSpeed Insights & CrUX API
- Lighthouse CI
- Query Monitor / database profiling
- CDN and caching configuration
Timeline
How long this actually takes
Measurement takes a week, fixes two to five weeks depending on the platform and your deployment cadence. Then you wait for field data, which is a rolling 28-day average — a change deployed today cannot fully show for four weeks. Budget six to ten weeks from start to verified result. The commercial argument worth being clear about: speed affects rankings weakly and conversion strongly. If you are doing this for rankings alone, expect modest returns. If you are doing it because customers on mobile are abandoning, expect a measurable difference.
Pricing model
Fixed-price project
Fixed price for diagnosis and a defined fix scope. Where the cause turns out to be hosting or infrastructure, that is quoted separately because it is a different kind of spend.
Questions
Website Speed Optimisation questions
Will a caching plugin fix our speed problem?
Partly, and less than the marketing suggests. Caching helps time to first byte and repeat visits. It does nothing about oversized images, heavy JavaScript or third-party scripts, which are usually the larger causes. Installing one and stopping there is the most common half-measure we find.
How fast does our site actually need to be?
Fast enough that mobile users on a mediocre connection do not abandon — practically, largest contentful paint under 2.5 seconds on field data. Chasing a Lighthouse score of 100 has diminishing returns and is not what Google measures for ranking anyway.
Is our hosting the problem?
Sometimes, and it is diagnosable rather than a matter of opinion. If time to first byte consistently exceeds 600ms under normal load, the server is a genuine constraint and front-end work will not get past it. Below that, the cause is almost always what the page is loading.
Will this improve our conversion rate?
Usually, and more reliably than it improves rankings. The relationship between load time and abandonment is well established, particularly on mobile. We measure conversion before and after rather than citing someone else’s case study at you.
How is this different from Core Web Vitals for SEO?
That service diagnoses what speed is costing you in search and produces a specification. This one does the engineering. Plenty of clients buy both together; some buy the diagnosis and have their own developers implement it, which is a perfectly good outcome.
Will the improvement last?
Only with guardrails. Speed work degrades as new features, scripts and images are added over the following year. That is why performance budgets and CI checks are part of the scope rather than an upsell — without them you will be buying this again in eighteen months.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.