過去数日間Core Web Vitals対策でprelaodを活用した手法を検証してましたが、結果としてその不具合の原因がお客様サイトや高速化で利用するプラグイン、はたまたサーバーでもないという事がわかりました。この不具合は一部のお客様サイトに影響が出るため情報共有します。
preload部分認識不具合の概要
本来どのブラウザでもpreloadが指定されている場合、その通りに読込が優先されます。今回は1ページに3つ以上のpreloadが指定されている場合、Chrome最新版（バージョン90+）を利用した閲覧環境だと3つではなく2つしか読み込まれません。
一方でバージョン86等、シミュレーションツール等でChromeの旧バージョンを使用している場合は本影響を受けません。
多くの場合一般ユーザーが利用するChromeは自動アップデートされますので大半は最新版を既にご利用されているはずです。Chromeの更新仕様については公式ヘルプをご参照ください。
Core Web Vitalsへの影響
Core Web Vitals評価に関わる期間はデータ元となるCrUX収集期間28日間とされており、仮にCore Web Vitals要件を達成するために1ページにつき3つ以上のpreloadを設定しているサイトはこの不具合が解消されるまでの間本来よりも若干ですが遅いサイトとして判断される可能性があります。
WordPress高速化作業への影響
preloadによる対策が必要なサイトについては作業中のシミュレーション結果が対策を全て反映した結果になりません。高速化作業の完了まで期間が延びる可能性があります。またPageSpeed Insightsスコア等も気にされる場合（SEOでは現状ですと必要ないです）は当方の作業でも期待通りのスコアに達しない可能性があります。
特にWebPageTestでモバイルかつLTE回線をシミュレーションする作業は高速化では大事でして、そのシミュレーションによる判断に影響が出ます。
一方で全てのサイトでこの対策が必要ではありません。この対策が必要なサイト（同じテーマでもレイアウト次第で必要な場合もあれば不要な場合もあります）に該当する場合本不具合が発生している期間中はpreload対策を必要としないサイトを同時作業において優先させていただきます。
この不具合が解消されるまでの期間
第三者としてはChromeの修正を待つのが一番です。不具合解消までに1ヶ月かかる事はないと見込んでいます。
本件については日頃情報交換する海外のWordPressプラグイン開発者と問題を共有しており、Chrome開発陣への不具合情報提供等についても代理で動いてもらう形で検討中です。
