Performance¶
🌐 Websites¶
Measured in production on ekit.app (October 2026), a site built and hosted with Ekit.
| Metric | Result |
|---|---|
| PageSpeed Insights (mobile) | 100 Performance · 100 Accessibility · 100 Best Practices · 100 SEO |
| Cached page — server time | ≈ 2 ms (median) |
| Full render (data, templates, no cache) — server time | ≈ 30 ms |
| Throughput, cached pages | ≥ 4,300 pages / second |
| Throughput, every page rendered (no cache at all) | ≈ 350 pages / second |
| Errors | 0 out of more than 750,000 requests |
Test conditions¶
- Server: the production server, one machine, 5 API processes behind nginx (HTTPS).
- Load generator: autocannon, run on the same machine (it shares the CPU, so the figures are conservative).
- Cached pages: the home page, from 10 to 400 simultaneous connections, 20 s per step.
- No cache: the same page rendered in full for every request (data queries, templates, layout), from 5 to 50 simultaneous connections.
- Saving in the Studio under load: a site file was saved in the Studio while the site served ~4,300 pages / second — no errors, no visible slowdown.
Reading the figures
The cached-page throughput stopped growing at about 4,300 pages / second from 50 connections onward: that is the limit of the load generator (single-threaded), not of the server. The real capacity is higher.
Times above are server times (Server-Timing header). What a visitor sees also includes the network: a CDN brings pages closer to distant visitors.
Why it is fast¶
- Server-side rendering: visitors receive complete HTML, with no framework to download before the page appears.
- Page cache: a page is rendered once, then served from memory until the site or its data change — cleared automatically, never stale.
- Only the data the page uses: each page runs the datasources of its view and of the partials it actually includes, nothing else.
- Compressed responses (gzip) and browser revalidation (
ETag→304 Not Modified).
🔌 Public API¶
The Ekit API was subjected to production-like load tests simulating real-world traffic patterns. The results demonstrate extremely low and stable latency, making it ideal for Server-Side Rendering (SSR) and SEO-critical applications.
| Metric | Result | Status |
|---|---|---|
| Average Response Time | 31.34 ms | ✨ Excellent |
| p95 Latency | 40.61 ms | ✨ Excellent |
| Server Error Rate (5xx) | 0.00% | ✅ Rock Solid |
| TTFB (Time to First Byte) | 31.34 ms | ⚡ Ultra-Fast |
🛠 Test Conditions¶
- Environment: Production cluster
- Origin: High-speed VPS (Europe)
- Scenario: Real API workloads (table fetch, filtering, sorting, record access)
- Load: Sustained traffic at ~14 requests/second
- Duration: 4 minutes of continuous load
📈 Latency Distribution¶
- Median (p50): 30.72 ms
- p90: 39.05 ms
- p95: 40.61 ms
- p99: 44.22 ms
Technical insight:
A p95 latency of ~40 ms means Ekit adds virtually no perceptible delay to SSR pipelines, even under sustained load.
🔒 Reliability & Protection¶
- 0 server-side errors (5xx)
- Stable response times throughout the test
- Built-in rate limiting protects infrastructure without impacting legitimate traffic
💡 Why it matters¶
- Core Web Vitals: ~30 ms TTFB helps keep LCP and CLS in the green.
- Scalability: Architecture designed for high-traffic, content-heavy platforms.
- Developer Experience: CMS flexibility with near-native API performance.
Report generated using k6 (Grafana Labs)