# SSR/ISR Invocation Cost Modeling

Use this reference when the primary cost driver being modeled is server-side rendering, incremental static regeneration (ISR), or edge-function invocation — i.e., compute that runs per-request or per-revalidation rather than being served as a static, fully-cached asset.

## What people get wrong

The common bad assumption is:

> "We use SSR/ISR, so it's basically static — the cache handles it."

That is incomplete, and it is the single most common cause of frontend cloud-cost surprises. Caching mode is not binary; it determines *how often* compute runs, and that invocation rate is the entire cost driver. Two surfaces that both say "we use ISR" can have 100x different compute bills depending on revalidation cadence, tag-invalidation frequency, and whether requests bypass cache due to query-string or header variance.

## Officially grounded shape (Context7-verified, Next.js docs)

Per current Next.js documentation (`/vercel/next.js`):

- **Time-based revalidation** (`fetch(url, { next: { revalidate: N } })`) uses a stale-while-revalidate pattern: cached content is served immediately, and regeneration happens in the background once the content's age exceeds `N` seconds. This bounds worst-case regeneration frequency to roughly `traffic-during-window / N`, not per-request.
- **On-demand revalidation** (`revalidateTag()`, `revalidatePath()`) explicitly invalidates cached content from a server action or route handler, causing the *next* request after invalidation to trigger a fresh render. This decouples regeneration from a timer entirely — invocation count is driven by how often the invalidation trigger fires (e.g., a CMS webhook), not by a fixed interval.
- **Image optimization** (legacy `next/image` pipeline): images are optimized dynamically on first request and cached in `<distDir>/cache/images`; on expiration, a stale image is served immediately while regeneration happens in the background and the new result is cached. This means image-transform compute cost is driven by the *cardinality of distinct requested variants* (width/quality/format combinations), not by pageview count — a large `deviceSizes`/`imageSizes` matrix with the same source image multiplies cache-miss compute even for one logical image.

> Version note: caching defaults have changed across Next.js major versions (`fetch` caching behavior, `dynamicIO`/cache-components experiments). Verify default caching behavior against the installed version via Context7 or official docs before assuming a specific revalidation model — do not assume App Router defaults carry over from Pages Router or from an older major version.

## Non-negotiable design rules

### 1. Classify the invocation shape before pricing anything

Do not price "SSR" as a single line item. Classify each route/surface into one of:

- **Static / fully cached** — served from CDN edge cache, effectively zero marginal compute per request.
- **Time-based ISR** — bounded regeneration rate; cost scales with `unique-pages / revalidate-interval`, not with traffic.
- **On-demand revalidated** — regeneration rate scales with invalidation-trigger frequency (e.g., CMS publish events), which can spike independently of traffic.
- **Per-request SSR (no cache)** — regeneration rate equals request rate; this is the only shape where cost is strictly traffic-linear in compute, and the most expensive per-pageview.

Mixing these into one blended "SSR cost" figure hides which routes are the actual problem.

### 2. Treat cache-key fragmentation as a cost multiplier

Query parameters, cookies, or headers included in the cache key (e.g., per-locale, per-experiment-variant, per-logged-in-state rendering) multiply the effective number of "unique pages" that each need independent regeneration. A page with 3 locales x 4 A/B variants x authenticated/anonymous is 24 cache entries, not 1 — model compute cost against that multiplied cardinality, not the logical route count.

### 3. Distinguish linear from non-linear cost growth explicitly

- **Linear**: cost per pageview is roughly constant as traffic grows (static assets, well-bounded time-based ISR, edge-cached SSR responses).
- **Non-linear**: cost grows faster than traffic (per-request SSR with no cache, unbounded image-variant cardinality, cache-key fragmentation that scales with user/session count, retry storms from a slow origin).

Flag any non-linear pattern as an architectural risk even if the current bill is small — non-linear cost curves are the ones that blow budgets during a traffic spike or a viral moment, precisely when the business can least afford a surprise, and precisely when engineering has the least slack to fix it under pressure.

### 4. Do not price edge/serverless invocations from memory

