The measured results
Nine before-and-after measurements, on the same server, with the same data, against the same 6amMart release.
They are not all the same kind of measurement, so each group says which kind it is. Mixing a server response time with a phone's round trip and quoting one multiple across both would be meaningless.
These are the screens a shop owner actually feels. They are not the biggest numbers we have.
Rows 1 to 5 — response times a shopper waits on
Same server, same data, CDN bypassed, so what is being timed is the application and not a cache.
| # | What it is | Stock | Optimised | Faster by |
|---|---|---|---|---|
| 1 | Featured items on the home screen | 8.19 s | 0.37 s | 22× |
| 2 | Product search | 1.64 – 1.96 s | 0.09 – 0.12 s | at least 13× |
| 3 | Storefront home page | ~1.47 s | 0.073 – 0.096 s | at least 15× |
| 4 | Top categories | 3.34 s | 0.27 s | 12× |
| 5 | App configuration on launch | 0.53 – 1.15 s | 0.045 s | at least 11× |
Row 1 is the one worth sitting with. Eight seconds is not "slow" — it is long enough that a shopper on a phone concludes the app is broken and closes it. That row is the featured strip on the first screen they see.
Row 5 runs on every single app launch, before a customer can do anything at all.
Rows 6 and 7 — database questions per page
For these, "CDN bypassed" is not a meaningful condition. What is being counted is how many separate questions the application asks its database to draw one page.
| # | What it is | Stock | Optimised | Fewer by |
|---|---|---|---|---|
| 6 | Store earnings export | 8,614 questions | 12 questions | 717× |
| 7 | Product catalog listing | 557 questions | 92 questions | ~6× |
A page that asks 8,614 questions is not merely slow. It holds a database connection open for the whole time it is doing it, so a handful of admins opening that report together is enough to make the shop itself feel unwell for everyone.
This is also the clearest example of why the count matters more than the clock. On a small dataset those 8,614 questions are each fast, so the page looks acceptable in testing and collapses on a real shop.
Rows 8 and 9 — not server measurements
These two carry a caveat because they are a different kind of thing, and reporting them beside server timings without saying so would be misleading.
| # | What it is | Stock | Optimised | Change |
|---|---|---|---|---|
| 8 | Styling shipped on every website page — a build output, not a server timing | 921,603 bytes | 12,386 bytes | 98.6 % less (74×) |
| 9 | Ten app requests in sequence, from a handset over mobile data | 6,140 ms | 1,876 ms | 69 % less (3.2×) |
Row 8 is a byte count taken from the build output. No server was involved in producing it.
Row 9 is closest to what a customer experiences, and deliberately the smallest multiple on the page. It includes the mobile network, which we did not optimise and cannot. A shop owner who wants to know "what will my customer feel" should read this row, not row 1.
The admin panel, measured — August 2026
The rows above are what a shopper feels. In August 2026 we swept the other side: all 297 admin pages, on a real shop's data (66,701 orders, 113,231 order lines, 17,534 customers), each page requested warm through the real PHP opcache with its database queries grouped by statement.
The panel was not broadly slow — 269 of 297 pages already answered in under 200 ms. The cost was concentrated in a handful of report pages, each slow for a different reason, and each fix had to return identical figures before it was accepted.
| What it is | Before | After | What was wrong |
|---|---|---|---|
| Day-wise earnings report | 17.5 s | 0.71 s | one statement ran 122 times — once per day in the range — summing money in PHP; now one SQL aggregate, equal to the paisa |
| Delivery-rider list | 769 ms | 56 ms | loaded every rider's full transaction history just to print a count |
| Rental coupon page | 2.84 MB of HTML | 201 KB | rendered all 17,534 customers as dropdown rows |
| Item-wise report | 1.20 s | 0.38 s | paginated by running the query twice; now one pass plus a covering index |
| Store summary aggregate | 182 ms | 48 ms | answered from table rows; a covering index now answers it from the index alone |
Two report pages were measured and left alone on purpose — their cost is one honest scan of the whole order history, which is the job, not a defect. We publish that the same way we publish the wins: a number that will not improve, and why.
After the round, only 22 of 297 pages take over 200 ms, and all but two of those are whole-history report aggregates in the 300–900 ms band.
What we checked besides speed
Every optimised screen was compared against the stock screen's output to confirm it returned the same result.
Faster was never allowed to mean different. A page that produces different numbers quickly is not an improvement, and a speed number without that check behind it is not worth publishing.
How these were taken
| Condition | What it was |
|---|---|
| Before | The stock script exactly as CodeCanyon shipped it at the time of the experiment |
| After | The same script after the optimisation and hardening work, with the vendor's next release layered on afterwards |
| Server | The same machine for both runs — 4 GB, 2 cores |
| Method | Measured server-side, with the CDN bypassed, except rows 8 and 9 |
| Acceptance rule | Every performance change had to return identical data before it was accepted |
The arithmetic, printed
Where a measurement produced a range, the multiple is the least flattering the numbers allow: slowest "before" divided by fastest "after". Our internal report quotes midpoints and gets larger multiples. These are the conservative ones.
The same applies to rounding, in every case against us:
- Row 6 prints 717×, not the 718× our own report writes. 8,614 ÷ 12 = 717.83, and this page does not round a figure up in its own favour.
- Row 8 is 921,603 ÷ 12,386 = 74.4, printed as 74×.
- Row 9 is 6,140 ÷ 1,876 = 3.27, printed as 3.2×.
Do not read any of this as a general "6amMart does X" figure
Each number describes one screen, on one dataset, on 2 cores. Change the screen, the data or the hardware and the number changes.
What these numbers do not tell you
They do not tell you what an 8 GB server would do — we did not measure one.
They do not describe your catalogue, which is a different size and shape from the one we tested.
And they say nothing about the defects, several of which cost money without ever showing an error: defects fixed covers those, and what is still open covers what we have not solved.