Web Performance Consultant for enterprise platforms in the DACH region
Web Performance Consulting for Adobe Experience Manager and Magnolia Fixed Core Web Vitals target values, checked with every release
Large websites and portals do not become fast on their own, and without fixed target values they do not stay fast either. That is why measurement and sign-off belong in one hand, separate from implementation: target values per page type based on real-user data, tasks for your development team or agency, and sign-off of every release against these target values.
Implementation stays with your team. The target values are agreed in advance and checked independently afterwards.
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 collaboration follows.
- More than 20 years in web development, more than ten of them in web performance
- Ongoing Magnolia engagement in the insurance industry, AEM optimization for a German car manufacturer
- Independent of Adobe, of Magnolia and of implementation partners
Enterprise platforms stay slow despite testing and budget because nobody owns performance
On large platforms, the agency, marketing and IT work on the website at the same time. Performance is the metric that everyone influences and nobody is responsible for.
Lighthouse 100 in testing, Core Web Vitals missed for real users
Lighthouse, Google's testing tool, measures a page under lab conditions: without a tag manager, without cookie consent, without personalization, without real devices. Rankings, by contrast, depend on what real visitors experienced over the last 28 days. The gap between the two numbers is usually the entire marketing infrastructure.
Without a performance budget, every release shifts the values
A new module, an extra script, a larger hero image: every change affects load time, response time or layout stability. Without a performance budget and sign-off against it, this only becomes visible when Search Console flags the affected pages as needing improvement. By then the release has long been in production.
Performance has no owner on enterprise platforms
The agency delivers features, marketing adds tags, IT runs the platform. Performance cuts across all three areas. It needs a role that sets target values and checks that they are met.
The 28-day window of Google's real-user data delays every correction
Google calculates the Core Web Vitals from a rolling 28-day window. A regression shows up with a delay, and so does a fix. Teams that only react once the thresholds are missed lose two cycles before the numbers are right again.
Core Web Vitals Benchmark: two original studies of AEM and Magnolia platforms in the DACH region
For both systems, 46,394 domains were checked individually and the real-user data of every website found was evaluated. The studies answer the question that comes before any optimization: how many websites pass, and whether the cause for the rest lies in delivery or in the frontend.
Adobe Experience Manager: 49.4 percent pass the Core Web Vitals
49.4 percent of 4,222 websites pass the Core Web Vitals on mobile. For 80.3 percent of the slow websites, the server response time alone is already too high. Also covered: the distribution of AEM generations, the effect of Edge Delivery Services and the trend over 32 months. Full study: AEM Core Web Vitals Benchmark
Magnolia CMS: 64.2 percent pass the Core Web Vitals
Magnolia does not appear in any public technology statistics. This study identifies 172 installations in the DACH region and measures their values: 64.2 percent of the websites with real-user data pass, and the median server response time is 668 milliseconds. Full study: Magnolia CMS Core Web Vitals Benchmark
Core Web Vitals Benchmark: all studies at a glance, with method and data sets. Fundamentals under Core Web Vitals, the process under Website Performance Optimization.
Every analysis starts with the same distinction: if the delay occurs before the first byte, it is a task for operations and caching. If it occurs afterwards, it is a task for the frontend. Without an answer to this question, the effort is very likely to go into the wrong side.
Three services for measurable performance on AEM and Magnolia platforms
Each service has a clearly defined scope: the Core Web Vitals, the three metrics Google uses to assess user experience, with a target value per page type and a sign-off that measures every release against it.
Performance Assessment
Entry point, two to three weeksYour platform is measured the way Google measures it: per page type and market, with real-user data from the Chrome User Experience Report (CrUX) and, where available, from your real user monitoring. You receive the root causes, an inventory of all third-party scripts with their cost in milliseconds, a draft performance budget and a prioritized list of measures with acceptance criteria. The results are presented to your team and your agency.
Scope: one platform, one market and up to four page types. Additional markets and brands can be added.
Ongoing Performance Control
Ongoing responsibility, minimum term of three monthsAgreed target values, a monthly measurement against them, prioritized tickets and sign-off of every release. Your team is responsible for implementation; the check of its effect is independent of it.
- Monthly report against agreed target values for Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS)
- Tasks as tickets in your sprints, checks in the test environment
- Sign-off of every release against the performance budget
- Approval process for new scripts, tags and consent banner changes
- Escalation channel with a fixed response time for regressions
Three tiers by platform scope (table below)
Performance Sign-off in Migration Projects
Project, milestones, six to eighteen monthsWhether the move is to Edge Delivery Services, to Magnolia DX Cloud or to a headless frontend: the target values are set before the first sprint, and every milestone is signed off against real-user data, not against a lab score. Your implementation partner is responsible for the architecture; the acceptance criteria come from outside. After go-live, the engagement moves into ongoing control.
Scope by project and milestones
| Service | Basic | most frequently chosenTeam | Platform |
|---|---|---|---|
| Suitable for | one website or portal, one market | up to three markets or brands, one development team | multiple sites, brands and teams |
| Page types measured | up to three | up to eight | by agreement, no upper limit |
| Monthly report against target values | yes | yes | yes |
| Release sign-off | up to two per month | all | all, including hotfixes |
| Tasks as tickets | backlog per quarter | continuously in your sprints | continuously, with participation in refinements |
| Checks in the test environment | no | yes | yes |
| Approval of new scripts and tags | no | yes | yes, with a process for marketing and agency |
| Pull request reviews | no | no | yes, for performance-related tasks |
| Office hours for your team | no | every two weeks | weekly |
| Response time for a reported regression, with an initial assessment of the cause | three business days | two business days | one business day |
| Review of target values | annually | every six months | quarterly |
All tiers: minimum term of three months, then cancelable monthly at the end of the month. Switching between tiers is possible at the end of a month if the scope of the platform changes.
Not included: programming, operations and hosting, project management, and contract negotiations with your service providers. Implementation stays with your development team or agency. This separation is the prerequisite for keeping the sign-off against target values independent.
All tiers cover analysis, specification and sign-off against agreed target values, not implementation. A specific measurement result cannot be committed to, because it depends on which tasks your team implements and which content, scripts and campaigns are added during operation. What is committed is the measurement, the prioritization and documented evidence of where your platform stands.
Additional services: performance workshops and handover playbook
These services are available independently of ongoing control and can be booked individually.
Performance workshop for your development team
One day, up to twelve participants: measurement with real-user data, root cause analysis in the waterfall, performance budgets per page type, handling third-party scripts. Tailored to your platform, with examples from your own code.
One day, tailored to your platform
Performance budget workshop with marketing and IT
Half a day: shared target values per page type, approval process for new tags and scripts, escalation path for regressions. The result is a binding agreement between the departments involved.
Half a day with marketing and IT
Handover playbook
Documentation of all target values, measurement methods, check steps and approval rules for your platform, so that your team can take over ongoing control itself. Useful at the end of an engagement or when building an internal role.
Handover to your team
Meetings usually take place by video.
Four steps from the first measurement to ongoing sign-off against target values
Details on measurement, prioritization and sign-off are under Website Performance Optimization.
-
Initial performance analysis, 30 minutes
Before the call, Google's real-user data for your platform and two competitors is already prepared. The call clarifies platform, team, release cadence and whether working together makes sense.
-
Performance Assessment per page type and market
Measurement per page type and market, root cause analysis, and from that a prioritized list of measures with acceptance criteria. This gives your team and your agency a working basis for the next sprint.
-
Implementation by your development team or agency
Development stays with your team or agency. Questions are answered on an ongoing basis, and implemented tickets are checked in the test environment before they go live.
-
Sign-off of every release against the target values
Every release is signed off against the performance budget. The monthly report shows whether the target values are being met and what comes next.
Adobe Experience Manager Performance (AEM): Core Web Vitals from 6.5 to Edge Delivery Services
AEM 6.5 on Adobe Managed Services: end of support August 31, 2026AEM 6.5 on-premises: February 2027
In 2026 and 2027, many AEM platforms face a move to the cloud version or to Edge Delivery Services, Adobe's new delivery layer, which is marketed with a Lighthouse score of 100. That score is produced in the lab. Whether the values hold for real users is decided by the cache layer in front of AEM (Dispatcher), the bundled scripts and styles of the pages (client libraries), image delivery, tags and personalization (Adobe Target), and cookie consent. That is exactly where the target values per page type and market are set, and exactly where sign-off happens, regardless of which frontend your partner builds. For migrations, the target values are in place before the first block, and every migrated area is checked individually, so that a Lighthouse 100 in staging, the test environment before go-live, is matched by passing real-user values in production.
Magnolia CMS Performance: Core Web Vitals from DX Core to DX Cloud
Magnolia 6.4 as the current product lineDX Core self-hosted, DX Cloud as platform as a service
Magnolia is a Java platform with separate author and public instances; its content lives in a content repository and is published from the author side. Such a platform is fast when the cache in front of the public instances serves the requests and the light module templates do not query the repository again on every request. Everything else happens afterwards in the browser: in the delivered scripts and styles, in personalization and segmentation, in tags and in cookie consent. That is exactly where the target values per page type and market are set, and exactly where sign-off happens, whether the output comes from Magnolia in the classic way or goes to a custom frontend through the delivery APIs.
Measurable results: four metrics from client projects
Main content load time (LCP)
29.0 s to3.0 s
The main content loads instead of being blocked by video and scripts. The 2.5-second threshold is now within reach.
Layout stability (CLS)
0.46 to0.07
From a "poor" rating to "good". Misclicks caused by shifting layouts no longer occur.
HTTP requests
~250 to~20
External embeds reduced from around 170 to two, stylesheets merged from around 60 into one.
Data transferred
7.5 MB to1.0 MB
Uncompressed video, the main driver, replaced; unused CSS and JavaScript removed.
Values from anonymized client projects, including automotive and insurance, measured in the lab before and after implementation by the client teams. Real-user data from ongoing projects follows in the initial analysis. References are subject to confidentiality agreements and are therefore not named.
Christian Schreiber: Web Performance Consultant for enterprise platforms in the DACH region
Christian Schreiber has worked in web development for more than 20 years, with a background in business informatics. For more than ten of those years, his work has focused on the load time of websites and portals. The first large platforms ran on Adobe Experience Manager, for a German car manufacturer, embedded in the client's Scrum team on the agency side. For several years, he has been responsible for the performance of a Magnolia platform for an insurance group.
Implementation lies with the development teams who build your platform every day and know it best. His role is the other half of the job: setting target values, measuring against them and signing off. Measurement uses Google's real-user data, because that is exactly what Google and your visitors judge by.
He works exclusively with companies in Germany, Austria and Switzerland, in German, remotely and on site when needed.
Christian Schreiber: background, studies and tools, profile on LinkedIn and profile on XING
Frequently asked questions about web performance consulting, collaboration and engagement
Our agency already takes care of performance. Why bring in an external consultant?
The agency implements what it has been commissioned to do and measures its work against those requirements. If they contain no target value for performance, performance cannot be signed off either. An external role sets this target value and signs off releases against it. This is not competition for the agency but a role that is missing on the client side. In most projects, this leads to close cooperation with the agency, because clear acceptance criteria make its work easier too.
Adobe markets Edge Delivery Services with a Lighthouse score of 100. Is that not enough?
The score comes from a simulation without a tag manager, cookie consent, personalization or real devices. Google, by contrast, evaluates real user experiences over the last 28 days. Edge Delivery is a good starting point. Whether the values hold in production depends on what marketing and third parties add afterwards.
We have Lighthouse in our CI pipeline. Do we need more?
Lighthouse in the pipeline prevents major outliers in the code. It does not see tags from the tag manager, consent logic, A/B tests or differences between markets. Ongoing control adds real-user data, performance budgets per page type and an approval step for everything that reaches the page from outside the repository.
Who implements the measures?
Implementation is usually done by your development team or agency. The deliverables are tickets with acceptance criteria and answers to questions, followed by sign-off against the agreed target values. Separating specification from implementation is the prerequisite for keeping the sign-off against target values independent.
Do you commit to green Core Web Vitals for our platform?
No, and nobody who is not responsible for implementation should. The values result from your code, your content, your campaigns and your service providers' scripts. What is committed is the service that comes from outside: measurement based on real-user data, target values per page type, prioritized tasks with acceptance criteria, sign-off of every release against these target values, and monthly evidence of where your platform stands. A commitment to a measurement result would be a commitment about your team's work.
How does this fit into our sprints?
The collaboration follows your cadence: participation in refinements as needed, the meetings in which the team clarifies tasks for the next sprint, tickets in your system, for example Jira or Azure DevOps, and checks in the test environment. On your side, this requires a fixed point of contact and access to the test environment, real user monitoring and Search Console.
Search Console reports poor Core Web Vitals. What is the first step?
The report names affected URL groups, not the cause. The first step is to split the main content load time into server response time, resource load time and render delay, separated by page type and device. Only then is it clear whether the cause lies in delivery, in the frontend or in the scripts from the tag manager and consent banner. This breakdown is the subject of the Performance Assessment.
When do Core Web Vitals improvements become visible in Google's data?
Google calculates the values from a rolling 28-day window. A measure that goes live today is fully visible after four weeks at the earliest. How much the values improve depends on how many of the prioritized tasks the team implements and how much the platform changes during operation. In projects with a working sprint cadence, the first effects are usually measurable after two to three releases. After that, the task is to maintain the level reached.
How do Core Web Vitals affect the conversion rate?
Reliable figures come from A/B tests: 8 percent more sales after a 31 percent reduction in main content load time, and 8.4 percent higher retail conversion per 0.1 seconds faster mobile load time. Both figures are listed with their sources in the box at the top of the page. The economic effect arises before ranking, in user abandonment behavior. As a ranking signal, the Core Web Vitals are one among many.
How does web performance consulting differ from page speed optimization?
Page speed optimization usually means one-off technical measures on a website, often measured by the Google PageSpeed Insights score. Web performance consulting starts earlier and ends later: target values for real users, priorities for the development team, sign-off of every release and a process that keeps the values from getting worse again. The score is a diagnostic tool, not a goal, because Google does not use it for ranking.
Where do Core Web Vitals most often fail on enterprise platforms?
In three places, almost always in this order: at the cache layer in front of delivery, when parameters, sessions or personalized areas bypass it; at the third-party scripts from the tag manager and consent banner that weigh on Interaction to Next Paint; and on pages where teasers, assets and personalized components load later without reserved dimensions. What this means for each system is described on the pages on AEM performance and Magnolia CMS performance.
How is the scope of the collaboration defined?
Each service has a scope defined in writing. It depends on the number of sites and markets, the release cadence and the number of teams. After the free initial analysis, you receive a written proposal with scope and process. Ongoing control has a minimum term of three months.
How does the engagement process work?
The service description and the draft contract are available before the first meeting with your procurement team, as is the distinction from temporary agency work. The engagement is with a self-employed consultant on invoice, usually under a service agreement or framework agreement. Your side provides budget approval and a fixed point of contact who organizes access to the test environment, real user monitoring and Search Console.
Is engaging a single consultant a risk under the German Temporary Employment Act (AÜG)?
The service is described in terms of results: defined deliverables, no attendance obligation, no duty to follow instructions, no integration into your organization. Your team is responsible for implementation; specification and sign-off against the agreed target values come from outside. This separation is also the feature that distinguishes a service contract from temporary agency work and false self-employment.
Do you also support CMSs other than AEM and Magnolia?
The focus is on Adobe Experience Manager and Magnolia, because that is where the longest projects and the most complex release processes are. For other systems of enterprise size, the initial analysis clarifies the individual case. For smaller websites, a provider that also handles implementation is the better choice.
Free initial performance analysis: 30 minutes and the values of your platform
In any case, you receive:
- Google's real-user data for your platform on load time, response time and layout stability, for the homepage and your most important page type
- a comparison with two competitors of your choice
- an initial assessment of where the biggest bottleneck lies and the likely order of magnitude of the effort for your team
- a clear statement on whether working together makes sense
- Phone
- +49 162 7506034
- mail@ch-schreiber.net
- Region
- Germany, Austria, Switzerland