On this page
What application performance work involves
When an application feels slow, there is usually one dominant cause. It might be a database query that scans a whole table, a page that makes hundreds of small queries instead of one, an external API called on every request, or a report computed from scratch each time. Performance optimization means finding that cause with evidence, fixing it, and confirming the improvement with measurements.
This complements our server performance service, which focuses on operating system, web server and database settings. Here we go further into the application: code paths, queries, caching and background work.
Warning signs
- Certain pages or API endpoints are much slower than the rest.
- Performance was fine at launch but degrades as data grows.
- A SaaS dashboard or export times out for your largest customers.
- An e-commerce catalogue slows down when filters are applied.
- The team’s response has been to keep upgrading the server.
Performance problems also have indirect costs that are easy to miss: support tickets about timeouts, customers abandoning slow checkouts, and developers spending time firefighting instead of building features. Fixing the root cause usually pays back on all three.
What’s included
- Baseline measurements of response times for key pages and endpoints.
- Profiling of slow requests to identify where time is spent.
- Database analysis: slow queries, query plans, indexes and N+1 patterns.
- Caching strategy for expensive computations and repeated lookups.
- Moving slow work such as emails, reports and imports into background jobs.
- Front-end checks where relevant: asset size, caching and render-blocking resources.
- A report with before-and-after numbers and remaining recommendations.
We keep the report readable for non-developers as well, so decision-makers can see what was slow, what was changed and what the measured result was, without needing to interpret profiler output.
Our method
- Measure: agree which journeys matter and record their current performance.
- Profile: trace slow requests to the specific queries or code responsible.
- Fix: tackle the biggest constraint first, one change at a time.
- Verify: re-measure under the same conditions and record the difference.
- Prevent regression: add monitoring or tests so the same problem is noticed if it returns.
We keep a running log of each change and its measured effect. That log becomes part of the report, and it also helps your developers understand which patterns caused problems so they can avoid them in new features.
Tools we use
We use database tools such as slow query logs and EXPLAIN for PostgreSQL and MySQL, framework-level profilers for Laravel, Django, Node.js and similar stacks, and load testing tools to reproduce busy periods. Redis is a common choice for caching and queues. For ongoing visibility, Prometheus and Grafana or your provider’s monitoring show response times and resource use over time.
Tool choice matters less than method. The same measure, fix and verify loop applies whatever the language or framework, and we use whatever profiling your stack already supports before introducing anything new.
Typical causes and fixes
| Cause | How it shows up | Typical fix |
|---|---|---|
| N+1 queries | A list page runs one query per row | Load related data in a single query |
| Missing index | A query slows as the table grows | Add the right index and confirm with the query plan |
| Work done during the request | Pages wait on emails, PDFs or external APIs | Move the work to a background queue |
| Repeated expensive computation | The same report is calculated for every visitor | Cache the result with a sensible expiry |
| Unbounded results | Endpoints return everything at once | Pagination and field selection |
What affects timeline and cost
A single slow endpoint with an obvious cause can be fixed quickly. More time is needed when slowness only appears under production load or data volume, when there is no staging environment with realistic data, when several causes interact, or when the fix requires restructuring part of the application. Access to the codebase and a way to test safely make a big difference.
Sometimes the honest conclusion is that a larger server or a managed database really is the right answer. When that happens, we say so and show the measurements that support it.
Common mistakes
- Optimising code that is not actually slow while the real bottleneck remains.
- Adding caching without a plan for invalidation, so users see outdated data.
- Adding indexes everywhere, which slows down writes.
- Declaring success based on how it feels rather than measured numbers.
Related: Monitoring & Logging, API Development and Python Development. See all DevOps & Deployment services, the DevOps guide, or contact us.
Frequently asked questions
Do you need access to our code?
For application-level work, yes. Read access lets us profile and pinpoint issues; we can make fixes directly or give your developers precise changes.
Will you just tell us to buy a bigger server?
Only if the measurements show that is genuinely the answer. Often the bottleneck is a query or code path that no amount of hardware fixes efficiently.
How do you measure improvement?
We record response times for agreed pages and endpoints before and after, under comparable conditions, and share the numbers.
Can you optimise a WordPress or WooCommerce site?
Yes. Common wins include object caching, reducing heavy plugins’ queries and moving scheduled tasks off page loads.
Will this break anything?
Changes are made one at a time and tested in staging where possible, with monitoring watched closely after release.
Talk to us about performance optimization
Find the actual bottleneck before spending money on larger servers.