When Storipress markets itself as having the world's fastest hosting, we were not joking. Sites literally load in milliseconds, and a good reason why we're able to do this is by literally building our own CDN.
Whilst this choice may have clear performance benefits, there was also a more practical reason why we chose to roll our own CDN. Due to Storipress existing as a multi-tenant hosting solution, in order to issue and deliver individual SSL certificates as required with custom domains, off-the-shelf CDN solutions would have been cost prohibitive at $600/month per cert.
Resultantly, we literally had to build our own proprietary network of servers as it was the only feasible way Storipress could provide SSL for custom domains. This may seem like a daunting task (and it was), but Storipress’ unique architecture enabled us to do some interesting things:
Unlike other CMSs, Storipress sites are pre-rendered as static files. Because these files are not dynamically rendered, this also allowed us to store these files in a file store instead of a database.
Unlike other webservers which serve 5-20 files per request, this server would serve 1, pre-compressed static HTML (CSS inlined) file per request. Larger files like Javascript and rich media (images + video) are code split and offloaded to third party CDNs.

Storipress’ Hosting Architecture. Not visualised is the global routing layer which sits above the SSL servers which directs requests to the geographically closest node.
Measuring Performance and Scalability
The architecture described above is highly unusual, with there being no publicly known information on its scaling characteristics. Prior to launch, our team needed to know how this system would scale, so we decided to test it!
Our testbench setup:
One 0.25 vCPU AWS Fargate node running OpenResty.
This node is connected to an AWS EFS file store which contains solely HTML files with CSS inlined. JS and rich media are offloaded to ‘real’ CDNs for delivery.
Two tools, K6 and Hey, were used to send simulated traffic to the server and stress the CPU. K6 was scripted to hit a variety of URLs with Hey only hitting the resource heavy homepage. These tools were hosted on Linode to avoid sending traffic from AWSs internal network.
Results:
1.2M Requests/Hour
The point where this 0.25 vCPU node fails is at 1.2M pageviews/hour, at a data egress cost of $3.60 USD. This is 890M requests/month at a HTML transfer cost of $2,680, on a server less powerful than a Raspberry Pi.
3rd party CDN costs: $26
Delivery of non-HTML files for this amount of traffic has an upper bound cost estimate of $26USD/1.2M pageviews. This is due to these files being extremely optimised, and can decrease a further 65% with scale pricing.
Unbeatable TTFB
As the first few requests hit the server, TTFB goes from 800ms to 2-20ms as requested files start to be cached in RAM.
Discussion
Our team knew this architecture would be scalable, but not to this extent. On receiving these results, we initially thought it was a bug as we could not understand around how a 0.25vCPU could deliver this many requests. We re-ran this test 12 times under different operating parameters to confirm the results.
Our team theorises this insane performance is as our nodes only deliver 1 static file per request; standard webservers dynamically process multiple code files per request from a database, placing exponentially more stress on the CPU.
Closing Notes
Our endless chase for performance doesn't end there however. Whilst the above test demonstrates the power of our HTML CDN on a single 0.25 vCPU node, Storipress' production hosting architecture has 16 nodes distributed across the world, each having approximately 6x more vCPU power than the machine used in our test.
This means that even with these results, in production, we are running a CDN with approximately 96x more compute power than the test instance with 16 regions of failover. And, perhaps unsurprisingly, on stress testing, we have not been able to push our this architecture to failure (knock on wood).
This means Storipress has truly class leading performance, scalability, and cost that cannot be replicated by other solutions, benefits which we pass onto you — and benefits only achieved through our vertical integration of hosting with our unique CMS software architecture.