The Sub-Second Website
How We Achieved 1,500x Faster Page Loads Using Rust, WebP, and Memory-Resident Architecture
South City Computer | January 2026
Table of Contents
1. Executive Summary
This white paper documents our experimental journey to build the fastest possible website for a small business. Through systematic optimization, we achieved:
- 1,500x faster page loads (from 2.4 seconds to 1.6 milliseconds)
- 78% reduction in image payload (20MB to 4.3MB)
- Sub-millisecond response times (36-382 microseconds) for core assets
- 26,000-58,000 requests/second throughput on modest hardware
2. The Business Case for Speed
2.1 User Expectations Have Changed
47% of users now expect load times under 2 seconds, tightened from 4 seconds just a few years ago. 53% of mobile users abandon sites taking longer than 3 seconds.
2.2 The Bounce Rate Cliff
| Load Time | Bounce Rate | Change |
|---|---|---|
| 1 second | 7% | Baseline |
| 3 seconds | 11% | +57% |
| 5 seconds | 38% | +443% |
2.3 Conversion Rate Impact
Sites loading in 1 second achieve 39% conversion rates. At 5.7 seconds, this drops to 0.6%—a 65x difference. Website conversion rates drop by an average of 4.42% for each additional second of load time.
2.4 Real-World Case Studies
| Company | Improvement | Business Result |
|---|---|---|
| Amazon | 100ms faster | 1% more sales (~$3.8B/year) |
| Renault | 1s LCP improvement | 13% conversion increase |
| Vodafone | 31% LCP improvement | 8% sales increase |
3. Methodology
3.1 Test Subject
South City Computer website featuring:
- Single-page design with 5 sections
- 15 high-quality photographs
- Bilingual content (English/Spanish)
- Contact form with email delivery
3.2 Testing Rounds
Round 1: Baseline ├── nginx + Rust API + JPEG from disk └── Result: 2.4 second page load Round 2: Image Optimization ├── Convert all images to WebP └── Result: 78% size reduction Round 3: Full Optimization ├── Monolithic Rust binary ├── All assets embedded in memory ├── Minified CSS/JS └── Result: 52ms page load Round 4: High-Performance Benchmarking ├── Custom benchmark tools (scc-benchmark, scc-perf-client) ├── High-concurrency testing methodology ├── Reproducible performance measurements └── Result: 1.6ms full page load, 58,085 req/s
4. Technical Implementation
4.1 Traditional vs Optimized Architecture
TRADITIONAL STACK
─────────────────────────────────────────
User Request → nginx → [Disk Read] → Response
↓
[Proxy] → PHP/MySQL → Database
MONOLITHIC RUST BINARY
─────────────────────────────────────────
User Request → Rust Binary → [Memory] → Response
│
├── All HTML/CSS/JS in memory
├── All images in memory
└── API handlers compiled in
Single process, zero disk I/O, sub-ms response
4.2 Why Rust?
Rust web frameworks consistently top performance benchmarks:
| Framework | Throughput (req/s) |
|---|---|
| Actix-Web (Rust) | ~680,000 |
| Axum (Rust) | ~650,000 |
| Go (net/http) | ~450,000 |
| Express (Node.js) | ~150,000 |
| Django (Python) | ~30,000 |
Notably, Cloudflare rebuilt their entire edge infrastructure in Rust, achieving a 25% performance improvement.
4.3 WebP Image Optimization
| Image | JPEG Size | WebP Size | Reduction |
|---|---|---|---|
| store-interior | 3.0 MB | 400 KB | 87% |
| repair-work | 2.9 MB | 361 KB | 88% |
| puerto-morelos-plaza | 2.9 MB | 1.1 MB | 62% |
| TOTAL | 20 MB | 4.3 MB | 78% |
5. Benchmark Results
5.1 Response Times
| Asset | Size | Latency Range | Throughput |
|---|---|---|---|
| Health Check | 250 B | 32-212μs | 58,085 req/s |
| index.html | 32 KB | 36-382μs | 26,795 req/s |
| style.min.css | 16 KB | 33-136μs | 41,100 req/s |
| main.min.js | 13 KB | 34-125μs | 45,406 req/s |
| logo.webp | 5 KB | 34-151μs | 39,287 req/s |
| storefront.webp | 128 KB | 107-455μs | 3,676 req/s |
5.2 Full Page Load
5.3 Optimization Summary
| Metric | Before | After | Improvement |
|---|---|---|---|
| Image total | 20 MB | 4.3 MB | 78% smaller |
| Binary size | 28 MB | 19 MB | 32% smaller |
| CSS size | 21 KB | 16 KB | 24% smaller |
| Page load | ~2.4s | ~1.6ms | 1,500x faster |
| Memory usage | 50-200 MB | ~1.1 MB | 45-180x less |
| Throughput | ~100 req/s | 58,085 req/s | 580x faster |
6. Comparison: Custom vs WordPress + CDN
6.1 WordPress Performance Reality
WordPress powers 43% of websites, but performance varies significantly:
- Average WordPress desktop load: 2.5-3 seconds
- Average WordPress mobile load: 13.25 seconds
- WordPress ranks 15th out of 20 CMSs for speed
6.2 Can Cloudflare Fix WordPress?
Cloudflare provides significant improvements for static content, but cannot fix:
- Slow server-side rendering (PHP/MySQL)
- Plugin overhead (average WordPress site has 20+ plugins)
- Database query latency
- Large page payloads
6.3 When to Use What
Choose WordPress when:
- Content changes frequently (CMS features needed)
- Non-technical users manage content
- Time-to-launch is critical
Choose custom code when:
- Performance is competitive advantage
- Content is relatively static
- SEO rankings critical in competitive niche
- Memory/compute costs matter
7. Conclusions
7.1 Key Findings
- Image optimization has the highest ROI — WebP conversion alone provides 78% size reduction with minimal effort.
- Rust excels for performance-critical applications — 58,000+ req/s on basic hardware with sub-millisecond response times.
- CDNs level the playing field significantly — Cloudflare can make WordPress competitive for static content.
- Custom code in Rust/Go provides 100-1000x better performance than interpreted languages with heavy frameworks.
7.2 The Bottom Line
For most websites, WebP images + Cloudflare CDN provides 80% of the benefit with 10% of the effort.
For competitive niches where every millisecond matters, the Rust + memory-resident architecture provides unmatched performance that no amount of caching can replicate.
Download This White Paper
Save this technical document as a PDF for offline reading or sharing with your team.
Download PDFQuestions or Need Help?
We're happy to discuss your specific use case and recommend the right approach for your business.
Contact Us← Back to Projects