MENU
ExcelVBAを中心にお役に立てる情報を発信しています
  1. ホーム
  2. Webの基礎学習
  3. WordPress×PHP
  4. 【WordPress高速化】SWELLのCLSをCSSで改善

【WordPress高速化】SWELLのCLSをCSSで改善

記事内には広告が含まれます
WordPress×PHP
【WordPress高速化】SWELLのCLSをCSSで改善
目次

はじめに

「WordPress高速化」シリーズの第2回です。【WordPress高速化】CLSの原因を検証ツールで探す方法（以下「前回の記事」）では、Chromeの検証ツールで、ずれた場所を見つけて高さを測る方法を紹介しました。

今回は、その続きです。当サイト（WordPressテーマ「SWELL」）で、実際にどの場所に、どんなCSSを追加したかを紹介します。結果、PageSpeed InsightsのCLSは次のように変わりました。

PageSpeed InsightsのCLSの変化。対策前0.14、content-visibilityを入れて0.26に悪化、min-heightに変えて0.02、コードの表示を調整して0.0026、最終的に0.0008

途中で一度、かえって悪化させてしまった書き方もありました。うまくいった方法と合わせて、失敗した理由も解説します。

この記事の数値（高さ）は、当サイトのレイアウトで測ったものです。ウィジェットの構成や記事下の設定はサイトごとに違うので、そのままコピーせず、前回の記事の方法で自分のサイトの高さを測ってから使ってください。

当サイトで起きていたこと

Search Consoleで、パソコンの「CLS に関する問題: 0.25 超」が174件出ていました。不良だったのは記事ページで、カテゴリーページは良好でした。

前回の記事の方法で調べると、SWELLの記事ページには、読み込みの後から高さが変わる場所がいくつもありました。

SWELLの記事ページで、後から高さが変わる場所。メイン列の目次、目次下の広告、記事下エリア（前後の記事、著者、関連記事、記事下の広告）、サイドバーのウィジェットと広告
場所後から高さが変わる理由
目次SWELLはJavaScriptで目次の中身を作るため、最初は中身がない
広告枠広告が届くまで高さが0
記事下エリア関連記事などが後から入り、フッターが押し下げられる
サイドバーのウィジェット人気記事や新着記事が後から入る

なお、AdSenseの自動広告は全画面広告（オーバーレイ）だけを使っていました。ページの上に重ねて表示されるだけなので、本文は動かず、CLSの原因にはなりません。

対策の基本：min-height で高さを先に確保する

対策の考え方は1つだけです。後から中身が入る場所に、先に高さを確保しておく。中身が入っても高さが変わらなければ、下の文章は動きません。

高さの測り方と、min-heightを設定する場所（入れ物の側）の考え方は、前回の記事の「方法3」で解説しています。パソコンとスマホで高さが違うので、SWELLの切り替え幅（960px）で分けて書きます。測った値は小数点つきのままで構いません。

以下のコードは、当サイトの追加CSS（「外観」→「カスタマイズ」→「追加CSS」）から要点を抜き出したものです。

対策1：目次と目次下の広告

SWELLの目次（.p-toc.-double）は、ページの表示後にJavaScriptで中身が作られます。その直前まで目次は空なので、中身が入った瞬間に本文が押し下げられます。目次の下にある広告枠（.w-beforeToc）も、広告が届くまで高さが0です。

/* パソコン表示（画面幅960px以上） */
@media screen and (min-width: 960px) {
	/* 目次 */
	.p-toc.-double {
		min-height: 313px !important;
	}
	/* 目次下の広告 */
	.w-beforeToc {
		min-height: 280px !important;
	}
}

/* スマホ表示（画面幅959px以下） */
@media screen and (max-width: 959px) {
	.p-toc.-double {
		min-height: 314.84px !important;
	}
	.w-beforeToc {
		min-height: 280px !important;
	}
}

目次の高さは、SWELLの目次の設定によって決まります。当サイトの設定は次のとおりです。

設定当サイトの値
目次に表示する見出しh2まで
目次の省略表示項目が5個を超えると省略

この設定では、目次に表示される項目は最大5個なので、目次が313pxより高くなることは基本的にありません。見出しが5個より少ない記事では、確保した高さの下に少し余白が出ます。

目次にh3まで含めるなど設定を変えると、目次の高さも微妙に変わります。設定を変えたら、高さを測り直しましょう。

対策2：記事下エリア（前後の記事・著者・関連記事）

記事本文の下にある.l-articleBottomには、前後の記事へのリンク、著者の紹介、関連記事が並びます。関連記事は読み込みの少し後に中身が入るため、一瞬見えていたフッターが押し下げられるずれが起きていました。

そこで、全体を囲む親の要素と、中の3つの要素の両方にmin-heightを設定しました。

