スピードスコアテストの考察

投稿 2018年07月04日
2
webのあれこれ
InstructionMFISEO高速化

考察というかですね、スコアばかり気にしていると本質を見失いかねない という注意喚起でもあります (´・ω・`)

GTmetrixPageSpeed Insights でテストをするのは大変結構なことではありますけれど、スコアに気を取られすぎて泥沼にはまり込んでいる方も(笑)

GTmetrixは何を指摘しているのか

GoogleのSpeed Insightsは置いといて、GTmetrixを中心に説明したいと思います。
GTmetrixの結果ではスコアが2つ出てきますが、左がGoogle、右はYahoo!のAPIよる測定結果です。
GoogleとYahoo!は 重要視する内容が違う ので結果も違ってきます。

スコアは提案の有無である

GTmetrixが、というよりもいろんなスピードテスト系ツールが何をしているかというと、
この内容を表示するのにもっと出来る何かがあるんじゃないの?
という指摘なんですね。

この内容を」というのはですね、既に適用されているデザインだとかレイアウトだとかそういうものを「維持する」というのが前提になっているわけです。
この前提が無ければ「ページに画像を掲載しないでください。」「JSは使わないでください。」「CSSはなるべく使わないでください。」といった極端な指摘も可能になってきます。
そうではなくて、「そのページ内容ならここをもっと良くできるんじゃない?」という 提案 である、と。そゆことですね (´・ω・`)

よく勘違いされているようですが、
ページの表示(ローディング)が早ければハイスコアに、遅ければロースコアになるというわけではない
んです。ここ重要。

  • 提案数が多い = 修正できそうな箇所が多い = ロースコア
  • 提案数が少ない = 修正できそうな箇所が少ない(やれることはほぼやり尽くしている) = ハイスコア

こういうことなんですよ? (´・ω・`)
例えば「ローディングが0.8秒でDスコア」のページもあれば、「ローディングが2秒でAスコア」のページも実際にあるんです。
閲覧者が「このページは速い」と感じるのは スコアではなく体感速度 ですよね。
スコアの高低はテストして初めてわかることであって、一般読者はスコアを目安にはしていません。

ただし理論上は「スコアを高くする(提案に従う)ことでローディングスピードが向上するかもしれない」のですから、できることはやっていこうよ、と。
じゃあできないことはどうするか。
やらない。つか、やれない。

なんでこのスコアになるのか、なんで対処ができないのか、この辺りの割り切りがスムースにできるかどうかも大切のように思います。
つまり「割り切り力」(笑)

GoogleとYahoo!の主な提案は「クリティカルレンダリングパス」の最適化

スピードテストがざっくり何を目指しているかというと、
クリティカルリソースを減らす
ことです。

クリティカル というのは強い英語表現ですね。
「致命的な」「重大な」「危機的な」という意味を持っており、良い意味で使われることは稀です。
レンダリング とは「描画」のこと。
データを実際の音声や画像など五感で理解できる形に具現化することを指します。
パス とは「通路」「道すじ」のことです。
つまり「クリティカルレンダリングパス」とは
描画の際に最重要とみなされる工程
のことだと思えば大体合ってます。
そして「クリティカルリソース」とは
めちゃくちゃ重要だとみなされるリソース(資源, ここでは様々なファイルのこと)
のことです。簡単に言うと「最重要リソース」ですね。

そのリソース(htmlファイルやCSSファイルやJSファイルなど)が 実際にクリティカルなのか、それとも クリティカルになってしまっているのか という判断をちゃんと行いましょう、ということなんですね。

例えばCSSファイルは通常 <head> 内にしか置けません。
(JSのcreateElementを用いた設置などは除外します)
そしてCSSファイルというのはクリティカルリソースです。
また、JSファイルも同じく通常はクリティカルリソースです。

外部CSSファイルをいくつも小分けにしてはいけませんよ、という記事を過去にUPしています。

head内を整理しましょう - カスタマイズ

テンプレートのカスタマイズが大好き。jQueryやCSSも色々やってみたい。 という方に気をつけて頂きたい点をまとめようと思います。 無作為にポンポンと外部ファイルを追加しない 色々やりたい気持ちはわかりますしやっても全然構いませんけれども、head内がゴッチャゴチャのグッチャグチャになっている方がとても多いんですね (∵`)...

