Webコアバイタルとしてのstyle読み込みにいブラウザが表示レンダリングを妨げる為、それを回避(非同期遅延処理)する場合、
<link rel=”stylesheet”>標準的な仕様を、<link rel=”preload”>とする。
W3Cからの引用
多くのアプリケーションでは、リソースがいつフェッチされ、処理され、ドキュメントに適用されるかをきめ細かく制御する必要があります。たとえば、リソースの競合を減らし、初期ロードのパフォーマンスを向上させるために、アプリケーションによって一部のリソースのロードと処理が延期される場合があります。この動作は通常、リソースのフェッチをアプリケーションによって定義されたカスタム リソース読み込みロジックに移動することによって実現されます。つまり、リソースのフェッチは、特定のアプリケーション条件が満たされたときに、挿入された要素または XMLHttpRequest によって開始されます。
ただし、一部のリソースをできるだけ早くフェッチする必要がある場合もありますが、その処理および実行ロジックはアプリケーション固有の要件に従う必要があります。依存関係管理、条件付き読み込み、順序保証など。現時点では、パフォーマンスを犠牲にすることなくこの動作を提供することはできません。
既存の要素 (img、script、link など) の 1 つを介してリソースを宣言すると、リソースの取得と実行が結合されます。一方、アプリケーションはフェッチを行いたいが、何らかの条件が満たされるまでリソースの実行を遅らせる場合があります。上記の動作を回避するために XMLHttpRequest を使用してリソースを取得すると、ユーザー エージェントの DOM およびプリロード パーサーからリソース宣言が隠蔽されるため、重大なパフォーマンス ペナルティが発生します。リソースの取得は、関連する JavaScript が実行されたときにのみディスパッチされます。これは、ほとんどのページに大量のブロック スクリプトがあるため、大幅な遅延が発生し、アプリケーションのパフォーマンスに影響を与えます。リンク要素の preload キーワードは、早期フェッチを開始し、フェッチをリソースの実行から分離するという上記の使用例に対処する宣言型フェッチ プリミティブを提供します。そのため、preload キーワードは、ユーザー エージェントからリソースを隠したり、リソース取得の遅延ペナルティを被ったりすることなく、アプリケーションがカスタムのリソースの読み込みと実行動作を構築できるようにする低レベルのプリミティブとして機能します。
たとえば、アプリケーションは preload キーワードを使用して、CSS リソースの優先度の高い非レンダリング ブロッキングのフェッチを早期に開始し、アプリケーションが適切なタイミングで適用できます。
と、なんやら理解した風でやはり小難しい。画像では link rel=”preload” に遅延処理として onload=’this.onload=null;this.rel=”stylesheet”‘ を追記するのは既に一般的になりつつあるが、その後の処理がどうも生成処理に問題がある様だ。
<link rel=”preload” />後に、<noscript>と処理をしている事を見かける、確かにonload=’this.onload=null;this.rel=”stylesheet”‘ではjavascriptにてコントロールする為に、javascriptをOFFの場合スタイルシートが正常に読み込まれない訳だが、この<noscript>自体好ましくない、サイトソース検証では避けるようにメッセージがあり、SEO検証でもこの<noscript>は避けるように指示がある。
<link rel=”preload” onload=’this.onload=null;this.rel=”stylesheet”‘ /><link rel=”stylesheet”>とするのが本来仕様であり、javascriptをOFF状態環境でもスタイルシートとして正常な処理になりモダンなソース生成になる。
どちらにしても、この処方は個人の考え方もありこれは間違いとは言えないのが混乱元でもあろう。