Job audit-endpoint-performance-before-after · revised 11 October 2026
Measure one slow endpoint or page, make one agreed change and re-measure the same way
Server response time for one endpoint or server-rendered page is measured, one agreed change is made and it is measured again the same way. You get both sets of numbers. Not browser metrics.
You might be seeing
- One endpoint or page is described as slow, but nobody has numbers that two people would agree on
- A performance change was shipped and nobody can show the effect
No passwords, keys, card details or admin invites needed to start.
What usually happened
A single endpoint or page is slow to answer, and the team has opinions but no measurement it can repeat. Timings from one run on a developer's machine move by more than the change being tested, averages hide the slow tail, and the real cost may sit in database queries, repeated calls or payload size rather than where people expect. The job covers server-side response time only: how long the server takes to answer one request. It builds a repeatable measurement of that, finds the largest cost, makes one agreed change and measures again in the same way. It is a lab measurement of one target, not a promise about every user's experience, and it does not measure what happens in the browser after the response arrives.
Who it’s for: A founder or engineering lead with one named endpoint or page that users and the team call slow, and no agreed way to say how slow it is or whether a change helped.
Usually starts when: Customers or staff complain about one screen or one API call, or a previous attempt to speed it up left everyone arguing about whether it worked.
The result: You receive a measurement method you can rerun, the baseline and the after server response times taken the same way, a ranked list of what the server's time is spent on, and one pull request with the agreed change. The report states the change in the numbers whatever it is, including no change.
Check whether this job fits
Answer from what you have observed. These checks show whether one target can be measured repeatably before any code or data is shared.
Checks you can run yourself
Time it three times
Request the page or call the endpoint three times on the same copy, once to warm it and twice timed, and note the server response time of each. Use invented data, not a customer's.
Look for: If the timed results differ by a large fraction of their size, noise is high and the baseline will need more runs. If they agree, a single change should show clearly in the figures.
What you get
- The measurement script or procedure, the conditions it ran under and how to rerun it
- A report with the baseline and after figures, the spread between runs and the ranked list of costs
- A pull request with the one agreed change and its tests
- A short list of the other findings that were not changed, with the expected effect and the effort each might need
Included
- One API endpoint, or one server-rendered page, in one application, measured in one non-production copy with representative synthetic data, agreed in writing. The measured quantity is server-side response time: the time from sending the request to receiving the first byte and the complete response
- A repeatable measurement: a fixed request script, warm-up runs discarded, an agreed number of timed runs per condition, and the median and 95th percentile of the response time reported, with successful and failed requests kept apart
- A ranked profile of where the server's time goes, from query counts and timings, repeated calls to the database or other services, and response payload size, as relevant to the target
- One agreed change to the application code or a query, chosen from the findings and bounded in the proposal; any index or schema change is written up with its rollback and tested on the copy
- The same measurement repeated after the change under the same conditions, with a check that the responses for the request set are unchanged
Not included
- Front-end and browser work: Core Web Vitals (loading, layout shift, responsiveness), rendering, scripts, images, fonts and any browser-side metric or target. That is the separate job to bring one Core Web Vitals metric on one page into the good range
- Load testing, stress testing or capacity planning for many simultaneous users
- Measurement or changes in production, or field data from real visitors, which a lab measurement cannot replace
- Hosting, network, caching layer or database server changes beyond the agreed code or query change; any production index or schema change is applied by you
- More than one endpoint or page, or a rewrite of the application
- A guaranteed speed-up or a target figure, unless a target is agreed in writing before work starts and written into the acceptance check
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Two baseline measurements taken on separate occasions with the written method agree within the spread stated in the report, which is agreed with you before the change is made.
Evidence: Both baseline result sets with the number of runs, the median, the 95th percentile and the conditions.
The after measurement uses the same method, data, number of runs and conditions as the baseline, and the report shows the median and 95th percentile before and after, whatever the difference.
Evidence: The two result sets side by side with the stated conditions, and the independent reviewer's rerun.
The responses for the agreed request set are identical before and after, apart from fields the report names as expected to differ, and the existing tests give the same results.
Evidence: The response comparison and the test output before and after.
If a target figure was agreed in writing, the report says plainly whether it was met under the stated conditions; if it was not met, it says why and what else would be needed.
Evidence: The agreed target, the measured result and the report's statement.
Your authorised maintainer accepts the pull request and the report.
Evidence: The changed-file list, the independently reviewed diff and your written sign-off.
Sign-off. You rerun the measurement from the written method, read the report, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. If the target cannot be measured reliably or the cost lies outside the application, we explain what we found and stop. A speed-up is not a condition of payment unless a target was agreed in writing.
When it fits, and when we stop
It fits when
- A non-production copy exists, or can run locally, with data volumes close enough to production that the slowness shows up
- The slow behaviour can be triggered by a single request that you can describe without customer data, and the time is spent in the server's answer rather than in the browser afterwards
- The code can be shared through an authorised company-controlled route after agreement, and a named person on your side can review and merge the pull request
We stop and tell you if
- The slowness cannot be reproduced in the non-production copy, so there is nothing to measure
- Repeated baseline runs vary so much that a change of the size you hope for could not be told from noise: we report the spread and what would reduce it, and stop
- The cost lies outside the application, such as a third-party service, the network or shared hosting we cannot change, and no change in your code can help
- The server answers quickly and the delay is in the browser after the response arrives: we say so and point to the Core Web Vitals job instead of measuring browser metrics here
- Measuring needs production data or production access
What could go wrong
The change is one pull request. Closing it before merge changes nothing; after merge your maintainer can revert it. Any index or schema change comes with a rollback written and tested on the copy, and you apply and, if needed, reverse it in production.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The after figure looks better because the conditions differed, such as a warm cache or a smaller dataset. | The method fixes the data, the warm-up, the number of runs and the machine, and the reviewer reruns it; the report lists the conditions for both runs. |
| A lab improvement does not carry through to what real users experience. | The report says it is a lab measurement on one copy. Field data from real visitors is a separate source, and lab and field figures can legitimately differ. |
| The change speeds the target but alters its results. | The request set is replayed before and after and the responses compared, and the existing tests must give the same results. |
| The mean looks fine while a slow tail remains. | Both the median and the 95th percentile are reported, with successful and failed requests kept separate. |
An independent reviewer reruns the measurement from the written method, checks that the before and after conditions were the same and checks that the responses did not change. Your authorised maintainer reviews and merges under your existing rules.
Need to keep it working?
More changes from the findings list, or measuring another endpoint or page, are agreed as separate written scopes.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your own team can start by measuring the distribution rather than the average. Google's site reliability book explains why averages hide the slow tail and why latency is best bucketed. sre.google
- web.dev explains why lab measurements and real-visitor field data of a page differ, and to use field data to prioritise and lab data to debug. If the delay is in the browser rather than the server, fixing one browser-side metric on one page is a separate job we list. web.dev
Questions
Will you make it faster?
We aim to improve the biggest cost we find and measure the effect, but we do not promise a speed-up, and payment does not depend on one. The report gives the before and after numbers whatever they show, including no change, and a target can be written into the acceptance check if you want one.
Will this improve my page speed score or Core Web Vitals?
No. This job measures only how long the server takes to respond to one request. Browser-side metrics such as loading, layout shift and responsiveness are the separate job to bring one Core Web Vitals metric on one page into the good range.
Why only one change?
One change measured properly shows its effect clearly. Several changes at once cannot be told apart. The other findings are listed with expected effect and effort so you can choose the next.
Is this a load test?
No. It measures one target for one request at a time on a copy. How the system behaves with many users at once is a different measurement and outside this job.
Why not measure in production?
This job never touches production. A copy with realistic data volume is where we can repeat the measurement safely. Field data from real visitors is useful for prioritising and is a separate source.
Send an enquiry
Send us
- The endpoint or page, in words or as a path without private identifiers, and what slow means for it: a server response time you have seen or a complaint
- The language, framework and database in general terms, and whether a non-production copy with realistic data volume exists
- Roughly how often it is used and who notices (customers, staff, a partner system)
- Do not send code, production data, credentials or logs with customer details in the first enquiry
Later, once you agree
- The agreed source revision through an authorised company-controlled code-export route, with a branch route for the pull request
- Access to the non-production copy, or instructions to run it locally, and a synthetic dataset at a size agreed to be representative
- The request to measure, described as a path, method and synthetic parameters, any server response-time target agreed in writing, and the named person who accepts the report
You own the application, the data and every environment. We work on a copy through a company-controlled identity, never a personal login, with synthetic data. You review and merge the pull request, and you apply any index or schema change to production yourself.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “audit-endpoint-performance-before-after” as the subject.