CloudFlareの使い処

試してみて、わかったことを書き連ねておきます。2011年10月1日現在の私見です。

基本的にクラウドフレアによってもたらされるスピードはそこそこ速い程度です。サーバーが世界中に分散されていますから、世界中からあなたのサイトに対して、そこそこ速いレスポンスが得られるということになります。

転送用のサーバーは日本では東京にあります。DNSサーバーはカルフォルニアにあるようです。当方、新潟からpingを打つと40ms-100ms程度かかります。面白いのは、登録したドメインごとにDNSサーバーは異なっているのですが、約40msか約100msかのどちらかになります。これはいつも一定ではなく時間によっても変わります。推測ですが、実態へのアクセスが東京なら40msでカルフォルニアへ行く時が100msになっているようです。切り替わっているようですね。（出来れば、日本からのアクセスは全部東京へつないでもらいたいですね。ほとんどカルフォルニアへ行っているようです。しかし、仕組みがよくわかりません。:) ）

クラウドフレアによってhtmlはキャッシュされません。ですから、動的サイトでページの生成に時間がかかり、それがページが表示される際のボトルネックになっているならば、スピード的なメリットは少ないです。（平たく言うなら、よくあるのがCMSで拡張を使いすぎているとかのパターンです。重い原因が拡張の使いすぎ、遅い拡張を使っているとかならば、それらの拡張を整理しない限り、クラウドフレアを利用してもメリットはありません。）また、この理由により、CMS側での生成htmlページのキャッシュは行なっておくべきです。

ページの表示が重い原因が、重い背景である場合などで、そのレスポンスと転送時間が遅さの原因ならば、クラウドフレアのキャッシュによる、スピード向上は期待できます。

もし日本で高速レスポンスサーバーを利用しており、サイトの読者が日本人がメインであれば、クラウドフレアを採用しても、スピード的には遅くなるだけでしょう。メリットは転送量を減らせることです。

高速レスポンスサーバーを利用していても、ターゲットが世界中の人々であるなら、メリットはありますね。この場合、スピード面では日本の利用者に多少犠牲になってもらい、その分、他の国からのスピードアップという利点を得ることになります。ただし、htmlはキャッシュされませんから、そのアクセスの時間は（クラウドフレアのサーバーを通してでも）もともとのサーバーからの距離が遠くなればなるほど、その分アクセス時間は多少はかかってしまうことになります。

htmlはキャッシュされないということは、もともとのサーバーが遅かったり、回線の問題で遅かったりするならば、その影響は受けるということです。

また、どうもサイトへのアクセスがしばらない状態が続き、その後にアクセスすると、最初のアクセスはレスポンスが落ちるようです。初めはブラウザのキャッシュのせいかと思いましたがそうではなく、どうもクラウドフレア側の仕組みが原因ぽいですね。

それと使っていて気がついたのは、一時的にクラウドフレア自体のレスポンスが落ちる時間帯があるということです。約１０分ほど、反応が鈍くなります。その時間帯はいつもは３秒かからずに読み込まれるページが１０秒ほどかかります。どの程度の頻度で起きるかは、まだ使用時間が少ないため、わかりません。もともとのサーバー的に問題は無いのに、やけにレスポンスが落ちるのです。当初は、キャッシュが更新される時の問題かと思いましたが、そうでもないようです。

Googleのアドセンスや、他の広告、アフェリエイトのJavascriptをアチラコチラに貼っているのが表示の遅い原因の場合、まだベータの機能ですが、Rocket Loaderの機能が役に立ちます。Javascriptの読み込みを非同期にしてくれるものです。直接自分でソースに手を入れるやり方と、クラウドフレアにまかせてしまう方法を選べます。当方のサイトで試した結果、ページの読み込みは半分になり、表示は１秒から３秒ほど改善されました。まあ、これもCMSに存在するならばその様な機能、もしくは拡張機能を利用すれば同様な効果が得られますね。

Auto Minifyという機能もあります。css,js,htmlを短くしてくれる機能のようです。ただ、当方の環境では、CMS側で短くするだけでなく、バラバラのcssとjsをまとめてくれる拡張機能を採用しているため、メリットはありませんでした。この機能を使うと、多少はクラウドフレアで処理時間がかかるのか、わずかに遅くなりました。この機能はCMS側でどの程度仕事をさせるかによって、有利不利が決まりそうですね。

速度的に気がついたのは以上です。

転送量については、制限のあるサーバーを利用している場合、転送量を増やしている大本が何であるかによって、メリットが変わります。軽いサイトでアクセス量が多く、htmlが転送量を占めているような、めったにないサイトでは、キャッシュによる転送量減少のメリットは少ないでしょう。逆に、大抵のサイトのように、背景画像であったり、提供している画像などのリソースが転送量を食いつぶしているなら、メリットはおおいに期待できます。

DNSで設定されるdirectというサブドメインがなんなのかよくわかりません。デフォルトではクラウドフレアのキャッシュを通さない設定になっています。これは、要するに自分のサイトをキャッシュ抜きでアクセスしたい場合に、使うためのサブドメインとしてクラウドフレアが薦めているもののようです。実際に使用するためには、自分のサイト側、共有サーバーであればcPanelなどの操作パネルから、DNSの設定でdirectを設定しなければ使用できません。しかしながら、悪意を持った使用者からすれば、クラウドフレアがアクセスを弾くことで、そのサイトがクラウドフレアを使っていることがわかるわけです。ならば、direct付きのサブドメインへアクセスすれば、クラウドフレアのキャッシュのみならず、セキュリティーをくぐれる事になってしまいます。ですから、directという決め打ちの名前でなく、別のオリジナルなサブドメインをこの目的で使ったほうが良いと思います。更に、開発モードへの切り替えが用意されており、これを使えば３時間の間、キャッシュレスでアクセスできます。サイトに手を入れるなどの目的の場合、開発モードをつかいましょう。