Optimize caching: set images' cache
Hi, I was testing our community website on Google Page Speed and it suggests me to "optimize caching", especially the images' cache expiration date. I'm quite a beginner about web caching so ...
Forum Discussion
Hi Henrik,
First, as a general best practice, make sure that any time you are referencing an image you have uploaded in Studio, you use the static asset URL so that browsers can benefit from our CDN. This is simple using FreeMarker in your custom components and skins.
Normally, optimizing caching involves deciding how you want the browser cache and the CDN cache (which, here, sits in between the browser and the community) to work. Then, like you said, there are a few HTTP response headers that can be used to tweak the specific behavior.
We don't provide a large amount of configuration for those cache-related parameters today, but we try to be smart with the headers. We serve all images and other static assets with "Expires" cache headers. In most cases, this is 24 hours in the future, which is a common best practice for expiration. Uploaded user images and attachments get a shorter time to live (TTL) because they are subject to moderation and privacy settings. If the image is supposed to go away, we want it to go away sooner than later.
We also serve proper "Etag" and "Last-Modified" headers, which can be useful for letting browsers know whether they need to download the latest version of an image or use a cached copy.
Finally, we serve "Cache-Control" headers that advise the CDN to force an update a least every once in a while. For skin images, that is usually around 12 hours. For user-uploaded images, that's 5 minutes (reasoning explained above). This header is to be obeyed by the CDN and generally does not affect the end user experience at all.
Of course, any feedback is always appreciated about specific assets that are a problem for you.
Andrew
Hi Andrew,
Thank you very much for your answer!
I was using the webUI function to get the static links of my assets:
<img src='${webUi.toStaticAssetUrl("/t5/image/serverpage/image-id/9787i2E014C1E5064A9BF")}' />What is the difference with ${asset.get("/html/image.jpg")} and should I replace all my "webUI.toStaticAssetUrl" by "asset.get"?
Should I also use that function in the CSS and in the wrapper (js files in the header) of the community? (It seems to me that all links in the CSS file are already converted to static links, but not in the wrapper.)
Here is an example of what I get with Google Page Speed:
Leverage browser caching
Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network.
Leverage browser caching for the following cacheable resources:
- http://groupecasino.i.lithium.com/html/assets/cvous_background.png (expiration not specified)
- http://www.cvous.com/html/assets/cvous.config.js (expiration not specified)
There is one asset for which I used "webUI.toStaticAssetUrl" and the other one for which I didn't (I will correct that). The link are thus different. But in both cases, the tool says that no expiry date is specified. Any idea on that?
Thanks for the help!
Henrik
Hi Henrik,
With regard to the webUi context object and using it for URLs, that method is deprecated in favor of asset.get. I don't know the precise details on the differences between the two, but asset.get is the new best practice for static asset URLs. I would suggest switching all of your cases over to use the new method whenever you get a chance.
About adjusting URLs to use the CDN -- cache optimization is one way to get better end user performance, and using a CDN is another way. Our CDNs send the same cache headers that we send, so switching to the CDN will not help with the browser cache. But what it will do is reduce load on the community (which has the potential to improve overall experience for all users), and it will also let users download more assets faster, from servers close to their location (edge servers).
As I mentioned, we have different expiry behavior for different types of assets. For this situation where you are seeing an "Expires" header missing, this may be a case where we can improve. I encourage you to submit an idea to our product idea exchange because this would be a good feature enhancement for performance.
