Your website needs to be fast and efficient; fast for your end users to ensure they have a good experience and don’t leave prematurely, fast for the admins so they can add content quickly, fast for Google so it rewards you with a decent quality score and therefore improved SEO ranking. OK, agreed, a fast website is a good thing all round, but there are a few major areas that may get in the way of you achieving this.
Areas that can impact on your ability to deliver a fast website:
- The ‘Application' – the efficiency and quality of your website code and database
- Hosting – the physical or cloud server(s), the amount of RAM, speed of discs, effectiveness of caching layers, ability to scale up to meet demand etc.
- The Internet – The global network that your server is connected to. Generally, something that’s out of your control, hint: that’s where a CDN (Content Delivery/Distribution Network) can help out.
Adding an extra layer of performance and protection to your website
We were recently preparing for the first real test of a newly developed drupal website and needed to be absolutely certain we had a rock-solid platform in place and had mitigated any issues that might occur. The test being one of BAFTA's main events of the year, the televised Film Awards, that generates global interest and high volumes of traffic over a short period of time. We had an idea of what to expect, based on the stats we had from previous years' events, and had experience of supporting a legacy Drupal site that we’d taken over management of. We had predictable times and expected levels and locations of traffic for which to prepare for.
We had developed the new website with optimisation and scaling in mind; load-balanced cloud servers, separate database servers, server-side caching considered with Varnish and Memecache, as well as PHP code and database queries benchmarked and optimised. We had thoroughly load-tested various scenarios, traffic patterns and anticipated user journeys way beyond the expected levels.
So, we had pretty much done everything we reasonably could to address the Drupal website (the Application) and had also scaled-up the cloud hosting resources allowing for extra capacity. That just left ’The Internet’ as a potential weak point! With a website hosted in a single location, no matter how robust the application and servers are, there’s a risk the internet connections and network leading to your servers will become a ‘bottleneck’. Time to look at a CDN.
“A content delivery network or content distribution network (CDN) is a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance."
There are lots of CDN services available to consider. To get to the point, the promised speed and simplicity of setup, a number of recommendations from respected peers, reasonable costs (yes, even a free tier) with no tie-in contract led us to investigate Cloudflare. We were primarily interested in a CDN for the performance benefits but Cloudflare also offered a number of other features that were appealing too.
What does Cloudflare promise?
"CloudFlare protects and accelerates any website online. Once your website is a part of the CloudFlare community, its web traffic is routed through our intelligent global network. We automatically optimize the delivery of your web pages so your visitors get the fastest page load times and best performance. We also block threats and limit abusive bots and crawlers from wasting your bandwidth and server resources. The result: CloudFlare-powered websites see a significant improvement in performance and a decrease in spam and other attacks.”
Features Cloudflare offers:
- CDN (Content Delivery/Distribution Network): distributes your website content around the globe placing it closer to your users and speeding up delivery. This also removes the bottleneck from accessing your server reducing your bandwidth and processor useage. Win Win Win.
- Optimizer: Compressing images and files and loading resources efficiently to speed up page loads and deliver a better user experience. Not to mention being looked on favourably by Google – fast loading sites rank better.
- Security: An easily configurable web-based firewall (Web Application Firewall) and threat ‘control panel’. Learning from the Community of Cloudflare sites and intelligently and proactively blocks suspicious visitors. At the higher level paid plans, sophisticated DDoS (Distributed Denial of Service) attack protection. Not to mention simple implementation of secure traffic through their Universal SSL service, if you need it.
- Analytics: Who doesn’t like data. With the Cloudflare analytics you get a dashboard report of genuine visitors, threats, crawlers and bots. It tells you how many requests you’ve had and how many and how much bandwidth Cloudflare has saved you. At certain plan levels the reporting is real-time too.
Installation and setup of Cloudflare (with Drupal).
Cloudflare promises simple setup and implementation of any website, not just Drupal. It does this by routing your website traffic through its network and claims to be able to get you up and running in under 5 minutes. With the free and entry-level plans the service is enabled by turning over your DNS management to Cloudflare. This is a pretty easy step to take with Cloudflare scanning your existing DNS settings at the point of ‘adding your website’ through the control panel to make it nice and easy. The online DNS control panel in Cloudflare is actually really easy to use, however, it’s not always an option to do this, particularly if you’re doing this on behalf of a customer that needs to retain management of their name servers with another service. This was the case with us, so we opted for the CNAME approach...
The CNAME setup method is only available on the higher cost Business ($200 month) and Enterprise plans. In a nutshell a CNAME just masks a particular url to another URL within Cloudflare’s system – in our case we routed www.bafta.org and staging.example.com subdomains through Cloudflare to trial the service before deciding whether or not to implement across the full BAFTA portfolio of sites. If you’re going down the CNAME route then you need a little assistance from Cloudflare’s support team. A few questions back and forth with the, presumably, US timezone based support team turned the 5 minute setup into a 48 hours. It would be useful to have this as self-service through the control panel, but not a big deal.
Configuring your (Drupal) website for Cloudflare
For all websites, not just Drupal, there’s a simple server configuration that is required for Cloudflare to be fully effective and recognise user visits by their original IP address. You can read more about that particular requirement over at Cloudflare but with Drupal this can also be easily implemented through a Cloudflare Drupal module too.
One of the most important things we needed to ensure was that new content, like awards announcements, was being published immediately. To do this we needed to Purge the Cache – basically, how to tell Cloudflare that a page has been updated on the website, ‘purge’ (delete) the old one from the Cloudflare network and to pull the new version in. This is made really easy with a couple of Drupal modules including ‘Cache Expire’ and ‘Cloudflare Purge’. There’s a few configuration options available with the modules so you can specify exactly what constitutes a ‘content update’ triggering a purge.
After turning on the service against a staging version of the website we testing and tweaked a few of the settings, including setting up Page Rules to tell Cloudflare to ignore the CMS admin pages, before enabling on the live website. And that’s pretty much it.
First impressions
Setup was quick and easy and even with the CNAME approach we were up and running in a couple of days.
The performance and security settings were easy to configure using the Cloudflare presets so little in the way of caching and optimisation knowledge is needed. With heavy optimisation and compression enabled we experienced a few issues with JavaScript, mainly causing embedded Instagram content to not display correctly. We customised the performance settings a little and this fixed the problem temporarily – more investigation is required as we’d like to see on-the-fly optimisation of javascript and CSS in place.
Our website was already heavily optimised; image compression, javascript and CSS aggregation and minifying, and also Drupal and Varnish caching in use so some of the potential benefits of Cloudflare were already implemented elsewhere in the technology stack. If you were to implement Cloudflare on a poorly optimised site the performance gains would be more significant and noticeable.
Page loads were extremely responsive through a short but intense peak usage period with thousands or concurrent users, hundreds of thousands of pages served and over 150GB of data served without a hitch.
Approximately 97% of site content was being served through Cloudfare’s infrastructure, massively reducing the demand on the servers. With no charges for bandwidth Cloudflare can protect you from any unexpected charges from your hosting company should your site become very popular very quickly. Cloudflare also identified over 9000 ‘security threats’ from undesirable IP's.
Performance statistics
Do our 'visitors get the fastest page load times and best performance’ through Cloudflare, as promised?
It would have been useful to be able to test the site under severe load, with and without Cloudflare enabled, but our usual test tool of choice, Loader.io, appeared to be blocked by Cloudflare. I suspect this was due to the security layer within Cloudflare and likely flagged as a DDoS attack (which was also reassuring). This is something we intend to look at again to see if load testing is possible.
Drupal 7 site VS Drupal 7 website on ‘regular’ traffic period.
We’ve only had a short period to assess Cloudflare with the same website, same content, same hosting platform – with and without Cloudflare enabled – and these initial stats are based on a small sample through Google Analytics and its definitions of -/+% change.
On the downside, DNS lookups appear to be slower. I’m no DNS expert but guess this is potentially due to the CNAME setup and the extra step needed to route the request to Cloudflare – but we’re talking milliseconds here.
Pretty much everything else looks faster.
Greatest noticeable difference (Across a single hour period)
- Average Domain Lookup Time 0.04 v. 0.03 secs Very slightly slower
- Average Server Connection Time 0.01 v. 1.50 (-99.47%) Much Faster
Across a 6 day comparison period of ‘normal’ traffic
- Average Server Response time 0.5 v. 0.5 (0%) : Same
- Average Page Download Time: 0.19 vs 0.61 sec (-68.43%) Faster
- Average Server Connection Time 0.03 v. 0.06 (-46.55%) Faster
Drupal 7 site vs Proprietary Java CMS on ‘heavy’ traffic period
This year’s BAFTA Film awards were held on the 8th February 2015. We took a few days either side of the date and compared this to the corresponding period from 2014 which was served by a proprietary Java based CMS. It’s worth pointing out that both the CMS and hosting platform have changed so there’s a few variables in play that could effect page load speeds – for example, rich content, volume and quality of images. However, given that over 95% of the traffic on awards night was being handled by Cloudflare, and therefore bypassing Drupal and the new Rackspace Cloud hosting infrastructure, it’s reasonable to suggest that performance gains would have been seen even on the legacy technology stack.
Global traffic (new vs old)
- Across the global traffic, Average Server Response Times at the very highest hourly peak 0.28secs vs 18.12secs (-98.47%) Faster
- Across the global traffic, Average Server Response Times during awards period 0.29secs vs 3.65secs (-92.04%) Faster
- Across the global traffic, Average Page Download Time at the very highest hourly peak 0.27 vs 6.73secs (-95.99%) Faster
- Across the global traffic, Average Page Download Time during awards period 0.26 vs 1.45secs (-82.06%) Faster
Traffic from the Americas (new vs old)
- Across the Americas traffic, Average Server Response Times at the very highest hourly peak 0.19secs vs 22secs (-99.14%) Faster
- Across the Americas traffic, Average Server Response Times during awards period 0.44secs vs 1secs (-55.66%) Faster
- Across the Americas traffic, Average Page Download Time at the very highest hourly peak 0.27 vs 6.73secs (-95.99%) Faster
- Across the Americas traffic, Average Page Download Time during awards period 0.43 vs 1.87secs (-76.82%) Faster
Traffic from Asia (new vs old)
- Across the Asia traffic, Average Server Response Times at the very highest peak 0.13secs vs 37.42secs (-99.64%) Faster
- Across the Asia traffic, Average Server Response Times during awards period 0.51secs vs 1.65secs (-69.27%) Faster
- Across the Asia traffic, Average Page Download Time at the very highest peak 1.92 vs 4.25secs (-54.80%) Faster
- Across the Asia traffic, Average Page Download Time during awards period 0.41 vs 1.51secs (-72.58%) Faster
Summary
- Reduced hosting costs. Fewer server resources required and less bandwidth consumed
- Better performance for a distributed global audience
- Benefits most noticeable with high levels of traffic
- Security enhanced, visibility of threats improved and mitigated
- Minimal changes required to server configuration: plug and play
- One of the most economical ways to add performance and optimisation quickly and cheaply.
A well coded, optimised site can still get benefits from distributing content, placing it closer to your audience, and also get the added benefits of improved security and protection. And with a free option available, high performance CDNs are now available to pretty much anyone.
