In the last posts I described that you should use caching to increase the performance. But caching works only for static content. Most websites aren’t built on top of static pages but they are highly dynamic, presenting dynamic content which can be different for every user who’s visiting this page.
So, the first and easiest part for caching are images and media elements. Cache them! Every request not hitting your CQ instance is a good request. Youre webservers are faster than your CQ instances and scale much better. So configure the dispatcher to cache all files with the extension “.jpg”, “.png” and “.pdf” (and probably some more depending on your content), always keeping in mind that pages with such an extension must not be have different content depending on request data!
The harder part are the content pages, which may change and must be changed based on request data. Usually you cannot cache them because you don’t want to present a cached personalized page to all users requesting that url. But some optimizations are possible:
- If the number of valid parameter values is rather slow, you can implement them as selectors. Then the page is cachable again, but think of the cache size. Don’t accept any kind of selector.
- Reduce the effort for the system to render your dynamic page. If only a small part is based on previous input, you can split the whole rendering process into 2 parts. First rendering the dynamic parts by CQ;this is then parsed by the SSI module of your webserver which then adds the static parts to the page. Voila, only a small part is rendered directly by CQ, most parts could come out of the dispatcher cache.
I some later posting I will cover these 2 points more thoroughly.