“Static” sounds like a compromise. In practice, a static site is often the most reliable version of a website: no runtime to crash, no database connection to exhaust, no plugin to patch, and a response that can be served from anywhere.
The mistake is treating static as a universal answer. It is not. It is the right answer when the finished output is files.
The decision is about request time
Ask one question: does this page need to know something at the moment the request arrives?
- A marketing page, documentation page, portfolio or event page: no. Build it once.
- A dashboard with a logged-in user: yes. It needs a runtime.
- A store with inventory and checkout: yes. It needs a runtime and a database.
- A blog with comments moderated elsewhere: usually no. Build the posts, hydrate the comments separately.
Static does not mean “no JavaScript”. A React or Vue build is still static output. It means the HTML and assets are produced ahead of time and served as files.
What you give up
You give up the ability to run code on every request. That means no server-side sessions, no request-time database queries in the page, and no cron inside the site. Those needs move to another service: a small API, a form endpoint, a scheduled job or a managed database.
Static is a deployment model, not a feature list. Choose it when the output is files, not because it is fashionable.
Why it is cheaper
A static site does not need a long-lived process. It can be served by a small web server with a tiny memory footprint, and it can be cached aggressively. On Shika Pages, the plan is free because the workload is genuinely small: files, a certificate and a request counter.
That is not a trick. It is the correct price for the resource being used.
When to move up
Move to app hosting the day the site needs a database, a login, a webhook, an API route or a background job. Do not pay for a runtime before that. Do not stay on static after that.
Static is not the cheap version of a real app. It is the correct version of a different job.