Provider pricing for edge-function invocations, SSR compute duration, and image-transform requests changes across pricing tiers and providers, and differs materially between "included in platform plan" vs. "metered pay-per-use" billing. Ground any specific per-invocation or per-GB-second rate in the provider's current published pricing page or a user-supplied billing export — do not assert a specific dollar rate from training-data memory, since these rates are revised frequently and vary by committed-use tier.

## Minimal safe modeling flow

1. Classify each route/surface by invocation shape (static / time-based ISR / on-demand / per-request SSR).
2. For each non-static shape, identify the cache-key dimensions (locale, auth state, experiment variant, query params) and compute effective cardinality.
3. Get actual or estimated traffic volume per surface (analytics export, CDN log sample, or user-stated estimate — label whichever it is).
4. Compute expected invocation count: time-based ISR ≈ `cardinality / revalidate_interval_seconds × window_seconds`; on-demand ≈ trigger frequency; per-request SSR ≈ request volume.
5. Apply current provider pricing (billing export preferred; public rate card as fallback, labeled `modeled-from-public-pricing`) to invocation count and compute duration/memory profile.
6. Flag any surface where invocation count scales faster than traffic as non-linear risk, independent of the resulting dollar figure.

## Adversarial checklist

Before presenting an SSR/ISR/edge cost figure as reliable, answer these:

- Did I classify by actual invocation shape, or did I average everything into one "SSR" bucket?
- Does the cache key include anything that fragments cardinality (locale, auth, experiment, query string)?
- Is the revalidation interval time-based, on-demand, or both layered together?
- Did I verify current caching-default behavior against the installed framework version via Context7/official docs, or am I assuming defaults from memory?
- Is the pricing rate billing-data-verified, or modeled from a public rate card that may not reflect the account's actual committed-use discount?
- Have I flagged any non-linear growth pattern regardless of whether the current dollar total looks small?

If any answer is "I don't know," say so explicitly rather than presenting a confident number.

## When to push back

Push back if the user asks to:

- disable a cache layer, revalidation window, or CDN tier purely to "make the number smaller" without checking Core Web Vitals impact,
- assume a flat per-request cost figure without classifying invocation shape first,
- accept a public price-sheet estimate as final without flagging that real committed-use pricing may differ substantially,
- treat a non-linear cost-growth pattern as acceptable because "the bill is still small today."

Those shortcuts produce a number that looks precise and is not, and they defer an architectural risk instead of surfacing it.

# Third-Party Script Cost Attribution

Use this reference when ranking third-party scripts, tags, or dependencies by their cost and performance contribution against their measured business value — not just their bundle size.

## What people get wrong

The common bad assumption is:

> "Third-party scripts are free — they're hosted by the vendor, not by us."

That is wrong in two separate ways. First, the vendor's hosting cost is irrelevant; what matters is the cost *the frontend surface incurs on behalf of loading and running it*: the CDN egress/request count if self-hosted or proxied, the CI build-minute cost if bundled at build time, and — the largest and most commonly ignored cost — the Core Web Vitals and conversion-rate impact of the script's execution, which translates directly into revenue at the margin. Second, "third party" bundles wildly different cost profiles under one label: a 2 KB feature flag SDK and a 400 KB chat-widget bundle with its own CDN calls are not comparable line items.

## Officially grounded shape (web.dev / Lighthouse performance budgets)

Per current web.dev guidance:

- Performance budgets can be defined per resource type (script, image, font, stylesheet, third-party, total) and per resource *count*, not just size — a `resourceCounts` budget on `third-party` requests is a first-class Lighthouse budget primitive (`budget.json`), independent from a size-based budget.
- Quantity-based metrics (page weight, request count, third-party request count) are explicitly recommended as an early-stage, easy-to-communicate proxy — useful for a cost/business conversation with non-engineering stakeholders even before deeper timing-based metrics are modeled.
- A commonly cited critical-path budget is under ~170 KB of compressed/minified critical-path resources for a fast experience on constrained devices/networks — useful as a reference point when arguing that a given script's weight materially eats the surface's total budget, not just "feels heavy."

