< Return to Feed
Kayla Amaral - 03.13.2017

Cracking the Code on Adobe Experience Manager’s Thumbnail Servlet. Literally.

 

Cracking the Code on Adobe Experience Manager’s Thumbnail Servlet. Literally.

 

The website launch wasn’t going so well. After months of development, the custom website our developers had built in Adobe Experience Manager (AEM) was ready to launch. But as the DNS swing took place and our AEM team waited for the DNS to flush on their workstations, the site that had loaded in milliseconds the day before was now taking 5+ seconds to load. A Google PageSpeed test confirmed the team’s fear—custom components built into the site were pulling large images uploaded by the content authors.

 

One of the top selling points for using AEM for our client’s website was based on the CMS’s image rendition feature. The ability to upload and use any size image gave our Creative team the freedom to use the highest and best visual assets available. But what had been presented as an asset was proving to have serious and unexpected limitations.

 

Our initial attempt at resolution was to implement image specifications and ask for the content authors to follow these new image guidelines. However, our Creative team rightfully pointed out that the CMS had been selected, in part, based on the allure of its auto-rendition feature and should make good on that promise to accommodate images of any size.

 

Next, we created thumbnail renditions using AEM’s Digital Asset Management (DAM) update asset workflow and implemented source sets. But this resulted in broken images if the rendition wasn’t created.

 

In addition, while thumbnails of a smaller, standardized size produced acceptable image quality, slow load times continued. We created web renditions via the DAM Update Asset workflow only to discover that the AEM’s out-of-the-box thumbnail servlet is hard-coded to pull thumbnails, i.e., cq5.thumb.

 

After discussions with Adobe, three options were suggested for handling image renditions with custom components:

 

  1. Downsize the image asset outside of AEM, using Image Magic, a free third-party tool. However, we had already taken this approach with the results deemed unacceptable by the client.
  2. Call the direct rendition using path, another approach we had already tried but which presented its own problems.
  3. Create our own custom servlet code to overcome AEM’s limitation of its own servlet which only uses .thumb.

 

One user story and lots of testing later, our client’s site is now live thanks to a custom servlet developed by Sagepath’s developers.

Click Here to See the Code

The takeaway is that Adobe doesn’t yet offer a good solution for using web renditions with custom components. So if you’re producing a site under these conditions, bet ready to code a custom servlet.