RubyonRailsアプリケーションでのHTTPキャッシング

キャッシュを説明する一般的な方法は、後ですばやく取得できるようにデータを保存することです。これは、再計算する必要がないように計算されたデータを保存することを意味する場合もありますが、データを再度フェッチする必要がないように、データをローカルに保存することを指す場合もあります。オペレーティングシステムは頻繁にアクセスされるデータをRAMに保持しようとするため、コンピュータはこれを常に実行し、ハードドライブやSSDからデータを再度フェッチする必要がないようにします。

同様に、ブラウザはダウンロード済みのリソースを再利用しようとします。初めて新しいウェブサイトにアクセスしたときに、おそらくこれを自分で見たことがあるでしょう。ブラウザがすべてをプルダウンする必要があるため、初期読み込みに時間がかかります。 すべての画像、JavaScript、スタイルシートを含めて必要です。面白い事実は、CNNホームページを新たにダウンロードすると、ブラウザが1993年頃の元のDoomゲームよりも多くのデータをフェッチすることです。好奇心旺盛なことに、このブログ投稿を書いている時点で、CNNは私のマシンに3MB強をダウンロードします。 〜15MBで、これは広告ブロッカーが有効になっている場合ですが、元のDoomインストーラーは〜2.2MBでした。

ブラウザがこのデータをキャッシュするには、サーバーとの調整が必要です。ブラウザは、何をどのくらいの期間キャッシュできるかを知る必要があります。そうしないと、サーバーに新しいバージョンが使用可能になったときに古いコンテンツが表示される可能性があります。この記事では、このクライアント/サーバーキャッシング調整がどのように実行されるか、およびRailsがそれを変更するために何を提供するかを見ていきます。

Ruby on Railsがこれをどのように処理するかに焦点が当てられていますが、実際のメカニズムはHTTP仕様の一部です。言い換えれば、ここで話しているキャッシングはインターネットのインフラストラクチャに組み込まれているため、最新のWebサイトとフレームワークの開発方法の基礎になります。 Rails、シングルページアプリケーション（SPA）、静的サイトなどのさまざまなフレームワークはすべて、これらのメカニズムを使用してパフォーマンスを向上させることができます。

HTTPリクエスト-レスポンス

あなたはおそらく、少なくとも大まかに言って、要求と応答のライフサイクルに精通しているでしょう。Webサイトのリンクをクリックすると、ブラウザがそのコンテンツの要求をサーバーに送信し、サーバーがそのコンテンツを送り返します（注ここでは、意図的に多くの複雑さを強調しています。

この前後のトランザクションで送信される実際のデータを少し掘り下げてみましょう。各HTTPメッセージには、ヘッダーと本文があります（ と混同しないでください）。 および HTMLタグ）。リクエストヘッダーは、アクセスしようとしているパスと使用するHTTPメソッド（GET / PUT / PATCH / POSTなど）をサーバーに通知します。必要に応じて、ブラウザの開発者ツールまたは curl などのコマンドラインツールを使用して、これらのヘッダーを詳しく調べることができます。 ：

# curl -v honeybadger.io
...
> GET / HTTP/1.1
> Host: honeybadger.io
> User-Agent: curl/7.64.1
> Accept: */*

出力のこの最初の部分は、リクエストヘッダーです。 GETを発行しています honeybadger.ioへ 。次に、サーバーが送り返したもの（「応答ヘッダー」）が続きます。

>
< HTTP/1.1 301 Moved Permanently
< Cache-Control: public, max-age=0, must-revalidate
< Content-Length: 39
< Content-Security-Policy: frame-ancestors 'none'
...
< Content-Type: text/plain

応答にはHTTPコードが含まれます（例： 200 成功または404 見つからないため）。この例では、curlが http に接続しようとしているため、これは永続的なリダイレクト（301）です。 安全なhttpsにリダイレクトするURL URL。応答ヘッダーには、コンテンツタイプ（ text / plain ）も含まれます。 ここにありますが、他のいくつかの一般的なオプションは text / htmlです 、 text / css 、 text / javascript 、および application / json 。

応答本文はヘッダーの後に続きます。この場合、 301 であるため、本文は空白です。 リダイレクトには本文は必要ありません。 curl -v https://www.honeybadger.ioで再試行した場合 、ブラウザでソースを表示している場合と同じように、ここにホームページのコンテンツが表示されます。

これを自分で試してみたい場合は、次の2つのヒントがあります。

1. curlを含む応答ヘッダーのみを表示するには（たとえば、要求ヘッダーや応答本文を表示しない場合）、 -Iを使用します curl -I localhost：3000のようなオプション 。
2. デフォルトでは、Railsは開発環境にキャッシュしません。 rails dev：cacheを実行する必要がある場合があります 最初に。

< Content-Type: text/html; charset=utf-8
< Etag: W/"b41ce6c6d4bde17fd61a09e36b1e52ad"
< Cache-Control: max-age=0, private, must-revalidate

class UsersController < ApplicationController
  def index
    @users = User.includes(:posts).all

    render :index if stale?(@users)
  end
end

# curl -I localhost:3000 -- first page load
ETag: W/"af9ae8f2d66b9b6c4d0513f185638f1a"
# curl -I localhost:3000 -- reload (change due to CSRF token)
ETag: W/"f06158417f290334f47ea2124e08d89d"

-- Add stale? to controller code

# curl -I localhost:3000 -- reload
ETag: W/"04b9b99835c359f36551720d8e3ca6fe" -- now using `@users` to generate ETag
# curl -I localhost:3000 -- reload
ETag: W/"04b9b99835c359f36551720d8e3ca6fe" -- no change

class UsersController < ApplicationController
  def index
    @users = User.includes(:posts).all

    expires_in 10.minutes
  end
end

# curl -I localhost:3000
Cache-Control: max-age=600, private

class UsersController < ApplicationController
  def index
    @users = User.includes(:posts).all

    http_cache_forever(public: true) do
      render :index
    end
  end
end

# curl -I localhost:3000
Cache-Control: max-age=3155695200, public