Now that we have the DNS configured in CloudFlare, we can enable the features that CloudFlare provides.
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.
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 anna.ns.cloudflare.com and dave.ns.cloudflare.com.
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 https://chrome.google.com/webstore/detail/fgbpcgddpmjmamlibbaobboigaijnmkl.
It should turn orange if the site has CloudFlare enabled, along with the features that it is using. Here it is for me on letsgrababeer.com:
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.
Aggressive caching: This caches assets with a query string. Assets with different query strings should be considered different. (For example, http://ipadevice.com/pic.jpg?with=query1 would be cached as well as http://ipadevice.com/pic.jpg?with=query2 would be cached differently.)
Simplified caching: This caches assets with a query string, however ignores the contents of the query string. (For example, http://ipadevice.com/pic.jpg?with=query1 would be cached and http://ipadevice.com/pic.jpg?with=query2 would be cached equally.)
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.
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.
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.
window.onload time, improving your Google search ranking.
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.
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.
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
@mydomain.com 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 include:_spf.google.com ~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.
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: http://support.google.com/a/bin/answer.py?hl=en&answer=174124.
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.