Fast static site hosting

Speed without inventing a CDN product

“Fast static hosting” marketing often slides into unverifiable global edge claims. StaticHost does not ship a built-in CDN product, and this guide will not fake benchmarks. Fast here means: small payloads, few round trips, correct caching fingerprints, and a host that serves files without application-layer drag.

Static sites already avoid per-request template rendering and database queries on the origin. That is the architectural win. Everything else is craft.

Measure before you mythologize

On the HTTPS preview:

1. Open DevTools Network, disable cache, reload.
2. Note document size, number of requests, largest asset.
3. Throttle to a mobile profile; watch LCP candidates (usually hero image or big font).
4. Fix the largest sane thing first.

Repeat after each deploy. Deploy history lets you roll back a “performance improvement” that made things worse.

Payload craft

• Compress images appropriately; prefer modern formats.
• Subset fonts; avoid loading unused weights.
• Minify at build (hugo --minify, Vite production build, etc.).
• Delete dead CSS/JS.
• Do not upload source maps to production unless debugging.

Build on your machine—StaticHost will not run minifiers for you.

Request craft

• Inline a tiny critical CSS only when you understand the trade.
• Avoid chain-blocking third-party scripts on first paint.
• Combine sensibly via your bundler rather than twenty hand tags—but do not create a megabyte monolith either.
• Prefer root-relative asset URLs that 200 on first try; 404 cascades feel “slow.”

Wrong zip nesting causes HTML without CSS—perceived performance zero—zip guide.

Caching craft

Fingerprinted assets (app.1a2b3c.js) can be cached long; HTML should revalidate more eagerly so new deploys appear. Bundlers do fingerprinting when you run production builds (Vite, webpack, etc.). Hand-written app.js may need manual cache busting query strings.

Routing craft

SPA history mode that 404s on deep links feels broken, not slow. Fix architecture—SPA—before hiring a performance consultant.

What StaticHost contributes

• Static file serving (no PHP/app bootstrap tax on the origin).
• HTTPS preview for realistic testing.
• Rollback when an optimization deploy fails.
• Predictable plans: Starter $9 (1×2 GB), Pro $30 (3×10 GB + staging), Scale $65 (10×30 GB), Business $130 (30×100 GB + teams). Trial ~1 day.

What it does not contribute: a marketed global CDN tier, edge workers, or fake “50 ms worldwide” charts. If your audience is truly global and TTFT from one origin is insufficient after assets are lean, evaluate adding a CDN you control in front—or a different platform. Until measurements demand it, craft beats mythology. Companion philosophy: lightweight high-performance.

Staging performance budgets

On Pro staging, run Lighthouse against staging builds with production-like asset sizes (not localhost). Bake VITE_ API hosts that do not point at glacial VPN-only staging APIs if you care about field numbers.

Worked example: cutting LCP on a marketing rebuild

Baseline on HTTPS preview (mobile throttle): LCP 4.8s, hero hero.png at 3.2 MB, two font weights at 180 KB each, main JS 420 KB uncompressed-looking transfer because you uploaded a dev build.

Actions, one deploy at a time:

1. Re-export hero to hero.webp at 1600px wide (~160 KB). Redeploy. Re-measure.
2. Subset to one font weight; self-host the file on StaticHost instead of three Google Fonts round trips. Redeploy.
3. Run npm run build (production) locally—StaticHost will not do this—and upload dist with fingerprinted, minified assets. Confirm you did not ship node_modules.
4. Defer the analytics snippet until window.load.
5. If a “performance” PR accidentally breaks CSS paths, roll back from deploy history immediately; speed work that blanks the page is not an improvement.

You never needed a CDN SKU to recover most of that LCP. You needed honesty about payload and build mode. Plans still do not include a built-in CDN product at $9, $30, $65, or $130—and that is fine until data says otherwise.

Failure table: “slow site” tickets that are not the network

Extra procedure: a 20-minute performance pass before every major launch

1. Deploy candidate to HTTPS preview (or Pro staging).
2. Cold-load with cache disabled; export Network HAR mentally—note top three bytes offenders.
3. Confirm all first-party assets return 200 (404 chains destroy “fast”).
4. Throttle mobile; record LCP element; optimize that asset first.
5. Grep for http:// so mixed content does not disable features on the eventual HTTPS custom domain—SSL guide.
6. If you use a client router, hard-refresh a nested route; fix routing before debating TTFT.
7. Keep the previous deploy as rollback insurance.
8. Only after the pass, attach or advertise the custom domain (DNS verify → cert).

No forever-free tier after the short trial; paying $9 for Starter does not magically minify your images. Paying $130 for Business buys sites, storage, and teams—not an automatic global edge. When you eventually need a CDN, put one you understand in front of origin files rather than pretending the plan table hid one.

Related shopping context: where to host, pricing.

Third parties and the illusion of origin speed

A perfectly lean StaticHost origin still waits on slow tag managers, chat widgets, and A/B scripts. Measure with third parties disabled once to see your true baseline, then add them back one at a time. If LCP is dominated by a marketing pixel, upgrading from Starter ($9) to Business ($130) will not help—those tiers do not include a CDN product and do not remove third-party RTT.

Prefer sending analytics after idle callbacks, and avoid injecting multiple competing video players. When a stakeholder insists on three chat tools, show the Network waterfall on HTTPS preview; evidence beats opinion. Rollback remains your friend when a “harmless” tag tanks interaction time. Craft first, optional external CDN later, plans sized for sites and storage—not for magical latency SKUs.

FAQ

Is static always faster than WordPress?

Often for brochure pages, because you removed PHP and DB from the hot path. A bloated static bundle can still lose to a lean WP page. Measure.

Does HTTPS slow me down?

TLS is negligible compared to multi-megabyte heroes. Use HTTPS—SSL guide.

Will upgrading from Starter to Business make pages faster?

Not magically. Higher plans add sites/storage/teams, not an automatic CDN.

Should I enable every Vite compression plugin?

Prefer defaults that emit compressed-friendly assets; confirm actual transfer sizes in Network.

Can poor DNS TTLs feel like slowness?

On first resolve yes; afterward caching dominates. Still fix DNS correctly—custom domain.