Thus, I have listed down a few points which I found one should definitely try and make their site performant than now it is, if by not much.
- URL handling: Vanity URL is one of the best feature introduced with WCS 11g8 which has altogether removed the usage of assemblers (which used to be in old product of WCS erstwhile FatWire). Should you have vanity urls for blobs as they are simply images / docs and they don't need any urls as they are simply displayed directly. But there may a case wherein a customer might want to share image / document url to other platforms which should not change with time as people may bookmark or share it further across other channels. This is where it is important to have vanity url for blobs as well. I propose the following solution which has worked for our clients until now: In order to have vanity url for blob, you simply select blobs on vanity url screen and check "Is downloadable?" as needed. Most important thing is url pattern which one needs to configure which we learnt from our past mistakes and works well be it clustered or non-clustered infrastructure. URL pattern like following works quite well: /[may be locale value for e.g. en]/[asset id of the asset]/[blobname].[extension] for e.g. /en/1234/image1.png Having asset id within the URL itself is perfect for situation wherein RSS or WCS are clustered. Furthermore, you can add more blob header information as well with Vanity URL.
- Rendering / displaying images: I particularly said images not documents because WCS based websites are mostly text and images. For text, there are few compression techniques and they work well (check white space compression). For images, it is quite difficult to display the appropriate image which fits the section of a website. From my past experience, usually content editors use the same image across small box items to sliders to search boxes, etc. which becomes bottleneck for rendering the page fast as the browser may take time to download & serve the images to an end user. If you really have websites with very big images in size and dimension that can really hurt user experience if not performant enough. So how to tackle ? These are few ways which worked for us:
- Use CDN (Content Delivery Network): This is known to many and is used to make their website faster for better user experience but does comes at a cost of configuration and maintenance.
- Cache your images to higher TTL: This requires quite good amount of time to figure out the optimal time for images to cache and that can be still be not good enough. Configuration within WCS and RSS is another challenge.
- Don't allow users to upload images higher than certain size. This can be achieved using WCS and already described in the developer guide (check Uploader). But still some images do need to be higher in dimension and customer may not have the most optimized image.
- Use webserver to serve images: As it seems easier to say, it is little bit harder to make it work properly as challenge comes on how to handle during publishing and not to mention adding / updating / deleting images can also be quite tricky to setup. May be there are already such plugins available but still requires quite an effort to make it work smoothly.
- Compress your images using free / paid services as mentioned by Google. This is what we have used for one of the clients where they have nearly thousands of images to display on their websites and thus, optimal compressed images are displayed. Clients uploads an image, which on saving asset calls the external API which provides compressed and good quality of image, store in an attribute and use the compressed image for displaying on website.
- Use OOTB ImageOptimizationFilter flex filter: This one is my favorite as this particular flex filter generates good quality of optimized and resized images for devices configured within WCS. But as I have known from past that many customers don't want to contribute content for Touch, Desktop and NonTouch devices within WCS as that task is very tedious and repeatative, this filter may not be that helpful. For those who are already use devices, they can refer on how to use this flex filter and optimize images. For those who don't use devices or mobility feature much, still can use this filter in following way: Just follow the steps mentioned in the above link and create renditions of the images as needed which would generate 2 images: [your image name]_Touch and [your image anem]_NonTouch. As a customer or development team, you should already know which sizes of images would fit in which sections. You can display accordingly either Touch or NonTouch image and thus, can save quite a lot of bandwidth for your end users. This particularly filter is quite useful which not only compresses image size but also provides 2 renditions of images with good quality. If you need more renditions, then you can definitely write your own custom implementation of ImageOptimizationFilter as mentioned in the guide. This flex filter is optimized within 12c and works quite well.
- Use webserver to configure default expiration for images of about certain optimal value like 7 days, 1 month or even 1 year. This is subject to client's wishes and needs to be catered accordingly.
- Last but not least, using combination of above is certainly going to achieve a faster and good experience for end users.
There may be other tricks as well to handle image compression and optimization but I guess this should provide some hints on tackling performance related to images.
Need help? Click here.
