本記事は、KUSANAGI for ConoHa（1Gプラン）でPageSpeed InsightsとGTmetrixのスコア改善を図った過程です。
PageSpeed Insights新版ですとLCPの改善方法となります。
アイキャッチの画像はConoHaイメージキャラクター美雲このは (C)GMO Internet, Inc. 再利用禁止
謎の項目「表示可能コンテンツの優先順位を決定する」
一番手こずった項目です。
説明ページ を読んでも、他のページと違って具体的にどうすればいいのかさっぱりわかりません。
説明ページのポイントは、
・リソースで使用されるデータの量を減らす。
・スクロールせずに見える範囲のコンテンツのサイズを削減する。
コードの見直しをする
ここでLuxeritasを作った「るな 」さまのページを見てみる。
100-100、さすがです。
ということはLuxeritasの構造には問題ないことになる（当たり前ですが）。
トップページのコード、相当いじったしなあ……と見直してみます。
するとかなりのアラが。
セレクタの組み方間違えていたり、無駄な構成あったり。
一つ一つ自分で作るつもりで見直していきました。
その結果。
他にも検索してはあれやこれや試してみましたが、全然ダメ。
どうしようって感じでした。
原因（？）判明！
しかし、サイト記事更新した後、PageSpeed Insightsで計測したところ……。
なぜか項目が消えていました。
たまたまではなく何回やっても消えています。
はて？
まあ消えたならいいこと。
次を更新しよう。
そして更新後……
呆然としながらトップページを眺める。
しかしそこで原因に気づきました。
「表示可能コンテンツの優先順位を決定する」の原因はファーストビューにおける画像のファイルサイズ
本サイトは先頭固定記事を大きく表示するレイアウトにしています。
こんな感じ。
現在は「表示可能コンテンツの優先順位を決定する」が表示されていません。
画像サイズは5kbです。
一方で、
(C)GMO Internet, Inc. 再利用禁止
これをサムネイルに使ったときは出ました。
前者に比べていかにも重そう。
画像サイズを調べてみると18kb。
つまり、
まさに「サイズを小さくする」という指摘そのものの原因です。
……と言っても。
圧縮してこれなのだから、どうしようもないです。
「サイトおしらせ」も兼ねて大きくしてあるので、このレイアウトはやめたくない。
画質30まで落としてもファイルサイズはそんなに減らない。
ということで、「これでいい」と割り切りました。
サムネイルサイズ次第のものをこだわってもしかたありませんので。
ただ原因が判明して、すっきりはしました。
【2017/3/17追記】子テーマのstyle.cssファイルを分離する ～AutoptimizeやLuxeritasの結合機能を使っている場合
「表示可能コンテンツの優先順位を決定する」の別の解決法を見つけたので追記しておきます。
ある程度カスタマイズしてstyle.cssが肥大化している場合（20kbくらい）、かつLuxeritasのCSS結合機能を使っている場合限定です。
それは、次の通り。
→CSSを結合し、インライン化する（インライン化しないとレンダリングブロックチェックに引っ掛かるたため）。
→関係ない方のCSSファイルを圧縮し、非同期で読み込ませる。
CSSの圧縮はこちらで。
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);
ファーストビューの必要な部分をインライン化するという手法が一般に知られてますが、その考えと近いです。
単に結合するだけだとファーストビューに不要な部分まで結合するので、その結果「表示可能コンテンツの優先順位を決定する」を注意をされます。
なので分離して、（結合圧縮された）style.min.cssの量を減らすわけです。
これと同じ現象はプラグインAutoptimizeでも生じます。
Autoptimizeの場合は結合から除外するcssを指定。
（Luxeritasと違い、何も指定しなければ全てのcssを結合する）
上記のスクリプトファイルを作成→実行すればいいです。
なお、高速化に一番効くのは「ファーストビューに使う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の攻略です
コメント