１．WordpressでCocoonを使っていてCLSに関する問題が突然発生して困った人向けの話
2022年6月更新
最終的に私はCocoon設定→SNSシェアボタン→「トップシェアボタンの表示」のチェックを外して、メインカラムトップシェアボタンを非表示にする事で「CLS に関する問題: 0.10 超」をPC版サイトでも解決できました。
以下はやや古い記事です。
2021年5月からランキング要因にCore Web Vitals(コアウェブバイタル)という指標が使われるようになるという話がGoogleから発表されています。この指標はサーチコンソールから「ウェブに関する主な指標」として確認できるのですが、特に何もしてないのに「不良」になったり「改善が必要」になったり「良好」になったりする事があります。
本サイトは以前は特に問題なかったのですが、11月上旬に突然、「CLS に関する問題: 0.25 超（モバイル）」とモバイルに大量の「不良」が出るようになりました。詳しく調べると不良と出ているのは全部AMPページでした。
理由が全く分からずに苦戦したのですがようやくわかったので、WordpressでテーマにCocoonを使っている人向けのピンポイントの情報としてまとめておきます。
Cocoon 設定 → ヘッダーから
高さ
高さ（モバイル）
ヘッダーロゴサイズ
の３つを指定する事で私は回避できました。
以前は上記が空欄のままでも特に問題は指摘されなかったのですが、直近では指定してないとモバイルのAMPページでCLSに関する問題が、少なくとも本サイトでは指摘されるようになりました。
また、これもCocoon限定の話ですが、「目次の表示」→「目次を表示する」の部分をONにしているとCLSの数値が悪化する事があるように見えます。
WordPressでテーマにCocoonを使っているわけではなくとも、CLSに悩んでいる方はサイズ指定が出来ていない画像がないか再チェック、及び上記の目次のようにクリックすると開閉するアコーディオン的な(蛇腹的な)仕組みがどこかにないかチェックすると良いと思います。
また、キャッシュを無効化して、わざと遅いPC／スマホ／回線でアクセスするとCLSのズレが何で発生しているのか視覚的にわかりやすくなるのでオススメです。自分が使っている環境が早いとどの段階で何がずれてしまっているのか指摘されている部分がわからない時があります。
2021年1月26日追記）
上記に書いたように、以前はサーチコンソールの「ウェブに関する主な指標」のモバイルはAMPと通常ページが別々に評価されていたのですが、1月26日以降、AMPではない通常のモバイルページは評価対象に出なくなりました。
CLSの問題を調べていて気付いたその他の事
実は４種類ある
コアウェブバイタルは４種類存在します。
（１）PC用ページ
一番楽
（２）モバイル用ページ
少し上げにくい（2021年１月下旬以降、サーチコンソールでは評価対象にならなくなりました）
（３）PC用ページ(AMP)
二番目に楽（サーチコンソールでは評価対象になってません）
（４）モバイル用ページ(AMP)
これが一番上げにくい。
本サイトはPCユーザがモバイルユーザより圧倒的に多いと言う特性のためPC版のスコアが上げやすく、モバイル版のスコアに苦戦しています。理由はおそらくコアウェブバイタルが「過去 28 日間の収集期間のフィールド データ」を使ってスコアを付けているためです。
ユーザ数が多いとCDN(AMP含む)によるキャッシュが有効になる割合が高いため、平均速度は改善され、全般的にスコアは良くなります。しかし、ユーザ数が少なくページ数が多いと、キャッシュが利かないファーストアクセスが多くなるので結果として素のサーバーの性能が大きく影響するのでスコアは停滞気味になってしまいます。
2020年12月9日追記)
Googleが2020年12月3日に公開した「Core Web VitalsとPage Experienceに関するFAQ」を訳しました。現時点ではコアウェブバイタルがランキング要素に使われるのはモバイル検索になる予定であるようです。本サイトはモバイルで気軽に読むような記事はほとんどないので、な、なんだって～！という感じではあります・・・
慎重に調べないとトレードオフになる場合がある
コアウェブバイタルの指標は以下の３つです。
（１）LCP（Largest Contentful Paint）
最も大きなコンテンツ(画像等)が表示されるまでの時間
（２）FID（First Input Delay）
ユーザーが最初に操作を行った際に、ブラウザが反応するまでにかかった時間
（３）CLS（Cumulative Layout Shift）
後から表示されたコンテンツによってページのレイアウトがどれぐらいズレるか？
LCPやFIDを改善するために「レンダリングを妨げるリソースの除外」などで、最初の画面の表示に必要のないCSSやJSを非同期や後から読み込むようにしましょう的なアドバイスをPageSpeed Insightsが言ってくる時があると思うのですが、これを真に受けて実行するとCLSが悪化する場合があります。
レンダリングをブロックしているのではなく、レンダリングに使っているものを後読みしてしまって、読み込みが全て完了した時点でページのレイアウトが完成する、つまり場合によっては画像等の位置が後からずれるようになってしまうのでCLSが悪化する事があるのです。この逆もあり得ます。PageSpeed Insightsの言ってくる事はあまり鵜呑みにできない事があるので注意です。
https://maxcdn.bootstrapcdn.comは多分遅い
「レンダリングを妨げるリソースの除外」対象としてfont-awesome.min.cssが指摘される事が多く、こちらも困っていたのですが、font-awesomeの公式サイトに載ってるもう一つのCDNであるuse.fontawesome.comを使うようにthemes/cocoon-master/lib/_defins.phpを修正して、サイト高速化の事前読み込み対象サイトにも追加したら、font-awesomeに対する「レンダリングを妨げるリソースの除外」の指摘はなくなりました。ただ、点数的には１～２点程度しか上がっていないようのでmasterに手を加えてまでやるべきかというと微妙な気もします。
2020年12月4日追記)
use.fontawesome.comへの切り替え対応をした際、PageSpeed Insightsではエラーを指摘されなかったのですが、数日後にサーチコンソールから「許可されたフォント プロバイダを除き、外部のスタイルシートはサポートされていません。代わりにドキュメント インライン「style amp-custom」タグを使用してください。」とのエラーが出ました。良く良く調べるとuse.fontawesome.comはAMPプロジェクトのホワイトリストには登録されているのに、fontawesome側がもう使用しないと宣言しているとの事で、普通にアクセスするとNot Foundになってしまいます。そのため、maxcdn.bootstrapcdn.comの方に戻しました。
誰にどの項目の改善を任せるのか考える事が大切
登場人物は５名、プラグイン等は楽なのでポチポチと高速化をやってくれそうなチェックボックスをONにしたくなりますが、相互に打ち消し合ったり、上書き/スキップされて有効になっていなかったりするので誰に何を任せるのか意識した方が良いです。
（１）CDN(AMP含む)
キャッシュがやってくれている(やらかしてくれている)場合がある
（２）Webサーバー
キャッシュやRewriteなどがやってくれている(やらかしてくれている)場合がある
（３）ワードプレス
組み込み処理が色々とやってくれている(やらかしてくれている)場合がある
（４）ワードプレスのテーマ
独自の高速化やキャッシュ、AMP用の特殊処理などが色々とやってくれている(やらかしてくれている)場合がある
（５）ワードプレスのプラグイン
キャッシュ用のプラグインや画像最適化プラグインなどが高速化のために色々とやってくれている(やらかしてくれている)場合がある
Webサーバ側でWebp対応ブラウザのみにWebpを配信するように.htaccess等で設定してCDNも使っていると一部で誤動作するけど中々気づけない
Cocoonの限定の話ではありませんが、PageSpeed Insightでスコアを上げるためのヒントとして提案される事の多い、WebP等の新画像フォーマットですが、プラグインなどを使えば導入はそれほど難しくないですが、全ブラウザに対応するのはWebP対応のCDNを選択する必要があり難しいです。
一般的なWebP対応の際は、Webサーバ側でmod_rewrite等でwebp対応ブラウザだったらjpegやpngをリクエストされてもwebpを返すように設定して対応すると思いますが、CDNによってはキャッシュされている画像があればサーバ側に問い合わせずにブラウザに返してしまうため、
Webp非対応ブラウザがアクセスしてキャッシュ作成→Webp対応ブラウザがアクセス
Webp対応ブラウザがアクセスしてキャッシュ作成→Webp非対応ブラウザがアクセス
のいずれのパターンも意図通りに動きません。そしてなかなか動いていない事に気づけません。WordPressの場合であればEWWW Image OptimizerのJS WebP リライト機能で対応可能という話もあるですが、AMPサーバでの動作が確認できていないのと、LabデータだとCLSが悪化したりしなかったりする謎の挙動を示すので問題なく対処できているのかどうかがわからず悩みます。
「Webp前提で非対応ブラウザを切り捨てる」 or 「Webp非対応ブラウザも対応するが全体的なコアウェブバイタルは悪化する」の２択になりますが、2021年春まで後者で行って春頃にもう一度ブラウザ比率を見て、場合によってはWebpへの切り替えアナウンスをして切り替えてしまうおうかなと考えています。
第三の道として、amp-img タグを入れ子にして外側は.webp指定、内側はfallbackステータスを付け加えて元画像指定にする事を自分で頑張って実装すれば対応可能になるという話もあるので、これも考えましたが無駄な通信が発生する懸念があるのと、春までにWordPress本体または何らかのプラグインかテーマが素敵な解決策を見つけてくれる可能性があるのでこちらはペンディングとします。
Googleも開発に関わっているワードプレスのプラグインでAMP(AMP Optimaizer)も試してみましたが、推奨設定ではURLからAMP=1のパラメータを自動削除してくるようで問題の切り分けが非常にやりにくくなったので導入は見送りました。やはり丁寧にどの段階で何を対処するのかを整理していなかないとダメだと思いました。
と言うか、webp非対応ブラウザは特にサファリ13以前等、まだそこそこいるのにPageSpeed Insightsが次世代画像の利用を推奨してくるのはどうなのか？
世の中にはまだまだ3G等の細い回線を使っている人もいるんじゃよ、的な事を言ってくる場合もあるのにブラウザはwebp対応前提で良いのかね？とは思います。