使って構築しましょう。トライアルリリースノート仕事効率化ウェブに最適なツールを使用して、ユーザーに最良のエクスペリエンスを提供します。既製のライブラリを使用して、すばやく効率的に作業できます。美しくパフォーマンスの高いウェブをデザインしましょう。よって翻訳されました。重要なサブリソースに関するヒントをサーバーがブラウザに送信する仕組みについて説明します。PollardXGitHubMastodonホームページ早期ヒントとはウェブサイトは時間の経過とともに高度化しています。)が必要になることは珍しくありません。残念ながら、この「サーバーの思考時間」はブラウザがページのレンダリングを開始するまでに、余分なレイテンシが発生します。実際、サーバーがレスポンスを準備する間、接続は実質的にアイドル状態になります。メインリソースへの応答方法を決定するサーバー上ですべてがブロックされます。レスポンスを送信するために使用されます。)やページで使用される可能性の高いオリジンに関する情報をブラウザに送信できます。ブラウザは、メインリソースを待機している間に、これらのヒントを使用して接続をウォームアップし、サブリソースをリクエストできます。ブラウザがこのような「サーバーの思考時間」を活用するのに役立ちます。秒速くなることもあります(前後の比較を参照)。200(またはその他の最終的なレスポンス)を送信できる場合、早期ヒントは有用ではないことに注意してください。要素を使用)で使用することを検討してください。レスポンスの生成に少し時間が必要な場合は、以下の説明をご覧ください。ページ、つまりユーザーがウェブサイトにアクセスしたときに通常最初に開始するページを特定することです。ページを参考にします。回目のナビゲーションで必要なサブリソースをすべて確保する可能性が高くなります)。良い第一印象を与えることも重要です。ヒントの候補となるオリジンまたはサブリソースを特定します。主要なユーザー指標に最も大きく影響するオリジンとサブリソースです。JavaScript、スタイルシート、さらにはウェブフォントなど、レンダリングをブロックするサブリソースを探します。同様に、ユーザーに関する主要な指標に大きく貢献するサブリソースをホストするオリジンを探します。使用している場合は、早期ヒントの候補としてこれらのオリジンやリソースを検討できます。最適化する方法をご覧ください。単純にコピーすることは、最適ではない場合があります。リソース(たとえば、後で検出されるフォントや背景画像など)が必要になります。行うことをおすすめします。サポートしているわけではありません。ブラウザのサポートをご覧ください。事前接続またはプリロードしていたリソースとは異なる場合があります。目のステップは、古くなったリソースやメインリソースで使用されなくなったリソースやオリジンで早期ヒントを使用するリスクを最小限に抑えることです。)は、最適な選択ではない場合があります。存在する可能性がある場所であればどこでも適用されます。不一致が生じる可能性が高くなります)。例として、次のフローについて考えてみましょう。使用してプリロードすることを提案します。含むウェブページが配信されます。バージョン(abcd105)更新されています。href="/main.abcd105.css">一般的には、かなり安定しており、メインリソースの結果からおおむね独立したリソースとオリジンを目指します。つに分割することもできます。初期ヒントで使用するために設計された安定した部分と、メインのリソースがブラウザで受信された後に取得できる動的な部分です。個の早期ヒントで即座に応答します。レスポンスには、関連する事前接続とプリロードのヒントを含めます。)でフォローアップします。ヘッダーを含めることをおすすめします。つに分割」の提案に従った場合のキーリソースの動的部分など)で補うこともできます。as=scriptしばらくすると、次のようになります。早期ヒントは主要なブラウザすべてでサポートされていますが、早期ヒントで送信できるディレクティブはブラウザによって異なります。リソースで確認できます。ヘッダーが表示される。リソースを使用する際の注意事項。オンにしないでください。キャッシュから読み込まれます。テスト用の信頼できる証明書も必要です。ヘッダー情報が表示されません。サポートレベルの概要を次に示します。使用する場合はサポートされます。試験運用版モジュール。プラットフォームを使用している場合は、早期ヒントを手動で実装する必要はありません。ドキュメントで早期ヒントがサポートされているかどうかを確認するには、次のリストをご覧ください(すべてを網羅しているわけではありません)。苦労するかもしれません。個の早期ヒントを出力する場合にのみ、後続のレスポンスを待つことを理解している新しいクライアントにのみ、このようなヒントが送信されるようにする必要があります。リクエストでのみサポートされているため(現在の制限事項をご覧ください)、他のリクエストで不必要に送信しなくて済むというメリットもあります。接続でのみ送信することをおすすめします。ほとんどのブラウザでは、これらのプロトコルでしか受信できません。ページに早期ヒントを全面的に適用していて、最適化案をさらに見つけようとしている場合は、次の高度なパターンが適しているかもしれません。リクエストを行っている訪問者に対しては、早期ヒントのレスポンスをページ内の下の方の深いコンテンツ、つまり優先度の低いリソースで早期ヒントを使用するのに合わせることができます。優先度が高く、レンダリングをブロックするサブリソースまたはオリジンに注力することをおすすめしたことを考えると、直感に反するかもしれません。ユーザーがしばらく操作した時点までに、ブラウザには重要なリソースがすでにすべて割り当てられている可能性が高くなります。そこから、優先度の低いリソースに注意を向けるのが合理的です。使用する場合などです。実装されている早期ヒントの制限事項は次のとおりです。ドキュメントのメインリソース)でのみ使用できます。サポートされません)。早期ヒントを使用して取得したリソースと接続が切断されます。キャッシュから取得されます。したがって、早期ヒントを使用してプリロードできるのは、キャッシュ可能なリソースのみです。回、ドキュメントで再び)。キャッシュは無効になります(ページの読み込みを続行しても)。ヘッダーを使用したサポートには対応していません。使用してレスポンシブ画像をプリロードすることはできず、これを使用すると誤った画像が読み込まれる可能性があります。こちらの対応方法の提案に関するディスカッションをご覧ください。次のステップコミュニティからの関心に応じて、次のような機能で早期ヒントの実装を補強する場合があります。キャッシュを使用するキャッシュ不可リソースの早期ヒント。リクエストで送信される早期ヒント。リクエストで送信される早期ヒント。早期ヒントでのプリフェッチのサポート。優先すべき点や早期ヒントの改善方法について、皆様からのご意見をお待ちしております。違いをご存じでしょうか。サーバーがレスポンスとともにサブリソースのプッシュを開始できます。これは驚くべきことのように聞こえますが、結果的に重要な構造上の欠点が生じました。ブラウザにすでに備わっているサブリソースのプッシュを回避することが非常に困難でした。この「過剰な」ネットワーク帯域幅の使用効率が低下し、パフォーマンス上のメリットが大幅に阻害されました。実際にウェブ全体のパフォーマンスにおいて実質的にマイナスになっています。実際にはより優れたパフォーマンスを発揮します。事前応答を送信する機能と、実際に必要なものの取得や接続をブラウザが行うヒントを組み合わせたものだからです。理論上対処できるすべてのユースケースを網羅しているわけではありませんが、早期ヒントの方がナビゲーションを高速化するためのより実用的なソリューションであると考えられます。さんのサムネイル画像。ライセンスにより使用許諾されます。ライセンスにより使用許諾されます。サイトのポリシーをご覧ください。関連会社の登録商標です。