Performance is a critical concern for any web implementation. Users expect high performance, responsive web experiences and will abandon experiences that don’t deliver. Here are some things you need to consider to ensure Adobe solution performance:
- Scaling of Underlying Hardware
- Development Best Practices
- Author Instance Performance
- Publish Instance Performance
- Dispatcher Caching Percentage
- Website Performance
Sizing the Underlying Hardware
Properly sizing and scaling the underlying server instances is a critical initial step to ensuring AEM performance. Perficient recommends consulting with Adobe Managed Services and/or Adobe Launch Foundation Services on properly sizing instances.
In general, the key performance needs are sufficient processing and memory. An important point to consider is AEM will allocate Sling Job pools according to the number of cores on a machine, so for Job-heavy use cases, such as ingesting assets or processing forms, having enough cores is critical.
In addition, since AEM leverages disk storage when using the TarFS, provisioning with IOps-optimized SSDs vs spinning hard drives provides a significant performance improvement. Leveraging S3 for blob storage can provide better cost and resiliency, but at the cost of higher latency.
Beyond individual servers, provisioning reasonable supporting hardware/services such as Load Balancers and a Content Distribution Network (CDN) will ensure the performance and scalability of the overall application.
Development Best Practices
There are a number of development best practices to ensure performance. These include avoiding JCR Queries as much as possible, evaluating OAK Indexes for any queries, ensuring all Resource Resolvers are closed, ensuring as much of the content of the website can be cached, caching API responses and avoiding data structures which create too many child nodes of a single node.
One important interaction a lot of team miss are background and non-web services, such as servlets. All non-trivial services should be monitored for failure and slow responses. Beyond just simple success/failure monitoring, in combination with Commons StopWatch, Sling / Felix Health Checks or Sling Metrics can be used to ensure background processes are executing in a reasonable timeframe.
During the development process, Static Code Analysis tools can help identify memory leaks and best practice compliance. Leveraging performance testing tools such as Tough Day and/or JMeter to performance test every release will ensure that applications should perform well under load.
Note: For customers using Cloud Manager, both Static Code Analysis and performance testing are included in the Cloud Manager deployment process.
AEM Instance Performance
Regular maintenance tasks should be configured such as configuring cleanup tasks such as Version Purging, Workflow Cleanup, Online Compaction and Audit Log cleanup. All production and pre-production environments should be installed in Production-Ready mode.
AEM Author Performance
Author performance is difficult to scale since AEM instances generally can’t scale authors horizontally without creating a separate application stack. Generally speaking, the AEM Author instance should be 2x the specs of the Publisher instances.
It is especially critical to ensure maintenance tasks are run on author as there is more repository churn on the authors than publishers in most cases.
The most common performance issues with Author instances are workflows and blocked activations so make sure the activation queue, job queue, and workflow instances are monitored. Too many of any of these will bring an author instance to a crawl.
Content structure and taxonomy are important considerations for author instances. How pages are assembled, navigated and edited can have a significant effect on author productivity. Effectively leveraging Editable Templates and Experience Fragments can reduce authoring time by separating out common content from page-specific content and thus reducing content entry time.
Publisher Performance
Unlike authors, publishers can be scaled horizontally, the primary limitation here is licensing. Beyond following development and server best practices, to ensure performance in publisher performance, ensure that the Publisher is configured for production and has the Link Checker disabled.
If your application does serve a significant amount of non-cacheable content, such as an intranet or logged in site, Publisher instances should be correspondingly expanded in CPU Cores and Memory to accommodate.
For applications with a significantly large number of users and groups, using external group membership can have a significant performance improvement. This will be the subject of a future blog post.
Dispatcher Performance
The most critical aspect of dispatcher performance is to ensure as much content on the site is cached as possible. Sling Selectors and Suffixes can be used in the place of query strings to create dynamic, but still cachable pages. All query strings not needed for server-side processing (such as campaign ID’s), should be ignored by the dispatcher.
Blocking non-authorized requests will help prevent DDOS attacks as well as reducing server time serving invalid requests.
Balancing the needs of referential content and creating a structure to allow a lower stats level will help ensure that replication does not need to invalidate the entire cache.
From a delivery perspective, the dispatcher web engine should be configured to optimize the delivery of the website to the user’s browser. This includes client-side caching, compression and HTTP/2 support. mod_pagespeed can provide a “quickstart” for optimizing dispatcher performance, though not all options are appropriate for every site.
Performant Personalization
For content that needs to be individualized to the user, leveraging Ajax or Sling Dynamic Includes can allow for creating a personalized experience. For personalizing content via segments, leveraging Adobe Target brings a much more powerful, marketing-friendly tool for personalizing content, so we would recommend using Target over personalizing via segments in AEM.
Though AEM does support an integration to edit Targeted content in AEM, generally we would recommend authoring Targeted content in Target as it offers a richer, nicer experience and requires less client-side code to execute.
Managing Redirects
Managing redirects from the legacy system can also be an issue when there is a large number of legacy redirects. Perficient contributed a tool for managing these redirects to ACS AEM Commons called Redirect Map Manager. With this tool, each migrated page can indicate its legacy URL, marketers can define vanity URLs and lists of redirects can be loaded as flat files.
Website Performance
In the end, what users care about is how fast the website loads. Optimizing the server performance will not overcome a poorly developed HTML page.
A few key performance best practices include combining and minifying CSS and JavaScript via Client Libraries or NPM Builds (Note: HTTP/2 does influence this, however without ensuring two different copies of the stylesheets can be served for HTTP/1.1 vs HTTP/2, this is still a best practice until HTTP/2 support becomes more prevalent) and avoiding document.write or inline styling/scripts.
Optimizing Images
Images represent the largest assets served on most websites, thus resizing images to the smallest workable size represents one of the biggest wins for optimizing website performance.
There are a number of options to resize images in Adobe, including:
- Core Components Adaptive Images – Most useful for out of the box image components
- ACS AEM Commons Named Image Transformations – Useful for retrofitting existing components or sizing images in a non-Adaptive image-based component
- Adobe Dynamic Media – The most powerful option, especially useful for sharing images with multiple Adobe and non-Adobe tools
No matter which option you choose, optimizing image sizes is a must for delivering a performant site.
Optimizing Digital Marketing Tags
The most basic step is optimizing marketing tag delivery via a Tag Management System such as Launch by Adobe. The Tag Management System should deliver all tags and avoid multiple includes. To avoid page flicker, Adobe Target should be integrated into the body or head, as high as possible.
Consider integrating Launch via Asynchronous deployment instead of the default synchronous method.
Teams should careful consider which tags to execute immediately and which to defer to balance the needs of the marketing teams to measure and optimize and the performance needs of users.
Single Page Applications
Single Page Applications such as AngularJS or React are a solution for delivering a “reload-less” experience, however, they come with significant downsides from a Content Management, Digital Marketing and SEO perspective vs traditional server-rendered websites. By developing with ES6 / TypeScript and transpiling to vanilla JavaScript we can develop experiences with similar usability but without the bloat or downsides of Single Page Applications.
To determine whether or not to implement an application in a SPA, consider what kind of application you are creating. Is this a content application or a functional application? Functional applications such as profile editors, social interactions and customer portals fit well into the SPA model, but managing a content-heavy site such as a marketing website, documentation portal or intranet proves cumbersome with a SPA.
Where to Start
With all of these potential ideas on how to ensure website performance with Adobe, where should you start? It’s best to start front to back. Use a performance testing tool such as Google Page Speed Insights or GTMetrics to identify issues directly impacting users and work backward through the stack identifying and optimizing issues.
Additional Reading
- https://helpx.adobe.com/experience-manager/kb/performance-tuning-tips.html
- https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/configuring-performance.html
- https://blogs.perficient.com/tag/mastering-the-aem-dispatcher/
- https://helpx.adobe.com/experience-manager/kb/optimizing-the-dispatcher-cache.html
Acknowledgments
Thanks to the following people for contributing ideas and feedback for this post:
