Development Agency
Contact Sign in Get a project quote

Service

Performance Optimisation

For businesses and publishers whose site has become slow, expensive to run or unstable under load, and who want the causes found and fixed with measurements taken before and after, not a new site.

Get a project quote

The problem

What goes wrong today

Where it usually starts

The site that needs performance work usually got slow gradually.

  • Each new feature added a script, a font, a tracking tag or a plugin; each new section added a query to the page; the image library grew without anyone resizing anything.
  • Nobody noticed until the figures from a real-user tool turned red, a listing page started timing out on busy evenings or the hosting bill doubled because the server was upgraded to keep up.
  • On a phone over a mobile connection the home page takes long enough that visitors leave before it finishes drawing, the layout jumps as advertisements and images arrive, and a tap on a menu does nothing for a second.

Where it gets harder

Attempts to fix it have been guesses: a caching plugin that broke the login, an image plugin that resized everything badly, a bigger server that made the problem rarer but not gone.

  • The developers who look at it each have a theory, but nobody has measured which pages matter, where the time goes on each of them or which queries run a thousand times per request.
  • The business wants the site it has to be fast and stable, with the work prioritised by evidence and the result shown in the same figures that flagged the problem.

Scope of the service

What the build covers

Performance work normally runs in three parts: measurement, fixes in priority order and the controls that keep the result. Measurement starts with a baseline from real-user data where it exists and from repeatable lab runs where it does not, on the pages that carry the traffic and the pages that are slowest, at phone and desktop widths and on a throttled connection. We profile each page from the server outwards: database queries per request and the slow ones, template rendering time, response caching and what invalidates it, page weight by type, scripts and third-party tags and what they block, fonts, images and their formats and sizes, and the layout shifts and input delays that the Core Web Vitals measure. The result is a list of causes ranked by their effect on the measured figures and their cost to fix.

Fixes are applied in that order and measured one at a time, so each change is tied to a result: query reduction and indexing, server-side and edge caching with correct invalidation, image resizing and modern formats, script deferral and removal of tags that do nothing, font loading, critical CSS and reserved space for late content. Controls are added last: a performance budget checked on every deployment, monitoring of the real-user figures and a report you can read.

When the scope grows

Scoping scenario

A classified vehicle listings portal with a search page that runs several hundred queries per request and times out on Sunday evenings wants it stable and fast without rebuilding. The query profile, the cache design for a page with many filters and the measurement across a week of real traffic make this a project, and the scope document names the pages and figures in scope.

Deliberately out of scope

  • A redesign or platform change, which the website development and migration services cover, and any promise about search rankings, which depend on far more than speed. We report the figures we measured, never a lab score presented as real-world data

Deliverables

What you receive

  • A measurement baseline on the pages that matter: real-user figures where available, repeatable lab runs otherwise
  • A written findings report ranking the causes by measured effect and cost to fix, and the scope agreed from it
  • Database, caching and server-side fixes applied to the existing codebase with each change measured
  • Front-end fixes: images, fonts, scripts, third-party tags, layout stability and input responsiveness
  • A performance budget and automated check added to your deployment process
  • Monitoring of the real-user figures with a report your team can read without a specialist
  • Handover notes explaining each change, why it was made and how to keep the result

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the codebase, hosting, analytics and any real-user measurement; the pages that matter and the problem as you see it are listed.

    Project stage: Onboarding

  2. Planning

    Baseline taken and the site profiled from database to browser; causes ranked and the fixes in scope written into the scope document.

    Project stage: Planning

  3. Design

    Cache design, invalidation rules, image and font strategy and the performance budget designed before anything changes.

    Project stage: Design

  4. Development

    Fixes applied in ranked order on a staging copy, each measured against the baseline before the next is started.

    Project stage: Development

  5. Client review

    Your team checks the staging site for anything that behaves differently, especially logged-in and editing flows affected by caching.

    Project stage: Client review

  6. Revisions

    Side effects corrected, cache rules refined and the measurements repeated.

    Project stage: Revisions

  7. Ready for launch

    Changes deployed in stages with monitoring watched after each; the performance budget switched on in the deployment pipeline.

    Project stage: Ready for launch

  8. Delivered

    A comparison report against the baseline after a period of real traffic; monitoring continues under the maintenance service if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Real-user measurement and analytics tools with consent handling
  • Content delivery networks and edge caching with tag-based purging
  • Image processing and media storage services
  • Advertising and tag management platforms whose scripts affect the figures
  • Database monitoring and query profiling tools
  • Hosting control panels and deployment pipelines for the performance budget
  • Uptime and error monitoring services

