Portless
Portless performance: measure proxy overhead separately from developer convenience
Design an honest Portless benchmark around equivalent protocols, backend work, route count and browser behavior without inventing latency or savings.
What you will learn
- A readable URL is not a latency benchmark
- Compare equivalent paths and report failures
- Account for operational and sharing costs
Before you start
- Basic HTTP origins, ports and command-line concepts
- Ability to distinguish loopback, LAN and public exposure
Trace a named request, choose explicit setup boundaries and separate observed behavior from untested integrations.
Key takeaways
- Developer convenience and request latency are different outcomes.
- Linear matching is a profiling hypothesis, not proof of a bottleneck.
- Functional test passes provide no throughput or financial savings claim.
A readable URL is not a latency benchmark
Portless can reduce the human work of remembering port assignments and updating local references. That convenience is different from request throughput or application startup time. A proxy introduces another connection path and may perform TLS and protocol adaptation; the size of the overhead depends on the workload, runtime and browser rather than the friendliness of the URL.
The source matches routes through several linear Array.find passes and calls getRoutes on each request. This supports a hypothesis that route count and callback work can affect lookup cost, but does not establish a practical bottleneck. A caller returning an in-memory array and one reading state have different overhead. Profile the actual integration before proposing a cache that could make route changes stale.
Compare equivalent paths and report failures
A useful experiment fixes the application revision, response size, machine and runtime, then compares direct and proxied requests under controlled connection reuse and concurrency. Separate warm requests from startup and certificate setup. Report latency distributions and error counts rather than a single best request, and retain raw measurements so retries do not silently erase failures.
HTTP/2 multiplexing is a distinct browser-side feature, not evidence that the whole application becomes faster. Compare the same protocol where possible, then separately evaluate the intended HTTPS and HMR workflow. A benchmark of a tiny JSON response cannot stand in for a framework page with streaming, asset loading and WebSocket reconnects. Our 24 functional cases intentionally provide no performance conclusion.
Account for operational and sharing costs
Time spent diagnosing trust, conflicting versions, stale routes and startup services belongs in an adoption evaluation. Optional sharing adds external tools and their own access policies and potential charges. The local package license does not establish the price of those services, and this article does not quote unverified subscription prices.
Start with a measurement sheet whose unknown values are null. Record developer interruptions separately from CPU, memory, request latency and failure rate. If stable URLs save time in your team, show the observed before-and-after task and its limitations; do not convert the source inventory or a successful smoke test into a fabricated percentage improvement.
Implementation steps
- 1
Fix the backend, runtime, protocol and payload.
- 2
Measure direct and proxied warm requests with failures retained.
- 3
Evaluate startup, certificate and HMR behavior separately.
- 4
Publish raw observations and leave unmeasured savings unknown.
Copy-ready example
{
"benchmarkStatus": "proposed, not executed",
"routeCount": null,
"directP95Ms": null,
"proxyP95Ms": null,
"errorCount": null,
"developerMinutesSaved": null,
"externalSharingCost": null
}Frequently asked questions
Does HTTP/2 guarantee lower page-load time?
No. Application work, connection reuse, assets and protocol adaptation all matter. Measure the browser workflow you actually intend to use.
Can the 24-case probe be quoted as a benchmark?
No. It verifies selected behavior with fixture servers and records no comparative latency, throughput or cost measurements.
Sources
- packages/portless/src/proxy.tsSource checked 2026-09-08
- packages/portless/src/types.tsSource checked 2026-09-08
- README.mdSource checked 2026-09-08