Application and database performance audit

A slow application does not always have one simple cause

The same symptom can have several sources. A screen may be waiting for the database, an external API or a queue. The problem may also be too many operations, missing or misplaced caching, the way data is processed, environment configuration or work performed in the browser.

This is why we do not start an audit by adding random indexes or changing the server. First we identify the scenario that matters to the business, the conditions in which the problem occurs and a repeatable way to measure it. Only then do we examine the relevant parts of the system.

When this audit makes sense

An important task keeps taking longer

It may be opening a report, saving an order, searching, importing data, generating a document or an operation performed by an employee many times a day.

The system slows down as the business grows

More data, users or integrations have exposed a limit that was not visible before. You need to know whether the cause lies in queries, application code, architecture or the environment.

Timeouts and inconsistent response times appear

The same operation is fast once and blocks the process another time. This is common with queues, scheduled jobs, integrations, imports and operations running concurrently.

You have several theories but no evidence

One person recommends a larger server, another a database redesign and someone else a framework change. The audit separates causes from symptoms and puts the work in the right order.

First, we define what "slow" means in this system

There is no single score that describes the performance of an entire application. Loading a public page, saving a large form, calculating a report, processing a queue and importing thousands of records all require different measurements.

Before measuring, we agree on:

• the exact screen, action or process;
• the environment and conditions in which the problem occurs;
• the data volume, number of operations or load needed to reproduce it;
• available measurements, technical logs and access restrictions;
• how a future fix should be verified.

This lets us compare like with like instead of drawing conclusions from one accidental test.

Example: a slow report does not automatically mean a missing index

Suppose a sales report takes several seconds to open. The cause could be one expensive query, but it could also be hundreds of small queries executed in a loop, waiting for an external service, processing too much data in the application or generating a response the user does not need in full.

Adding an index without reviewing the execution plan may change nothing. Increasing server resources may only postpone the problem. We therefore reproduce the situation, collect measurements and determine where the time is actually spent.

This is a hypothetical example of the analysis method. It does not describe a specific project and does not imply that every application has the same problem.

What we can examine

We agree on the exact scope before starting. Not every application needs every area below.

We perform only measurements that are safe for the agreed environment. Any action that may change data, increase load or affect users requires a separate decision and suitable test conditions.

How the audit works

1. We briefly qualify the problem

A call of up to 20 minutes helps us understand the symptom, its business impact and the access that may be needed. It is free, but it is not a diagnosis, code review or report.

2. We agree on scope and safe conditions

We define the scenarios, environment, materials, limitations and result format. If load testing is needed, we also agree on its scale and how the live system will be protected.

3. We reproduce the problem and record a baseline

We collect measurements for the agreed operations. If the problem cannot be reproduced, we document that limitation instead of forcing the evidence to fit a convenient theory.

4. We isolate the bottlenecks

We examine only the agreed layers. We compare measurements, execution plans and application behaviour to identify evidence-based causes.

5. We set priorities and a verification method

We separate quick fixes from changes that require broader modernisation. For every important recommendation, we explain how to verify its effect after implementation.

What you receive

The deliverables are defined in the proposal. They usually include:

• the examined scope and measurement conditions;
• a measurement-based baseline;
• confirmed bottlenecks with evidence and priority;
• short-term recommendations and changes requiring further development;
• a method for retesting after fixes are implemented;
• a proposed order of work;
• a separate implementation estimate when the scope can be defined reliably.

We provide the summary in the format agreed before the audit. You can use it for further work with Domin Software or pass it to another contractor, subject to confidentiality and without publishing the materials.

Why a Lighthouse score alone is not enough

Lighthouse is useful for testing how a specific page loads under laboratory conditions. On its own, it does not describe the database, queues, imports, authenticated areas or the real experience of every user.

Google distinguishes laboratory data from field data collected from real users. Results may vary because of device, network, location and test conditions. When a public page is within scope, we therefore treat Lighthouse as one source of evidence, not as the entire diagnosis or a guarantee of a particular score.

Database performance depends on the execution plan, not just a list of indexes

Database tools can show which plan was chosen for a query and what happened during execution. PostgreSQL and MySQL provide the EXPLAIN family of commands for this purpose, with exact capabilities depending on the engine and version.

These measurements help assess the number of rows processed, how data is joined and where the query performs more work than expected. Adding an index is not a universal fix: it must match the real query and may also affect writes.

We select diagnostic methods for the specific database and environment. We do not run costly or data-changing operations in production without agreeing safe conditions.

What the basic audit does not include

Unless the proposal says otherwise, the basic scope does not include:

• implementing the recommended fixes;
• ongoing monitoring and application maintenance;
• building additional infrastructure for large load tests;
• a full security audit or a complete audit of an application created with AI;
• a guaranteed Lighthouse score, response time or supported user count;
• fixing components that cannot be examined safely in the agreed environment.

If the analysis shows that the system needs a broader rebuild, the next step may be application modernisation. If ongoing care, monitoring and change support are needed, see application and online store maintenance. We can estimate selected recommendations as a separate stage of PHP and Laravel development.

Timing, estimate and payment

Each audit is priced individually because the scope depends on the number of processes, technology, available data and test conditions.

As a working estimate, allow 5 to 10 business days after we receive all agreed access and materials. The final deadline is stated in the proposal.

Payment is usually due after the agreed stage is complete. For a larger scope, we may agree on a deposit. If you commission the following project from us, the audit fee is included in the total cost of that work.

Frequently asked questions

Is a PageSpeed Insights or Lighthouse report enough?

It can help start a conversation about a public page, but it does not replace measurements of the affected process. It cannot by itself explain a slow report, import, database write, queue or authenticated operation.

Do you need production access?

Not always. We first establish where the problem can be reproduced safely. We prefer a test environment or controlled measurements. Production access is agreed only when necessary and can be limited appropriately.

Does the audit include implementing the fixes?

Not in the basic scope. We first provide the diagnosis and priorities. Implementation can be estimated separately, and you may also give the materials to another contractor.

Will adding an index solve the database problem?

Sometimes the right index helps, but not for every query or situation. We first inspect the execution plan, the amount of processed data and how the application uses the query.

Which technologies can you examine?

We most often work with PHP and Laravel applications, online stores and their databases. We qualify other technology stacks before estimating the audit so that we do not promise analysis we cannot perform reliably.

Is an audit possible without existing monitoring?

Yes, if the problem can be reproduced and enough material is available for measurement. If the data is insufficient, we may first recommend a safe way to collect it. This limitation will be stated clearly in the result.

What to send first

In the form, describe:

• which action or part of the system is slow;
• when the problem occurs and whether it can be reproduced;
• how it affects employees, customers or sales;
• the approximate number of users, records or operations, if known;
• the technologies used, if known;
• recent major changes to the application or environment;
• existing reports and measurements, without including confidential data.

Do not send passwords, API keys, database copies or customer data in the form. We will agree on a secure way to provide any required materials separately.

If you want to organise the available information first, use the performance audit preparation checklist. The tool does not diagnose the problem and does not require you to send confidential data.

CTA: Describe the performance problem

Technical sources

• Google: Web Vitals - the distinction between field data and laboratory diagnostics, including limits of measuring INP in a typical lab test.
• Google: Getting started with measuring Web Vitals - why laboratory and real-user results may differ.
• PostgreSQL: Using EXPLAIN - execution plans and actual runtime information used in query analysis.
• MySQL 8.0: Obtaining Execution Plan Information - execution plans and EXPLAIN ANALYZE measurements.