People don’t like waiting. They certainly don’t like waiting for web pages to load. This is why we are now using a content delivery network (CDN) that speeds up this process. Here, we look at exactly what this means and how it may affect you.
What is a content delivery network (CDN)?
A CDN is a network of servers set up to deliver web-based content faster, particularly assets like images and pdfs that include a lot of data. Delivery is faster because the servers are distributed geographically so there will always be a server close to the user, wherever they may be. This means their images and pdfs will load quicker.
We are using a CDN from Amazon Web Services (AWS), who also host our website. As well as the CDN, AWS also provide an image manipulation tool that allows us to load different sizes and quality of images to the site depending on what type of device is being used. The system recognises the type of device being used and automatically changes the url. This allows us to introduce responsive imagery across the site, where users on mobile devices will be shown smaller images.
What are the benefits?
The primary benefit of introducing this technology is it will improve the time it takes to load a webpage. In the digital age we live in, users don’t like to wait, especially the undergraduate demographic. A shorter load time improves user experience particularly for international users. For example, if a user in Australia is using our website, they will be loading images from a server local to them as opposed to having to load images from the UK.
Page speed is a factor in how search engines rank results. Over time, this technology will have a positive impact on our search ranking. Users are more prone to leave a slow-loading website. A CDN can reduce this bounce rate and increase the time that users spend on the site. A faster website should mean people stay and stick around for longer.
We will also save space on our web servers. Normally, when providing responsive imagery when an image is uploaded, we would have to save several different size versions of the image. At a minimum, you’d have a small, medium, large and full-size version of each image. Now, we can store the original image and, when it’s used, the system changes the URL to create different sizes of images on the fly. These images are stored by the image manipulation service and are not on our servers, saving us space.
As a CMS user, what do you need to know?
When you use T4, these changes will have no effect on how you upload images and add content. Images should still be uploaded using the specification in our digital guidelines and optimised by passing through TinyJpg.
There is a small trade-off of using the service in terms of waiting initially for images to be published but I believe the benefits far outweigh this. When web content with a new image is added, it needs to be published to our web server, which is synced with AWS. The sync runs multiple times every hour but it means, when publishing a new image, there could be up to 10 minutes before it is synced and therefore available to use. So the content would be live but the image wouldn’t be there. Ten minutes is the very maximum though. In most cases, it will quicker and sometimes it will be synced immediately. Hopefully, this trade-off will only be temporary. We are working with T4 and AWS on a solution.
If you have any questions, please feel free to contact us or book a slot at one of our drop-in sessions which are regularly advertised in Inform. You can do both by emailing firstname.lastname@example.org.