# Magnolia Performance Requirements Template

Deutsche Fassung: https://ch-schreiber.net/downloads/magnolia-performance-anforderungen.md

Template for tenders, requirements specifications (RFP) and implementation contracts of Magnolia CMS projects.

Source: Christian Schreiber, ch-schreiber.net, https://ch-schreiber.net/en/magnolia-performance-requirements

License: Creative Commons Attribution 4.0 (CC BY 4.0), https://creativecommons.org/licenses/by/4.0/

Values in square brackets are placeholders. The starting point is Google's thresholds for "good". Target values apply per page type, measured at the 75th percentile of field data on mobile devices.

## Requirement 1: Target values per page type from real-user data

**Requirement:** For the page types [homepage, overview page, detail page, form], the following values apply on mobile devices at the 75th percentile of field data: Largest Contentful Paint at most [2.5] seconds, Interaction to Next Paint at most [200] milliseconds, Cumulative Layout Shift at most [0.1]. Target values apply per page type, not per domain. A Lighthouse score is not a target value.

**Acceptance criterion:** After go-live, the values are demonstrated per page type over 28 days in the field data of the Chrome User Experience Report (CrUX) or of a Real User Monitoring. Before go-live, a lab measurement under defined conditions serves as a preliminary check.

## Requirement 2: Server response time and cache strategy

**Requirement:** Time to First Byte at the 75th percentile is at most [800] milliseconds. The cache in front of the public instances serves at least [value] percent of anonymous requests per page type. Parameters that do not affect the content do not create a separate cache variant, no sessions are created for anonymous visitors, and a publication invalidates only the affected paths.

**Acceptance criterion:** Cache hit ratio and response time are demonstrated per page type from the cache and CDN logs, and invalidation is demonstrated with a test case involving a publication.

## Requirement 3: Budget for JavaScript and CSS per page type

**Requirement:** Light module resources and theme files are bundled per page type. Per page type, at most [value] KB of JavaScript and [value] KB of CSS are loaded compressed; the part for the visible area is separated from the rest, and scripts for later interactions are deferred. For headless frontends, the first view is rendered on the server.

**Acceptance criterion:** The sizes are measured per page type in the delivery pipeline; a build that exceeds the budget is rejected.

## Requirement 4: Image delivery and layout stability

**Requirement:** Image variants of the imaging module are generated in advance in at least [number] widths and in modern formats instead of on first request. Every image carries height and width in the markup. The largest image in the visible area is loaded with priority and never lazily.

**Acceptance criterion:** Lab sample per page type, layout shifts in the field below the target value from requirement 1.

## Requirement 5: Approval process for tags and third parties

**Requirement:** Tags, personalization services and every other script from the tag manager, consent banner, analytics or testing tool are checked against the performance budget and approved before go-live. The number of simultaneously active personalization segments per page type is limited to [number]. The consent banner does not shift any content.

**Acceptance criterion:** An inventory of all third-party scripts with their blocking time in milliseconds is available at sign-off and is updated with every release.

## Requirement 6: Measurement in operation from go-live

**Requirement:** Before go-live, a Real User Monitoring per page type, market and device is set up, complemented by the cache hit ratio and the response time of the public instances. In addition, the field data of the Chrome User Experience Report is checked monthly against the target values.

**Acceptance criterion:** Before go-live, the measurement delivers values for all page types from requirement 1.

## Requirement 7: Sign-off per milestone by an independent party

**Requirement:** Every milestone and every release is signed off against the target values from requirements 1 to 6 by a party that is not itself responsible for implementation. Missed target values result in prioritized tasks with acceptance criteria. This also applies to the move from DX Core to DX Cloud and to a headless frontend.

**Acceptance criterion:** A sign-off report per milestone states the measured value, target value and source per page type.