“Tested” is only useful when the test can be inspected and its limitations are visible. Z Tools therefore keeps bounded scripts and raw JSON/CSV beside the source, while deliberately refusing to expose those scripts as public benchmark endpoints. That protects a small shared-hosting deployment from becoming a free stress-test service.
Suites in the current raw result
| Suite | Cases | What it verifies |
|---|---|---|
| Base64 overhead | 7 deterministic byte sizes | Output-length/padding behavior |
| JSON cases | 7 parser inputs | Success/failure edge behavior |
| SHA-2 reference timing | 3 algorithms × 3 sizes | Bounded Web Crypto execution |
| Case splitting | 5 mixed identifiers | Acronym/number/punctuation splitting |
| Color contrast | 5 known pairs | Relative-luminance calculation |
How the current run separates timing from UI checks
The raw benchmark script intentionally uses Node.js/V8 for deterministic JavaScript reference measurements and records Node/Python versions in environment. A separate Playwright smoke pass loads the local PHP site in Google Chrome and checks the core controls, page errors, and representative responsive widths. SHA timing is published only as a Node/V8 reference—not as Chrome/Safari/Firefox performance.
Why deterministic fixtures
Random inputs make debugging harder. Byte buffers are generated by a fixed formula; JSON cases are literal strings; color pairs are fixed hex values. If a future run changes behavior, the input stays constant and the result is diffable.
Why image results can be skipped
The image script checks installed PHP GD/codec functions before measuring. The current run has GD with JPEG, PNG, and WebP encoders, so image-results.json records real fixture output sizes, codec baselines, and savings. If a future host lacks a required codec, the result records skipped_reason instead of copying numbers from another machine.
Publication rules
- Never publish a number without its environment/method.
- Never turn the benchmark scripts into a public HTTP execution endpoint.
- Prefer functional edge cases over microbenchmarks when the user decision is about correctness.
- If the production host differs, rerun there before making production-specific performance claims.
- Keep the raw result files with the source so a future maintainer can compare runs.
What this methodology does not prove
It does not prove every browser is compatible, every device is fast, or every input is safe. The local Chrome smoke pass is bounded and does not replace post-deployment checks against the real hostname, HTTPS configuration, Apache rules, and production codec build.