How we would approach it

Worked example

Concept demo

A vehicle listings portal whose search page times out on Sunday evenings

The situation

A classified portal has a search page with many filters that runs several hundred database queries per request, becomes unstable at the weekend peak and has layout shifts from late-loading advertisements and images.

Why it is a custom build

The custom route is needed because the fixes depend on this site's query patterns, filter combinations and advertising setup, which a generic caching plugin cannot model.

The scope we would propose

  • A baseline from a week of real-user data on the search, listing and home pages
  • A query profile leading to eager loading, indexing and a facet count cache keyed by filter combination with invalidation on listing changes
  • Edge caching of listing pages with tag-based purging
  • Image resizing and modern formats for listing photographs
  • Reserved space for advertisements and lazy loading below the fold
  • Deferral of non-essential scripts
  • A performance budget in the deployment pipeline
  • A comparison report after the next weekend peak

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of page types in scope and how different their performance problems are
  • Size and condition of the existing codebase and whether its developers are available
  • Database complexity: query volume, data size and the reporting that runs alongside
  • Caching constraints: logged-in users, personalisation and how often content changes
  • Third-party scripts, advertising and tags that must remain
  • Media volume and whether an image pipeline exists
  • Whether real-user measurement exists or must be set up for the baseline
  • Hosting and content delivery setup, and who controls it

Start from a package

  • Software package

    Magazine publishing package

    Issue planning, contributor workflow, long-form templates, digital issue delivery and back-issue archive for magazines that publish on a schedule.

    Custom build

  • Software package

    Event listings package

    Organiser submissions with moderation, venue pages, recurring events, calendar and map search, saved events with reminders and promoted slots for what's-on portals.

    Custom build

  • Software package

    Vehicle listings portal package

    Dealer and private seller accounts, feed intake, advanced search with alerts, tracked enquiries, moderation queue, paid listing packages and dealer reviews for vehicle marketplaces.

    Custom build

FAQ

Frequently asked questions

Will this improve our search rankings?

Page experience is one of many factors search engines consider, and we cannot promise ranking or traffic outcomes. What we deliver is measured: the real-user and lab figures before and after, on the pages you care about, with each change tied to its effect. Those figures are what we report.

Do we need a new site?

Usually not. Most of the gains come from the database, caching and front-end loading on the site you have. Where the platform itself is the limit, we say so and point you to the migration or website development services rather than spending your budget on a site that cannot be made fast.

What kinds of site benefit most?

Content-heavy and listing-heavy sites: publishers such as those on the magazine publishing package, listing sites such as the event listings package and the vehicle listings portal package, and shops with large catalogues, where many filters, images and advertisements meet real traffic. Smaller sites usually need a shorter engagement.

How do you measure, and do you report lab scores?

We prefer real-user data from a consented, sampled web-vitals beacon or your analytics, because it reflects what visitors experience. Lab runs are used for repeatable comparison during the work. We never present a lab score as field data, and we report what we measured on which pages, over what period.

How do we stop it getting slow again?

With a performance budget checked on every deployment, so a change that adds weight or queries beyond the limit is flagged before it ships, and with ongoing monitoring of the real-user figures. Both are set up as part of the work and can continue under the maintenance service.

Get a project quote for performance optimisation software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences