Default web stack (Astro on Cloudflare)

Overview

The documented default web stack 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.

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

The framing here draws on an internal 2026 build-standards research brief (compiled May 22, 2026) covering framework choice, hosting, and progressive-enhancement primitives. The cost-and-satisfaction comparison between Astro on Cloudflare Pages and Next.js on Vercel, and the framework-level performance gap, are both summarised inline with their primary sources.

Astro 6 stable, March 2026

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

Source: astro.build/blog/ (Astro 6 release notes). Confidence: Verified.

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.

Astro on Cloudflare Pages: the low-cost default versus Next.js

The published cost comparison documents that for a small-business marketing site Astro on Cloudflare Pages runs near zero recurring spend at small-business volumes, while Next.js server-side rendering on Vercel sits in a monthly subscription range that scales with traffic. Astro ships "zero JavaScript by default." Companion measurement from the Web Aloha agency documents WordPress-to-Astro migration as a substantially smaller engagement than a Next.js rebuild, and the annual hosting-plus-plugin spend dropping by approximately an order of magnitude relative to a typical WordPress stack of the same era.

Source: Alex Bobes, "Astro vs Next.js" (alexbobes.com/programming/astro-vs-nextjs/, 2026), reporting effectively no recurring hosting cost for Cloudflare Pages at small-business volumes against a recurring monthly subscription range for Next.js SSR on Vercel that scales with traffic; Web Aloha (webaloha.co/wordpress-vs-astro-for-business/), reporting WordPress-to-Astro migration as a small one-time engagement and annual hosting-plus-plugin spend dropping by approximately an order of magnitude relative to a typical WordPress stack of the same era. Confidence: Verified (vendor-neutral practitioner benchmark).

State of JS 2025 placed Astro 39 satisfaction points ahead of Next.js among practitioners — "its satisfaction ratio now has a 39% gap with leader Astro" — characterising Astro's run as a "dramatic transformation from near obscurity to serious contender."

Source: State of JS 2025 (2025.stateofjs.com/en-US/libraries/meta-frameworks/). Confidence: Verified.

The framework-level performance gap is also documented: Astro benchmarks show ~40% faster page loads and ~90% less JavaScript than equivalent Next.js builds for static content sites, attributed to partial hydration / islands architecture / static-first rendering.

Source: eastondev.com Astro vs Next.js benchmark (December 2025, updated May 2026); corroborated by Alex Bobes 2026. Confidence: Single-source vendor-neutral practitioner benchmark; methodology disclosed but small sample.

Astro vs Next.js: CWV evidence Next.js can be the wrong default

Per the 2024 Web Almanac Performance chapter, Fig. 9.3:

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

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

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; Next.js sat at the bottom of the pack with roughly 1-in-4 pass rates.

This is the empirical reason the default is Astro for content work, even when the team is fluent in React.

Edge vs origin: Cloudflare default for SMB, with explicit flip conditions

For sub-100k pageviews/month SMB sites — the bulk of the engagement profile this stack targets — Cloudflare Pages + Workers is the default. The flip conditions are narrow and named.

Latency math for a KW SMB serving primarily Ontario traffic:

• Cloudflare PoP in Toronto → user: 5-15 ms.
• Vercel iad1 (Virginia) → Ontario user: 25-40 ms.
• Single origin in Toronto VPS → Ontario user: 5-15 ms.
• Single origin in Toronto → user in BC or NY: 60-100 ms.

For 95%-local-traffic, the pure latency case for edge is weak. The case for Cloudflare is broader:

1. Global CDN for static assets (every option provides this).
2. Sub-5 ms V8 isolate cold starts for SSR/dynamic logic vs container-based serverless at 250 ms+.
3. Predictable pricing model that beats Vercel by ~5-10× at SMB volumes.
4. Free tier that genuinely covers SMB volumes.
5. DNS + CDN + edge compute + image optimization in one console.

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.

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.

Next.js 16 (October 2025): Cache Components and dynamic-by-default

Next.js 16 (released October 2025) shipped a meaningful semantic change worth tracking even when Next.js is not the default stack.

• 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.
• Turbopack is the default dev bundler (production builds still in beta).
• middleware.ts renamed to proxy.ts.
• React Compiler 1.0 stable opt-in (not enabled by default).

Source: nextjs.org/blog/next-16. Confidence: Verified.

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.

Practitioner read: 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.

React Compiler 1.0 stable, October 7, 2025

React Compiler 1.0 released stable on October 7, 2025.

Verbatim (react.dev):

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

Next.js 16 integration (nextjs.org/blog/next-16):

"promoted from experimental to stable. It is not enabled by default as we continue gathering build performance data."

Confidence: Verified.

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.

Speculation Rules: eagerness: "moderate" as 2026 default

Speculation Rules with eagerness: "moderate" is the 2026 default for instant navigation. Per Arjen Karel's CoreDash field data (corewebvitals.io):

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

Confidence: Moderate-to-high — single-source field measurement, but mechanism is well-understood and corroborated by Google Chrome team posts.

Browser support: Chrome / Edge / Opera stable; Safari 26.2 behind a flag; Firefox positive standards position, not shipped. Covers ~70% of global traffic.

Default JSON:

{ "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }] }

moderate prerenders on hover (desktop) or 50 ms after a link enters the viewport (mobile, per Chrome 144 from January 2026).

Risk mitigations:

• Use moderate, not immediate, on most sites.
• Exclude logout / cart-mutation / admin URLs explicitly.
• 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.
• Never use GET requests for state-mutating actions (this is true regardless of Speculation Rules, but they make the lapse exploitable in seconds).

GTM with 18 tags: ~20× TBT, per Chrome Aurora

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

Confidence: Industry-consensus.

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.

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

Image pipeline: AVIF source, WebP fallback, JPEG last

The standard image pipeline on every build under this standard:

• Source format: AVIF (Q ~50-60) for hero/photography, WebP for everything else, JPEG fallback.
• <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.
• fetchpriority="high" on the LCP image only — at most one per page; multiple cancel out the benefit.
• loading="lazy" below the fold, loading="eager" for the first 3-6 images.
• Explicit width and height always (kills CLS).
• Vary: Accept header configured correctly at the CDN.

CDN choice (in order of preference):

1. Cloudflare Polish / Cloudflare Images — default for Cloudflare-hosted sites; bundled, edge-optimized, no egress fees.
2. Sharp + Astro Image Service — works everywhere, build-time, no runtime cost. Good for static-output Astro.
3. Next.js <Image> — fine on Vercel, expensive elsewhere (Vercel charges per source image). Avoid on non-Vercel hosts unless the cost has been measured.
4. Cloudinary / imgix — only if the client already has a contract.

Build gate: pre-commit hook or CI step that fails on raw JPEGs over 200 KB.

WebP compression evidence (Google study)

Per 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."

Source: https://developers.google.com/speed/webp/docs/webp_study. Confidence: Verified (Google primary).

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.

Rendering strategies and AI-crawler hygiene

Three rendering architectures define the indexing-and-extraction risk profile of any site:

• SSR (Server-Side Rendering) — HTML generated on the server before delivery, per request. Content present in the initial response.
• SSG (Static Site Generation) — HTML generated at build time as static files. Content present in the initial response.
• CSR (Client-Side Rendering) — server delivers a near-empty HTML shell; the client's browser executes JavaScript to fetch data and build the DOM. Typical of default single-page-app setups in React, Vue, Angular.

SSR and SSG present content to Google directly in the initial HTML. CSR requires Google to render before content exists. Hybrid approaches (Next.js, Astro islands, Remix) blend SSR/SSG for indexable pages and CSR for app surfaces — that hybrid pattern is the default under this stack and sidesteps most of the rendering risk.

Source: Standard web-architecture taxonomy; Google Search Central JavaScript SEO documentation. Confidence: High.

The risk profile shifted again with the rise of AI assistants. Per Vercel + MERJ research, most non-Google AI crawlers do not execute JavaScript at all — including GPTBot, ClaudeBot, and PerplexityBot. Over 500 million GPTBot fetches were tracked with zero evidence of JS execution. Implication: a CSR site can be a Google success and an AI-surface ghost simultaneously — Google may render and index it fine while ChatGPT, Claude, and Perplexity see only the empty HTML shell.

Source: Vercel + MERJ research (companion to the 2024 rendering study). Confidence: Medium-high — methodology disclosed. Caveat: vendor incentive flagged (Vercel sells server-rendering frameworks), but the directional result is consistent with standard bot architecture (headless HTTP fetch, not headless Chromium) and Cloudflare's separately-reported AI-crawler logs.

This is the architectural reason a static-first or SSR-first default is now load-bearing for both SEO and AI citation. CSR sites are routinely invisible to the AI-answer surfaces clients increasingly care about.

Internal linking, discovery, and PageRank flow

Internal linking and site architecture have three separable effects, with very different evidence strength on each:

• Discovery (solid). Google discovers URLs by following links; pages with no internal links ("orphans") may never be found even if they sit in a sitemap. Reducing click-depth from the homepage improves discovery and recrawl odds. Industry-consensus / Verified.
• Crawl efficiency (solid for large sites). Clear architecture and shallow depth help Googlebot reach important pages — relevant mainly for large/complex sites. Crawl budget is over-rated for small sites. Verified.
• Importance / PageRank flow (real but unquantified). Internal links pass importance signals, and Gary Illyes has confirmed PageRank-type scoring remains in use inside Google's ranking systems. But Google publishes no formula or weighting, and the "dilution" logic is a framework rather than a measured constant. Single-source / Directional-Speculative on magnitude.

Case studies attributing ranking gains to internal-linking changes suffer from survivorship and selection bias: sites that rank well had many things right at once, so isolating internal linking's contribution is rarely valid.

Source: Google Search Central documentation; Gary Illyes on-record commentary. Confidence: Mixed by sub-claim as graded above.

Caveat: Structured data does not substitute for HTML links — breadcrumb markup helps render breadcrumb UI but does not pass link equity the way a real <a href> does.

CMS workflow decision matrix

The decision framework adopted under this standard for picking a CMS during migration:

Client profile	Recommendation	Why
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
Edits monthly, single editor, comfortable with forms (not Word)	Keystatic (Astro/Next.js)	Git-based, no database, no SaaS bill, schema-as-TypeScript
Weekly+ but team has engineers / dev on staff	Markdown in Git, no CMS	Maximum portability; PR review = editorial workflow
Structured content reused across web + email + native app	Sanity (only)	Content Lake, GROQ queries, true headless
Wants to keep the WordPress editor experience	Headless WordPress + Next.js	Preserves editor muscle memory; doubles infrastructure cost
Daily editors, large team, complex publishing workflow	Stay on WordPress	Migration is the wrong project for this profile

What non-technical clients actually need vs think they need:

• They think they need: Gutenberg-equivalent visual builder for every page.
• 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.
• 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.
• 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.

FatLab's honest framing:

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

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.

Data layer: avoid Astro DB / Astro Studio as a strategic bet

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

Defaults for SMB sites needing a database:

• Cloudflare D1 for small SQLite workloads, low write volume (likes, view counts, form submissions).
• Neon Postgres for anything more complex; pairs with pgvector for RAG.
• Supabase if the client wants a managed admin UI included.

MotherDuck pricing changes 2026 (analytics layer note)

MotherDuck'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.

Source: https://layerbase.com/blog/motherduck-pricing-changes-2026.

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.

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

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 that inform analytics guidance.

Infrastructure cost-floor context

The near-zero hosting and per-request pricing that anchors the default stack sits on top of a two-decade collapse in unit infrastructure prices. The magnitudes, summarised from primary pricing histories:

• Storage: $0.15/GB → ~$0.02/GB on S3 = roughly 85% lower, or about 7× more data for the same dollar. AWS states ~85%; the hidekazu-konishi.com timeline corroborates "over 84%" across tiers, with major cuts in 2009, 2014, and December 2016.
• Compute: entry-tier EC2 fell from ~$0.10 to ~$0.005 per instance-hour — roughly 20× cheaper at the floor.
• Bandwidth: transit fell from ~$1,200 to ~$5 per Mbps between 1998 and 2010 — roughly 240×, with continued decline since.

Source: AWS S3 pricing history; hidekazu-konishi.com independent timeline; long-running bandwidth pricing surveys. Confidence: Verified for storage and compute; single-source for bandwidth. Caveat: AWS's own "we've cut prices N times" framing is vendor self-congratulation and should be quarantined — only the dated launch price and current published price are primary.

The structural change underneath the unit-price drop is a shift from capex + ongoing ops labour to pay-as-you-go opex with the provider absorbing administration. The pre-cloud baseline was a dedicated server in a colocation rack, plus bandwidth, plus a sysadmin to patch, back up, and fail over the machine — capex on the box, opex on the labour. The post-cloud equivalent is managed hosting, serverless compute, and managed databases, billed by use. A hobbyist or SMB can now run, for roughly $5-$50/month, a managed-DB-backed application that around 2005 implied a dedicated server plus a non-trivial slice of a sysadmin's salary.

Source: Synthesis of pre-cloud and post-cloud pricing entries. Confidence: Industry-consensus.

The clearest worked example: in 2007/2008, a single New York Times engineer ran OCR over the paper's full scanned archive on EC2, on a personal credit card, for about $200. A task that would have required a six-figure capex purchase the year before became a weekend project.

Source: GeekWire AWS history. Confidence: Verified.

In adjacent payments infrastructure, Stripe launched in 2011 with the key innovation that card data never touches the merchant's server — Stripe.js exchanges the card for a token client-side, removing the heaviest PCI compliance burden from the SMB.

Source: ByteByteGo / Stripe. Confidence: Verified.

The relevance to the default stack: the Cloudflare / Vercel / Neon / Stripe layer that makes near-zero recurring hosting cost for an Astro-on-Cloudflare-Pages marketing site possible is the endpoint of this multi-decade structural shift, not a marketing claim. It is also why "self-hosted DuckDB + Parquet on S3/B2" is a credible architecture for an SMB analytics layer rather than a hobbyist toy.

AI-assisted developer productivity: the honest 2026 ceiling

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

Published research range — three primary sources:

• GovTech Singapore GitHub Copilot study (arXiv:2409.17434): "coding/tasks speed increased by 21-28%".
• 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".
• 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.

Confidence: Moderate. The field is moving fast and results are workload-dependent.

Translation:

• Fluent users with skill-library discipline → meaningful (20-30%) lifts.
• Naive power-users on unfamiliar codebases → can be slower than baseline.
• Honest ceiling for a 2-person marketing-site shop: ship 1.3-1.7× the marketing-site work a 2024-equivalent shop could once the team is fluent.
• Cap is set by client communication, discovery, and design — not coding.

Where AI benefits most (high confidence):

• Greenfield Astro/Tailwind scaffolding.
• Boilerplate refactors (renaming, type-narrowing, API client updates).
• Framework migrations (Tailwind v3→v4, Astro 4→5→6, Next.js 14→15→16).
• Writing tests for existing code.
• One-off scripts and CMS schemas.

Where it benefits least (moderate confidence):

• Performance optimization (requires human judgment about what to measure).
• Accessibility decisions.
• Information architecture and content strategy.
• Anything requiring institutional/client context the model doesn't have.

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.

Rules carried by the default stack

The following rules are the operational expression of the stack. They are documented in writing, applied at engagement scoping, and enforced in CI where possible.

R1. Default stack is Astro 5/6 + Tailwind v4 on Cloudflare Pages

Every new engagement under this standard 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.

Flip rules (documented in writing, not assumed):

• 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.
• Flip to SvelteKit 2 + Svelte 5 only when the team has existing Svelte fluency.
• Flip to headless WordPress + Next.js only when the editor team explicitly requires the Gutenberg experience and the cost premium is accepted in writing.

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

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.

R2. For content-heavy, SEO-critical, AI-citation-sensitive client sites, the default is headless WordPress with Astro on Cloudflare Pages

For sites in the content-heavy, SEO-critical, AI-citation-sensitive class, the default proposal is headless WordPress (WPGraphQL) with Astro on Cloudflare Pages, rather than WordPress with a page builder or Next.js server-side rendering. The six-class framework that names this site profile is documented in Agency methodology for small-business website projects.

Why:

• Performance: Astro ships roughly ninety percent less JavaScript than Next.js for static content (eastondev benchmark, December 2025).
• Cost: the Alex Bobes 2026 and Web Aloha measurements summarised in the Astro-on-Cloudflare section above document near-zero monthly cost for Astro on Cloudflare Pages against a recurring monthly figure for Next.js SSR on Vercel, and Web Aloha documents annual hosting plus plugin spend dropping by roughly an order of magnitude on the migration.
• AI extractability: pre-rendered HTML, server-render-first, no JavaScript hydration needed for content reads.
• Practitioner satisfaction: State of JS 2025 — Astro held an approximately thirty-nine-point satisfaction lead over Next.js.

How to apply:

• For content-heavy / SEO-critical / AI-sensitive sites, lead the proposal with headless Astro. Page-builder-plus-WordPress is presented as the older pattern.
• For web-app / authenticated-flows sites, Next.js remains the default — Astro is the content-site stack.
• WordPress remains the authoring layer (editors continue to work in wp-admin); Astro renders the public site.

R3. Defer or delay every third-party script until user interaction

Every third-party script on a client site built under this standard 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.

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.

How to apply:

• Inventory third-party scripts at engagement onboarding; rank by ROI.
• For Next.js: next/script with strategy="lazyOnload" for analytics, chat, A/B testing, heatmaps.
• For others: Partytown to move 3rd-party JS to a web worker.
• 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.
• Chat widgets (Intercom, Drift, HubSpot): only load on click of a chat trigger, never on page load.
• One-script-in, one-out rule: net script count never grows without explicit justification.

R4. Performance budgets enforced in CI

Every client site built under this standard 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.

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.

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

How to apply:

• Use the 2026 performance-budget targets as the default.
• Tools: Lighthouse CI (free) for build-time enforcement; DebugBear or SpeedCurve for field-data monitoring.
• Build fails on budget violation — no overrides without explicit waiver in the PR.
• Quarterly budget review: tighten where slack exists; document why if any threshold is loosened.

R5. LCP image gets explicit dimensions + fetchpriority="high" + no lazy-loading

Every client page built under this standard identifies its LCP element (typically the hero image) and ensures:

1. Explicit width and height attributes (prevents CLS).
2. fetchpriority="high" attribute (raises Chrome's preload-scanner priority).
3. No loading="lazy" (lazy-loading the LCP image is the #2 cause of LCP failure).
4. Modern format (WebP or AVIF).
5. Proper srcset / sizes for responsive serving.
6. NOT hidden from preload scanner — never data-src, never CSS background-image, never JS-injected URL.

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.

How to apply:

• Use Next.js <Image priority> on the hero (which sets fetchpriority="high" and disables lazy-loading).
• For non-Next.js sites: hand-coded <img> with all six properties.
• Verify with WebPageTest filmstrip: the hero image should be in the first batch of requests, before any third-party scripts.
• Re-check after any plugin or theme update — defaults change.

R6. Do not recommend Astro DB / Astro Studio as a strategic platform bet

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

How to apply: for SMB sites needing a database, default to:

• Cloudflare D1 for small SQLite workloads, low write volume (likes, view counts, form submissions).
• Neon Postgres for anything more complex; pairs with pgvector for RAG.
• Supabase if the client wants a managed admin UI included.

R7. Validate rendered HTML via Search Console URL Inspection in the first weeks after launch

In the first weeks after launch, Search Console URL Inspection (Live Test) is used to view the rendered HTML Google actually sees. The inspection confirms that:

• Critical content (headings, body copy, key facts) is present in the rendered HTML.
• Internal links are present as <a href> elements.
• The canonical tag is correct.
• Structured data (if any) is present and valid.
• The mobile rendered HTML matches the desktop rendered HTML for the above.

Why: Lab tools, browser DevTools, and "view source" can show different HTML than Googlebot rendering produces — caching, JS execution order, and server-side bot detection can all diverge. URL Inspection is the closest thing to Google's ground truth.

How to apply: inspect at least five representative pages per launch (homepage, top service page, top product or article, a deep page, the mobile-rendered version). If the rendered HTML is missing content visible in the browser, the rendering pipeline is broken and the fix lands before promote.

Sources and confidence

• Astro 6 stable, March 2026 — astro.build/blog/ (Astro 6 release notes). Verified.
• Astro on Cloudflare Pages vs Next.js cost/satisfaction — Alex Bobes (alexbobes.com/programming/astro-vs-nextjs/, 2026); Web Aloha (webaloha.co/wordpress-vs-astro-for-business/); State of JS 2025 (2025.stateofjs.com/en-US/libraries/meta-frameworks/). Verified.
• Astro vs Next.js performance gap (~40% faster, ~90% less JS) — eastondev.com Astro vs Next.js benchmark (December 2025, updated May 2026); corroborated by Alex Bobes 2026. Single-source vendor-neutral practitioner benchmark.
• Next.js 10-point CWV drop on FID → INP transition — 2024 Web Almanac Performance chapter, Fig. 9.3. Verified.
• Edge vs origin latency math; Cloudflare default for SMB — practitioner field measurements; internal latency baselines for KW/Ontario SMB traffic.
• Next.js 16 (Cache Components, Turbopack, proxy.ts, React Compiler 1.0 opt-in) — nextjs.org/blog/next-16. Verified.
• React Compiler 1.0 stable, October 7, 2025 — react.dev release post; quoted verbatim. Verified.
• 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.
• GTM with 18 tags increases TBT ~20× — Chrome Aurora team via corewebvitals.io. Industry-consensus.
• Image pipeline AVIF + WebP + JPEG, fetchpriority on LCP only — Cloudinary/Smashing AVIF compression measurements; Caniuse browser support; standard 2026 practitioner build pattern.
• 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).
• Rendering strategies (SSR / SSG / CSR) — standard web-architecture taxonomy; Google Search Central JavaScript SEO documentation. High.
• Non-Google AI crawlers do not execute JavaScript (GPTBot, ClaudeBot, PerplexityBot; 500M+ GPTBot fetches, zero JS execution) — Vercel + MERJ research (companion to the 2024 rendering study). Medium-high; vendor incentive flagged but result consistent with bot architecture and Cloudflare-reported logs.
• Internal linking — discovery / crawl efficiency / PageRank flow split — Google Search Central documentation; Gary Illyes on-record commentary. Discovery and crawl efficiency Verified; PageRank-flow magnitude Single-source / Directional-Speculative.
• 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.
• 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.
• 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.
• 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/.
• Storage cost-floor (~85% S3 price drop; ~7× more data per dollar) — AWS S3 pricing history; hidekazu-konishi.com independent timeline. Verified. AWS "we've cut prices N times" framing quarantined as vendor self-congratulation.
• Compute and bandwidth cost-floor (EC2 entry ~20× cheaper; transit ~240× 1998-2010) — synthesis of pre-cloud and post-cloud pricing entries. Verified for compute; single-source for bandwidth.
• Capex → opex structural shift — synthesis of pre-cloud and post-cloud entries. Industry-consensus.
• NYT EC2 archive job 2007/2008 (~$200, one engineer, personal credit card) — GeekWire AWS history. Verified.
• Stripe launched 2011; card data tokenised client-side (Stripe.js), removing the PCI burden from the merchant — ByteByteGo / Stripe. Verified.
• Search Console URL Inspection — rendered-HTML validation post-launch — Google Search Central URL Inspection documentation. Verified.
• 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.
• Web Almanac 2025: +7.8% median mobile page weight YoY — referenced in support of CI-enforced budgets. Verified.
• Internal research brief on 2026 build standards — compiled May 22, 2026; framework-choice and progressive-enhancement primitives.