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.

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.

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.

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.

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.

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.