Skip to main content

You are viewing a project that is currently in draft state for the Standards Working Group in the Green Software Foundation. This project should not be considered finished or officially supported in any way by the Green Software Foundation or its members.

Architecture Patterns

In short: the rules are the same for every kind of web application, but different architectures put work in different places. This page shows where each common pattern's energy lands in the formula, so that nothing is missed and nothing is counted twice.

The patterns below were the edge cases the original draft singled out. Every application in scope (Scope and Application Types) follows the same boundary; these notes simply apply it.

Static site generation (SSG)​

  • O_server covers only the energy to serve static files: the web server and CDN edge.
  • The energy to build the site is development and build infrastructure, which Clause 5.3 excludes from the score. It can be assessed separately: see Development Lifecycle Emissions.
  • O_client is included as normal, and O_network is reported or not as for any other application.

Single-page applications (SPAs)​

  • Include the initial page load and all the API calls the application makes afterwards.
  • We recommend a functional unit that represents a complete user workflow, not just the initial load: an SPA does much of its work after the first page appears.
  • Client-side hydration and ongoing JavaScript execution belong in O_client.

Progressive web applications (PWAs)​

  • Online use is counted as normal.
  • When the application runs offline from cached resources, there is no O_server or O_network for that use, but O_client is still measured.
  • Service worker execution belongs in O_client.

Serverless and edge computing​

  • Serverless function execution belongs in O_server, including cold-start overhead, which is real resource use.
  • Edge function execution at CDN nodes belongs in O_server.
  • Clause 7.2 requires the allocation method for shared infrastructure to be disclosed.

Details are on Server-Side Emissions.

API-first architectures​

  • The back-end API's serving energy belongs in O_server.
  • The front-end application that consumes the API belongs in O_client.
  • We recommend a functional unit that represents value delivered to the end user, not individual API calls (see Choosing a Functional Unit).

If the API is also used directly by programmatic clients, only the browser-facing use is in scope; see Scope.

Patterns at a glance​

PatternO_serverO_clientWatch out for
SSGServing onlyAs normalBuild energy is excluded (Clause 5.3)
SPAInitial load and later API callsHydration and ongoing JavaScriptA functional unit that only counts first loads
PWAOnline use onlyAlways, including offlineService worker work
Serverless and edgeFunctions, including cold startsAs normalDisclosing the shared-infrastructure allocation
API-firstAPI servingFront-end consumptionA functional unit of raw API calls

Please submit any comments you have here.