When architecture changes the emissions profile

Decisions about whether pages are pre rendered, rendered on each request, or rendered in the client affect energy use in four places. Client devices use battery and CPU to parse markup run scripts and render pixels. The network moves bytes between client browsers and servers. Origin infrastructure consumes CPU cycles storage and database work. Build and deployment pipelines consume compute during site generation and preview builds. Which of those is dominant depends on traffic volume visitor device mix cache hit rate and how often builds run.

How static and dynamic approaches shift work

Static pre rendered pages push compute into the build phase and into the CDN. For stable pages that receive many hits this can deliver very low per visit server compute because the CDN serves cached bytes. Dynamic rendering moves compute to the origin or edge per request. If each request triggers templating database queries or third party calls the per visit server energy and associated emissions can rise quickly. Client side rendering shifts work to the device where CPU and battery matter most which can be appropriate for highly interactive apps but costs more on low power devices.

Key real world variables that change the tradeoff

Cache hit rate is the most important single variable. High cache hit rates make pre rendered pages efficient because origin compute is rare. Cache miss patterns determine how often dynamic work occurs. Traffic skew matters. A small fraction of pages may receive most views so investing in pre rendering those first often yields the biggest marginal benefit. Personalization and user specific content reduce cacheability and push systems toward dynamic work. Freshness requirements and editorial cadence change the cost of pre rendering because frequent full builds increase build pipeline compute. Third party APIs invoked at render time can dominate cost regardless of whether the page is static or dynamic.

Measurement first checklist before the architecture choice

Make decisions from measured signals not assumptions. Start by mapping a small set of representative pages or user journeys and gather three types of data. First collect front end metrics that show transferred bytes CPU work time to interactive and actual device distribution using real user monitoring. Second collect server side metrics that show CPU time memory usage database queries and cache hit versus miss rates from CDN and origin logs. Third collect pipeline metrics that show how long builds take and how many builds run per day including preview and branch builds. Combine these signals to compute per page or per journey energy drivers and to identify whether savings come from reducing data transfer reducing server compute or reducing build frequency.

Tools and signals to collect

• RUM and lab tools use browser RUM to capture device distribution and payload sizes and use a synthetic test to isolate script execution time and layout work.
• Edge and origin logs extract cache hit rates and origin request counts from the CDN and measure average CPU time per request at the origin.
• Build telemetry record total build CPU minutes per build frequency and whether builds are full or incremental.
• Database and third party monitoring measure query counts latency and cache effectiveness for any data sources consulted during render.

Decision rules that produce low emissions without breaking the product

Apply rules that map product needs to architecture choices. If the content is stable for minutes hours or days and many anonymous users visit the same pages favor pre rendering and serving from a CDN. If pages must show user specific secure data or reflect every request uniquely serve them dynamically but reduce origin cost by caching composable fragments. If editorial cadence causes thousands of full builds per day investigate incremental or on demand rendering so you do not pay full build cost on every change. If the visitor device mix includes many low power mobile devices shift heavy interactive logic away from initial page load and prefer server or edge composition of minimal payloads.

Practical patterns that balance emissions and functionality

• Pre render core content pre render the pages with the highest traffic and cache them at the CDN. Load user specific bits later with small API calls or with client side hydration limited to the interactive fragments.
• Cache fragments split pages into a cacheable shell and an uncacheable personalized fragment so the origin only renders the small fraction of the page that changes per user.
• Use incremental on demand generation for large catalogs generate pages at first request and then cache them so you avoid building the entire site on every push.
• Apply stale while revalidate serve cached content immediately and update cached entries asynchronously to preserve perceived speed while keeping origin work lower.

Four realistic scenarios and recommended approaches

Marketing site with high traffic and low personalization

For brochure pages pre rendering plus aggressive CDN caching minimizes both origin compute and network egress from your origin. Focus engineering effort on reducing payload size trimming third party scripts and using optimized images to lower client and network energy. Keep build frequency reasonable and use incremental build features where available to avoid paying heavy build costs for small content changes.

E commerce catalog with many pages and occasional updates

Pre render top pages such as best sellers and category pages. For the long tail use on demand generation or server side generation at the edge plus CDN caching to avoid building thousands of low traffic pages on every content update. Cache product metadata separately from pricing and inventory so the dynamic pieces can be updated without busting caches for the whole page.

Interactive web app with per user data

Serve the initial shell as a small static payload then fetch user data using efficient APIs. Wherever possible cache non sensitive shared queries to reduce origin load. Avoid shipping large client frameworks if a progressive enhancement approach will deliver the required experience with less runtime work on the device.

News site with high editorial churn

Pre render breaking stories but limit full site builds. Implement a publishing pipeline that only regenerates changed pages or segments. Use short lived CDN TTLs for pages that need to update frequently and consider pushing updates to cache using cache invalidation APIs rather than rebuilding the site.

How to measure the carbon difference in practice

Do not rely on high level calculators alone. Build a simple reproducible measurement plan. Choose a representative user journey and record front end metrics for a sample of real sessions including payload size execution time and device class. From server logs measure origin CPU seconds per request database query counts and cache hit rate. Multiply energy per CPU second with a local grid intensity factor if you need absolute greenhouse gas estimates but use relative comparisons for most engineering decisions. The important result is the direction and magnitude of change when switching an architecture or caching policy not a single precise number.

Run controlled comparisons

Run A B tests where one variant uses pre rendering and the other uses dynamic rendering for the same page. Capture both user experience metrics and server telemetry. Compare requests to origin CPU time and TTL driven cache hits. Look for regressions in perceived performance on typical devices as well as reductions in origin compute and network volume.

Mitigations for dynamic features that are hard to avoid

If you need per request personalization the following approaches reduce the carbon impact. Cache until personalized data diverges. Use short lived edge caches and store only minimal personalization state at the edge or in small cookies. Move heavy work to background processes and update caches when the background work completes. Batch writes and avoid synchronous third party calls during render. When using serverless functions favor providers and configurations with warm containers or provisioned concurrency to avoid frequent cold start overhead.

Next steps for product teams

Start with a short audit using the measurement checklist then choose a pilot page to validate an architectural change. Track cache hit rate origin CPU and user experience together so you can justify tradeoffs to stakeholders. Over time codify rules into page templates and your build pipeline so that each new page or feature defaults to the most efficient option that still meets product requirements.