# Performance baseline and measurement boundaries

10 November 2026. The [roadmap TODO](ROADMAP_TODO.md) owns the 18 performance items and their status. This file holds measurement evidence and the comparison protocol.

## Frontend artifact baseline

Read-only census of the existing Windows Next.js 16.4.1 / Turbopack export for isolated I18N source `4c12f7691ff5e73f537135ffed60c0b599c7ce37`. The index SHA-256 is `6f99eecb975bd8f5aee81ada5dbc15abbf6364df0df80dd8ffdd5bc2381a835e`. Gzip sizes use local gzip level 6. They are estimates of encoded content size and exclude response headers.

| Export inventory | Files | Raw bytes | Gzip-6 bytes |
| --- | ---: | ---: | ---: |
| All JavaScript | 58 | 3,603,806 | 1,069,697 |
| All CSS | 2 | 3,958 | 1,189 |
| Modern async JS declared in root HTML, deduplicated | 6 | 468,253 | 139,328 |
| Legacy nomodule JS | 1 | 112,594 | 39,627 |
| CSS declared in root HTML | 1 | 293 | 227 |

No source maps were emitted. The largest exported JS chunk is 550,002 raw bytes and contains JobTable and catalogue identifiers. The largest inventoried image files are favicon.ico (147,708 bytes), logo512.png (133,453 bytes) and logo192.png (32,284 bytes). The three current landing SVGs total 27,380 bytes.

Cold loopback Chromium 151 at 1366×900 used fresh contexts, blocked external fonts and fixture responses with 15 Jobs. Observed JavaScript resources were 18 files / 2,005,036 raw bytes / 591,192 estimated gzip bytes for both `/` and `/login`, and 20 / 2,033,779 / 601,065 for `/jobs`. This includes dynamic client requests. Compression estimates still exclude headers and deployed encoding. There was one initial paged Jobs GET and one duplicate on EN→NB. The published fix `97d06180b7f41f8cd9d93c30b373ff3e8eac67b2` kept one initial GET and reduced the extra GET from one to zero under the same fixture. 34 tests, type-check, scoped lint and export passed. See `docs/i18n/JOBS_LOCALE_READS.md` on `codex/perf-jobs-locale-read`. It is isolated from A3.

The isolated JobTable split `85ebbd9f65cba700ecbeae26126a137caa0e7f08` used three paired cold runs. Landing and Login each fell from 2,005,009 to 1,763,692 raw JS bytes, a reduction of 241,317 bytes or 12.0%. Estimated gzip fell by 71,386 bytes per route. Jobs added three requests and 29,311 raw bytes. Its usable-row medians were 1,014 and 939 ms in this small local sample. These timings establish no repeatable throttled or field gain. 74 tests in six suites plus type-check, scoped lint, build, authenticated Jobs/Trash keyboard and anonymous route guard passed. See `docs/i18n/JOBTABLE_ROUTE_CHUNK.md` on `codex/perf-jobtable-chunk`. This remains isolated from A3.

Repeat on the exact A3 candidate with identical cache, network and CPU settings, routes, browser and fixture sizes. Use route request logs to separate shell bytes from lazy chunks. Use the Turbopack analyzer to trace ownership before moving an import and React Profiler to find costly commits. [Next.js bundling](https://nextjs.org/docs/pages/guides/package-bundling) · [React Profiler](https://react.dev/reference/react/Profiler)

## Backend and database baseline

Historical P9 requalification used MariaDB 12.2.2, 250 applications, eight Career roles and two readers over 15 minutes. It recorded 3,382 successful reads, p50 23.84 ms and p95 33.24 ms. Later P9-SEC-02 source reported p50 24.08 ms and p95 33.41 ms. These are historical source-bound measurements. No new backend/API latency, MariaDB plan, contention, resource or pool measurement was run in this intake. [P9 performance receipt](../redesign/phase-9/p9-requal-01/PERFORMANCE.md)

The ordinary applications page fix at `bca750446f1069eb55d648be838be192d70c2d30` reduced correspondence aggregate rows from 250 and 2,500 to 15 in two disposable SQLite fixtures. Board and empty results issue zero such aggregate commands. 36 selected tests passed, including existing tenant, paging, filter and board parity. This measures rows returned by the aggregate. It does not establish MariaDB rows examined or endpoint latency. Preserve existing readiness and follow-up semantics in future work. Only use MariaDB ANALYZE on an approved disposable dataset because it executes the statement. [EF Core efficient queries](https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying) · [MariaDB ANALYZE](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/analyze-and-explain-statements/analyze-format-json)

Existing public static and authenticated data boundaries remain distinct. Any output cache candidate needs explicit HTTP, tenant and mutation checks. Evaluate byte reduction before enabling compression on additional routes and keep HTTPS side-channel exposure in scope. Pool size and replica proposals need a capacity budget, actual connection measurements and isolated failure tests. [ASP.NET Core 9 output caching](https://learn.microsoft.com/en-us/aspnet/core/performance/caching/output?view=aspnetcore-9.0) · [ASP.NET Core 9 compression](https://learn.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-9.0) · [MySqlConnector options](https://mysqlconnector.net/connection-options/)