本記事は、KUSANAGI for ConoHa（1Gプラン）でPageSpeed InsightsとGTmetrixのスコア改善を図った過程です。
PageSpeed Insights旧版「表示可能コンテンツの優先順位を決定する」の改善策として書いた記事です。
新版ですとLCP（Largest Contentful Paint）の改善方法となります。
アイキャッチの画像はConoHaイメージキャラクター美雲このは (C)GMO Internet, Inc. 再利用禁止
謎の項目「表示可能コンテンツの優先順位を決定する」（旧PSI）
一番手こずった項目です。
説明ページ を読んでも、他のページと違って具体的にどうすればいいのかさっぱりわかりません。
説明ページのポイントは、
・リソースで使用されるデータの量を減らす。
・スクロールせずに見える範囲のコンテンツのサイズを削減する。
何を言ってるのか全然わからない
※後者はファーストビューのことです。
CSSコードの見直しをする
ここでLuxeritasを作った「るな 」さまのページを見てみる。
100-100、さすがです。
ということはLuxeritasの構造には問題ないことになる（当たり前ですが）。
トップページのコード、相当いじったしなあ……と見直してみます。
するとかなりのアラが。
セレクタの組み方間違えていたり、無駄な構成あったり。
一つ一つ自分で作るつもりで見直していきました。
その結果。
速くはなったけど、「表示可能コンテンツの優先順位を決定する」は消えない！
他にも検索してはあれやこれや試してみましたが、全然ダメ。
どうしようって感じでした。
PSIに指摘された原因判明！
しかし、サイト記事更新した後、PageSpeed Insightsで計測したところ……。
消えてる！？
なぜか項目が消えていました。
たまたまではなく何回やっても消えています。
はて？
まあ消えたならいいこと。
次の記事を更新しよう。
次の記事を更新した後、
また出た！
呆然としながらトップページを眺める。
しかしそこで原因に気づきました。
「表示可能コンテンツの優先順位を決定する」の原因はファーストビューにおける画像のファイルサイズ
ヒントは「記事を更新して注意が消えて、別の記事を更新したら注意が出たことでした。
つまり、
原因は、ファーストビューにおける「イラストの密度」の差にあります
（当時の）本サイトは先頭固定記事を大きく表示するレイアウトにしています。
こんな感じ。
現在は「表示可能コンテンツの優先順位を決定する」が表示されていません。
画像サイズは5kbです。
一方で、
(C)GMO Internet, Inc. 再利用禁止
これをサムネイルに使ったときは出ました。
前者に比べていかにも重そう。
画像サイズを調べてみると18kb。
つまり、
単純に画像のファイルサイズが大きかったからいけなかったのね
と言っても、圧縮してこれなのだからどうしようもない。
「サイトおしらせ」も兼ねて大きくしてあるので、このレイアウトはやめたくない。
ということで、「これでいい」と割り切りました。
サムネイルサイズ次第のものをこだわってもしかたありませんので。
ただ原因が判明して、すっきりはしました。
【2024年追記】
この帰結として、トップページに大きいファーストビュー画像を採用したレイアウトはPSIスコアが落ちます。
トップページだけですので実用上はあまり関係無いと思われますが、PSIスコア重視なら避けた方がいいです。
【2017/3/17追記】子テーマのstyle.cssファイルを分離する ～AutoptimizeやLuxeritasの結合機能を使っている場合
「表示可能コンテンツの優先順位を決定する」はCSSが肥大化している場合にも生じます。
そのため別の方法でも解決できます。
ある程度カスタマイズしてstyle.cssが肥大化している場合（20kbくらい）、かつLuxeritasのCSS結合機能を使っている場合限定です。
それは、次の通り。
→CSSを結合し、インライン化する（インライン化しないとレンダリングブロックチェックに引っ掛かるたため）。
→関係ない方のCSSファイルを圧縮し、非同期で読み込ませる。
CSSの圧縮機能はCocoonやLuxeritasですとついています。
ついてないテーマはこちらでどうぞ。
CSSを非同期で読み込ませる方法は、luxe.jsに次の記述をします。
(function(){
var n = document.createElement('link');
n.async = true;
n.defer = true;
n.type = 'text/css';
n.rel = 'stylesheet';
n.href = '【CSSファイルまでのパス】';
var s = document.getElementsByTagName('script');
var c = s[s.length - 1];
c.parentNode.insertBefore(n, c);
})(document);
ファーストビューの必要な部分のCSS（＝クリティカルCSS）をインライン化するという手法が一般に知られてますが、その考えと近いです。
単に結合するだけだとファーストビューに不要な部分まで結合するので、その結果「表示可能コンテンツの優先順位を決定する」を注意をされます。
なので分離して、（結合圧縮された）style.min.cssの量を減らすわけです。
実際にこの方法で警告消えたよ
これと同じ現象はプラグインAutoptimizeでも生じます。
Autoptimizeの場合は結合から除外するcssを指定。
（Luxeritasと違い、何も指定しなければ全てのcssを結合する）
上記のスクリプトファイルを作成→実行すればいいです。
おまけ
「無駄」を削る過程で色々試してみて、記事の趣旨とは関係なく高速化に効果あった方法を紹介します。
KUSANAGIプラグインでテーマの翻訳を切る
KUSANAGIを使ってなくとも「001 Prime Strategy Translate Accelerator」は多くの方が使っていると思います。
高速化とくれば絶対に名前の出てくるプラグインですから。
これにつき、KUSANAGIかつ同プラグインの提供元であるプライム・ストラテジー社社長「中村けん牛」様の記事。
「翻訳を停止」して高速化する
WordPressに再度ログインして、翻訳アクセラレータの設定画面で「サイトに表示される翻訳された文章」の項目を「翻訳を停止」に設定してください。
（略）
この設定は、「テーマに翻訳処理がほとんど含まれていない場合」に大変有効です。
（略）
Webサイトのフロントでは翻訳処理そのものをスキップすることで、英語版のWordPressと同等のパフォーマンスを得ることができます。
その発想はなかった！
翻訳をキャッシュすれば速くなる。
これは当たり前に思い浮かびますし、同プラグインでキャッシュしていたわけです。
どこのサイトでも「キャッシュをする」にしておくように書いてました。
しかし実際問題として使うのは国産テーマ。
そもそも管理画面以外、翻訳自体が要らないわけで。
まさに目からウロコでした。
抜粋を呼び出すコードをget_the_excerptに変更する
tantan様の以下の記事で紹介されていました。
よく使われているのはこちら。
<?php the_excerpt(); ?>
これを以下に変更します。
<?php echo get_the_excerpt(); ?>
抜粋の多いページなら、体感でわかるほどキビっとします。
ただし<p>タグを付与しなくなるためCSSの変更しないといけない場合もあります。
まとめ
「表示可能コンテンツの優先順位を決定する」は、よくわからないって人多いみたいです。
有効な解決法の１つは「ファーストビューのサイズを単純に小さくすること」。
もし当サイトと同じく大きいサイズの画像を用いている場合は、小さいサイズのものに入れ替えて試してみてください。
次回からはGTmetrixの攻略です
