Lightweight high performance static hosting

Lightweight is a discipline, not a plan upgrade

High performance on static hosting comes from sending fewer bytes and fewer requests—not from buying a louder marketing adjective. StaticHost does not include a built-in CDN product, and this essay will not invent one. It argues for lean artifacts on a strict file server (try_files $uri $uri/ =404), HTTPS previews that let you measure reality, and rollbacks when an “optimization” deploy fails.

Principles

1. The fastest request is the one you do not make. Delete unused scripts and tracking until product truly needs them.
2. The origin should not think. No PHP bootstrap, no SSR tax—StaticHost only serves files you built elsewhere.
3. Fingerprints beat hope. Bundlers that emit app.[hash].js make long-cache assets safe.
4. Images dominate. A 40 KB HTML file cannot save a 4 MB hero.
5. Routing correctness precedes microperf. A 404 shell on deep link is a failed experience—SPA.

Build for production every time

npm ci
npm run build
# hugo --minify
# JEKYLL_ENV=production bundle exec jekyll build

Dev builds are not performance artifacts. Upload only output—dist, build folder. StaticHost will not minify for you.

Budget example (adjust to your context)

Fail the build in CI if budgets blow—your CI, not StaticHost.

Fonts

Self-host two weights maximum for many sites. font-display: swap. Subset if you know the glyph set. Fonts are a common silent weight tax.

Third parties

Each tag manager can undo careful bundling. Load noncritical analytics after idle. Prefer first-party static files on StaticHost for CSS/JS you control.

Measuring on StaticHost

Use the HTTPS preview (and later the custom domain) with DevTools throttling. Field data (CrUX) matters more than lab vanity once live. Staging on Pro ($30, 3 sites, 10 GB) lets you compare builds without burning production. Plans also: Starter $9 (1×2 GB), Scale $65 (10×30 GB), Business $130 (30×100 GB, teams). Trial ~1 day; no forever-free.

When to add a CDN yourself

After assets are lean, if your audience is far from the origin and TTFB dominates in measurements, evaluate a CDN you operate in front of your origin. That is an architecture decision—not a feature pretence of this product. Companion: fast static site hosting.

Anti-patterns

• Uploading node_modules “for completeness”
• Uncompressed PNGs as CSS backgrounds
• Shipping three carousels on a homepage that needs one idea
• History-mode SPA without files, then blaming the host for “slow errors”
• Expecting a plan upgrade alone to shrink JS

A realistic week shipping lightweight high performance static hosting

Monday starts with a broken relative CSS path that only appears once the files leave a designer’s laptop. You flatten the zip so index.html sits at the archive root, redeploy to StaticHost, and HTTPS preview finally matches local intent. There is a short trial (~1 day), not a forever-free tier; no cPanel, no email, no built-in CDN product.

Wednesday adds a custom domain. DNS is created exactly as the dashboard specifies; verification lags an hour; the certificate appears afterward. Someone asks whether email is included—you point them at a mail vendor and keep MX untouched. Preview HTTPS is available immediately; custom-domain certificates issue only after DNS verifies.

Thursday an engineer enables history-mode routing for a “cleaner URL.” Refresh on a nested path 404s. You revert to hash routing for the week’s deadline and schedule prerender work properly instead of inventing an nginx rewrite StaticHost will not apply. Plans: Starter $9 (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams).

Friday staging on Pro receives a build with staging API URLs baked via public env prefixes. Production stays on last week’s known-good deploy until Monday’s review. Rollback remains one click if marketing’s late copy drop breaks mobile layout. StaticHost serves prebuilt files via zip or GitHub and does not run npm, Hugo, or Jekyll remotely.

Deploy history supports rollback when a publish goes wrong.

That week is what lightweight high performance static hosting looks like when the host stays boring and the team respects file truth.

Worked measurement procedure on preview

Performance claims without numbers are décor. Use the HTTPS preview (and later the custom domain) like a lab bench:

1. Deploy the candidate dist/_site to StaticHost.
2. Chrome DevTools → Network → disable cache → throttle to “Fast 3G” or a realistic mobile profile.
3. Record transfer size for document, CSS, JS, fonts, and LCP image separately.
4. Compare against your soft budgets (for many brochure sites: lean HTML, modest JS, sized hero).
5. Fix the largest offender in source; rebuild; redeploy; measure again.
6. Keep the previous deploy available for rollback if the “optimized” build breaks layout.

Staging on Pro ($30, 3 sites, 10 GB) lets you A/B two builds without overwriting production. StaticHost will not minify for you and does not include a built-in CDN product—lean artifacts first; consider your own CDN only when measurements say geography dominates.

Failure table (perf work that backfires)

Anti-pattern reminder: uploading node_modules for “completeness” wastes storage against 2/10/30/100 GB caps and helps nobody. Trial ~1 day; Starter $9, Pro $30, Scale $65, Business $130; no forever-free, email, or cPanel. Companion: fast static site hosting.

Third-party script budget you can actually enforce

Before merge, list every third-party tag. Cap noncritical tags behind idle callbacks. If a tag cannot justify its kilobytes on a throttled preview run, it does not ship. StaticHost will faithfully serve a heavy homepage; faithfulness is not the same as performance. Your CI budget gates and your staging comparisons on Pro are the control surfaces—plan tiers ($9/$30/$65/$130) only change capacity.

FAQ

Does Business plan make sites lighter?

No. It adds capacity and teams. Lightness is your build.

Is static always high performance?

It removes server render cost; it does not stop you from shipping heavy clients.

Should I inline everything into one HTML file?

Sometimes for tiny pages; often hurts caching. Prefer reasoned splits.

Do I need HTTP/2 myths?

Modern HTTPS stacks already multiplex; still reduce request count for other reasons (compression dictionaries, parsing cost).

Can WordPress be “lightweight static”?

Only as an export snapshot. Live WP needs a PHP host.