AEM Performance Requirements Template Template with seven requirements for Adobe Experience Manager projects, free to use under CC BY 4.0
Most performance problems on an Adobe Experience Manager platform arise during implementation and only become apparent after go-live. The reason is rarely a lack of skill, but a requirements specification without measurable speed requirements: what is not required is neither implemented nor signed off. This template contains seven requirements with acceptance criteria for tenders, requirements specifications (RFP) and implementation contracts of Adobe Experience Manager projects.
Values in square brackets are placeholdersDownload the template as Markdown
Using the template: fill in the placeholders per template
Each requirement consists of wording for the requirements specification and an acceptance criterion. Values in square brackets are placeholders. Google's thresholds for "good" serve as the starting point; stricter values make sense for page types that generate a lot of revenue, such as form flows. Values that the existing platform already achieves better today belong in the requirements specification as a baseline, so that the project does not make the platform worse.
Requirement 1: Target values per page type from real-user data
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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.
Download: AEM template as Markdown under CC BY 4.0
The template as a Markdown file contains all seven requirements with placeholders for insertion into a requirements specification, tender or proposal. It is licensed under Creative Commons Attribution 4.0: clients, agencies and IT service providers may use and adapt it, including in commercial proposals, with the attribution "Christian Schreiber, ch-schreiber.net".
Requirements become commissioned tickets for the AEM implementation partner
Without requirements in the requirements specification, performance becomes unpaid rework after go-live or a point of dispute between client and implementation partner. With them, it becomes commissioned work that can be signed off. How the collaboration works is described under Performance Partner for AEM Agencies; the technical causes are covered under Adobe Experience Manager Performance, the process of an optimization under Website Performance Optimization.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, regardless of whether a project follows.
Frequently asked questions about performance requirements in an AEM RFP
Which target values belong in an AEM requirements specification?
Target values for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift per page type, measured at the 75th percentile of field data on mobile devices. The starting point is Google's thresholds: 2.5 seconds, 200 milliseconds and 0.1. In addition, server response time, the cache strategy, a budget for JavaScript and CSS, and rules for images and third parties.
Why field data instead of a Lighthouse score?
Google rates pages by what real visitors experienced over the last 28 days. Lighthouse measures a single simulated session without the tag manager, consent banner and real devices. A score can be 100 while the field data misses the threshold; it is therefore not suitable as a contractual target value.
May the template be used in your own proposals?
Yes. The template is licensed under Creative Commons Attribution 4.0 and may be used and adapted, including commercially, with the attribution Christian Schreiber, ch-schreiber.net.