# AEM Performance Requirements Template

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

Template for tenders, requirements specifications (RFP) and implementation contracts of Adobe Experience Manager projects.

Source: Christian Schreiber, ch-schreiber.net, https://ch-schreiber.net/en/aem-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 template, 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. Dispatcher and CDN serve at least [value] percent of anonymous requests per page type from the cache. Dispatcher filters ignore parameters that do not affect the content, and a publication invalidates only the affected paths; statfileslevel and invalidation rules are documented.

**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:** Client libraries are delivered separately per page type, not as one shared bundle for all pages. 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.

**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:** Images are delivered via the image component of the Core Components or Dynamic Media with defined renditions in at least [number] widths and in modern formats. 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:** Adobe Launch, Adobe Target, the data layer 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. An owner is named for every script. 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 measurement based on real-user data per page type, market and device is set up, in Cloud Service via Operational Telemetry or a separate Real User Monitoring. 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 migrations to Cloud Service and to Edge Delivery Services, see AEM 6.5 End of Support.

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