{"id":4250079,"date":"2019-04-30T13:06:27","date_gmt":"2019-04-30T13:06:27","guid":{"rendered":"https:\/\/www.deptagency.com\/insight\/optimising-cloudfront-from-a-sitecore-perspective\/"},"modified":"2019-04-30T13:06:27","modified_gmt":"2019-04-30T13:06:27","slug":"optimising-cloudfront-from-a-sitecore-perspective","status":"publish","type":"article","link":"https:\/\/www.deptagency.com\/en-nl\/insight\/optimising-cloudfront-from-a-sitecore-perspective\/","title":{"rendered":"Optimising Cloudfront from a Sitecore perspective"},"content":{"rendered":"
\n\t\n\t<\/svg>\n\t\t\t\n\t\t\tBack to all articles\t\t<\/span>\n\t\n<\/a>\n\t\tOptimising Cloudfront from a Sitecore perspective\t<\/h1>\n\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t<\/picture>\n\t\n\t<\/div>
\n\t\t\t\n\t\n\t
\n\t\tJames Simm\t\t
\n\t\tHead of Engineering\n\t\t\t<\/div>\n<\/div>\n\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\tDate\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t30 April 2019\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t<\/div>\n<\/div>\n\n
\n\t
\n\t\t\n\t\t\t\t\t
\n\t\t\t\t\n\n\t\tRecently we\u2019ve been doing an extensive amount of work with both AWS and Sitecore, with site performance and reliability being the main aim. This led us to unravel how we can use CloudFront as a CDN, by offloading as much as we can over to it. As such, I thought I\u2019d write up a few of the tips I picked up along the way, relating not just to Sitecore, but CloudFrot in general.\t<\/h2>\n\n\n\t\tGenerally people use CloudFront for serving images, other static assets, or even to serve a whole site through the platform. It allows for edge caching (which means geo-located servers), resulting in a quick and high-speed website.\t<\/p>\n\n\n\t\tHave a test environment that matches your production environment\t<\/h2>\n\n\n\t\tThis is probably the golden rule when implementing systems like these, since you don\u2019t want to be trying out new settings on a production instance. I\u2019ve seen many implementations where people try to spend a bit less by not having the infrastructure of the test environments match that of production. While they don\u2019t need to be of the same scale, the setup should be similar. This carries over to CloudFront, where a test distribution is probably the only way to reliably test new CloudFront behaviour settings, as well as new functionality in your webapp coexisting with CloudFront.\t<\/p>\n\n\n\t\tGet familiar with the cache statistics page\t<\/h2>\n\n\n\t\tThe cache statistics page should be your first port of call when testing or debugging your CloudFront distribution, as it provides very useful, detailed statistics on how well your distribution is working. With time, you want to be aiming for a hitrate above 99% for your assets to maximise the efficiency of the cache. Tweaking the behaviour settings for your distribution to achieve this can be somewhat of a trial and error process, since every webapp has different requirements. As a starting point, I\u2019d recommend leaning towards anything that improves caching, then adapting based on testing your implementation.\t<\/p>\n\n\n\t\tHere are some example settings from one of our projects, however you will need to tweak things based on your specific needs.\t<\/p>\n\n\n\t\tAnother neat little trick you can do, is to set the header in the Chrome dev tools to show on network requests, so you can get a nice overview of your assets and what is and isn\u2019t hitting CloudFront.\t<\/p>\n\n\n\t\tThis is done by simply right clicking on the column names in the network tab, selecting \u201cManage Header Columns\u2026\u201d and adding a custom column called \u201cX-Cache\u201d which is the header that CloudFront returns.\t<\/p>\n\n\n\t\tOnce you\u2019ve done this you should be able to see which assets are and are not hitting CloudFront. Bear in mind that this is just from your machine, and should be taken with a pinch of salt; people in other parts of the world, or with different setups or request headers could have a totally different experience.\t<\/p>\n\n\n\t\tOffload everything you can\t<\/h2>\n\n\n\t\tThis one might be obvious, but you want to be offloading everything you can to the CDN, not just images. If you can offload scripts, styles and fonts, then you should. You can even take it further and offload api endpoints if the data is unlikely to change. One setting we use, is to cache based on query string; this lets us bust the cache for new deployments of the site, as we have version query strings for our static assets. Caching based on query string also means that your images can pass through height and width parameters, or any custom image parameters you might have, caching the end result flawlessly.\t<\/p>\n\n\n\t\tA common gotcha for fonts is CORS, as since you most likely will be serving your static assets from another domain, CORS will block them without the correct configuration. We got around this by allowing for GET, HEAD and OPTIONS methods, as well as passing through the \u201cAccess-Control-Allow-Origin\u201d header. Bear in mind this will also require a bit of work on your webapp, to pass through the relevant header.\u00a0More information on this can be found in this stack overflow post\u00a0here.<\/a>\t<\/p>\n\n\n\t\tSitecore\u00a0 has its own HTML caching functionality and you should lean on this heavily for pages instead of using CloudFront. Otherwise functionality such as A\/B testing, personalisation and even publishing won\u2019t work correctly. But aside from this, practically everything is fair game.\t<\/p>\n\n\n\t\tThe Sitecore changes\t<\/h2>\n\n\n\t\tThe Sitecore configuration changes are actually relatively simple, although if you\u2019re using any computed fields or link generation outside of the standard out-of-the-box functionality, it can get a little complicated. Assuming you\u2019re just looking at the default, the main point of integration is that of the MediaProvider. You\u2019ll need a configuration like the following:\t<\/p>\n\n\n\t\tThen that provider should extend the default MediaProvider and override GetMediaUrl with your own implementation. This is so you can make sure that modifications and new versions of the image pull through. There\u2019s a nice implementation from the incredibly knowledgeable JammyKam\u00a0here<\/a>, as well as a lot of really useful tips for CloudFront\u2019s Azure counterpart.\t<\/p>\n\n\n\t\tAn alternative approach, would be to hash the image and use that as a query string, but when looking into this bear in mind this is different from the current hash that Sitecore puts in the request query string (which is described\u00a0here<\/a>) and worth thinking about if you have any issues with resizing.\t<\/p>\n\n\n\t\tWith this in place, you should see your images in preview using the new CDN url you\u2019ve specified, though note that in the example above, the role definition requires the role of content delivery, which I\u2019d recommend to make sure there isn\u2019t any crazy experience editor issues.\t<\/p>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\n\t\n\t