Choosing Hosting — CDN / Edge / Static First

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.”

What is hosting in the first place

Hosting is, roughly speaking, “the system for placing the files of your website or app and delivering them to users worldwide.”

Imagine a delivery network’s distribution hubs. If the warehouse (server) is in only one location like Tokyo, shipping to Hokkaido or Okinawa takes time. Placing relay hubs (CDN) across the country enables fast delivery from the nearest hub. Furthermore, “pre-stocking frequently ordered items at each hub” (caching) eliminates even the need to check with the main warehouse. Hosting design is the process of deciding how to build this delivery network.

Why hosting design matters

What happens if you neglect hosting design? On mobile, 53% of users abandon a load that takes 3+ seconds (Google study) — no matter how good the features and pages you’ve built, if delivery is slow, users won’t see them.

Deciding where to place and how to deliver HTML, CSS, JS, and images built by the frontend 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.

This domain should be designed independently from the backend. Delivery speed is UX itself.

”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.

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.

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.

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.

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 possible

HTML 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.

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.

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).”

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.

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.

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.

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.

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.

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.

CDNs don’t protect just by being installed. Settings and operation decide the value.

AI decision axes

1. CDN-first design (latency, DDoS, load distribution trinity)
2. Static First (all-SSR is over-engineering)
3. Hashed filenames + long cache (drop invalidation reliance)
4. Git push = production deploy (AI-driven assumption)

Git push = deploy is the premise of AI-driven development

With Git-integrated platforms like Vercel, Netlify, and Cloudflare Pages, pushing to main branch immediately becomes production deployment. The entire flow of AI generates code → creates PR → merges → auto-deploys runs without human intervention, maximizing deploy frequency in AI-driven development.

With manual FTP or custom deploy scripts, human manual operations sit between AI-written code and production deployment, creating a deploy bottleneck.

Edge functions and AI combination

Edge functions (Cloudflare Workers, Vercel Edge Functions) execute at CDN edge locations worldwide, achieving single-digit-ms latency. AI-generated API endpoints and middleware deployed to edge suit use cases like personalization, A/B testing, and geolocation routing where latency matters. The constrained runtime (no Node.js full API) actually helps AI write more focused, correct code.

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

Related Articles

https://en.senkohome.com/arch-intro-frontend-rendering/ https://en.senkohome.com/arch-intro-frontend-auth/ https://en.senkohome.com/arch-intro-frontend-bff/

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.