CSSファイルはそれ一つがクリティカルリソースですから、複数のファイルがあればそれぞれ全てがやはりクリティカル。
つまりCSSファイルが5つあればクリティカルは5つ存在することになります。
だから「一つにまとめようね」という説明をしたのが上記リンク先の記事内容です。
一つにすれば単純にクリティカルリソースの数は一つで済みます。

JSファイルはhead内に置いても置かなくてもいずれにしろクリティカルです。
なので可能な限り async を指定します。
JSがhtml内で見つかるとhtmlの描画は一旦中断され、JSの内容に集中します。
(headへのJSファイル設置を避けてbody終了タグ直前にまとめるのはこのためです)
ただhtml後方にまとめたところでJSが稼働するまで他の作業はストップしてしまいます。それがクリティカルである所以です。
スクリプトファイルにasync属性を追加すると、JSの解釈を待たずに他の作業を並行することが可能になります。
つまりクリティカル化を避けることができるわけですね。
そしてCSSファイルと同様、JSも可能な限り一つのファイルにまとめることをおすすめします。

ファイルをまとめること、JSへのasync指定はとても大事

みなさんが容易にできそうなのは「CSSファイルをまとめること」だと思います。
JSファイルは記述の順序がとても大事ですし、「個別記事では必要だけどトップページでは不要なJS」といったようにページ種で要不要が分かれる内容もあります。
不要なページではJS自体を読み込む必要が無いのですから、なんでもかんでも一つにまとめれば良いというわけでもありません。
また、テンプレート製作者は「ユーザーによるカスタマイズ」も念頭に置いてコーディングをしています。
JSファイルとJSの実行コードとが分けられている場合、元ファイルを解釈してから実行、という手続きを踏まなければならないところ、元のJSファイルにasyncが指定されていては実行コードとの順序が逆転してしまう可能性があります(というか逆転します)
そうなるともうそのJSは機能を失ってしまいますので、そんなに単純な作業ではありません。
実行コードもファイルに含めてしまえば良いのですが、ちょっとした変更を加えたい際などは困ることに(笑)

JSファイルをまとめる際は、ファイルの順序、実行コードも含めること、ページ種別の切り分け、などに注意して作成してください。
これは高度な部類に入るかなぁと思います (´・ω・`)

クリティカルリソースを減らせればスコアが上がります。

注目すべきは DOMContentLoadedまでの時間

Google Chromeがわかりやすいので例に取ります。
右クリック > 要素検証 > Network
ネットワークタブで Waterfall の確認ができます。
どんなリソースがどの段階でロードされて何秒要しているか、といった図ですね。

エラーが一つ出てますがブラウザ拡張のadblockのせいなので無視してください。
紫のラインが表示されています。これが DOMContentLoadedです。
この 紫のラインが出てくるまでの秒数を短縮しなさいよ というのがスピードスコアテストが主に言っていることなんですね。

クリティカルリソースが多ければ多いほどこの紫ラインは右に移動します。
少なければ少ないほど左に移動します。

紫が左になったからといって赤ラインも同じ分量左に移動してくれるわけではありません。
ここがちょっとしたジレンマを感じるところだと思います(笑)
ですが理論値としては紫が早く出れば赤も多少早く出る、と。
赤は「全てのリソースのロードが終わりました」を意味しています。
つまり「Fully loaded time」で、ページ表示速度はこれのことです

たぶん多くの方が赤いラインばっか気にしているのではないかと思います。
スコアに大きく関連するのは寧ろ紫の方 ですYO (o'ω')

ページ表示速度が速くてもスコアが低いことは往々にしてある

私のブログのトップページからテキトーに選んで判定してみました。

ページスクリーンショット

キャッシュなし初回訪問時waterfall

キャッシュありwaterfall

キャッシュなし状態でのDOMContentLoadedは 720ミリ秒。
フルロードが 953ミリ秒
ということでページは1秒以内に表示されていることがわかります。
これは無料ブログでは上出来と言っても良いのではないかと。

キャッシュが効いている状態でのDOMContentLoadedは 163ミリ秒。
フルロードが 433ミリ秒
いやもうこれめっちゃ速いでしょう。自画自賛とはいえ (´・ω・`)

ところがこのページをGTmetrixで判定すると…。

Googleは Cスコアですよ。C(笑)
1秒以内で表示されてもC (GTの結果はカナダサーバーなので数ミリ秒遅くなっていますが)
このページはたまたま記事の右下段がNo imageなので画像の通信リクエストが発生していません。
もしここにも画像が表示されていたらこのページの判定は Dスコア です。

