Book Image

Instant CloudFlare Starter

By : Jeffrey Dickey
Book Image

Instant CloudFlare Starter

By: Jeffrey Dickey

Overview of this book

Ensuring your website is up, fast, and secure is a difficult yet crucial task. Learning how to protect and safeguard your web presence from malicious attackers whilst also making sure that it is optimized is important for any website administrator. CloudFlare helps you augment your website with additional security, as well as provide the extra bit of speed that will set you apart from the competition."Instant CloudFlare Starter" will show you how to leverage the power of the cloud to ensure that your website is running at its very best. It will also tell you exactly what CloudFlare is doing when you enable various features, and guide you through the entire setup and configuration process.After learning about what CloudFlare actually is, you'll be shown how to fully optimize and secure your own website - using the latest that CloudFlare has to offer.As well as ensuring that your own site is protected with CloudFlare, you'll learn exactly how it actually secures your website from malicious attackers. This is in addition to making sure that you can send and receive emails effectively from your own domain, as well as learning how CloudFlare can enable your site’s static assets to load quickly, with little effort on your part.You'll be guided through the whole optimization process - with additional tips and guidance that help you avoid common mistakes and pitfalls, alongside coverage of optional modules that can additionally improve the speed of your website, add analytics, or even entirely new functionality.With detailed explanations of things to look out for and how CloudFlare can solve your problems on your website, "CloudFlare Starter" will ultimately show you how to optimize and secure your website effectively with minimum hassle.
Table of Contents (7 chapters)

Quick start – configuring CloudFlare features

Now that we have the DNS configured in CloudFlare, we can enable the features that CloudFlare provides.

Step 1 – configuring initial settings

We'll be welcomed with a screen allowing us to set some initial settings.

I suggest setting Performance to CDN only (safest) at first, and Security to Medium. Feel free to read through the various options to decide what you would like. The reason I suggest the lowest level of performance is that you don't yet know how your site will react to CloudFlare. Click on Continue when done.

Step 2 – switching nameservers to CloudFlare

Now we are at the step where we need to change our domain registrar's nameserver settings over to CloudFlare. You'll see a screen similar to the following screenshot:

Now I need to go to my registrar and set the nameservers to and

The nameservers that CloudFlare needs you to use may be different from mine:

And that's it.

You should receive an e-mail when the nameservers are transferred. It might take up to 24 hours, but it usually happens within a couple of minutes.

To check if your site is working, I suggest the Claire plugin for Google Chrome. It will show an icon when you're browsing a CloudFlare site at

It should turn orange if the site has CloudFlare enabled, along with the features that it is using. Here it is for me on

Step 3 – configuring performance settings

Now that we've got CloudFlare up and running, let's take a look at the performance settings and figure out how to tune them best for your site. To get to the performance settings page, go to CloudFlare settings on your CloudFlare dashboard:

Now click on the Performance settings tab to see the different options available to you.

The first option you'll see on this page is the Performance profile setting:

I don't recommend you to use this setting. This will set the individual settings, shown in the following screenshot, to either have a more aggressive caching profile, or a more stable profile.I suggest you read each of the individual settings and set them to what will work for your website instead.

Caching levels

The caching level will adjust the types of static assets that will be cached on your website. Static assets include JavaScript, CSS, and images. There are three levels, basic, aggressive, and simplified:

I think it is a confusing naming convention because simplified is more aggressive than aggressive is. The query string will be completely ignored under simplified, whereas the aggressive mode will store different versions for different query strings.

To find out if your assets use a query string, open up the Resources tab of Developer Tools in Google Chrome and reload your page. If you see any query strings, you will probably want aggressive or simplified caching.

If you can, use simplified caching. I'm not sure exactly how CloudFlare's caching works, but usually when caching has to take query strings into account, it will slow down considerably.

Caching TTL

The caching TTL defines how long the static assets will be cached. If your assets change frequently, you'll want this to be low. This is because users will have old assets until TTL is updated. A high TTL will result in a faster experience for your users.

If your static assets never change, keep this high. You can change filenames, or add a query string (depending on the caching level).

The best approach to this is to have some kind of cache busting strategy. That is out of the scope of this book, as it would require server-level changes. However, proper cache busting allows for unlimited caching TTLs.

Asset minification

