Website Performance Optimization Fixed target values per page type, prioritization by cause, sign-off separate from implementation
Large websites do not become fast by themselves, and without fixed target values they do not stay fast either. This page describes how an optimization works that holds after the first wave: first, what real visitors experience is measured, then the causes are separated, then target values per page type are agreed, and at the end there is a sign-off that takes place independently of the implementation.
Adobe Experience Manager and Magnolia CMSGermany, Austria and Switzerland
Performance optimization starts by separating server and browser
The common sequence is: run a tool, note the score, work through the list. This leads to work on images and scripts while the time is lost elsewhere. In our own study of 4,222 websites, 80.3 percent of the pages that are too slow already have a server response time above the limit. No frontend measure has any effect there.
The work therefore starts with a separation: 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. This one distinction saves several weeks in most projects.
Website performance optimization process in four steps
- Measure what visitors experience. Field data per page type, market and device instead of an average across the domain. Plus an inventory of all third-party scripts with their blocking time in milliseconds.
- Separate by cause. Server response time versus processing in the browser, per page type. The result is a list sorted by impact, not by effort.
- Agree on target values. A performance budget per page type with one owner per value, plus acceptance criteria that fit into a ticket. The wording for this is provided in the AEM Performance Requirements Template and the Magnolia Performance Requirements Template.
- Sign off and hold. A check against the agreed values after every release, limits in the delivery pipeline, approval for new tags.
Target values per page type instead of an average for the domain
An average across a platform hides the places where things get stuck. Home pages carry the most campaign components and therefore the highest risk of layout shifts. Listing pages have the most expensive queries and the most images. Detail pages are usually uncritical and are therefore often cited as proof that the platform is fast. Form flows carry the most interaction and therefore the strictest requirement for response time to input.
Four page types, four target values, four different causes. The same breakdown applies to measurement, otherwise a deterioration cannot be attributed.
A performance-optimized website shows six characteristics in operation
A website is not fast because of a single good measurement but because the causes of slow pages are under control over time. Performance-optimized platforms share six characteristics, regardless of the CMS:
- The server responds from the cache. Response time is below 800 milliseconds, and the cache hit ratio is measured per page type.
- The main content comes first. The largest image in the visible area is loaded with priority, never deferred, and stylesheets do not block the initial render.
- JavaScript has an upper limit per page type. Each page loads only what its components need.
- The layout has reserved space. Images, teasers, personalized components and the consent banner do not shift any content.
- Third parties require approval. New tags only go live after a check against the performance budget.
- Measurement runs continuously in the field. Real user monitoring reports deteriorations within a day, not only after four weeks in Google's data.
Measurement is based on Core Web Vitals from field data
The assessment is based on the Core Web Vitals: Largest Contentful Paint as main content load time, Interaction to Next Paint as response time to input and Cumulative Layout Shift as layout stability. In addition, Time to First Byte serves as a diagnostic value for server response time, because it determines where the work begins.
The source for the assessment is field data, not lab data. Which tools use which source is described under Measuring Core Web Vitals. A score from a lab tool is useful for comparing two versions of the same page, not as an agreed target.
Without fixed rules, the effect wears off after two to three quarters
After the first wave, the obvious items are done and the values improve. Then come campaigns, new tags, a testing tool, a chat, an additional segment in personalization. Each one is justifiable on its own, and taken together, the platform is back where it was after two to three quarters.
Three rules counter this: fixed limits per page type in the delivery pipeline that reject a build; an approval for every new tag and every new service; and real user monitoring that reports a deterioration within 24 hours instead of letting it become visible in Google's data only after four weeks.
Independent consulting: implementation and sign-off kept separate
Implementation stays with your team or your implementation partner. The deliverables are target values, tickets with acceptance criteria, answers to questions and the sign-off. This separation is not a division of labor for convenience but the precondition for the sign-off to remain independent: whoever produces a result does not check it themselves.
The three services, a Performance Assessment, Ongoing Performance Control and Performance Sign-off in Migration Projects, are listed with their scope under Services. For implementation partners, Performance Partner for AEM Agencies and Performance Partner for Magnolia Agencies describe how requirements become commissioned tickets.
CMS performance: specifics of AEM and Magnolia
What needs to be done in a specific system differs. For Adobe Experience Manager, the focus is on the Dispatcher, client libraries, the data layer and Edge Delivery Services, described under Adobe Experience Manager Performance; what Adobe's AEM Sites Optimizer takes over in this context is covered on a separate page. For Magnolia CMS, it is the cache in front of the public instances, light modules and personalization, described under Magnolia CMS Performance. How fast platforms on both systems actually are is shown in the Core Web Vitals Benchmark.
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 we work together.
Frequently asked questions about website performance optimization
What does a Performance Assessment include?
The scope of the Performance Assessment depends on the number of markets and page types; the proposal follows the free initial performance analysis. It includes measurement per page type and market with real user data, an inventory of third-party scripts with their blocking time, the separation by cause in operations and in the frontend, and prioritized tasks with acceptance criteria. The full scope of all services is listed on the home page.
Do you implement the measures yourself?
No. Implementation is carried out by your development team or your implementation partner. The deliverables are target values per page type, tickets with acceptance criteria, answers to questions and the sign-off of the result. Separating specification and implementation is the precondition for the sign-off to remain independent.
How long does it take before anything changes?
The assessment takes two to three weeks. After that, it depends on the release cycle: Google calculates the values from a rolling 28-day window, so a change is fully visible no earlier than four weeks after go-live. First effects are usually measurable after two to three releases.
Why is a one-time optimization not enough?
Because the gain gets used up. Every campaign brings components, every quarter new tags, every release new scripts. Without fixed limits in the delivery pipeline and an approval process for new tags, a platform is back at its starting level after two to three quarters.
What distinguishes this service from an agency?
The agency implements, this service checks. There is no implementation in the same project, no stake in the implementation partner and no commission from a vendor. This keeps the sign-off of a result independent of whoever produced it.