一方Yahoo!の判定は Aスコア ですね。
なんでこんな差が出るかというと Googleは画像のサイズにうるさい からです。
でもこのページの速度を「遅い」と感じる方はまず居ないと思います。だって1秒以内なわけだし(笑)
でもスコアはCよ。CとかDなのよ emoji
スコアにこだわりすぎるな、という持論(もちろんFC2ブログ上でです)の証明でもあります。

FC2ブログのトップページサムネイルの仕組み

サンプルにしたページは 要約表示タイプ のテンプレートです。
トップページでは各記事が並んでおり、それぞれの サムネイル画像 も表示されています。
このサムネイルの横サイズが… どうでしょうね、レスポンシブですから一定ではないにしろ約350pxぐらいでしょうか。
サムネイルとして収まっているimg要素(つまり画像)の実寸は 横1200px です。
何故1200pxかというと、私が1200pxの画像をアイキャッチ画像指定あるいは本文最初の画像として掲載しているから です。
つまりトップページの画像の実寸は表示サイズがいかなるサイズだったとしても 元画像依存・ユーザーがアップロードした内容に依存 しているということです。
で、Googleはそれに対して「表示サイズと実寸が著しく違うじゃないか。実寸を小さく加工しろ。」
というわけで大きく減点をしています。

サンプルテンプレートではトップページに画像を表示させるのに
<%topentry_image_url> という独自変数を利用しています。
この変数は アップロードした画像のURLを取得 するものです。

FC2ブログでは他にもサムネイル画像を表示させる変数が存在します。
<%topentry_image_w300><%topentry_image_72> です。
ところがこの2つの変数は URLだけを取得するわけではない んですね。

<%topentry_image_w300> は変換されると以下のような内容に書き換わります。

<img src="横300縦200に切り出された画像のアドレス">

<%topentry_image_72> は変換されると以下のような内容に書き換わります。

<img src="横72縦72に切り出された画像のアドレス">

こうして img要素 として変換が行われます。
画像のアドレスも原画のそれではなく、別で生成されたものが適用されます。
そして 必須属性の alt が付かない のも特徴です。
必須属性ですからバリデートエラーですね。

2つのサムネイル用変数はimg要素としてしか利用できませんし、その要素に何かしらの属性を追加するといったことも不可能です。
ですからとっても使い勝手が悪いんですよね。属性追加もクラス名追加もできませんので lazyloading対象にもできません
そして繰り返しになりますがバリデートエラー(笑)

こういった事情があるのに加え、これまた繰り返しになりますが以下のような「高解像度ディスプレイでのぼやけ問題」があります。

スマートフォンで画像がぼやける際の対処と画像容量削減 - カスタマイズ

スマホだと画像がぼや〜っと不鮮明になってしまう場合の原因と対策ですー (´・ω・`)...

スマートフォンで画像がぼやける対策【2倍じゃもう足りない!】 - webのあれこれ

何も考えずに画像を掲載するとスマートフォンでめっちゃぼやけるよ。 という記事を以前に書き、その原因・対処なども記しています。 その記事だけやたらアクセスが多いんですよね。 つまり多くのスマートフォンユーザーさんが困ってるってことよね。...

なので300pxのボックスにそのまま300pxの画像を入れるわけにいかないというかね (´・ω・`)
だから300×200できできの <%topentry_image_w300> も、72四方の <%topentry_image_72> もはっきり言って 使い物にならない
従って解像度も維持でき(維持できるかは原画のサイズ次第ですが)、バリデートエラーにもならなくて済むように元画像URLだけを取得する <%topentry_image_url> を選択しているというわけです。
そしてその選択がGoogleから指摘を受ける原因になっています(笑)

