Do you have a successful Episerver site, but want to expand its reach into new markets or enable it to encompass multiple regions? Paul Gruffydd, Technical Director at AmazeRealise and one of Episerver’s ‘Most Valued Professionals’, has some suggestions to make.
When going global, it’s easy to get caught up in the practicalities of localisation while neglecting the basics. High on the list of priorities should be ensuring the site performs consistently well in all of the countries and regions it serves (not just where the main stakeholders live).
This isn’t as straightforward as it seems, so what are the options available?
Location location location
For most Episerver solutions, all localised versions of a given site will be served from the same instance of the CMS, so choose a central location to host your site based on where the majority of your traffic comes from. You can take a scientific approach by estimating the percentage of traffic that would be best served by each of the regions in question and approximating the latency between those regions to calculate the optimal location however, the answer is often fairly evident.
Use caching effectively
To make the most of your site you should always consider how best to cache your content. One of the main challenges we face when delivering a site globally is network latency. The closer we can get to the browser we’re serving files to, the better. And you don’t get much closer than the user’s machine itself. The more we cache on the user’s machine, the less outbound requests we’re making and the lower the impact of the network latency.
Implement a Content Delivery Network (CDN)
If I could recommend just one of these techniques, it would be this one. Seriously, just do it. Even if you’re just serving a single region, a CDN can dramatically improve a site’s performance (if you use it correctly). A CDN builds on the browser caching techniques described above by caching your content at edge locations closer to your end users. This means that you get a double-whammy performance boost in that there’s lower latency between the user and the content and, just as importantly, your server isn’t having to handle requests for content cached in the CDN, freeing up resources to process requests which can’t be cached.
In the not-so-distant past, implementing a CDN was impractically expensive for all bar the largest companies but nowadays you can implement a CDN for almost nothing on the likes of Azure, AWS CloudFront and CloudFlare (in fact, you get CloudFlare as part of an Episerver DXC service subscription). In some cases, these CDNs go beyond the basic functionality of a traditional CDN, adding DDoS protection, Web Application Firewall and image optimisation capabilities, making your site even faster and more resilient.
While there are many benefits to running your language sites from a single instance of the CMS, sometimes it makes more sense to set up an entirely separate instance for a given location on infrastructure closer to your end users. This approach works well in situations where your country sites are entirely managed by local teams and don’t necessarily have to share a common structure. It can also be useful for overcoming technical hurdles such as serving content targeted to China without needing to rely on extensive caching on local CDNs. This approach can be augmented where necessary by building content synchronisation between instances to allow easier sharing and interlinking of content.
What if you’ve got a blank canvas? One option would be to look at decoupling the CMS from the website so that the CMS sits in a single location and is simply used as a data source with the rendering and serving of the content happening independently in locations closer to your end users. It’s an approach we’ve advocated at AmazeRealise for many years but requires careful consideration to be implemented effectively.
The release of the Episerver Content delivery API has opened up various options in terms of how we consume content produced in the CMS. By coupling this with the latest updates to Episerver’s on-page editing capabilities, you can take a headless build approach without having to sacrifice the editing experience.
Although it’s not going to happen overnight, there are some interesting developments in this area. Many of Episerver’s newer products and features have been built as independent hosted services and we’re already starting to see that approach extending beyond new features into the core of the CMS and Commerce. Adopting this kind of distributed approach reduces the risk from a failure of a single region and paves the way for the next generation of distributed web applications making it a win-win-win for Episerver, partners and customers.
Before that happens though, try some of the tricks above and start bringing the world to your doorstep.
If you’d like to tap into the knowledge we’ve developed as a Gold Partner of Episerver (previously Premium Partner), get in touch using the form below.