This is the host-installed version of CloudFlare/Railgun as offered very successfully at Arcustech.
The arrangement is different from Railgun offered with the $200/month CloudFlare Business plan. It is free, and it takes a different approach to configuring the connection between your site and Railgun's high-speed server.
The configuration needs to operate properly with Locale multilingual features, and with SSL coverage for Craft CP admin and Stripe e-commerce pages.
I'm going to answer this one, to share information on how I just did it. One issue will remain, but that will be raised in a separate question.
The first thing is to understand the URL layout which CloudFlare/Railgun will require. You or your hoster will create A records in DNS for all but one of these, each of them pointing to your server IP.
There's an order in which these records should be created, which your hoster will specify, in order to check all is well before aetting the CloudFlare service to be fully active for visitors to your site. So don't just go ahead from this list!
Ok. Notice that the CNAME alias is from www.domain.com. Your hoster will give you a set of prefix rules to go in your public Craft directory's .htaccess file, above the handling which calls Craft itself. If you have special rules there to cause automatic switching to SSL for the Craft CP, a small portion of those will need to go before the CloudFlare additions. I'll cover that in another question/answer on automatic SSL itself, updating an earlier post to one of the cookbooks, and as setup has slightly changed.
The result of the DNS and .htaccess additions is that your site will now always redirect visitors to www.domain.com even if they originally linked simply domain.com. As you can see, www.domain.com is aliased by the CNAME record to call CloudFlare rather than your site directly, and that's how the speed-up caching is applied.
Railgun will also operate on this URL once you turn it on from your CloudFlare control panel, the one which will have been set up for you by your hosting provider. You want to let them do that, as it is different and differently connected than one which would result from you signing up to CloudFlare independently, thus enabling your hoster's service.
Then you can see why the extra cloudflare-source DNS access is needed. Your main site will refer to www.domain.com, which comes from CloudFlare. CloudFlare must then get its picture of your site from somewhere else, and cloudflare-source.domain.com is that place.
Now that we have CloudFlare arranged via DNS and .htaccess, what do you need to do in Craft configuration to properly use it? As it turns out, not very much.
You need to refer Craft to the now-required www.domain.com wherever it needs reference to your site, rather than domain.com. In particular, the constant siteUrl needs to be set this way You can do that in the CP General configuration page, and/or as a definition in general.php.
Thus if you are not using languages (Locale on Craft Pro), in general.php you would set:
'siteUrl' => 'http://www.domain.com/',
while if you are using languages you would in general.php set the siteUrl array by the same principle, according to the languages on your site. This example is for English, Russian, and Swedish:
'siteUrl' => array(
'en' => 'http://www.domain.com/en/',
'ru' => 'http://www.domain.com/ru/',
'sv' => 'http://www.domain.com/sv/',
),
Several such arrays can be used individually as ever within a multi-site configuration, covering staging servers and so forth if you use that method. With or without multisite, if you've set your staging server as its own subdomain, then that will automatically bypass CloudFlare/Railgun for staging, which is very likely what you'd prefer.
Lastly, if you are using Craft Pro languages (Locale), you'll need to copy the fully equipped main site .htaccess to each of the language folders on the html site, so that they will respond appropriately. Not an option, and one of those fun ways to go wrong with languages, which when set up properly, are on Craft very easy and practical to work with.
How much improvement do you gain, from setting this up?
It can be quite dramatic.
On initial Pingdom testing and a site of not quite medium complexity, I'm seeing >5x improvement monitored in the US: from 2.5 seconds to 0.3 seconds for full all-images page loads, that important first customer access to your site.
Going overseas, CloudFlare is making practical a European customer's site from a single server base at Arcustech in the US. The same ordinary first-load pages go from 3 seconds to under 0.5 seconds. A difficult page with video players on it goes from around 25 seconds to around 1.7 seconds complete, both of these in Amsterdam from Minneapolis servers. The delay on the slow page is due to the video player background loading of libraries, so the screen view comes up more rapidly, but you can see it would be unusable without CloudFlare.
You can see that the CloudFlare-amplified service is as if it was local in Amsterdam. Across Europe one can see via Pingdom that not all areas will be as fast, but with the distribution of CloudFlare edge servers, all will be practical; 1-second pages say instead of half-second, and a little more for the video page, but by use of player-assisted 'poster' images it comes up visually much more quickly than it completes, so a few seconds will be fine there also.
These figures are assuming the caches are full at the edge servers. The very first access will be slower, if helped by CloudFlare's excellent connections, as always with a cache.
How much Railgun adds, for which we take this special configuration's effort, has to be complex. If you are running CNN-sized pages, it will measurably help a lot, as big boys and girls are using it, as well as other edge caches with similar (and very expensive) features. If you are running small pages, most of the time it will not be so visible. In between, in between.
However, I suspect Railgun is likely to speed up first-viewer-on-empty-edge-cache page speed also, due to its keepalive single connection and compressed, high-availability path. Similarly, it should help unexpectedly more than usual whenever there is network congestion and extended latency, which as anyone who uses or monitors them knows certainly happens a lot on transoceanic paths. As we note with the Netflix wars bringing it to visibility, it's not happening a little within North America itself. Edge caching and delta compression sending only in-page differences is clearly a way to insure and proceed, when it is free as in these Arcustech-type arrangements; at least I feel so for my present and future customers.
Taylor, I think your best bet would be to email support at Arcustech directly about this.
They're very able to help; just put clear questions to them and think you'll be pleased.
As far as I am aware, the arrangement I used would be the same as you would get on a higher end plan -- it's Arcustech's node point that enables the Railgun part in either case.
Have to confess, it's been a while since I've worked with this, and as you can see, it's an effective arrangement, if needing to be pretty well understood to get the best from it. You should draw out the pattern, or whatever will get it into your head.
A key point of understanding is that your web app will still need to run for each access, so it needs to be fast for fast overall results. Caching is your friend, and that is its own subject, as intricate as it needs to be for a given site's needs.
The big advantage Railgun can give is to run compressed versions of content deltas out to the edge point your client accesses in the world, on a single held-open connection so this is as fast as it could be. This will help a lot with individual propagation latency, but you still have roundtrip latency plus the server time for your CMS to answer. Make things fast on your side, and the overall delay should be below important noticing. Just not instantaneous actually.
Content that doesn't change, and reports not no-cache will sit on CloudFlare's edge servers once it first gets there, so that, which should include the bulk of your large resources like images, will be as if local -- for a country or region, anyway.
The tests I did were very promising for a travel bureau site which wanted to show well in Europe and Eastern Europe/Russia. For Russia, there weren't edge servers, but it would look as good as Eastern and Central European sites in use from Russia ordinarily. You can read about the issues over that border, and look at the map of CloudFlare to see they've done their best to ring for best results.
Best fortune on this, and you might put a note here once you get it up to report your experience. Always good we can all learn interesting things from those.