/* パソコン表示（画面幅960px以上） */
@media screen and (min-width: 960px) {
	/* 記事下エリア全体 */
	.l-articleBottom {
		min-height: 1195px;
	}
	/* 前後の記事へのリンク */
	.p-pnLinks.-style-normal.-thumb-on {
		min-height: 63px;
	}
	/* 著者の紹介 */
	.p-authorBox {
		min-height: 295px;
	}
	/* 関連記事 */
	.l-articleBottom__section.-related {
		min-height: 583px;
	}
	/* 記事下の広告 */
	#swell_ad_widget-9 {
		min-height: 280px !important;
	}
}

スマホ用の値は次のとおりです。スマホは横幅が狭く、関連記事などが縦に並ぶので、パソコンよりかなり高くなります。

場所セレクタパソコンスマホ
記事下エリア全体.l-articleBottom1195px1806px
前後の記事.p-pnLinks.-style-normal.-thumb-on63px96px
著者の紹介.p-authorBox295px439px
関連記事.l-articleBottom__section.-related583px1100px
記事下の広告#swell_ad_widget-9280px280px

当サイトでは、関連記事の中にインフィード広告を表示する設定が残っていました。広告が入るかどうかで関連記事の高さが変わってしまうため、インフィード広告の設定は削除しました。CSSで高さを確保するより、高さが変わる原因そのものをなくすほうが確実な場合もあります。

#swell_ad_widget-9のような番号は、ウィジェットを追加した順番で決まるので、サイトごとに違います。次の「対策3」で調べ方を紹介します。

対策3：サイドバーのウィジェット

パソコン表示では、記事の右側にサイドバーがあります。人気記事・新着記事・広告などのウィジェットも、後から中身が入ると下のウィジェットを押し下げます。

ウィジェットは、IDで1つずつ指定しました。IDは、ウィジェットを右クリック→「検証」で、ウィジェットを囲む要素のid="swell_popular_posts-3"のような部分を見て確認します。

/* パソコン表示（画面幅960px以上） */
@media screen and (min-width: 960px) {
	/* 人気記事（記事カード×5） */
	#swell_popular_posts-3 {
		min-height: 488px;
	}
	/* 新着記事（記事カード×5） */
	#swell_new_posts-2 {
		min-height: 488px;
	}
	/* サイドバーの広告（2つ） */
	#swell_ad_widget-3,
	#swell_ad_widget-2 {
		min-height: 250px !important;
	}
}

このほかのウィジェット（おすすめ記事、サイト内検索など）にも、測った高さを設定しました。スマホではサイドバーの内容が記事の下に表示されるので、スマホ用の値も別に測っています（人気記事・新着記事は583px）。

失敗例：content-visibility でかえって悪化した

記事下エリアの対策で、最初に試したのはmin-heightではなく、次の書き方でした。

/* ※悪化した書き方（使わないでください） */
.l-articleBottom {
	content-visibility: auto;
	contain-intrinsic-size: 1195px;
}

content-visibility: autoは、画面の外にある部分の描画を後回しにして、表示を速くするプロパティです。描画を後回しにしている間は、contain-intrinsic-sizeで指定した仮の大きさで場所を取っておきます。

ところが、これを記事下エリア全体に入れたところ、PageSpeed InsightsのCLSは0.14から0.26に悪化しました。

content-visibility: autoの仕組み。画面の外にある間は仮の大きさで場所を取り、画面に近づいたときに本当の中身を描画する。仮の大きさと本当の高さが違うと、その差の分だけページがずれる

画面に近づいて本当の中身が描画されたとき、仮の大きさと実際の高さに差があると、その差がずれになります。記事下エリアは関連記事や広告が後から入るため、仮の大きさと合いにくかったと考えられます。

content-visibilityをやめてmin-heightに変えたところ、CLSは0.02まで下がりました。

ただし、必ず悪化するわけではありません。当サイトでは関連記事やサイドバーの人気記事・新着記事にも指定していますが、問題は出ていません。それでも、CLS対策が目的なら、まずmin-heightで高さを確保するほうが確実です。

追加CSSのエディターでは、content-visibilityなどの新しいプロパティが赤い文字で表示されることがあります。これはエディターのチェック機能が新しいプロパティを知らないだけで、動作には影響しません。

最後の微調整：インラインのコードとコードブロック

0.02から先の原因は、本文中のコードの表示でした。当サイトはプログラミングの記事が多く、文中のコード（<code>）とコードブロック（プラグイン「Highlighting Code Block」、以下HCB）がたくさんあります。

文中のコード

文中の<code>に付けている余白や枠線のせいで、行の高さがわずかに変わっていました。display: inlineにして、行の高さを周りの文章と同じ（inherit）にしました。

/* 文中のコード：周りの文章の行の高さに合わせる */
.post_content p code {
	display: inline !important;
	vertical-align: baseline !important;
	padding: 0.2em 0.4em !important;
	margin: 0 0.4em !important;
	border: 1px solid #e2e8f0 !important;
	line-height: inherit !important;
}

HCBのコードブロック

検証ツールの「レイアウト シフト」タブで、HCBのコードブロックが表示の直後に下へ伸びて、元に戻る動きをしているのが見つかりました。コードの中に日本語が混じると、等幅フォントと日本語フォントが切り替わり、行の高さが一瞬変わっていたのが原因です。