この件についてはもう直せないというか 直さない 方向です。
だってスマホで画像がぼやけることがわかりきってますし、それ以上の理由として
各SNSサービスが横1200px以上の画像設定を推奨している
からです。
GoogleのAMPのサムネイル規定にしても横最小1200pxですし。
トップページサムネイルになるということは、SNSシェア時のサムネイル画像でもある のですから、ここはゆずれない場面ではないでしょうかね (´・ω・`)
スピードテストのGoogleの提案に従うか、スマホでのぼやけやSNS推奨やバリデートを取るか。
私は後者ですね。もちろん画像にlazyloadingが適用されている、というのが絶対条件ですが。

で、こういう意見があるんですよ。
「要約タイプのテンプレートの方が速度が速いと言うけれど、テストをしたら全文表示の方がスコアが高いのですが…。」みたいな。
もちろん記事内に画像が1件も無いだとか、そういった場合には全文の方が速くなる可能性もあります。
でもここで言いたいのは、「スコアが」という表現を必ず使われるんですよね。
つまり スコアの方ばかりを気にしている んです。
でも自分が閲覧側に回った時はどうですか?そのページのスコアってすぐにわかりますか?それともスピードテストにかけますか?
普通は体感速度がどうか、ってところで判断するはずです。なのに何故か自分のページとなるとやたらスコアばっか気にするというか、ね。

まとめ

FC2ブログの性質上「できることとできないこと、譲れることと譲れないこと」がある、という説明をしました。
極端なことを言うとこれが一番速いですよ ↓

  • 全文表示タイプを利用する
  • テンプレートデザインに画像を一切使用していないものを選ぶ
  • 本文に画像は掲載しない(この時点でSNSシェア時にサムネイルが無くなります)
  • SNS純正シェアボタン(ブログ個人設定で表示されるもの)は利用しない
  • あらゆるJSの使用を避ける
  • Google Analyticsを利用しない

上記を守れば100点が取れます。
でもこの内容で100点とったところでどうする?
サムネイル画像があった方がとっつきやすいのでページ誘導率は上がりませんか?
個性的なデザインのサイトの方が訪問者の印象に残りませんか?

補足ですがGoogleのアクセス解析を入れていると絶対に100点は取れません。
あとFC2ブログ個人設定で表示させるSNSボタン類は一つ一つ全てがクリティカルリソースです。FacebookとTwitterと拍手を表示させていればボタンだけでクリティカル数が3つになります。
なので ブログ個人設定SNSボタンの利用はおすすめしません。

やはりここは「バランス理論」です。
何かひとつだけ突出していてもダメ、ってやつ。
ページ表示がいくら速くとも印象に全く残らないサイトなんてたくさんあるでしょう。
とはいえめちゃくちゃ遅いサイトは問題外です。その場合には「デザインを諦めてでもなんとかせーや」と言って良いと思います(笑)
ただ実際はデザインがどうとかではなくて先に記したクリティカルリソースについて考えられているかどうかだったり、見た目の良さげなブログパーツ・なんとなく箔が付きそうなランキングバナーなどを何も考えずにベタ貼りしているだとか。 小さいから問題ないだろうとデコメ画像を大量に掲載しているだとか。
ギラギラチカチカした大容量動画GIFをベタベタ貼り付けているだとか。

最後になりますが、もし仮にFC2ブログ運営が各種サムネイルをURLだけ取得できるような変数を作ってくれたなら、要約タイプテンプレートの「画像デカすぎ」指摘問題を多少解決できるようになります。
そしてサムネイルサイズは「150px四方」「横300pxの16:9」「横600pxの16:9」を準備してくれたら制作上非常に嬉しい。
というわけで清き一票お願いしまーす ('0')/
FC2リクエスト「サムネイルサイズの見直しと変数の見直しをお願いします」

YOU MAY ALSO LIKE
もっと見る
vanillaice (Akira)
vanillaice (Akira)

2 COMMENTS

There are no comments yet.

ぼっちん  

1票して来ました(笑)

Akiraちゃん、おはようございます ^^
リクエスト、いま1票して来ました~(笑)

この記事、笑いつつも「だよね~ うんうん(^-^)」と再認識させて戴きましたけど、GTmetrixにしてもPageSpeed Insightsもその他同様ツールも「間尺に合わない」部分も多々あって、もっと表示速度の正しい実測値を表示出来るような改善を望むんですけどね (^^ゞポリポリ

2018/07/04 (Wed) 09:43
vanillaice (Akira)

Akira  

To ぼっちんさん

ぼっちんさん、こんにちは ('0')/

ご投票ありがとうございます(笑)
いや、冗談抜きでホントに実現して欲しいなぁ。
600サムネイルができたとしたら私ならスマホで横100%表示と仮定して600を使います。
でもDLしたユーザーさんが「ぼやけとかどうでもええねん!スコア命やねん!」という場合には300サムネイルの変数に変更するだけで一丁上がり。超簡単にスピードカスタマイズが可能になりますよね。

現状でも例えば最新のLa_Vitaなんかはトップサムネイルを300のものに変更すればGTでAスコア100%取れます。
でもバリデートエラー足すことのぼやけ足すことのLazyなし(笑)

ファイルの置き方などテクニカルな面についてはGoogleよりもYahoo!の方が的確かなぁ、と思います。

2018/07/04 (Wed) 17:00