## Non-negotiable design rules

### 1. Attribute cost per script, not per "third-party" bucket

For each script, separately account for:

- **Bundle weight** — transferred bytes (compressed), which drives CDN egress cost if proxied/self-hosted, or drives page-load time regardless of hosting.
- **Request count** — each script may fan out to its own CDN/API calls (analytics beacons, ad-tech auctions, chat-widget polling) that are invisible in a simple bundle-size measurement.
- **Execution cost** — main-thread blocking time and its measured effect on Core Web Vitals (particularly INP and LCP), which is a performance cost, not a cloud-billing cost, but converts to a revenue/conversion cost.
- **Build-time cost** — if the script or its wrapper is bundled/transpiled/type-checked in CI, attribute a share of CI build-minute spend to it.

### 2. Require a stated business justification before ranking a script as "remove"

A script's cost is only meaningful relative to its value. Do not rank a script for removal purely by weight or execution cost — pair every cost figure with the script's stated business function (conversion tracking, support chat, personalization, fraud detection, ad revenue) and, where available, a measured lift/attribution figure. A high-cost script tied to a verified revenue driver ranks differently than an equally expensive script with no attributed owner or unclear purpose.

### 3. Separate "safe to remove," "safe to defer/lazy-load," and "requires owner sign-off"

- **Safe to remove**: no attributed business owner, duplicate functionality with another already-loaded script, or confirmed dead/unused (verify via network trace or tag-manager audit, not assumption).
- **Safe to defer/lazy-load**: legitimate business function but not required for above-the-fold interaction (e.g., load after first user interaction or via `next/script`'s lazy-loading strategies where the framework supports it) — verify the framework's specific lazy-loading API via Context7/official docs before recommending a specific implementation, since loading-strategy APIs vary by framework and version.
- **Requires owner sign-off**: anything tied to security (bot mitigation, fraud detection), compliance (consent management, accessibility overlays with a legal mandate), or a verified revenue driver — never recommend removing or deferring these unilaterally on cost grounds alone; escalate to the named business/security owner.

### 4. Do not conflate script cost with hosting cost

A script's own CDN bill is the vendor's problem. The frontend surface's cost exposure is: its own egress if self-hosting/proxying the script, its own CI cost if bundling it, and its own performance-to-revenue cost from execution. Keep these separate in the report so a reader does not think "removing this script saves us their hosting bill."

## Minimal safe attribution flow

1. Enumerate all third-party scripts/tags currently loaded (network trace, tag manager audit, or `package.json`/bundle-analyzer output for bundled third-party code).
2. For each script, capture: transferred bytes, request count/fan-out, measured main-thread/CWV impact if available (lab data from Lighthouse/WebPageTest, or field data from CrUX/RUM), and CI build-time share if bundled.
3. Attribute a stated business function and, if available, a measured value signal (conversion lift, support-ticket deflection, ad revenue) — mark as `owner-confirmed` or `unattributed` if no owner responds.
4. Rank by cost-to-value ratio, bucketing into safe-to-remove, safe-to-defer, and requires-sign-off.
5. Present dollar cost (CDN egress + build-minute share, evidence-labeled) alongside the performance/CWV cost and the stated business value for each item.

## High-risk assumptions to kill

- "It's third-party, so it doesn't cost us anything."
- "Nobody's complained about this script, so it must be fine to keep loading it eagerly."
- "This script is small, so its execution cost doesn't matter."
- "We can just lazy-load everything without checking what breaks."
- "Unattributed scripts are automatically safe to remove" — unattributed does not mean unused; verify before removing.

## When to push back

Push back if the user asks to:

- remove a script tied to fraud detection, bot mitigation, consent management, or an accessibility legal mandate purely for cost savings, without named security/compliance owner sign-off,
- rank scripts by bundle size alone without checking request fan-out or CWV execution impact,
- treat "no one knows what this does" as justification for silent removal in a live production surface without a verified owner check or a monitored rollback path.

Those are cost-cutting shortcuts that trade an unmeasured business or security risk for a measured dollar saving — surface the trade-off explicitly instead of making the call silently.