そこで、行の高さと等幅フォントを固定しました。

/* HCBのコードブロック：余白・行の高さ・フォントを固定する */
.hcb_wrap {
	margin-top: 28px !important;
	margin-bottom: 28px !important;
}
.hcb_wrap code {
	line-height: 21px !important;
	font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace !important;
}

28pxと21pxは、当サイトのHCBの元の値を「計算済み」タブで測ったものです。見た目は変えずに、値を固定しただけです。この2つの調整で、CLSは0.0026、最終的に0.0008になりました。

AIに聞いたCSSを使うときの注意

今回のCSSは、Google検索のAIモードに相談しながら作りました。とても助かりましたが、回答には根拠の弱い説明や副作用のある提案もありました。

  • 「小数点の端数（0.988pxなど）がCLSの原因」という説明：根拠が弱いです。効いたのは、高さの確保と、行の高さ・フォントの固定だと考えられます
  • text-renderingや-webkit-font-smoothingの追加：文字の描き方を変えるだけで、位置は変わらないので、CLSにはほぼ関係ありません
  • 本文の画像にaspect-ratioやwidth: 100% !importantを指定する提案：画像が縦に約1500pxに伸びたり、横幅いっぱいに拡大されたりしました。WordPressは画像にwidthとheightの属性を出力しており、ブラウザはそれを使って最初から縦横比を確保します。そのため、画像のずれ対策のCSSは基本的に不要です

AIの回答は、1つずつ反映して、そのたびに測るのがおすすめです。まとめて入れると、どれが効いたのかわからなくなります。

Search Consoleで改善を確かめる

PageSpeed Insightsの0.0008はラボの値（テスト用ブラウザで1回測った結果）です。Search Consoleは実際の訪問者のフィールドデータを使うので、反映には約28日かかります（違いは前回の記事で解説しています）。

CSSを追加したら、Search Consoleの「ウェブに関する主な指標」→「PC」→「CLS に関する問題」を開き、「修正を検証」をクリックしておきましょう。当サイトの結果（不良174件がどう変わったか）は、わかり次第この記事に追記します。

上級者向けの補足

[上級者向け補足]
Node.jsからChromeを操作して、スクロール中のずれを自動で記録するスクリプトも試しましたが、自動化したブラウザでは広告の出方が実際と違い、ずれを再現できませんでした。自分のChromeで、読者と同じように操作して確かめるのが一番確実です。

よくある質問・エラー対処

Q. CSSを追加したのに、見た目もCLSも変わりません

→ キャッシュが残っている可能性があります。SWELLの「SWELL設定」→「キャッシュクリア」や、キャッシュ系プラグイン・サーバーのキャッシュを削除してから確かめてください。また、min-height: 621.2px; !important;のようにセミコロンの位置を間違えると、その行は正しく読み込まれません。単位の付け忘れ（28ではなく28px）にも注意しましょう。

Q. 目次の下に空白ができてしまいました

→ 見出しが少なく、目次の項目が省略表示の上限（当サイトでは5個）に届かない記事では、確保した高さが余るためです。値を小さくすると、項目が上限まである記事で目次が伸びて、またずれが起きます。ずれをなくすことを優先して、項目が上限まであるときの高さに合わせておくのがおすすめです。見出しの数に合わせて、記事ごとに目次の高さを自動で変える方法は、このシリーズの今後の回で紹介する予定です。なお、関連記事の件数やウィジェットの並びを変えたときは、高さを測り直してmin-heightの値も見直してください。

おわりに（まとめ）

まとめ

SWELLのCLS対策は、後から中身が入る場所に、先に高さを確保することが基本です。

  • ✅ 目次・広告枠・記事下エリア・サイドバーに min-height を設定した
  • ✅ パソコンとスマホで値を分ける（SWELLの切り替え幅は960px）
  • ✅ content-visibility を記事下エリア全体に入れたら、CLSが0.14から0.26に悪化した
  • ✅ 最後の0.02は、文中のコードとコードブロックの行の高さ・フォントの固定で解消した
  • ✅ AIの提案は1つずつ入れて、そのたびに測る
  • ✅ Search Consoleへの反映は約28日後。「修正を検証」を押しておく

この記事が、少しでも誰かのお役に立てれば幸いです。

関連記事

当サイトの記事で使用したVBAなどのサンプルをDLできます

この記事のサンプルはありません！

ダウンロードページへは下のカードをクリックすればジャンプできます。
よろしければご利用ください！

サンプルのダウンロードはこちらから
【Excel VBA】記事内サンプルファイルダウンロードのページ 【Excel VBA】の記事内で使ったサンプルファイルを（Zipファイルで）ダウンロードできるようにしました。記事内では細かい部分の解説が不十分ですが、実際にファイルをダウ…


【CSS】テキスト関連プロパティについて基本解説｜Webの基礎

WordPress×PHP
CLS Core Web Vitals CSS min-height SWELL WordPress 高速化
よかったらシェアしてね！
  • URLをコピーしました！
目次