私はそれをクエリ文字列として行います。それは簡単で、十分に正確であり、達成するために複雑なレイヤーを必要としません。ファイルの最後の変更をクエリ文字列としてリンクに配置するだけです。これにより、ブラウザはファイルを更新します。
<link rel="stylesheet" type="text/css" href="/css/style.min.css?v=<?= File::modified(path('public').'/css/style.min.css') ?>" />
これを単純化するために、ファイルへのリンクを生成し、パフォーマンスを向上させるために最後の変更をキャッシュする単純なクラスを作成できます。使用すれば、LESSコンパイラのカスタム関数でも実現できます。
さて、サーバーキャッシングについてですが、アプリケーションに実際に恩恵を受ける多くのユーザーがいる場合は、CDNを検討する必要があります。これは、世界中での配布も処理し、そのクエリ文字列システムでうまく機能します。
編集:
ApacheのRewriteRulesを使用してこれにアプローチすることも可能です(そのためにnginxの経験がない場合)。クエリ文字列の生成に使用されるのと同じ手法で、URIのプレフィックス(またはサフィックス)を生成するために使用できます。
もう1つ試すことができるのは、主にのような静的アセットを処理するためのサブドメインを定義することですassets.example.com
。このドメインは、LaravelスタックなしでWebサーバーによって完全に処理できます。ただし、プロジェクト全体でアセットがどのように開発、コンパイル、使用されるかに大きく依存します。
私たちのアプローチ:
当社では、データベースエンティティのアセットにCloudFrontとS3を使用しています。各エンティティには独自のS3ディレクトリがあり、各アセットは一意のファイル名でバージョン管理されます(md5によって生成され、再アップロードされたアセットでの重複を回避します)。何かのようなもの:
/posts/876/060b90d67ac0c5e24da6de6ae547e3b1.jpg
また、CloudFrontで10個のサブドメインを定義したため、ブラウザーは同じドメインに対して6〜8個の同時リクエストの制限に達しません。
cdn0.example.com
cdn1.example.com
cdn2.example.com
... and so on
データベースの各エントリは、計算によって選択された排他的なサブドメインを使用しますresource.id % 10
。これは非常に高速で、各エンティティに対して常に同じサブドメインを返します(クライアントとCloudFrontキャッシュを支援します)。これは、画像を提供するために取得できる最高のものです。
UIイメージは排他的なサブドメインassets.example.com
に保存されますが、これまでのところバージョン管理は行われていません。これは、デザインをあまり変更しないためです。変更する場合は、新しいアセットを/v2/
または/newthemename/
フォルダーなどの中に配置する可能性があります。このアプローチは、ロールバックやユーザーが選択したテーマでさえも大いに役立ちます。
CSSとJSは、Laravel/public
ディレクトリ内からApacheによって提供されます。これは最速の方法ではありませんが、現在開発に重点を置いているため、LESSとClosureの自動コンパイルを行うことがはるかに重要です。エンドユーザー向けに起動すると、アセットをコンパイルし、タイムスタンププレフィックスを付けてS3 / CloudFrontに公開し、ビューレンダリング用に最後のタイムスタンプをキャッシュする自動デプロイシステムを思いつくでしょう。