AEM Performance Checklist

Performance is a really important topic. There are tons of articles out there explaining how critical it is for your site or app to be fast and secure, but let’s distill the things you must do in order to guarantee your AEM project is performant – whether you are building something new or maintaining or enhancing something already in place.

☐ Choose the right architecture

This may be a heavy topic, but it is an important one. Often when we start discussing performance issues, we forget to make sure that the basis is solid. Usually this is a one-time consideration, although it may need to be revisited if you are considering an upgrade where the architecture is a game changer. AEM provides different deployment scenarios under two Micro Kernels: TarMK, MongoMK.

The decision is easy: TarMK is designed for performance while MongoMK is used for scalability, so what are your AEM instances going to be used for? Are you going to have a heavy lift on authors? Publishers? Both? No worries you can find a detailed explanation in the official documentation.

☐ Carefully consider your content structure

There is a lot to cover here, but I will try to keep it short. First of all, let’s define what type of content structure we are talking about; a content structure can be any structure or place where data (which will become information) will be stored. In AEM terms, this could be: Pages, Tags, Experience Fragments (XF), Content Fragments, etc.

One of the most challenging problems when starting something from scratch is deciding the initial structure, and AEM is no exception. If you are going to start a new content structure or you need to try to resolve a major performance issue, consider reviewing the content structure. Try to answer the following questions:

• Is this structure located where it belongs?

• Can this structure escalate horizontally and vertically? (If needed)

• Does this structure have a logical hierarchy?

• Does this structure have an accurate naming convention?

• Is this structure easy to understand for another person or system?

☐ Manage your queries

There is a simple rule when dealing with queries in AEM: avoid them. In most cases, the content structure will help you avoid queries on AEM, but if you must use them, then make sure they are performant – and the only way to make it performant is by making sure any query has at least one index associated with it. There is a full page in the official documentation that covers queries and indexing in detail.

☐ Manage client libraries

Make sure the clientlibs (JS and CSS) are minified and loaded properly. This is usually easy to achieve thanks to the archetype structure defined by Adobe where you have a ui.frontEnd module which will do most of these tasks for you. But also try to avoid having JS or CSS specific to a component; this is a common anti-pattern that we will want to avoid. Remember that adding JS or CSS specific to a component will cause unnecessary extra http requests.

☐ Optimize images

Make sure the images are performant. I have a full post on this topic, but the short version is the following:

• Make sure to lazy load images.

• Make sure they are adaptive (the correct size delivered for the correct screen).

• Make sure they are using the correct size and format.

☐ Build a cache strategy

I can’t emphasize this enough: cache is definitely one of the keys to performance in AEM. Making sure your requests are being cached at different layers of caching is really important. On top of that, try to build a cache strategy where you clearly identify which type of assets may need auto-refresh, which can be cached longer, and so on.

☐ Keep your servers healthy

AEM comes equipped with several tools to monitor your servers health. Some of them will run periodically once configured, and some others will need you to keep an eye on them. Whatever the case, it is very important that you are familiar with them, and take advantage of them. If you are using AMS, these should be handled for you, but you should still make sure that everything is looking good.

☐ Plan for performance tests

If you are an Architect or have some decision-making responsibility, I strongly suggest you pay attention to this item. Most (if not all) of the performance issues can be avoided if we had the vision to plan for them. If you are using Cloud Manager, you must take advantage of the Quality Gate from Production pipeline, which provides a way to verify your site performance prior to each deployment (which is great). Outside of Cloud Manager, planning to execute a performance test regularly is a good practice. You could use something like below to start a performance test plan:

• Define goal: timings, resources, failures and success.

• Define targets. It can be publishers, authors, dispatchers, all.

• Define cadence. Is it driven by a time event? Or for something else?

• Define tools. You could use Adobe Tough day, JMeter, or another tool you’re familiar with.

☐ Define code standards

We are all human and we make mistakes, but a really great way to reduce those errors (at least code-wise) is having standards to follow. Here are some points which can seriously affect your performance:

• Make requests cacheable. As I said above, cache is the key. So, make sure when you use or create an http resource that this can be cached in different cache layers.

• Unclosed sessions. This is a serious thing and usually the root cause of memory leaks. Keep it simple, and use the rule, “If you open it, then you must close it”.

• HTTP timeout. This is another common issue while using http requests on the backend. Make sure there are timeouts to avoid leaving resources open. Ideally you should use a connection pool or other connectivity strategy while dealing with HTTP requests on the backend.

• Async jobs(Sling jobs). Make sure you are familiar with them and use them. Make sure they are not living forever but finished.

• Workflows. Same thing, but just make sure they work as they should. Be sure to periodically review the workflow console to check that there are no stale workflows.

Conclusion

This checklist can improve your performance when working with AEM projects. Once a project is finished (or even under way), it is not an easy or fun task to track down performance issues. But when starting a new project, you can make your life a lot easier by making sure that your contribution to the project is performant from the start. Whichever situation you find yourself in, I hope this checklist can provide you with a good starting point.