Making Your Website Faster and Safer with Cloudflare

Blog

Web Design Tips / Blog 195 Views

Cloudflare is an industry leader in the content-delivery space, reducing load and speeding up millions of websites.

What is peculiar about this provider is that it didn’t start as speed-up/performance tool, but was instead born from Project Honeypot, which was conceived as a spam and hacking protection service. To this day, this is one of Cloudflare’s major selling points: DDoS detection and protection. Their algorithms take note of visitors’ IP addresses, payloads, resources requested, and request frequency to detect malicious visitors.

Because it sits as a proxy between websites and all incoming traffic, Cloudflare is able to reduce strain on servers significantly, so much so that DDoS attacks won’t even reach the origin websites, as explained in this introduction. Cloudflare also provides the Always Online option, which caches a version of the user’s website and serves a limited version of it in case of origin server outage — when the original website returns 5xx or 4xx errors. It also features a full-fledged page cache.

These features can be a huge advantage: they can salvage a struggling web server under heavy load, and in case of server errors, can give some breathing room to developers to figure things out.

Always Online feature

It’s also available free. There are premium tiers, of course, and there are things (like additional page rules) that require paying, but the scope of Cloudflare’s free tier alone makes it worthwhile to learn its ins and outs.

Comparison benchmarks put Cloudflare somewhere in the middle in regard to speed, but it would be hard to argue that it is the best value CDN on the market.

Setting Up Cloudflare

