About this article
This article is the first deep dive in the “Frontend Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering hosting.
On mobile, 53% of users abandon a load that takes 3+ seconds (Google study). Hosting design decides the floor of UX. The article covers CDN, static hosting, edge computing, cache strategy, image optimization, Core Web Vitals — landing on the two principles “Static First” and “Git push = production deploy.”
More articles in this category
“Visible within 3 seconds” decides half
How HTML / CSS / JS / images built by frontend get placed and delivered is hosting design. Where backend “runs logic on a server,” frontend “delivers many static files to users worldwide” — required traits differ entirely. Deciding “use a CDN,” “process at the edge,” “how to cache” is the work of shaving UX in milliseconds.
Design independent from backend. Delivery speed is UX itself.
Major hosting forms
Frontend hosting splits into five forms; selection changes by project scale and operational style. From personal sites to large-scale services, each has appropriate options.
| Form | Examples | Trait |
|---|---|---|
| Self-server delivery | Distribute via Nginx / Apache | Classical, controllable, heavy ops |
| Cloud static storage | S3 / GCS / Azure Blob | Cheap and durable, CDN integration assumed |
| CDN delivery | CloudFront / Cloudflare / Fastly | Fast delivery from worldwide edge |
| Platform | Vercel / Netlify / Cloudflare Pages | Auto-deploy via Git integration |
| Full-stack | Next.js + Vercel / Nuxt + NuxtHub | Framework and hosting unified |
The modern favorite is platform-type: just git push and the auto-build, deploy, and CDN delivery complete. For personal projects, free tiers are practically usable.
CDN basics
A CDN (Content Delivery Network) places content copies on edge servers distributed worldwide and delivers from the nearest edge to the user. Closer physical distance lowers communication latency, dramatically improving perceived speed.
flowchart LR
U1([User<br/>Tokyo]) -->|10ms| E1[Edge<br/>Tokyo]
U2([User<br/>NY]) -->|10ms| E2[Edge<br/>NY]
U3([User<br/>Sydney]) -->|10ms| E3[Edge<br/>Sydney]
E1 -.|Cache miss only<br/>200ms| ORIG[(Origin<br/>S3 us-east-1)]
E2 -.| ORIG
E3 -.| ORIG
E1 -. Cache hit .- HIT1[Immediate]
E2 -. Cache hit .- HIT2[Immediate]
E3 -. Cache hit .- HIT3[Immediate]
classDef user fill:#fef3c7,stroke:#d97706;
classDef edge fill:#dbeafe,stroke:#2563eb;
classDef origin fill:#fee2e2,stroke:#dc2626;
classDef hit fill:#dcfce7,stroke:#16a34a;
class U1,U2,U3 user;
class E1,E2,E3 edge;
class ORIG origin;
class HIT1,HIT2,HIT3 hit;Tokyo users hitting US servers directly take 200+ms round trip; edge cache hits in Tokyo return in under 10ms. Beyond latency reduction, CDNs offer defensive effects: “reducing origin load” and “absorbing DDoS attacks.” They’re nearly required infrastructure for modern web services.
CDNs aren’t just “to be fast” but “to stay up.” Two-fold value.
Major CDN comparison
CDN products are competitive, each with strong points. CloudFront for AWS-centered systems; Cloudflare for free-tier and feature richness — modern standards.
| CDN | Trait |
|---|---|
| CloudFront | Full AWS integration, transparent pricing, simple S3 integration |
| Cloudflare | Wide free tier, rich edge features, strong DDoS protection |
| Fastly | High config flexibility; many media / e-commerce adoptions |
| Akamai | Enterprise default, strong in finance / government |
| Vercel Edge | Tightly coupled with Next.js, dev experience focused |
For personal-to-mid-scale, Cloudflare Pages / Vercel / Netlify; for AWS-centered, “CloudFront + S3” is the gold standard. Akamai-class is for large enterprises; no need at personal or small scale.
Cache strategy
For CDN, “how to manage caches” is the design crux. File types differ entirely in update frequency and acceptable staleness, so a uniform TTL can’t optimize.
| Target | Recommended strategy |
|---|---|
| HTML | Short-lived (minutes / no-cache) + ETag (content identifier triggering re-fetch only on change) |
| CSS / JS | Hashed filename + long cache (1 year) |
| Images | Long cache + CDN-side transformation |
| API responses | Cache-Control + Vary headers, individual control |
The decisive technique: filename hashing. Embedding content hash like main.abc123.js instead of main.js means filename changes when content changes — eliminating the “when to invalidate cache” worry.
main.abc123.js ← Content change = filename change
→ Long-term immutable possibleHTML short-lived, others long. Hashed filenames are the modern frontend’s default assumption.
Cache invalidation
The biggest CDN-operational theme: solving “users hold old caches at deploy.” Three methods exist; the conclusion: hashed filenames mostly solve it.
| Method | Trait |
|---|---|
| Hashed filenames | New URL automatic — no invalidation needed (default) |
| Explicit invalidation | Manual delete via CDN API; cost and propagation time |
| Short TTL | Disappears fast but cache efficiency drops |
CloudFront’s explicit invalidation is free for first 1000/month, but takes minutes to propagate worldwide and frequent issuance costs money. Hashed filenames let new URLs naturally cache-miss → fetch latest from origin, so invalidation itself is unnecessary. Modern build tools like Next.js / Vite / webpack ship this pattern by default.
Edge computing
Running code at CDN edges is edge computing. Traditionally CDNs were “just file delivery”; now lightweight processing runs at edges, enabling low-latency dynamic processing. A major trend in the late 2020s.
| Platform | Languages | Trait |
|---|---|---|
| Cloudflare Workers | JS / WASM (WebAssembly, browser/edge-runnable binary format) | V8 Isolate fast startup, Durable Objects |
| Vercel Edge Functions | JS / WASM | Tight Next.js Middleware integration |
| AWS Lambda@Edge | JS | CloudFront request modification |
| Deno Deploy | JS / TS | TypeScript-native, edge-first |
Strong areas: A/B test routing, auth pre-filters, country-based redirects, image transformation, lightweight APIs. Cold start is near-zero (ms-tens of ms), so suited for processing requiring real-time response — beyond traditional Lambda.
Edge: “light processing at low latency” is the optimum. Heavy processing remains origin-side.
Static vs dynamic delivery
Page delivery splits broadly into static and dynamic; the modern favorite is “Static First (static first, only required parts dynamic).”
| Delivery | Examples | Trait |
|---|---|---|
| Static (pre-rendered) | Astro / Next.js SSG / Jekyll | Fast, cheap, CDN-complete, outage-resilient |
| Dynamic (SSR) | Next.js SSR / Remix / Rails | Per-request, server required, latest data |
| ISR / OnDemand | Next.js / Gatsby | Periodic regeneration |
Static delivery puts all pages on CDN, so server outages don’t affect; delivery cost stays extremely low. Blog / docs / marketing sites: static is enough. SSR is needed for login-after screens with per-user content.
Design with Static First. Reasons to make everything dynamic are surprisingly few.
Domain, SSL, image optimization
When publishing under a custom domain, three pieces are needed: domain registration, DNS config, SSL certificate. Modern automation completes much of it in minutes.
| Item | Point |
|---|---|
| Custom domain | Route 53 / Cloudflare Registrar / OnamaeCom etc. |
| SSL certificate | Auto-issuance on the CDN side (Let’s Encrypt / ACM) |
| HTTP/2 / HTTP/3 | Auto-handled by CDN (no setup) |
| HSTS (HTTP Strict Transport Security) | Header forcing HTTPS (recommended) |
Modern hosting services (Vercel / Netlify / Cloudflare Pages) “auto-issue and renew SSL certificates” just by setting a custom domain. HTTPS is required (Chrome warns), and HTTP/3 support is essentially standard.
Image optimization
Images often take the biggest payload of a site. HTML is KBs but a single 2MB hero image is common; whether you optimize here changes display speed by seconds.
| Method | Substance |
|---|---|
| Next-generation formats | WebP / AVIF (half-to-third the size of JPEG) |
| Responsive images | srcset / Picture tag for screen-size delivery |
| Lazy loading | loading="lazy" attribute, off-screen deferred |
| CDN transformation | Cloudflare Images / imgix / Next/Image, etc. |
Next/Image and Astro’s <Image> auto-generate WebP / AVIF / multiple sizes / lazy load from one source image at build / request time. Using framework components beats hand-writing <img> tags decisively.
Image optimization directly affects LCP. Give up manual; rely on framework features.
Core Web Vitals
Core Web Vitals are Google’s perceived-speed metrics that directly affect SEO (search ranking). Aware of these three as frontend-design targets is the basic posture in modern web development.
| Metric | Meaning | Target |
|---|---|---|
| LCP (Largest Contentful Paint) | Time to largest content paint | < 2.5s |
| INP (Interaction to Next Paint) | Click responsiveness | < 200ms |
| CLS (Cumulative Layout Shift) | Layout-shift quantity | < 0.1 |
LCP improves via CDN, image optimization, initial-HTML size; INP improves via JS-execution reduction and main-thread freeing; CLS improves via specifying image / ad sizes upfront. Free measurement via Google PageSpeed Insights; regular checks help SEO.
Core Web Vitals numeric gates
Note: industry rates as of April 2026. Periodic refresh required.
Don’t aim at vague “fast site”; chase numerical targets — modern frontend operations. Google’s official thresholds are the industry standard.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | < 2.5s | 2.5-4.0s | > 4.0s |
| INP | < 200ms | 200-500ms | > 500ms |
| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
| TTFB | < 800ms | 800-1800ms | > 1800ms |
| JS bundle (after gzip) | < 170KB | 170-350KB | > 350KB |
| Image size (LCP image) | < 200KB | 200-500KB | > 500KB |
LCP 2.5s, CLS 0.1, INP 200ms tie directly to Google SEO judgment; “75% of page views in Good” is the criterion. PageSpeed Insights / Lighthouse / Search Console: “weekly measurement” and immediate response to drops — operational rule.
Bad Core Web Vitals drop search ranking. Embed measurement into operations.
”CDN means we’re safe” pitfall (industry case)
Cloudflare’s July 2019 large-scale outage is remembered as showing CDNs can themselves be SPOFs. A “single regular expression” deployed caused 100% CPU at all edges, affecting global traffic for ~30 minutes. The June 2021 Fastly outage (Amazon, GitHub, Reddit, NYTimes simultaneously down) was the same family — making “CDNs don’t fall” premise visibly invalid.
Stories of touching personal dashboards exactly during the Fastly outage and GitHub also dropping, taking minutes to grasp what was happening, are common. Rather than “we have CDN, so safe” thought-stoppage, designs include origin-direct fallback paths and incident-status-page operations — the shared lesson.
Multi-CDN (normally A, switch to B via DNS during outage) adoption is increasing among major media; sites pushing availability to extremes are heading toward “design that doesn’t trust CDNs too much.”
Hosting selection matrix
Optimal hosting configuration changes by project scale and requirements. Personal development and global large-scale deployment use entirely different stacks.
| Scale / requirement | Recommended |
|---|---|
| Personal blog / portfolio | Vercel / Netlify / Cloudflare Pages (free tier sufficient) |
| Mid-sized SaaS | CloudFront + S3 or Vercel Pro |
| Global large-scale | Fastly / Akamai + own origin (CDN tuning freedom) |
| Security-priority / internal | Private CDN / closed CDN |
This series’s host, senkohome.com, runs on “CloudFront + S3.” Vercel-family is easy, but for full self-management with “cost transparency”, hitting AWS directly is also practical.
Hosting operational traps
Common CDN/cache operational failures. All cause total site outage, stale content, billing explosion.
| Forbidden move | Why |
|---|---|
| Long-term cache HTML (max-age=31536000) | Old version persists after deploy; HTML short-lived (s-maxage=60) |
| Long cache without filename hashing | Invalidation needed per update; use build-tool auto-hashing |
| Relying on CDN invalidation | Worldwide propagation takes minutes, costs money. Solve via hashed filenames |
| Serving images at original size | Classic LCP killer. Use Next/Image, Astro Image, Cloudflare Images |
| Origin-direct without CDN | DDoS takes you down overnight. Cloudflare free tier is enough |
| No CDN-failure fallback | CDNs can be SPOFs, like 2019 Cloudflare and 2021 Fastly |
Casual Vary: User-Agent | Cache-hit rate plummets. CDN keys per User-Agent |
| Image without width/height | Direct CLS cause. Always specify fixed sizes |
| All-page SSR on Vercel / Netlify | Function-execution costs explode linearly. Static First |
| Manual FTP / SCP deploys instead of Git push | Kills AI-era productivity. Migrate to Git-integrated platforms |
CDNs don’t protect just by being installed. Settings and operation decide the value.
The AI-era lens
With AI-driven development as the assumption, hosting selection wins via “configuration AI can complete.” Git-integrated auto-deploy platforms (Vercel / Netlify / Cloudflare Pages) run from AI-generated code → push → deploy with near-zero human steps.
| AI-era favorable | AI-era unfavorable |
|---|---|
| Vercel / Netlify / Cloudflare Pages (Git-integrated) | Manual FTP, custom deploy scripts |
| Framework-tight (Next.js + Vercel, etc.) | Self-Nginx, manual SSL management |
| Edge functions (Cloudflare Workers, etc.) avoiding cold start | Traditional Lambda + CloudFront (start latency) |
| Hashed filenames + CDN standard config | Manual invalidation operation |
Frontend code AI generates often assumes “works just by pushing to Vercel/Netlify”; leaning on mainstream platforms harmonizes with AI. Edge computing has near-zero cold start, solving the FaaS-era latency worry; AI-generated code goes straight to production.
AI-era hosting: “Git push = production deploy” is the rule. Manual steps clash with AI.
Common misreadings
- “CDNs are for speed” -> The side effect of “DDoS absorption / origin-load reduction” matters more in many cases. Adopt as outage-resilience.
- “Long cache for HTML and CSS” -> Long-cached HTML produces persistent old-version hell. HTML short-lived, JS/CSS long is the rule.
- “Invalidation will handle it” -> Propagation takes minutes and costs money. Solve at the root via hashed filenames — modern style.
- “Optimize images later” -> Images are the largest payload, hitting LCP directly. Use framework features like Next/Image from the start.
What you must decide — what’s your project’s answer?
Articulate your project’s answer in 1-2 sentences for each:
- Origin (S3 / VPS / platform-type)
- CDN product (CloudFront / Cloudflare / Fastly, etc.)
- Cache TTL strategy (HTML short, static long)
- Custom domain and SSL automation
- Edge-computing scope of use
- Image-optimization policy (formats, CDN transformation)
- Core Web Vitals targets and measurement
How to make the final call
Hosting selection’s substance reduces to one point: “build CDN-first or origin-direct.” There’s almost no reason to operate a global public site without CDN. You get latency reduction, DDoS resilience, origin-load reduction, and SSL automation in one stroke.
Further, “Static First” (build static first, dynamicize only required parts via SSR / ISR / edge functions) is the favorite; all-page SSR is over-engineered. Locking down the “hashed filenames + long cache + HTML short” triple-set ends the cache-invalidation worry.
The decisive axis: lean toward “Git push = production deploy” configuration. Git-integrated platforms (Vercel / Netlify / Cloudflare Pages) auto-build, deploy, and CDN-deliver from a single push.
Manual FTP, self-Nginx, manual SSL clash with AI-driven development and increase human steps. For personal-to-mid-scale, Vercel / Netlify / Cloudflare Pages free tier is enough; for AWS-asset-leveraged mid-large scale, “CloudFront + S3 is the gold standard.” Either way, building “code is delivered when pushed” is the modern hosting starting point.
Selection priority:
- CDN-first design (latency, DDoS, load distribution trinity).
- Static First (all-SSR is over-engineering).
- Hashed filenames + long cache (drop invalidation reliance).
- Git push = production deploy (AI-driven assumption).
Summary
This article covered hosting — CDN, cache strategy, edge, Core Web Vitals.
CDN-first, Static First, hashed filenames, Git push = production deploy. Locking these four down makes delivery fast, robust, and lightweight in operations.
The next article covers rendering methods (MPA / SPA / SSR / SSG / ISR).
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (31/89)