cesnimda
5.1 KiB
Performance baseline and measurement boundaries
10 November 2026. The roadmap TODO 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 · 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
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 · MariaDB ANALYZE
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 · ASP.NET Core 9 compression · MySqlConnector options