The hidden cloud tax: why slow web apps cost more than their hosting bill
Slow pages cost you sales. Over-sized servers cost you cash. Both usually trace back to the same cause, and it is fixable. Here is how Shetab, the engine we build client apps on, approaches it, with the limits stated.
By the Desi Script engineering team · Updated 2026-11-10 · 9 min read
The short version
- Most web apps repeat avoidable work on every request. Shetab moves that work to before launch.
- That means faster first responses, less server needed per visitor, and a hosting bill that can fall by up to 70–80% when the current setup is oversized.
- Not every site needs it. The last section explains who benefits and who should simply tune what they have.
In this article
Speed is revenue, and the research is consistent
Page speed is often filed under "IT metrics". The published research ties it directly to commercial results:
−7%
Conversions lost to a 100 ms delay
Akamai's State of Online Retail Performance (2017) found that a 100-millisecond slowdown reduced conversion rates by about 7%.
+8.4%
Retail conversions from 0.1 s faster
Deloitte and Google's "Milliseconds Make Millions" study (2020) linked a 0.1-second improvement in mobile speed to higher retail conversions.
53%
Mobile visits abandoned after 3 s
Google's 2016 mobile research found more than half of visits are abandoned when a page takes longer than three seconds to load.
The pattern matters more than any single figure. Small delays cost real revenue, they cost more on mobile, and they cost more at checkout, where buyers are closest to leaving. For businesses whose customers are on mid-range phones and variable networks, a lean application matters even more because every extra kilobyte and round-trip is felt.
What Shetab changes: do the work once, before launch
Shetab (from the Persian word for acceleration) is the runtime we build client applications on. Its approach is simple to state: anything that does not change between visitors should be worked out at build time, not on every request.
An analogy: packing the suitcase before the taxi arrives
A conventional stack packs the suitcase while the taxi waits outside: finding routes, loading code and assembling the response, every single time. Shetab packs in advance. When a request arrives, the response is mostly ready.
Fast where we control it, honest about the rest
Under 0.05 ms is the time Shetab spends on its own routing and dispatch per request. A page's total time also includes database queries, the network and the browser. Shetab removes the framework's share almost entirely, and we design the rest to a page-speed budget you can verify.
That separation is the difference between a headline and a result. Faster server work means more requests handled per server, which is where the cost savings come from, and a quicker first byte, which is where the speed gains start.
Faster pages where it counts
Shetab does its routing and asset preparation before launch, so almost nothing is left to compute per request. The time your visitors wait is then down to your data and network, which we design for, not to framework overhead.
A smaller hosting bill
Less wasted CPU and memory means a single $20–$50 per month server can carry workloads that often sit on $500–$1,000+ per month of cloud infrastructure. We quote your saving from your real invoices, not a generic number.
Tamper detection built in
Each file is fingerprinted at build time and verified at runtime. If someone changes your application code on the server, the mismatch is caught instead of quietly running in front of your customers.
Send us your last three hosting invoices
We will tell you where the money is going and whether a migration, or a simpler fix, is the right move.
Traditional web stack vs. an application on Shetab
Where the two approaches differ, and what that means for the business. "Traditional" here means a typical general-purpose framework or CMS with plugins, scaled by adding servers.
| Area | Traditional stack | On Shetab | What it means |
|---|---|---|---|
| Server-side processing per request | Framework boots, resolves routes and loads dependencies on each request | Routes and assets prepared before launch; under 0.05 ms internal dispatch | Faster first byte, more headroom on the same hardware |
| Total page speed | Often 2–3 s on busy, plugin-heavy sites | Framework overhead removed; remaining time depends on queries, region and front-end | We set and test a page-speed budget during the build |
| Monthly infrastructure | $500–$2,000+ on multi-node cloud when over-provisioned | From a shared hosting plan to a $20–$50 VPS to start | Up to 70–80% saving where the current setup is oversized |
| Traffic spikes | Scaled by adding servers, which raises the bill | More headroom per server; load-tested against your expected peak | You see the test results before launch |
| File integrity | Changes to files on the server usually go unnoticed | Signed manifest; modified files are detected | Unauthorised code changes are caught early |
| Growth path | Re-platforming is common when outgrowing the first tier | Shared host or single VPS → split database and cache → multi-region, same codebase | Scale infrastructure without rewriting the app |
Server-side processing per request
- Traditional stack
- Framework boots, resolves routes and loads dependencies on each request
- On Shetab
- Routes and assets prepared before launch; under 0.05 ms internal dispatch
- What it means
- Faster first byte, more headroom on the same hardware
Total page speed
- Traditional stack
- Often 2–3 s on busy, plugin-heavy sites
- On Shetab
- Framework overhead removed; remaining time depends on queries, region and front-end
- What it means
- We set and test a page-speed budget during the build
Monthly infrastructure
- Traditional stack
- $500–$2,000+ on multi-node cloud when over-provisioned
- On Shetab
- From a shared hosting plan to a $20–$50 VPS to start
- What it means
- Up to 70–80% saving where the current setup is oversized
Traffic spikes
- Traditional stack
- Scaled by adding servers, which raises the bill
- On Shetab
- More headroom per server; load-tested against your expected peak
- What it means
- You see the test results before launch
File integrity
- Traditional stack
- Changes to files on the server usually go unnoticed
- On Shetab
- Signed manifest; modified files are detected
- What it means
- Unauthorised code changes are caught early
Growth path
- Traditional stack
- Re-platforming is common when outgrowing the first tier
- On Shetab
- Shared host or single VPS → split database and cache → multi-region, same codebase
- What it means
- Scale infrastructure without rewriting the app
Cost and scaling: grow without a rebuild
A common trap: version 1.0 is built on a fragile template, traffic grows, the system strains, and the advice becomes "we need to start again." Shetab is designed so growth means changing infrastructure, not rewriting the application.
Start lean
Shared hosting, or about $20–$50 / month on a VPS
Early-stage products can launch on an ordinary shared hosting plan. As traffic grows, one VPS runs the app, database and cache.
Split as you grow
Typically $100–$250 / month
Move the database and cache to their own machines and add rate limiting to protect against overload.
Go multi-region
Priced to your workload
Deploy across regions with a CDN or Kubernetes, using the same codebase.
How we size it
The ranges above are typical starting points, not guarantees. Before launch we load-test against your expected peak and share the results, so the first tier you choose is based on measured capacity for your workload. On shared hosting, some tuning options depend on what your host allows, so we confirm what your plan supports before we recommend it.
Security: what tamper-evident deployments do, and what they don't
On a conventional server, files can be changed by a compromised plugin or stolen login, and nobody notices until customers see injected ads or malware warnings. Shetab fingerprints every deployed file with SHA-256 when it is built and checks them at runtime. If a file no longer matches, the change is detected instead of running quietly.
What it covers
- Unauthorised changes to application code on the server
- Injected scripts added to deployed files
- Silent drift between what we shipped and what runs
What still needs normal good practice
- Patched dependencies and operating system
- Safe database queries and input handling
- Strong credentials, access control and backups
Tamper detection is one layer in a defence, not a guarantee of immunity. We build the other layers in too, and we would be suspicious of any vendor who calls their system unhackable.
Is this right for you? A straight answer
A strong fit if you have
- A customer portal, SaaS dashboard or high-traffic store
- Hosting bills growing faster than your traffic
- Slow pages hurting conversion or search visibility
- Planned launches or campaigns with spiky traffic
Probably not needed if you have
- A small brochure site with modest traffic
- A lean, already well-tuned setup on cheap hosting
- A problem a caching or query fix would solve
If we think a simpler fix will serve you better, we will say so. A migration that is not worth it is not worth selling.
What the audit involves
- 1. You share recent hosting invoices, traffic figures and the pages or flows that feel slow.
- 2. We measure where server time and money are actually being spent.
- 3. You receive a written recommendation: a quick fix, a migration to Shetab with a fixed-scope quote, or both.
Questions buyers ask us
Why do web applications get slower and more expensive over time?
Most apps are assembled from general-purpose frameworks, plugins and third-party scripts. Each layer does useful work, but each also adds code that runs on every request. Over a few release cycles the server is doing far more work per click than the business logic needs, so teams add servers to compensate. The hosting bill grows faster than traffic, and pages still feel heavy.
What is Shetab, and why did Desi Script build its own engine?
Shetab is the application runtime we build client products on. It does as much work as possible before launch, such as route resolution, asset preparation and integrity fingerprinting, so less work is left for each live request. We built it because the general-purpose frameworks we used for earlier client projects spent more server time on their own machinery than on the client's business logic.
Does “under 0.05 ms” mean my pages load in 0.05 milliseconds?
No, and you should be wary of anyone who says so. The 0.05 ms figure is the time Shetab itself spends routing and dispatching a request internally. A page's total load time also includes your database queries, the network between server and visitor, and the browser's own rendering. Shetab shrinks the part the framework controls to almost nothing, so the remaining time is down to the quality of the queries, hosting region and front-end, which we budget for during the build.
How much could we realistically save on hosting?
It depends on what you run today. The biggest savings appear when an app is over-provisioned to compensate for framework overhead, which is common with multi-node cloud setups. In those cases we have seen the monthly bill fall by 70–80%. If you already run a lean, well-tuned server, the savings will be smaller. We calculate the figure from your actual invoices and traffic during the audit, before you commit to anything.
Can it handle a sudden traffic spike on a small server?
A lean runtime leaves far more headroom on the same hardware, which is why a $20–$50 per month VPS goes a long way. We do not rely on that claim alone: before launch we load-test against your expected peak, such as a campaign day or a sale, and share the results. If one server is not enough, the architecture lets you split the database and cache onto separate machines without rewriting the application.
How does Shetab protect against tampering, and what does it not cover?
Every file in a Shetab deployment is fingerprinted with a SHA-256 hash when it is built. At runtime the engine checks files against that manifest, so an unauthorised change to your application code is detected instead of silently running. This is one layer of defence. It does not replace the basics: patched dependencies, parameterised database queries, strong credentials, access control and backups. We build those in as well, and we never describe any system as unhackable.
Are we locked in to a proprietary system?
You own your application code, your database and your domain. The apps use standard web technologies, including React and REST APIs, and run on ordinary Linux hosting, from a shared hosting plan to a VPS or a major cloud, so you are not tied to a particular provider. Shetab is the runtime underneath, and we are open about that: the licensing and hand-over terms are written into the contract before you sign, so you know exactly what you can do if you ever want to move on.
Can an existing slow website or portal be moved to Shetab?
Often, yes. We start with an audit of your current setup, traffic and invoices. If a migration makes sense, you receive a fixed-scope plan and quote that keeps your user data, branding and core workflows. If a smaller fix, such as caching or query tuning on your current stack, would solve the problem, we will tell you that instead.
Sources: Akamai, State of Online Retail Performance (2017); Deloitte Digital and Google, Milliseconds Make Millions (2020); Google/DoubleClick mobile speed research (2016). Cost and speed figures for Shetab are from Desi Script benchmarks and client projects; results depend on your current setup.
Find out what your architecture is really costing you
Send us your hosting invoices and the pages that feel slow. We will show you where the time and money go, and recommend the simplest fix that works, whether that is Shetab or not.