Setting a site up with Cloudflare is very straightforward. After registering at (cloudflare.com)[http://www.cloudflare.com], we can add a new website. While the system scans for the given domain’s IP and other details, we’re offered an introductory video. Upon completion, we’re given new nameservers to set up with our registrar.

Adding the website to Cloudflare

We need to register these nameservers with our registrar and wait for changes to propagate across the internet. It may take up to 24 hours.

This change means giving all control over our domain to Cloudflare. This also means that, if we have email on this domain (MX records), we need to transfer these records to Cloudflare. If we have any subdomains, they also need to be set up as respective A records in Cloudflare’s dashboard.

All existing domain records set up with our domain registrar or hosting provider need to be moved/copied to Cloudflare.

Some managed hosting providers may simplify/automate this transition process even more.

Cloudflare DNS dashboard

For each of our domain records, we can decide to simply let all the traffic pass through directly to our servers — which means we can set exceptions for certain subdomains — or we can turn off all Cloudflare functionality — for example, while we’re making some changes on the website.

switching CDN on

Once we’ve set the domain up, that’s basically all the work required outside of Cloudflare’s dashboard. There’s nothing more to do on the website itself, or the origin server. All further tuning is done on the Cloudflare website.

Setting up Encryption

An SSL certificate is part of the free plan on Cloudflare. There are four options for SSL setup, and we can find them under the Crypto tab in the dashboard.

  • OFF – this is self-explanatory. All traffic will be redirected to unsecured protocol (http)
  • FLEXIBLE – regardless of the protocol of our server, and whether we have an existing SSL certificate on it or not, Cloudflare will serve all our pages to end-visitors over https. Connections from Cloudflare to the origin server will go over an unsecured connection.
  • FULL – Cloudflare will communicate to your server via https, but won’t validate certificates on the origin. Traffic from Cloudflare to visitors is served over https.
  • FULL STRICT – Cloudflare will require valid (not self-signed) SSL certificates on the origin server. Traffic from Cloudflare to visitors is served over https.

With these settings, we need to make sure the setup is sensible because we have two layers between our end users and our server content, so omissions here can result in a redirect loop, or too many redirections which can end up slowing the website.

Cloudflare also offers the option to buy a custom certificate, and for premium users who require extra safety or care about their market image, it gives the option of uploading custom/premium certificates. This is a part of premium plans.

Securing the Website

This is one area where Cloudflare shines: it gives unprecedented value for free. Across the hosting landscape, DDoS protection is a premium service, and not always provided, even for paying customers.

Cloudflare offers unmetered DDoS protection on the free tier, together with some other, rather sophisticated tools that protect websites on an infrastructure level before malicious traffic even reaches it. It offers rate limiting — throttling of visits
according to user-defined, customizable rules. It offers smart firewall rules, country blocks, browser integrity checks, captcha protections, and more.

Today, when botnets rule the internet and freshly installed websites or servers are sometimes drowned in brute-force break-in attempts within minutes of going online, when spammers automatize web comments, and referrer spam is rampant even without any break-ins, POST attacks and slow attacks utilizing unorthodox means are not rare. This kind of protection can make or break smaller- or medium-sized websites.

There’s also scraping protection, denying certain resources to certain visitor profiles, or obfuscating emails.

Premium tiers offer even more options.

Speed and Performance

By default, with Cloudflare we get caching of static content — JavaScript, fonts, stylesheets, even images. We can set rules for cache expiration. For various CMS systems, there are plugins that can connect to Cloudflare so that we can purge the cache from within our website.

These static resources are “taken over” upon DNS setup by Cloudflare’s infrastructure, and are then served from its network of data centers across the globe, depending on the visitor’s location.

Resources can be cached (or fetched from origin) depending on query strings, or on cache headers set by our origin server. For example, in PHP we could set cache expiration like this:

header('Cache-Control: max-age=3600');

If this isn’t enough, we may need to remove Pragma, Expires and Cache Control headers:

header_remove('Pragma');
header_remove('Expires');
header_remove('Cache-Control');

We can also do this on the server level. In nginx, we would set these rules up in a virtual host block/file:

if ($http_cookie ~* "some-cookie") {
    #removing headers that stop Cloudflare cloudflare from caching
    more_clear_headers 'Pragma';
    more_clear_headers 'Expires';
    more_clear_headers 'Cache-Control';
    add_header Cache-Control "no-cache, no-store, max-age=0";
}

location ~* "(!?.*some-url-path.*)" {
    #removing headers that stop Cloudflare cloudflare from caching
    more_clear_headers 'Pragma';
    more_clear_headers 'Expires';
    more_clear_headers 'Cache-Control';
    add_header Cache-Control "max-age=3600";
}

Apache users would put something like this in their .htaccess file:

<IfModule mod_headers.c>
Header unset Pragma env=LONGCACHE
Header unset Expires env=LONGCACHE
Header set Cache-Control "max-age=3600" env=LONGCACHE
</IfModule>

Obviously, some-cookie and some-url-path above need to be replaced with proper values. These rules are also needed for page caching, mentioned below.

We can choose to minify our CSS, JS and HTML. There’s an option to leverage AMP for outgoing AMP links. There’s also a beta feature Rocket Loader that bundles and serves JS asynchronously, using the browser’s local storage to cache it. Be careful with this, though, because small mistakes in the order of loading of resources can break your website.

Paying customers have the Railgun feature available, which addresses the main pain point of caching systems — dynamic content. It tries to speed up dynamic content delivery from the origin server. It requires software installations on the origin server, and works through compressing of delivered content and “maintaining a single persistent connection for multiple simultaneous requests, eliminating network connection latency“. This is reminiscent of the multiplexing feature of the HTTP/2 protocol — only here, between the origin server and Cloudflare.

There’s also image compression/optimization for the Pro plan, in Polish and Mirage mechanisms. Under the Traffic tab, there are Argo route optimization across Cloudflare’s data centers across the globe, and load-balancing options.

Full-page HTML caching

Full-page caching means caching the whole output of our system — CMS, application, blogging system or anything else.

Under Page Rules, there’s a hidden gem that can transform your Cloudflare account into a full-fledged caching system that can compete with professional solutions like Varnish and — thanks to data centers over the globe — probably outperform it.

Full page caching setup

A Cache level rule set to Cache everything will cache the entire HTML content of the website, along with all other resources.

By ordering these rules, we can achieve complex caching/exclusion solutions and deliver even dynamically generated content with minimum latency. 15x improvements in Time To First Byte (TTFB) are not unheard of.

These rules support wildcards, and need to be ordered by priority:

*some-website.com/static/*
[/static/ subdirectory for static HTML pages]

*some-website.com/*.shtml
[.shtml file extension to signify HTML that is static]

*some-website.com/*?*static=true*
[adding static=true query parameter]

If we combine this rule with a Bypass setting like in the next image, we can set apart sections of our website that need to be cached/omitted from the cache under different conditions — such as admin sections, etc.

Cache bypass

If page cache is working, we should see CF-Cache-Status: HIT among our response headers in the browser’s inspector.

Paying customers have additional options of caching, or bypassing cache depending on a cookie. Here, cookie names can be set with wildcards, and content can also be cached depending on device type.

These rules are more sophisticated, and won’t be needed for every type of website. Free customers have three page rules available, but additional ones can be purchased.

HTTP/2 and server push

Browser inspector shows parallel, asynchronous loading of resources on HTTP/2 protocol

Browser inspector shows parallel, asynchronous loading of resources on HTTP/2 protocol

By default, free and enterprise customers get HTTP/2 turned on — a big improvement over HTTP/1.1 protocol — which includes:

  • multiplexing – multiple resources can be sent within a single connection, in an asynchronous way
  • header compression
  • server push – server predicts requests for resources, and sends them before the browser even requests them.

While recognizing the need to judge the improvements and value of Cloudflare on a per-case basis, it’s fair to say that, in general, the value that Cloudflare provides (particularly its free tier) sits solidly above average.

Conclusion

This article has covered how to use and configure Cloudflare with a website to make it fast, reliable, and DDoS proof. That’s not to say that a CDNed site is impenetrable. In fact, it brings new vulnerabilities to the table.

When human error caused Cloudflare services to suffer in the case of the Swedish Telia network provider in 2016, it was a major issue for European internet. It’s estimated that Cloudflare services are used by 6.2 percent of the world’s top 1 million websites.

In 2016, Telia's misconfigured router allegedly sent most of Europe's traffic to Asia

Infographic from Cloudflare’s post-mortem report of the Telia outage, when a misconfigured router rerouted a big part of European network’s traffic to Asia, resulting in packet losses.

Regardless, we shouldn’t fear CDNs because of incidents like these. They’re few and far in between, and contribute to the construction of a vastly more robust network in the end.

Comments