Tomcat サーバーの前に配置するようにワニスをセットアップしました。私が気付いたのは、Varnish がブラウザーに応答を送信する前に、完全なページ (すべての css、js など) が読み込まれるのを待っているように見えることです。
これにより、ユーザーが何かを見る前に大きな遅延が発生します。Varnish をバイパスしてサイトに直接アクセスすると、すぐに応答します。
総ページ読み込み時間は似ているかもしれませんが、サイトが遅いという認識があります.
誰かがこれに直面しましたか?
Tomcat サーバーの前に配置するようにワニスをセットアップしました。私が気付いたのは、Varnish がブラウザーに応答を送信する前に、完全なページ (すべての css、js など) が読み込まれるのを待っているように見えることです。
これにより、ユーザーが何かを見る前に大きな遅延が発生します。Varnish をバイパスしてサイトに直接アクセスすると、すぐに応答します。
総ページ読み込み時間は似ているかもしれませんが、サイトが遅いという認識があります.
誰かがこれに直面しましたか?
HTML にインラインで JS と CSS が含まれていない限り、説明した動作は技術的に不可能です。ブラウザーは、HTML を受信して解析し、個別の HTTP 要求を抽出<script>
してタグ付けし、送信する必要があります。<link>
それらが同じ Varnish サーバーに到達したとしても、それらが同じ「ページ」の一部であるとは認識されません。
Varnish に移動しない別のホスト名から静的 (JS、CSS、および画像) をロードするように HTML を変更してみてください。これにより、デバッグが容易になります。コマンドライン HTTP クライアントを使用して同じ結果を得ることができますcurl
。このシナリオでも同じようにパフォーマンスが低下する場合は、Varnish のログを確認してください。さらに多くのことを確認するためのヒントが得られる可能性があります。コメントとしてお気軽に追加してください。そうすれば、より良いお手伝いができるようになります。
ロードする完全なページ (すべての css、js など)とは、埋め込まれた js および css リソースのみを意味します。よろしいですか? Varnish は、クライアントに送信する前に、応答全体をバッファリング (およびできれば保存) します。バックエンドがレスポンスを段階的に (チャンクなどで) 送信する場合、バックエンドが最後のピースを送信した後にニスによってのみ配信されるため、キャッシュされていないページの表示が遅くなる可能性があります。
これが問題になる場合は、アプリケーションの技術設計を変更してください。ほとんどのリクエストがキャッシュから処理できることを確認し (これらのページは非常に高速になります)、js および css リソースを外部化します (ブラウザー キャッシュはリクエストの処理をまったく回避します)。ページのごく一部だけが遅く、キャッシュ可能性が低い場合は、非同期で読み込みます (Ajax など)。
インクリメンタル レンダリング (より多くのリソースが利用可能になるとブラウザーがページを再レンダリングする) の概念もありますが、Varnish がこの動作をどのように変更するかはわかりません。