※画像は誰かに呼び出されるのを待つキャッシュ達（イメージ）です。

サイトの表示を高速化するために、時と場合に応じてデータをキャッシュすることはとても重要です。 Drupalでは、Drupal 4でページ全体のHTMLをキャッシュする機能が組み込まれ、バージョンが進むとともに、さらにきめ細かく、ダイナミックにHTMLのキャッシュを設定できるように進化してきました。
Drupalでは、「あるデータのキャッシュが、どのような条件下で、どれくらいの長さ保存されるか」を示す設定をキャッシャビリティ(Cacheability)と呼びます。
Drupal 8では キャッシャビリティ・メタデータ という形式でキャッシャビリティを設定することで、簡単にカスタムのキャッシュ条件を設定することができます。 今回はCache API（以下キャッシュAPI）についてのドキュメントを翻訳してきたので、「レンダリング配列のキャッシャビリティ 日本語訳」と併せてご参考にしていただけると幸いです。

（翻訳開始）

Cache APIについて

原文： Cache API（翻訳時の最終更新日：2016年10月13日）

キャッシュAPIはDrupal 8において大きく改善しました。以下のセクションではそれぞれの機能の詳細について述べています。Cache APIの詳細ページも御覧ください。

キャッシャビリティ・メタデータ(Cacheability metadata)

アクセス結果からエンティティ、URLまで、直接レンダリング可能なデータや、何をレンダリングすべきかと決めるデータのすべてがキャッシャビリティ・メタデータを持ちます。

キャッシャビリティ・メタデータは3つのプロパティを持ちます。

キャッシュ・タグ(cache tags)

どのデータに対してキャッシュを効かせるかを表します。エンティティやコンフィギュレーションなど。

キャッシュ・コンテクスト(cache context)

キャッシュする際の「バリエーション」、もしくは、データがリクエストされる際のコンテクストを表すのに使います（筆者注：　コンテクストの例としては、アクセスしているユーザーの種類などがあります）

キャッシュの寿命(cache max-age)

キャッシュのタイムリミット、すなわち「時間依存性」を決めるのに使います。

実践： キャッシュAPIの典型的な使い方

典型的なDrupalサイトでは、最終的にはブロックやエンティティのようなものがレンダリングされ、コントローラーはレンダリング配列かレスポンスを返します。つまり、 通常はキャッシュAPIと直接やり取りすることはありません。 その代わり、以下のものを使います。

レンダー・キャッシュ（Render Caching、フラグメント・キャッシング　Fragment Cachingともいう）

レンダーAPI(Render API)がレンダリング配列に埋め込まれたキャッシャビリティ・メタデータを使います。そのため、キャッシュAPIはレンダリング配列のキャッシュをいじるために使われるべきではありません。 詳しくはレンダリング配列のキャッシャビリティ(日本語)を御覧ください。

レスポンス・キャッシュ

レンダーAPIによって使われたキャッシャビリティ・メタデータは、CacheableResponseInterfaceを埋め込むレスポンスオブジェクト（通常はHtmlResponce）までバブルアップ(伝達)されます。 これらのレスポンス・オブジェクトが持つキャッシャビリティ・メタデータによって、Drupal 8サイトはデフォルトでページ・キャッシュやダイナミック・ページ・キャッシュが効いた状態で表示されます。 詳しくはCacheableResponseInterfaceを御覧ください。

(翻訳終わり)