Performance
Adding Version Compare should not make your site feel slow. We focus on low added delay and modest resource use, rather than trying to be the fastest general-purpose web server.
Version choices happen locally in the proxy. It receives updated findings in the background, so a visitor's page does not wait for a call to Version Compare.
A comparison with nginx and Caddy
In this local test, Version Compare's response times were in the same range as nginx and Caddy, while also selecting a version and adding its tracking code.
| Server | Typical response | 95% completed within |
|---|---|---|
| App without a proxy | 2.1 ms | 5.8 ms |
| nginx | 3.7 ms | 10.4 ms |
| Caddy | 3.1 ms | 7.7 ms |
| Version Compare, selecting versions | 3.7 ms | 7.0 ms |
Typical means the middle response time, not the fastest. These are whole responses, including the app, not measurements of added delay alone.
How we measured
Measured on 5 November 2026 using Linux ARM64 containers in Docker Desktop on an Apple M1 Pro. Each server had one CPU and 256 MiB of memory. We measured 300 requests per server at 20 requests per second, over a local connection without HTTPS, compression, or a CDN. Versions: Version Compare 0.1.0, nginx 1.28.0, and Caddy 2.10.2.
This is a small synthetic page, not a production speed guarantee or a browser rendering test. The comparison servers forward the original page; Version Compare also selects its alternative and includes browser code. All measured requests completed without errors.
What matters for your site
- Your app still needs to generate its response. The proxy cannot remove that work.
- Personalised pages must reach your server. If visitors are far away, that journey can matter more than the proxy's processing time.
- Images, stylesheets, and other unchanged files remain cacheable. Static files use the operating system's efficient file-transfer path where available.
- Selecting and rewriting HTML uses more CPU than forwarding it unchanged. Check your own pages and hosting before choosing capacity.
If keeping static pages close to visitors through a CDN matters more than avoiding a visible version swap, the browser script may be the better fit. Otherwise, follow the server proxy setup guide.