Seven-Page Server Response Baseline From the Hermes VPS

Method

The collector made one cold HTTP request per route from the Hostinger VPS and measured elapsed wall time until the full response body arrived. It also recorded transferred HTML bytes. No repeated samples were averaged, so these values are a triage baseline rather than a latency benchmark.

The sample intentionally spans the homepage, two indexes, a browser-local tool, a policy page, a fixed guide, and a D1-backed article. That separates route-shape differences before any optimization is proposed.

Observed evidence

Findings

• The guides index was the slowest of seven observations at the collection time.
• The D1-backed article transferred more HTML than the fixed guide and homepage.
• One sample cannot distinguish origin processing, network variance, or cache warm-up effects.

Decision and resulting changes

Use the guides index and D1 article as the first two routes for repeated sampling. Do not claim a user-facing speed improvement until multiple regions and multiple runs support it.

• Published the raw baseline instead of presenting an unexplained performance score.
• Added explicit measurement origin and sampling limitations.
• Kept cache changes bounded and reversible.

Limits and reproduction

Re-run automation/evidence_collector.py against the public origin and compare the resulting JSON fields. A difference is evidence of a changed response, not automatically an improvement.

• The VPS location is not representative of every reader.
• Elapsed time is not Core Web Vitals and does not measure rendering or interaction.