Minification is the process of stripping unnecessary content out of JavaScript, CSS, and HTML. In some cases, it can dramatically reduce the file size of the assets, improving performance immensely.

You should not enable this unless you're minifying the assets before they reach CloudFlare. This can potentially cause some issues if the code is written badly. For example, if JavaScript is written without semicolons, sometimes minifying will cause errors in JavaScript. The code would have to be pretty bad for that to happen, so I would still try enabling it unless issues come as a result of it.

You'll need to do a cache purge in order to see the immediate effects of enabling these settings. Cache purge, in simple terms, means clearing the cached copies of assets. So if I clear the cache some time, CloudFlare will have to get original files from the server to serve further page requests.

Rocket Loader

When a web page is loaded, and if there is a JavaScript file, the page will immediately stop rendering and loading until the file is downloaded and run. This damages performance as the page could pipeline much of the loading time:

Rocket Loader instead loads all the JavaScript files asynchronously. This can improve performance by quite a bit. CloudFlare reports a page load time of 12 seconds down to 2 seconds. This also increases the page's window.onload time, improving your Google search ranking.

The downsides of enabling this are that (as of writing this book) it is a beta feature, which may cause issues. It also might cause flickering on page load, depending on how JavaScript-heavy a site is, and how exactly it is structured.

Website preloader

The website preloader is a pro feature that downloads static assets before they are required. It analyzes the most commonly accessed content from a website, and if it is not on the current page, it reaches out to ensure that the content will be available for subsequent requests:

There is little downside with this aside from potentially having your users download unnecessary content. This would happen asynchronously, so it would not significantly hurt performance, but would increase server costs.

How much of a benefit this provides will depend on how your site is structured.

Step 4 – configuring e-mail

Now that we have the website working, let's get our e-mail configured. If you don't need e-mail on your domain, you can skip this section.

If you don't currently have a mail server configured, the easiest way to do so is by setting up Google Apps for domains. At the time of writing this book, Google offers a free plan for up to 10 users.

Follow the instructions for your mail provider, and then ensure that your MX records are set appropriately in CloudFlare's zone file. Once you do that, there are a couple other configuration steps you will need to complete in order to ensure deliverability.

Deliverability is a measure of how likely it is for e-mails that are sent from your domain to get stuck in spam filters. The best two ways to ensure that it does not happen is by setting your SPF and DKIM records appropriately.

Sender Policy Framework (SPF) records

At e-mail's core, it cannot validate who has been sent a message. The from field can actually be edited to be any e-mail address. A method of verifying the "from" address of an e-mail is by using SPF records.

When you send an e-mail, you can allow recipients to validate that the e-mail came from a valid sender. If you were using Gmail, for example, it would mean that Gmail sends someone an e-mail, purporting from your domain. SPF records allow the client to check and see what hosts are allowed to send e-mail from that domain.

In other words, an SPF record says that if an e-mail gets sent with an address and did not come from Google, it is probably not me. If there is no match, the e-mail is very likely to end up in a spam box.

SPF records are pretty easy to set up; you'll have to look up your e-mail provider to see what the required SPF record is. For Gmail, it will be: v=spf1 ~all. Just go ahead and add that to your DNS configuration in CloudFlare like so:

Definitely set that up to avoid the e-mails that you send from ending up in spam filters.

This paragraph, technically, seems to be incorrect. SPF records, in my opinion, are out of the scope of this book. If the user has an SPF record, let's tell them to add it here. Or a link to learn more about SPF records would be enough I think.

DKIM (DomainKeys Identified Mail)

SPF records are one way by which a recipient can verify a "from" address, but it's only a partial solution. Basically what you're saying is any e-mail sent from Gmail is legitimate. There are a lot of Gmail customers, so that's not even close to a full solution.

DKIM keys allow you to say that only part of the e-mail sent from an e-mail server is a valid e-mail. They work by signing every outgoing e-mail with a digital signature. Recipients can take that signature and verify that it's valid by checking your domain's DKIM records. A side benefit is that this also ensures that the e-mail has not been tampered with along the way.

Not all e-mail providers support DKIM. If you're using Gmail, follow these steps to get a DKIM key:

Once you get a key, set the key in your CloudFlare DNS configuration:

DKIM records are a little more work to set up than SPF records, but I still recommend using them to ensure deliverability of your e-mail.