可視コンテンツの優先順位付け-Google PageSpeed Insights
誰かが私を助けることができるかどうか疑問に思います。可視コンテンツ（PVC）の優先順位付けに問題があります。
Googleのすべてのドキュメントを読み、スクロールせずに見えるコンテンツが上位500ピクセルであることを理解していますが、Googleがこれらの500ピクセルの外側または内側で検出してトリガーする内容を理解できません。私は考えられるすべてのことを試して解決策を見つけました。
ページ全体がスクロールせずに見えるページ、サイドバーのないページ、画像または小さな画像のないページ、CSSを使用して画像を読み込むページ、外部ファイルのないページ、jsがない場合、ページを作成してPVC警告を取得できます、などなど.
また、スクロールせずに見える位置に多くの画像や背景画像を含むページを作成することもできます。
GoogleがどのようにPVC警告をトリガーするかを決定する方法に光を当てる一貫したパターンまたはソリューションを見つけることができないようです。
たとえば、スクロールせずに見える外部ファイルやフォントをまったく使用しないページには、次のものがあります。
単一の小さな画像Navバーを備えた約150pxの高さのヘッダーヒーロー画像/ビッグ画像なしサイドバーを含まないDiv、キーテキストを含むh1およびh2タグのみ
そして、折り目の下にはいくつかの画像とテキストがあります。
このページはどのようにして可視コンテンツを優先していないとフラグ付けされますか？
また、上記のコンテンツを優先してページを作成し、テンプレートとして満足し、新しいファイル名として保存し、コアコードがまったく同じであるテキスト/画像に小さな変更を加えると、うまくいきます一方と他方ではありません。
それはページ速度の洞察で何度も何度も登場する唯一のものです-私のページはそれを引き起こしているかもしれない速度問題のトーンに悩まされています。
不思議な人のためのエラーは次のとおりです。
表示コンテンツの優先順位付けスクロールせずに見えるコンテンツを表示するには、追加のネットワークラウンドトリップがページに必要です。最高のパフォーマンスを得るには、スクロールせずに見えるコンテンツのレンダリングに必要なHTMLの量を減らします。 HTMLレスポンス全体では、スクロールせずに見えるコンテンツをレンダリングするには不十分でした。これは通常、HTML解析後に読み込まれる追加リソースがスクロールせずに見えるコンテンツのレンダリングに必要であることを示しています。 HTMLレスポンスに直接含めることにより、スクロールせずに見える範囲にレンダリングするために必要な可視コンテンツに優先順位を付けます。最終的なスクロールせずに見えるコンテンツは、完全なHTMLレスポンスでもレンダリングできませんでした。
ブラウザがページをレンダリングする前に、DOMおよびCSSOM木。そのため、できるだけ早くHTMLとCSSの両方をブラウザに配信する必要があります。
このプロセス全体の最終出力は、単純なページのDocument Object Model（DOM）であり、ブラウザはこれをページのすべての処理に使用します。
ブラウザがHTMLマークアップを処理するたびに、次のすべての手順が実行されます。バイトから文字への変換、トークンの識別、トークンからノードへの変換、DOMツリーの構築。処理するHTMLが大量にある場合は特に、このプロセス全体に時間がかかることがあります。
CSSOMおよびDOMツリーはレンダーツリーに結合されます。レンダーツリーは、各可視要素のレイアウトを計算するために使用され、ピクセルを画面にレンダリングするPaintプロセスへの入力として機能します。最適なレンダリングパフォーマンスを実現するには、これらの各ステップを最適化することが重要です。
レンダーツリーの構築は、クリティカルレンダリングパスがレンダーツリーを構築するためにDOMとCSSOMの両方を必要とすることを示しています。これにより、重要なパフォーマンスへの影響が生じます。HTMLとCSSの両方がレンダリングブロッキングリソースです。 HTMLは明らかです。DOMがなければレンダリングするものは何もないからです。しかし、CSS要件はそれほど明白ではないかもしれません。
デフォルトでは、CSSはレンダリングブロッキングリソースとして扱われます。つまり、CSSOMが構築されるまで、ブラウザーは処理されたコンテンツをレンダリングしません。最初のレンダリングまでの時間を最適化するために、できるだけ早く、できるだけ早くクライアントに送信してください。
JavaScriptを使用すると、コンテンツ、スタイル、ユーザーインタラクションへの応答など、ページのほぼすべての側面を変更できます。ただし、JavaScriptはDOM構築をブロックすることもでき、ページがレンダリングされるときに遅延します。インラインスクリプトを実行すると、DOMの構築がブロックされるため、初期レンダリングも遅延します。
Webページにスクリプトを導入するもう1つのプロパティは、DOMだけでなくCSSOMプロパティも読み取って変更できることです。スタイルのすべてまたは一部のプロパティの表示が変更される場合があります。このようにして、ブラウザはCSSOMのダウンロードと構築が完了するまで、スクリプトの実行とDOMの構築を遅らせます。
デフォルトでは、JavaScriptの実行は「パーサーブロッキング」：ブラウザがドキュメント内のスクリプトに遭遇した場合、DOMの構築を一時停止し、JavaScriptランタイムに制御を渡して、スクリプトを実行する必要がありますDOMの構築を進める前に実行します。ブラウザーは、スクリプトがページ上で実行することを計画していないため、最悪のシナリオを想定し、パーサーをブロックします。インラインスクリプトは、実行を延期する追加のコードを記述しない限り、常にパーサーブロックです。
最適なパフォーマンスを提供するには、JavaScriptを非同期にし、クリティカルレンダリングパスから不要なJavaScriptを削除します。
最初のレンダリングに可能な最速の時間を提供するには、3つの変数を最小化する必要があります。
重要なリソースの数。クリティカルパスの長さ。クリティカルバイトの数。
重要なリソースは、ページの初期レンダリングをブロックする可能性のあるリソースです。これらのリソースが少ないほど、ブラウザ、CPU、およびその他のリソースの作業が少なくなります。
同様に、クリティカルパスの長さは、クリティカルリソースとそのバイトサイズの間の依存関係グラフの関数です：一部のリソースのダウンロードは、前のリソースが処理された後にのみ開始でき、リソースが大きいほど、ダウンロードにかかる往復が多くなります。
最後に、ブラウザがダウンロードする必要がある重要なバイトが少ないほど、コンテンツを処理し、画面に表示するのが速くなります。バイト数を減らすために、リソースの数を減らし（リソースを削除するか、重要でないようにします）、各リソースを圧縮して最適化することで転送サイズを最小限に抑えることができます。
クリティカルレンダリングパスを最適化するための一般的な手順は次のとおりです。
リソースの数、バイト数、長さなど、クリティカルパスを分析し、特徴付けます。重要なリソースの数を最小限に抑えます。それらを削除し、ダウンロードを延期し、非同期としてマークします。
重要なバイト数を最適化して、ダウンロード時間（往復回数）を減らします。残りの重要なリソースがロードされる順序を最適化します。すべての重要な資産をできるだけ早くダウンロードして、重要なパスの長さを短くします。
要約-可視コンテンツの作成の依存関係のおおよそのチェーン：可視コンテンツ=> DOM =>重要なリソース（css、javascriptなど）。
考えられる解決策：要素のヘッド内にスタイルを適用しますが、スタイルをコードHTMLに埋め込むことなく、非同期をすべてのスクリプトの非同期/遅延ダウンロードとして使用します。これはすべてAMP-Accelerated Mobile Pagesに適用されます。
出典：Google Web FundamentalsのクリティカルレンダリングパスおよびGoogle Patnersヘルプのクリティカルレンダリングパスの最適化。
この警告は、おそらくページの下部またはスクロールせずに見えるコンテンツの下にあるcssまたはjavascriptの結果です。ページの外観をレンダリングするためにこれらのファイルに何かが必要な場合は、ページ全体が読み込まれ、ページの下部にあるcssファイルが読み込まれ、折り畳まれたコンテンツが表示されます。
これは遅すぎます。レンダリングをブロックするcssとjsを、スクロールせずに見えるコンテンツの上に配置して、ページの残りの前にロードされるようにする必要があります。これにより、ページの下部にある.jsとcssが読み込まれる前に、スクロールせずに見える範囲のコンテンツが表示されます。それはあなたのページをずっと速くします。