What This Is
Performance optimisation is making an existing system faster: reducing page load times, API response times, database query durations, and the delays that make users wait. This is diagnostic, investigative work. Find the bottlenecks, understand why they exist, and fix them without breaking what already works.
This is not a rebuild. It is targeted improvement to an existing application that functions correctly but runs too slowly. The system might be a web application where pages take seconds to render, an API where endpoints timeout under load, a database where queries have degraded as data has grown, or a website where Core Web Vitals scores are hurting search rankings.
The work is methodical: measure, identify, fix, verify. We instrument the application to find where time is actually spent (not where you think it is spent), identify the highest-impact optimisations, implement them, and measure again to prove the improvement. Most performance problems have a small number of root causes that account for the majority of the delay.
When You Need This
Performance optimisation becomes necessary when slowness is affecting users, revenue, or operations. Typical triggers:
- Your web application feels sluggish: pages take multiple seconds to load, interactions lag, and users complain or leave
- API response times have degraded as your data has grown. Endpoints that were fast with 1,000 records are slow with 100,000.
- Database queries are the bottleneck. You can see slow queries in your logs but do not know how to fix them without breaking application logic.
- Core Web Vitals scores are poor and Google is penalising your search rankings: LCP over 2.5 seconds, layout shifts, or interactivity delays
- Your system cannot handle concurrent users: performance degrades when multiple people use it simultaneously
- Background jobs are backing up. Queue processing that should take minutes is taking hours.
This is not the right service if the system needs fundamental architectural changes. If the performance problem is structural (a single-threaded design that needs to be parallelised, or a monolith that needs to be decomposed) that is a rebuild, not an optimisation. We will tell you during assessment if the system needs deeper work.
How We Work
Measure, find the cause, fix the cause, then confirm with real user data rather than a score.
Frequently the outcome is one or two specific changes rather than a programme, and where that is the case we will say so rather than propose an engagement.
Get in touch with the page that is slow and roughly when it started.
What You Get
- Performance audit identifying bottlenecks with timing data at each layer: database, backend, network, and frontend
- Database optimisation: query rewriting, index creation, N+1 elimination, and connection pooling
- Backend optimisation: caching strategies, eager loading, query reduction, and memory management
- Frontend optimisation: code splitting, lazy loading, image optimisation, and render performance improvements
- Infrastructure tuning: server configuration, PHP-FPM tuning, Redis caching, and CDN implementation
- Before and after metrics proving the improvement with real timing data
- Documentation of changes made and ongoing maintenance recommendations
Technologies We Use
- Laravel Debugbar / Telescope for backend profiling and query analysis
- PostgreSQL EXPLAIN ANALYSE for query plan inspection and optimisation
- Redis for caching layers: query results, computed values, and session data
- Chrome DevTools / Lighthouse for frontend performance analysis
- New Relic or equivalent APM for production performance monitoring
- Vite build optimisation for frontend asset delivery
The tools vary based on the system being optimised. The methodology does not.
Related Systems
Performance optimisation applies to every system type we build and maintain. A reporting dashboard that takes 10 seconds to load is not useful. A client portal that lags on every interaction erodes trust. For websites where Core Web Vitals are a concern, performance optimisation often runs alongside technical SEO work. Hosting and server configuration improvements are handled under infrastructure support.
Talk to Us About Your Slow System
If your application is slower than it should be and you need someone who can find the actual bottlenecks and fix them, get in touch and we will start with a performance assessment. Browse our services to see what else we work on.
Measure Before Buying Anything
The instinct when something is slow is to buy a bigger server. It is almost always the wrong first move and frequently changes nothing.
Performance problems on business systems are overwhelmingly caused by one of a small number of things, and none is raw hardware capacity. Finding which one takes an hour or two and usually makes the fix cheap.
Businesses spend real money on infrastructure for problems that were one missing database index.
Where The Time Actually Goes
The database, most of the time. Specifically a query that was fine with a thousand records and is not with a million, or a missing index, or the N+1 problem where a page runs one query per row instead of one query. That last one is invisible in the code and produces hundreds of queries per page.
A third party you are waiting on. An analytics script, a chat widget, a payment provider. When they are slow, you are slow, and it looks like your problem.
Work done at request time that could have been done in advance, which is what caching addresses.
Assets. Images far larger than the space they display in, and scripts loaded for features nobody uses any more.
Distance, if your users are far from your server. Physics, not code.
The Diagnosis Sequence
Real user data before lab tests, because a controlled test on a fast connection tells you little about what your customers experience.
Then: how many database queries does the slow page run, what is the slowest single query, what third parties are being waited on, and what is being recomputed that could be stored.
That order finds the cause on most systems within a couple of hours, and it means any spend afterwards is aimed at something real.
What Moves The Price
Whether the cause is known. Diagnosis is cheap. Fixing an architectural problem discovered during it is not.
How much can change safely. A system with tests can be optimised confidently. One without needs care, and care is time.
Whether the fix is structural. Adding an index is minutes. Restructuring how a report is generated is a project.
How much traffic you have. Optimising for load requires being able to reproduce it.
Where This Work Goes Wrong
Optimising without measuring. Effort spent on things that were never slow.
Chasing scores. Perfect performance numbers on pages nobody visits, while the checkout stays slow.
Caching over a problem. Caching a slow query makes the symptom disappear and leaves the cause, which resurfaces the moment the cache misses.
Ignoring the third parties. The most common single cause on marketing sites, and the easiest to fix, because most sites are carrying tags added for campaigns that ended.
Questions To Ask Whoever Quotes For This
- What did you measure, and what did it show? Ask before agreeing to any work.
- How many database queries does the slow page run?
- What are we waiting on that we do not control?
- Is this a fix or a workaround?
- What will it look like at twice the data volume?
A Brief You Can Send Anyone
What is slow: [the specific page or action]
For whom: [everyone, or particular users]
When it started: [and what changed around then]
How slow: [seconds, roughly]
What it costs: [abandoned checkouts, staff time, complaints]
Traffic: [rough volumes]
What we have already tried:
