Magnolia Performance Requirements Template Template with seven requirements for Magnolia CMS projects, free to use under CC BY 4.0
Most performance problems on a Magnolia CMS 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 Magnolia CMS projects.
Values in square brackets are placeholdersDownload the template as Markdown
Using the template: fill in the placeholders per page type
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 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
Wording for the requirements specification: 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
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 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.
Download: Magnolia 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 Magnolia 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 Magnolia Agencies; the technical causes are covered under Magnolia CMS 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 a Magnolia RFP
Which target values belong in a Magnolia 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.