{"id":1174,"slug":"default-web-stack","title":"Default web stack (Astro on Cloudflare)","kind":"reference","scope":"marketing-site","status":"current","audiences":["kevin","claude-code","smb-owner","candid-team"],"topics":["tech-stack","framework-choice","hosting-platforms"],"reference_body":"## Overview\n\nThe default web stack at Candid Creative for new marketing-site, knowledge-base, docs-site, and local-service-business engagements in 2026 is **Astro 5/6 + Tailwind v4 deployed on Cloudflare Pages/Workers**, with headless WordPress (WPGraphQL) as an optional authoring layer for content-heavy SEO-critical clients. The starter template includes View Transitions, Speculation Rules, Cloudflare Images bindings, and a `web-vitals` RUM snippet pointed at a Worker endpoint. This page consolidates the framework choice, hosting choice, performance posture, image pipeline, third-party-script discipline, CMS decision matrix, data-layer guidance, and the honest read on AI-assisted developer productivity that informs the stack's default settings.\n\nThe stack is a *default*, not a mandate. Flip rules are documented in writing rather than assumed: Next.js 16 + Vercel only for actual apps (auth, dashboards, complex mutations) or when a logged-in dashboard sits in the same codebase; SvelteKit 2 + Svelte 5 only when the team has existing Svelte fluency; headless WordPress + Next.js only when the editor team explicitly requires the Gutenberg experience and the cost premium is accepted in writing. The strategic rationale, the field measurements, and the rules below explain why the default lands where it does and where the boundaries are.\n\nSee [[research-brief-2026-build-standards]] for the source research brief that informs this page, [[astro-cloudflare-pages-zero-cost-vs-nextjs]] for the cost comparison kept as a standalone entry, and [[astro-vs-nextjs-40pct-faster-90pct-less-js]] for the framework-level performance comparison.\n\n## Astro 6 stable, March 2026\n\nAstro 6.0 released stable in March 2026. Major changes vs Astro 5: removed legacy `getEntryBySlug`, `getDataEntryById`, `Astro.glob`, and `Astro.canonicalURL` APIs. The release tightens around the v5 Content Layer model.\n\n**Source:** astro.build/blog/ (Astro 6 release notes). **Confidence:** Verified.\n\n**Migration implication:** Astro 5 sites built before March 2026 may still use the legacy APIs and will need a one-pass refactor when upgrading. Astro 5 remains a reasonable conservative default until Q3 2026 if minimizing risk on a specific client engagement is the priority. New greenfield work scoped from mid-2026 onward should start on Astro 6 directly.\n\n## Astro on Cloudflare Pages: the zero-cost default vs Next.js\n\nThe comparison of Astro + Cloudflare Pages vs Next.js + Vercel for an SMB marketing site lives as a standalone entry — see [[astro-cloudflare-pages-zero-cost-vs-nextjs]] — because the cost and practitioner-satisfaction numbers are referenced in client proposals separately. The short read carried into this default-stack page: Astro on Cloudflare Pages is roughly $0/month at SMB volumes versus $20-200/month for Next.js SSR, and State of JS 2025 placed Astro 39 satisfaction points ahead of Next.js among practitioners.\n\nThe framework-level performance gap is also a standalone — see [[astro-vs-nextjs-40pct-faster-90pct-less-js]] — and is the cleanest data point for the \"Astro ships ~90% less JavaScript than equivalent Next.js builds for content sites\" argument that anchors the default.\n\n## Astro vs Next.js: CWV evidence Next.js can be the wrong default\n\nPer the 2024 Web Almanac Performance chapter, Fig. 9.3:\n\n> \"Several technologies were significantly impacted, including a 19% drop for 1C-Bitrix, a 10% drop for Next.js (a React-based framework), and an 8% drop for Emotion (a CSS-in-JS tool).\"\n\nThe 10-percentage-point drop refers to Next.js's Core Web Vitals pass rate when First Input Delay (FID) was replaced by Interaction to Next Paint (INP) in March 2024. **Confidence:** Verified.\n\n**Implication:** \"Modern stack\" is not synonymous with \"fast.\" Client-side React without disciplined SSR/SSG is one of the few cohorts moving the wrong direction on Core Web Vitals. When arguing for Astro over Next.js for marketing sites, this is the cleanest framework-level data point. Astro's 2023 Web Framework Performance Report had Astro as the only framework exceeding 50% CWV pass — see [[astro-vs-nextjs-40pct-faster-90pct-less-js]]. Next.js sat *at the bottom of the pack* with roughly 1-in-4 pass rates.\n\nThis is the empirical reason the default is Astro for content work, even when the team is fluent in React.\n\n## Edge vs origin: Cloudflare default for SMB, with explicit flip conditions\n\nFor sub-100k pageviews/month SMB sites — the bulk of Candid Creative work — Cloudflare Pages + Workers is the default. The flip conditions are narrow and named.\n\n**Latency math for a KW SMB serving primarily Ontario traffic:**\n\n- Cloudflare PoP in Toronto → user: 5-15 ms.\n- Vercel iad1 (Virginia) → Ontario user: 25-40 ms.\n- Single origin in Toronto VPS → Ontario user: 5-15 ms.\n- Single origin in Toronto → user in BC or NY: 60-100 ms.\n\nFor 95%-local-traffic, the pure latency case for edge is weak. The case for Cloudflare is broader:\n\n1. Global CDN for static assets (every option provides this).\n2. Sub-5 ms V8 isolate cold starts for SSR/dynamic logic vs container-based serverless at 250 ms+.\n3. Predictable pricing model that beats Vercel by ~5-10× at SMB volumes.\n4. Free tier that genuinely covers SMB volumes.\n5. DNS + CDN + edge compute + image optimization in one console.\n\n**When to flip to Vercel:** the client requires it (existing relationship, agency contract); the project is a Next.js app needing zero-config ISR/Image/PPR; the team has Vercel-specific tooling expertise.\n\n**When to flip to a Toronto VPS:** the project needs PostgreSQL with real connection pooling (not HTTP-driver only). Alternative: Neon/Supabase serverless Postgres with Cloudflare as the front door.\n\n## Next.js 16 (October 2025): Cache Components and dynamic-by-default\n\nNext.js 16 (released October 2025) shipped a meaningful semantic change worth tracking even when Next.js is not the default stack.\n\n- **Cache Components / PPR** is now the default story: everything is dynamic by default, caching is opt-in via the `\"use cache\"` directive with `cacheLife` / `cacheTag`.\n- **Turbopack** is the default dev bundler (production builds still in beta).\n- **middleware.ts** renamed to **proxy.ts**.\n- **React Compiler 1.0** stable opt-in (not enabled by default).\n\n**Source:** nextjs.org/blog/next-16. **Confidence:** Verified.\n\n**Migration implication:** Migrating from Next.js 14/15 to 16 requires a deliberate audit, not an `npm upgrade`. RSC footguns persist — client/server boundary placement, cookie handling on server fetches, waterfall fetches inside Server Components.\n\n**For Candid:** Next.js 16 is not the default for marketing sites. Cache Components solves problems most SMB sites don't have, and \"everything dynamic by default\" adds cognitive load for brochure work. The flip rule to Next.js still applies when the project is an actual app — see the rules section below.\n\n## React Compiler 1.0 stable, October 7, 2025\n\nReact Compiler 1.0 released stable on October 7, 2025.\n\n**Verbatim (react.dev):**\n\n> \"We are releasing the compiler's first stable release today... The compiler has been battle tested on major apps at Meta and is fully production-ready.\"\n\n**Next.js 16 integration (nextjs.org/blog/next-16):**\n\n> \"promoted from experimental to stable. It is not enabled by default as we continue gathering build performance data.\"\n\n**Confidence:** Verified.\n\n**Application:** for React-heavy apps, enable on a branch, measure build time, then ship. For Astro sites with minimal client-side React, irrelevant. The compiler does not change the default-stack decision; it adjusts what to enable when Next.js *is* chosen.\n\n## Speculation Rules: `eagerness: \"moderate\"` as 2026 default\n\nSpeculation Rules with `eagerness: \"moderate\"` is the 2026 default for instant navigation. Per Arjen Karel's CoreDash field data (corewebvitals.io):\n\n> \"Across sites monitored by CoreDash, prerendered navigations have a p75 LCP of 320ms compared to 1,800ms for standard navigations on the same sites. That is an 82% improvement from a single API.\"\n\n**Confidence:** Moderate-to-high — single-source field measurement, but mechanism is well-understood and corroborated by Google Chrome team posts.\n\n**Browser support:** Chrome / Edge / Opera stable; Safari 26.2 behind a flag; Firefox positive standards position, not shipped. Covers ~70% of global traffic.\n\n**Default JSON:**\n\n```json\n{ \"prerender\": [{ \"where\": { \"href_matches\": \"/*\" }, \"eagerness\": \"moderate\" }] }\n```\n\n`moderate` prerenders on hover (desktop) or 50 ms after a link enters the viewport (mobile, per Chrome 144 from January 2026).\n\n**Risk mitigations:**\n\n- Use `moderate`, not `immediate`, on most sites.\n- Exclude logout / cart-mutation / admin URLs explicitly.\n- Use the new (Chrome 144, January 2026) **prerender-until-script** option for pages with analytics that fire on render — fetches HTML, begins rendering, but pauses JS at the first blocking script tag.\n- **Never use GET requests for state-mutating actions** (this is true regardless of Speculation Rules, but they make the lapse exploitable in seconds).\n\n## GTM with 18 tags: ~20× TBT, per Chrome Aurora\n\nPer the Chrome Aurora team via corewebvitals.io, a Google Tag Manager container with **18 tags** increases Total Blocking Time nearly **20×** vs a baseline page.\n\n**Confidence:** Industry-consensus.\n\n**Implication:** The single largest avoidable INP cost is **third-party JavaScript through tag managers**. Most SMB sites pick up 8-15 tags over a 2-3 year period (GA, ads pixels, chat, A/B, heatmaps, retargeting, conversion tracking) without ever auditing the cumulative cost.\n\nOperational pattern: **defer/delay 3rd-party scripts until interaction** via `@next/third-parties` or Partytown (web worker); quarterly tag audit; one-tag-in, one-out rule.\n\n## Image pipeline: AVIF source, WebP fallback, JPEG last\n\nThe standard image pipeline on every Candid build:\n\n- Source format: **AVIF** (Q ~50-60) for hero/photography, **WebP** for everything else, JPEG fallback.\n- `<picture>` element with type negotiation, AVIF source first. AVIF is ~50% smaller than JPEG, ~20-30% smaller than WebP per Cloudinary/Smashing measurements; ~85-90% global browser support per Caniuse.\n- `fetchpriority=\"high\"` on **the** LCP image only — at most one per page; multiple cancel out the benefit.\n- `loading=\"lazy\"` below the fold, `loading=\"eager\"` for the first 3-6 images.\n- **Explicit `width` and `height` always** (kills CLS).\n- `Vary: Accept` header configured correctly at the CDN.\n\n**CDN choice (in order of preference):**\n\n1. **Cloudflare Polish / Cloudflare Images** — default for Cloudflare-hosted sites; bundled, edge-optimized, no egress fees.\n2. **Sharp + Astro Image Service** — works everywhere, build-time, no runtime cost. Good for static-output Astro.\n3. **Next.js `<Image>`** — fine if you're on Vercel, expensive if you're not (Vercel charges per source image). Don't use on non-Vercel hosts unless you've measured the cost.\n4. **Cloudinary / imgix** — only if the client already has a contract.\n\n**Build gate:** pre-commit hook or CI step that fails on raw JPEGs over 200 KB.\n\n### WebP compression evidence (Google study)\n\nPer Google's WebP Compression Study (updated August 7, 2025), **WebP is 25-34% smaller than JPEG** at equivalent SSIM index. Google's own FAQ summarises this as *\"an average of 30% more compression than JPEG.\"*\n\n**Source:** <https://developers.google.com/speed/webp/docs/webp_study>. **Confidence:** Verified (Google primary).\n\n**Practical implication:** Modern image formats (WebP, AVIF) are the lowest-effort, highest-yield CWV improvement available. AVIF is even better than WebP for some image classes (20-50% smaller than JPEG depending on content). Use `<picture>` with AVIF + WebP + JPEG fallback for broad browser support.\n\n## CMS workflow decision matrix\n\nThe decision framework Candid uses for picking a CMS during migration:\n\n| Client profile | Recommendation | Why |\n|---|---|---|\n| Edits weekly+, multiple editors, needs visual preview, non-technical | **Sanity (Presentation tool)** or **Storyblok (Visual Editor)** | Hosted, real-time collaboration, click-to-edit preview, no Git literacy required |\n| Edits monthly, single editor, comfortable with forms (not Word) | **Keystatic** (Astro/Next.js) | Git-based, no database, no SaaS bill, schema-as-TypeScript |\n| Weekly+ but team has engineers / dev on staff | **Markdown in Git, no CMS** | Maximum portability; PR review = editorial workflow |\n| Structured content reused across web + email + native app | **Sanity (only)** | Content Lake, GROQ queries, true headless |\n| Wants to keep the WordPress editor experience | **Headless WordPress + Next.js** | Preserves editor muscle memory; doubles infrastructure cost |\n| Daily editors, large team, complex publishing workflow | **Stay on WordPress** | Migration is the wrong project for this profile |\n\n**What non-technical clients actually need vs think they need:**\n\n- They *think* they need: Gutenberg-equivalent visual builder for every page.\n- They *actually* need: write blog posts, swap a hero image, edit a phone number, add a team member. All trivially handled by any modern CMS with a forms-based UI.\n- They *fear losing*: live preview. Real fear. Sanity Presentation, Storyblok Visual Editor, TinaCMS, and Payload Live Preview all solve it; Keystatic and Decap don't.\n- They *will reject*: any workflow involving Git, branches, or pull requests. Even Decap (technically Git-backed UI) confuses clients with the \"draft\" vs \"merged\" states.\n\n**FatLab's honest framing:**\n\n> \"This is the complaint we hear most often from clients who inherited headless systems. Staff publish something, and it doesn't show up on the website. They learn they need to 'trigger a build,' 'clear the cache,' or wait for the deployment cycle to complete.\"\n\n**Real adoption note:** no reliable cross-agency survey exists on how often SMB clients edit post-launch. Anecdotally, modal SMB site goes 60-90 days between edits. Argument **for** simpler CMS (Keystatic) rather than paying Sanity seat fees the client won't exercise.\n\n## Data layer: avoid Astro DB / Astro Studio as a strategic bet\n\nAstro Studio (the hosted DB platform) was wound down in late 2024; existing databases were deleted on or after March 1, 2025. Astro DB the framework component still works and connects to libSQL/Turso, but the lack of a clear first-party hosting story makes it a weak bet for client engagements. Known gotcha: local data is reset on every production build (GitHub issue #13115, January 2025).\n\n**Defaults for SMB sites needing a database:**\n\n- **Cloudflare D1** for small SQLite workloads, low write volume (likes, view counts, form submissions).\n- **Neon Postgres** for anything more complex; pairs with pgvector for RAG.\n- **Supabase** if the client wants a managed admin UI included.\n\n## MotherDuck pricing changes 2026 (analytics layer note)\n\nMotherDuck's free tier supports 10 GB storage and 10 compute hours/month. The **Business plan moved from $100 to $250/month** between December 2025 and February 2026; the **Lite $25/month tier was removed** in the same change.\n\n**Source:** <https://layerbase.com/blog/motherduck-pricing-changes-2026>.\n\n**Confidence:** Verified by independent technical blogs (Layerbase, Tasrie IT Services). **Single-source caveat:** MotherDuck did not announce the change publicly — verify against the live pricing page before any client deliverable that relies on this figure.\n\n**Companion case study (Gardyn):** Daily analytics pipeline went from >24 hours to under 1 hour after migrating to MotherDuck — a **24× performance improvement at 10× lower cost** than alternatives evaluated. <https://motherduck.com/learn/reduce-cloud-data-warehouse-costs-duckdb-motherduck/>.\n\n**Strategic read:** The cheap-managed-OLAP window may be closing. **For SMBs scaling past the free tier, self-hosted DuckDB + Parquet on S3/B2 is now the more durable architecture.** This sits adjacent to the marketing-site stack but is part of the broader 2026 build standards Candid carries into client conversations about analytics.\n\n## AI-assisted developer productivity: the honest 2026 ceiling\n\nThe stack defaults assume the team uses AI assistance, so the honest read on productivity matters. Published evidence ranges from 21-28% speedup to 19% slowdown depending on workload and developer fluency.\n\n**Published research range — three primary sources:**\n\n- **GovTech Singapore GitHub Copilot study (arXiv:2409.17434):** *\"coding/tasks speed increased by 21-28%\"*.\n- **Longitudinal arXiv:2509.19708 (100+ developers):** *\"approximately 30-40% of code shipped to production through this tool accounts for overall 28% increase in code shipment volume\"*.\n- **METR 2025 RCT (arXiv:2507.09089, n=16 experienced OSS developers):** *\"allowing AI actually increases completion time by 19%—AI tooling slowed developers down,\"* despite developers forecasting a 24% reduction.\n\n**Confidence:** Moderate. The field is moving fast and results are workload-dependent.\n\n**Translation:**\n\n- Fluent users with skill-library discipline → meaningful (20-30%) lifts.\n- Naive power-users on unfamiliar codebases → can be slower than baseline.\n- Honest ceiling for a 2-person Candid Creative shop: **ship 1.3-1.7× the marketing-site work a 2024-equivalent shop could** once the team is fluent.\n- **Cap is set by client communication, discovery, and design — not coding.**\n\n**Where AI benefits most (high confidence):**\n\n- Greenfield Astro/Tailwind scaffolding.\n- Boilerplate refactors (renaming, type-narrowing, API client updates).\n- Framework migrations (Tailwind v3→v4, Astro 4→5→6, Next.js 14→15→16).\n- Writing tests for existing code.\n- One-off scripts and CMS schemas.\n\n**Where it benefits least (moderate confidence):**\n\n- Performance optimization (requires human judgment about what to measure).\n- Accessibility decisions.\n- Information architecture and content strategy.\n- Anything requiring institutional/client context the model doesn't have.\n\n**Push back on hype:** \"Vibe coding\" entire production marketing sites without review produces fragile code. The shops that win in 2026 use AI to accelerate the boring and keep humans on the judgment.\n\n## Rules carried by the default stack\n\nThe following rules are the operational expression of the stack. They are documented in writing, applied at engagement scoping, and enforced in CI where possible.\n\n### R1. Default stack is Astro 5/6 + Tailwind v4 on Cloudflare Pages\n\nEvery new Candid Creative engagement for a marketing site, knowledge-base, docs site, or local-service business site starts with Astro 5/6 + Tailwind v4 deployed on Cloudflare Pages/Workers. The starter template includes View Transitions, Speculation Rules, Cloudflare Images bindings, and a `web-vitals` RUM snippet pointed at a Worker endpoint.\n\n**Flip rules (documented in writing, not assumed):**\n\n- Flip to **Next.js 16 + Vercel** only when the project is an actual app (auth, dashboards, complex mutations) or the client also wants a logged-in dashboard in the same codebase.\n- Flip to **SvelteKit 2 + Svelte 5** only when the team has existing Svelte fluency.\n- Flip to **headless WordPress + Next.js** only when the editor team explicitly requires the Gutenberg experience and the cost premium is accepted in writing.\n\n**Why:** Astro ships dramatically less JavaScript than equivalent Next.js builds for content sites; Cloudflare's January 16, 2026 acquisition of The Astro Technology Company secured a sustainable steward; Cloudflare Pages + Workers gives sub-5 ms V8 isolate cold starts versus container-based serverless at 250 ms+. See [[astro-cloudflare-pages-zero-cost-vs-nextjs]].\n\n**How to apply:** When scoping a new engagement, the default proposal cites this stack. The Migration Audit deliverable recommends this stack unless one of the flip conditions is in writing.\n\n### R2. For content-heavy SEO/AI-critical clients (~$10k+ budget), default is headless WordPress + Astro on Cloudflare Pages\n\nFor Candid Creative clients in the **content-heavy, SEO-critical, AI-citation-sensitive** tier (typically $10k+ budget — Use Case C), the default proposal is **headless WordPress (WPGraphQL) + Astro on Cloudflare Pages**, not WordPress + page builder, not Next.js SSR.\n\n**Why:**\n\n- Performance: Astro ships ~90% less JS than Next.js for static content — see [[astro-vs-nextjs-40pct-faster-90pct-less-js]].\n- Cost: ~$0/month on Cloudflare Pages vs $20-200/month for Next.js SSR — see [[astro-cloudflare-pages-zero-cost-vs-nextjs]].\n- SMB migration: $1.5k-$5k from WordPress to Astro; ongoing $700-2,100/yr → <$200/yr (Web Aloha agency).\n- AI extractability: pre-rendered HTML, server-render-first, no JS hydration needed for content reads.\n- Practitioner satisfaction: State of JS 2025 — Astro 39-point satisfaction lead over Next.js — see [[astro-cloudflare-pages-zero-cost-vs-nextjs]].\n\n**How to apply:**\n\n- For Use Case C clients (content-heavy, SEO-critical, AI-sensitive): lead the proposal with Astro headless. The page-builder + WordPress comparison is presented as \"the old way.\"\n- Use Case D (web app, authenticated flows): Next.js is still right — Astro is for content sites.\n- Document the build hours and case-study results before quoting the same approach to Client #2.\n- WordPress remains the authoring layer (clients edit in wp-admin); Astro renders the public site.\n\n### R3. Defer or delay every third-party script until user interaction\n\nEvery third-party script on a Candid Creative client site is **deferred or delayed until first user interaction**, except those genuinely required for first paint (which should be rare). Default loading strategy: `strategy=\"lazyOnload\"` (Next.js) or Partytown / web-worker isolation.\n\n**Why:** Third-party JavaScript is the single largest avoidable INP cost. A GTM container with 18 tags increases TBT ~20×. Most SMB sites accumulate 8-15 third-party scripts over 2-3 years without auditing the cumulative cost.\n\n**How to apply:**\n\n- Inventory third-party scripts at engagement onboarding; rank by ROI.\n- For Next.js: `next/script` with `strategy=\"lazyOnload\"` for analytics, chat, A/B testing, heatmaps.\n- For others: Partytown to move 3rd-party JS to a web worker.\n- Anti-flicker holds on A/B testing tools (Optimizely, VWO) cost both LCP and INP — re-evaluate quarterly whether the test is worth the perf penalty.\n- Chat widgets (Intercom, Drift, HubSpot): only load on click of a chat trigger, never on page load.\n- One-script-in, one-out rule: net script count never grows without explicit justification.\n\n### R4. Performance budgets enforced in CI\n\nEvery Candid Creative client site ships with a **performance budget enforced in CI**. Lighthouse CI or DebugBear GitHub integration runs on every PR. Build fails if any budget threshold is exceeded. **Documented budgets without CI enforcement do not work** — they are wishlists.\n\n**Why:** A site can pass CWV at launch and regress within six months as content, plugins, and tags accumulate. The default arc of any maintained website is heavier next year than this year (Web Almanac 2025: +7.8% median weight YoY). Without CI enforcement, every \"small\" change ratchets the budget; six months later, LCP has crossed 2.5 s and nobody noticed.\n\nThe pattern was popularised by Tim Kadlec and Brad Frost. The 2025 Web Almanac confirms what they have been saying for a decade: **discipline at the CI layer is the only durable defense against compounding bloat.**\n\n**How to apply:**\n\n- Use the 2026 performance-budget targets as the default.\n- Tools: Lighthouse CI (free) for build-time enforcement; DebugBear or SpeedCurve for field-data monitoring.\n- Build fails on budget violation — no overrides without explicit waiver in the PR.\n- Quarterly budget review: tighten where slack exists; document why if any threshold is loosened.\n\n### R5. LCP image gets explicit dimensions + `fetchpriority=\"high\"` + no lazy-loading\n\nEvery Candid Creative client page identifies its **LCP element** (typically the hero image) and ensures:\n\n1. Explicit `width` and `height` attributes (prevents CLS).\n2. **`fetchpriority=\"high\"`** attribute (raises Chrome's preload-scanner priority).\n3. **No `loading=\"lazy\"`** (lazy-loading the LCP image is the #2 cause of LCP failure).\n4. Modern format (WebP or AVIF).\n5. Proper `srcset` / `sizes` for responsive serving.\n6. **NOT hidden from preload scanner** — never `data-src`, never CSS background-image, never JS-injected URL.\n\n**Why:** The single largest cause of LCP failure is hero-image mishandling. Google's own test on Google Flights showed `fetchpriority=\"high\"` alone moved LCP from 2.6 s to 1.9 s. Web Almanac 2025: **7% of sites still hide their LCP image from the preload scanner entirely.**\n\n**How to apply:**\n\n- Use Next.js `<Image priority>` on the hero (which sets `fetchpriority=\"high\"` and disables lazy-loading).\n- For non-Next.js sites: hand-coded `<img>` with all six properties.\n- Verify with WebPageTest filmstrip: the hero image should be in the first batch of requests, before any third-party scripts.\n- Re-check after any plugin or theme update — defaults change.\n\n### R6. Do not recommend Astro DB / Astro Studio as a strategic platform bet\n\nAstro Studio (the hosted DB platform) was wound down in late 2024; existing databases were deleted on or after March 1, 2025. Astro DB the framework component still works and connects to libSQL/Turso, but the lack of a clear first-party hosting story makes it a weak bet for client engagements. Known gotcha: local data is reset on every production build (GitHub issue #13115, January 2025).\n\n**How to apply:** for SMB sites needing a database, default to:\n\n- **Cloudflare D1** for small SQLite workloads, low write volume (likes, view counts, form submissions).\n- **Neon Postgres** for anything more complex; pairs with pgvector for RAG.\n- **Supabase** if the client wants a managed admin UI included.\n\n## Sources and confidence\n\n- **Astro 6 stable, March 2026** — astro.build/blog/ (Astro 6 release notes). Verified.\n- **Astro on Cloudflare Pages vs Next.js cost/satisfaction** — standalone entry [[astro-cloudflare-pages-zero-cost-vs-nextjs]]; State of JS 2025 + agency cost benchmarks.\n- **Astro vs Next.js performance gap** — standalone entry [[astro-vs-nextjs-40pct-faster-90pct-less-js]]; Astro 2023 Web Framework Performance Report.\n- **Next.js 10-point CWV drop on FID → INP transition** — 2024 Web Almanac Performance chapter, Fig. 9.3. Verified.\n- **Edge vs origin latency math; Cloudflare default for SMB** — practitioner field measurements; internal latency baselines for KW/Ontario SMB traffic.\n- **Next.js 16 (Cache Components, Turbopack, proxy.ts, React Compiler 1.0 opt-in)** — nextjs.org/blog/next-16. Verified.\n- **React Compiler 1.0 stable, October 7, 2025** — react.dev release post; quoted verbatim. Verified.\n- **Speculation Rules `eagerness: \"moderate\"` 82% p75 LCP improvement** — Arjen Karel, CoreDash field data via corewebvitals.io. Moderate-to-high (single-source field measurement, mechanism well-understood, corroborated by Chrome team posts). Browser support: Chrome / Edge / Opera stable; Safari 26.2 behind a flag; Firefox positive standards position, not shipped. ~70% of global traffic.\n- **GTM with 18 tags increases TBT ~20×** — Chrome Aurora team via corewebvitals.io. Industry-consensus.\n- **Image pipeline AVIF + WebP + JPEG, fetchpriority on LCP only** — Cloudinary/Smashing AVIF compression measurements; Caniuse browser support; standard 2026 Candid build pattern.\n- **WebP is 25-34% smaller than JPEG at equivalent SSIM (avg ~30%)** — Google WebP Compression Study, updated August 7, 2025. <https://developers.google.com/speed/webp/docs/webp_study>. Verified (Google primary).\n- **CMS workflow decision matrix; FatLab quote on headless publishing friction** — internal framework; FatLab quoted verbatim. No reliable cross-agency survey on SMB post-launch edit cadence; anecdotal 60-90 days between edits.\n- **Astro DB / Astro Studio wind-down (late 2024; data deleted on/after March 1, 2025); GitHub issue #13115 local-data reset** — astro.build communications + GitHub. Verified.\n- **MotherDuck Business $100 → $250/month; Lite $25 tier removed (Dec 2025 – Feb 2026); free tier 10 GB / 10 compute hours/month** — <https://layerbase.com/blog/motherduck-pricing-changes-2026>. Verified by independent technical blogs (Layerbase, Tasrie IT Services). Single-source caveat: MotherDuck did not announce publicly — verify against the live pricing page before any client deliverable that relies on this figure.\n- **MotherDuck Gardyn case study (24× perf at 10× lower cost; >24 hr → <1 hr daily pipeline)** — <https://motherduck.com/learn/reduce-cloud-data-warehouse-costs-duckdb-motherduck/>.\n- **AI-assisted developer productivity range (21-28% speedup to 19% slowdown)** — GovTech Singapore Copilot study (arXiv:2409.17434); longitudinal arXiv:2509.19708 (100+ developers, ~28% shipment volume increase); METR 2025 RCT (arXiv:2507.09089, n=16, +19% completion time despite forecast −24%). Moderate confidence; workload-dependent.\n- **Web Almanac 2025: +7.8% median mobile page weight YoY** — referenced in support of CI-enforced budgets. Verified.\n- **Research brief that informs this page** — see [[research-brief-2026-build-standards]].","rationale_body":"Consolidated topic page absorbing 18 atomic source entries per KB-CONSOLIDATION-PLAN.md (2026-06-11).","metadata":{"kb_role":"topic","word_count":4223,"last_updated":"2026-06-11","absorbed_count":18},"links":{"outgoing":[],"incoming":[]},"created_at":"2026-06-11T13:50:19.508Z","updated_at":"2026-06-11T13:50:19.508Z"}