Googleの スピードアップデート が2018年7月に来るよ。
ということで、自ブログのスリム化・高速化に勤しんでいる方も多いかと思います。
え？多いかな？どうだろう (´・ｪ・｀)
今回の記事では
- FC2のスペックを知っておく
- 数字に踊らされない
- 私の(Akira作の)テンプレートで軽量化できそうなところと提案
などについて。
あくまでも FC2ブログで というのが大前提です。
Google ウェブマスター向け公式ブログ: ページの読み込み速度をモバイル検索のランキング要素に使用します
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報
webmaster-ja.googleblog.comFC2ブログサーバーのスペックは中レベル
低くはないですね。しかし高くもない。
ここについてはやはり 無料会員の方が不利 になっています。
現在ですとあらゆるwebサービスがSSL化しつつあり、FC2も例に漏れずSSL化つまりhttps通信が可能になっています。
httpsは HTTP/2 (Hypertext Transfer Protocol version 2) という高速通信が可能ですが、それは サーバーによります。
FC2ブログの有料会員の場合、画像サーバーについてはアカマイCDNを経由しますのでHTTP/2が利用できます。
無料会員は 個別記事下のテキスト広告を表示させている 場合はHTTP/2が使えます。
ところが有料・無料を問わずブログ全体の通信は HTTP/1.1 のみなんですね。
HTTP/1.1 つまり旧式の通信であり 遅い ってことです。簡単に言えば。
ブログ全体はHTTP/1.1で、中に含まれる画像ファイルやJSファイルなどは、個人の環境(契約内容や選択)によってはHTTP/2が使える、ということです。
参考までに他ブログサービスの場合。HTTP/2の場合は 付けてあります。
- アメブロ ---
- はてな ---
- Yahoo! ---
- Blogger ---
- エキサイト ---
てか、Yahoo!(笑)
続いてサーバーのレスポンスについて。
専門用語的には TTFB (Time to First Byte)。
リクエストを行なって後、サーバーから最初の1バイトがレスポンスとして届くまでの待ち時間のことです。
数値(秒数)が低い = 速い
応答が早ければ早いほど性能が良いということになります。
GoogleはTTBFを 「200ミリ秒 にしろ」と言っているわけなんですが、FC2は平均400から遅い時は800とか。ダメじゃん(笑)
ただFC2のこの数値も他サービスと比較するならば遅いというわけではありません。
Google御大による絶対評価で言えば遅いのでしょうが ^^;
このサーバースペックについてはもうどうしようもありません。ここを語るならばもうサービス変えようか、サーバー借りようかって話しになってしまいます。
今回の主旨はあくまでもFC2ブログ残留(笑)
スピード計測サイトの数値に踊らされない
製作・提供の立場として画像の遅延読み込みを各テンプレートに取り入れている最中です。
この機会に遅延読み込みの効力も知って頂きたいので、テストファイルを作成してみました。
計測は GTmetrix を利用しようと思います。
各ファイルの測定がすぐにできるよう、以下のブックマークレットをまず登録してください。もちろん強制ではありません。
(スマホアクセスの方はごめんなさい)
黒背景の GT をマウスでドラッグ、ブラウザのブックマークバーにドロップ。
プレーンテキストのみ
まず、遅延読み込みのテストも兼ねていますので コンテンツはスクロールを行うまで出てきません。
アクセス直後は真っ白な状態です。スクロールすると下の方に内容がありますので確認してください。
ファイルが開きましたらそのまま先程登録したブックマークレットをクリックして Analyze をクリック。検証が始まります。
テスト結果スクリーンショット
YSlowの結果の方は割りと変化しますのでアレですが、テキストのみのページでも 100点取れてない という事実に注目(笑)
これはFC2のサーバーを通してますので、その仕様だと思ってください。
そして主にPageSpeed Scoreの方で言及を行なっていきます。
この「プレーンテキストのみ」のファイルが基本として以降のファイルと比較を行います。
プレーンテキスト + 絵文字
絵文字はFC2エディター(旧投稿画面のツール)からの挿入を前提としています。
ツールバーを利用した掲載の場合、その絵文字は全て 画像(img要素) です。
テスト結果スクリーンショット
AスコアからBスコアへ 1ランクダウン。
パーセンテージでは 13%ダウン という結果です。
出発点が97と高いからB84でとどまっていますが、出発点がBからならばCへ。CからならばDへ降格されるということです。
かなり勘違いをされている人が多いと感じるのがこの 絵文字の利用 なんですね。
「小さいから大丈夫。問題ない。」
問題なくない (・A・)
スコアを大きく下げた原因は容量の大小ではなく 通信リクエストが発生している 点です。
いくら小さくとも画像は画像。しっかり通信が発生します。
絵文字1つにつき1%の減点となります。
あなたの記事は絵文字だらけではないですか？
プレーンテキスト + 絵文字 + 画像遅延読み込み
画像の遅延読み込み(lazyloading, delay loading)を行うとどうなるかのテストケース。
内容はすぐ上の「プレーンテキスト + 絵文字」と最終レンダリング内容は全く同じですが、htmlは遅延読み込み用になっています。
そして当然ですが遅延させるためのJSファイルへのリンク(通信リクエストが発生します)が追加されています。
テスト結果スクリーンショット
スコア落ちてないですよね。パーセンテージが各1%落ちただけ。
これが遅延読み込みの有益性です。
でもね。しかしBUT
Fully loaded time のところ見てください。
451ミリ秒から1300ミリ秒に落ちてます。
スコアは維持できていますが、ページ表示の体感速度は逆に下がっているわけです。
スペード計測系テストツールでは往々にしてこういったことが起こるんですね。
ですから「スコアだけを見て」「スピード秒数だけを見て」何かを判断するのはかえって危険です。
やはり総合的に見ないと (´・ω・｀)
で、この結果から「結局lazyloadingなんて無駄じゃん」と結論づけるのも無謀です。
実際のページというのはテストファイルよりも遥かに複雑で入り組んだ内容になっているはずですからすぐに逆転現象が起こります。
とはいえスコアについては単純な 理論値 だいうことは言えるかと思います。
具体例を言うとFC2ブログには「全記事一覧ページ」が存在します。
このページは基本的にはサムネイルの取得・掲載が不可なので画像に関する警告は発生しません。
ですからスコアも高いはずです。
が、体感スピードとしてはかなり遅いです。モバイルで10秒超えるとかザラです。
でもスコアは高い。
数値に踊らされるな というのはそういう意味です。
プレーンテキスト + 絵文字 + YouTube
テスト結果スクリーンショット
A97からC75へ大幅ダウン。
プレーンテキスト + 絵文字 + YouTube + 遅延読み込み
プレーンテキスト + 絵文字 + YouTube + 遅延読み込みのページ
テスト結果スクリーンショット
遅延読み込みはスコアに対して非常に効果が高い、というのをお分かり頂けたのではないでしょうか。
テンプレートの軽量化
言及は私が製作したものに限ります。
提供する立場と利用する立場では取るべき対策も異なりますので、ここからはみなさんのお手元にある内容について「もしかしたらこうすると良いかも」の提案です。
シングルカラムへの変更
レンダリングの性質を考えるとこれが一番良いんですね。
CSSが複雑にならないというのももちろんありますし、最大の理由は ファーストビューに専念できる「かも」しれない というところです。
シングルカラムの場合にはサイドメニューは下の方にありますので、よほどのことがない限りabove the fold(画面内)には入ってきません。
であるならばCSS内容を後回しに出来る可能性があります。
複数カラムだとそういうわけにはいかないんですね。
サイドメニューの上辺とがメインの上辺が同じということは、それなりに整形をしておかないと未完成なページを閲覧者のみなさんにお見せすることになってしまいます。
テンプレートの中からシングルカラムを選ぶ。それ自体は何も難しくないので
難易度
シングルであることを活かしたCSS操作をするならば
難易度
above the fold内で確実に必要となるCSSは インラインCSS として <head> 〜 </head> 内に style要素 として記載します。
<html>
<head>
<style>.xxx{background-color:yellow}.yyy{color: blue}.zzz{font-size:8em}</style>
</head>
<body>
.
.
.
.
</body>
</html>
そしてabove the foldに関わっていないCSSはhead内には置かず </body> の直前に記載します。
インラインCSSをhead内に用いると同時にlink要素として外部CSSファイルも用いている方をたまにお見かけしますが、それは何の意味もありません。
<script>
var link = document.createElement('link');
link.href = 'CSSファイルアドレス';
link.rel = 'stylesheet';
link.type = 'text/css';
var head = document.getElementsByTagName('head')[0];
head.appendChild(link);
</script>
こうして後回しにします。
link要素はhead内にしか記載できない決まりですのでJSを利用して差し込みます。
ソースコードの書き方が難しいのではなく「above the fold(画面内)」と「below the fold(画面外)」のCSS内容の切り分けが非常に難しいので難易度MAX。
汎用ページ送りの使用を辞める
「汎用ページ送り」というのは私が勝手にそう読んでいるだけです。
全記事一覧・個別記事以外のページで表示されるページネーションのことです。
この使用を取り止めて、簡単な前後ページの遷移(prev, nextリンクのみ)にすればJSファイルを減らせますので軽くなります。
ただし個人的にこのタイプの送りは 必要 だと思います。
全30ページあるところ、目当てのページが10ページあたりにあると予測が立っているのに1ページづつ送るとかマジでストレス。
jQueryの使用を辞める
これは難しいかなぁと思います。
難易度
jQueryプラグインが総じて利用不可になるのと、プラグイン以外でもJS実行コードがネイティブJS(vanilla JS)で書かれていない場合には全て書き直しになります。
そこがクリアできるのならば脱jQueryを考えてみるのも良いと思います。
個別記事下のサムネイルつきページ送りの使用を辞める
こちらはいくつかのテンプレートに導入しています。
FC2ブログでは今のところ前後ページのサムネイルを取得する変数が存在しません。
そしてphpも使えませんので、ajax(非同期通信)を利用してOGP情報の取得を行なっています。
前後のページにバックグラウンドでアクセスしているわけです。
情報取得に赴いたページからプレーンhtmlあるいはプレーンテキストを取得し、その中からOGP設定画像を取り出してページ送りの背景に適用、という流れ。
非同期ですから取得先のJSを実行したりはしませんが、画像データなどは取得されます。
というわけでGTmetrixでも指摘を受けます。
ajax通信を辞める、というのが一つの提案。
難易度
辞める事自体は簡単でも代用htmlとCSSが必要になるためこの難易度にしておきます。
もう一つの提案は ajax通信のタイミングをスクロールした後に設定する。
寧ろこちらの方が簡単かな。
難易度
type:'GET' で検索するとひとかたまりのJS内容を発見できます。
それを以下の通り修正。
$(window).one('scroll',function(e){ここに元々あったJS内容$(this).off(e);});
ここでちょっと大事なこと言いますけども。
重要キーワード・ポイントは「スクロール」である
こういったテストツールだけでなくGoogle botもそうなんですが、スクロールを行わない んですね。
botはここでは置いといて、テストツールもスクロールという動作を行いません。
なのでスクロールで発火するJSについては実行コード自体は解釈しても、実際に動かすことはありません。
ajaxは情報の取得のために利用していますがスクロールしない限り別ページへのアクセスが行われなくなりますので、従ってスコア減点対象から除外される、というからくりです。
テスト系ツールはこの「スクロール実行」が大きなキーポイントになってくるかと思います。
この点を覚えておいて損はない (´・ω・｀)
コメント装飾のツールバー使用を辞める
コメント投稿欄にありますよね。こんなの。
使用取りやめの場合
難易度
これからご紹介する方法を取る場合
難易度
このコメントツールバーが実はめちゃくちゃ重たいんですよねぇ (´・ω・｀)
仕組みとしてはJSの document.write という方法でもって DOMを生成する というもの。
DOM というのはhtml要素の集合体です。テンプレート管理画面の上段「xxのHTML編集」というボックス内にズラーっと文字列ありますよね。アレのことです。
本来レンダリング(描画)される要素というのはこのDOM内に記述されてしかるべきものですが、それが出来ない場合もあります。
そんなときにJSでもってhtmlを書き出すという手法が取られることがあります。
まぁ今後は非推奨になっていくというか、既にGoogleが「document.write使うな！(怒)」って言ってますので廃れていく運命なのかも。
FC2のコメントツールバーはhtmlの書き出しだけでなく別のスクリプトファイルの読み込みやURLパラメータ付加など、いろいろやってるんですね。そら重たいわな (´・ω・｀)
で、このdocument.writeというのはasync deferなどの非同期指定ができないんですね。
DOMが無ければJSは実行できませんので当然ですが。
で、このスクリプトを遅延読み込みさせるための方法をご紹介しようと思っていたのですが、以下でご紹介します記事を拝見しまして、あぁこっちの方が良いな、と(笑)
コメント投稿欄のツールバーをlazysizesで遅延ローディングしてみました。 ｜ 富士宮で貯蓄と資産運用
だからdocument.writeは止めなさいって言ってるでしょ… コメント投稿欄のツールバーが… 先日、個別記事ページをGTmetrixでブログ速度分析したら、【Defer parsing of JavaScript(JavaScriptの解析を延期する)】の項目でズラズラと指摘されてしまいました。 う～ん。トップページではこんなに多く指摘されていなかったんだけどなぁ… 僕のブログの場合、トップページから右カラムにサイドメニューのプラグインが表示され...
手順などは詳細な説明がありますので参照して頂くとして。
注意点だけ書いておきますと、内部的には「そのJS内容は役目を果たせていないよ」という警告を受けます。
がエラーではありません。赤でなく黄色。
発想としては
スクリプトファイルは遅延読み込みを行う
↓
JSファイル内にあるdocument.write内容は無視して先にDOMを手打ちしておく
↓
JSファイルの一部(htmlの書き出し)は不能となるがDOM自体は既に存在しているのでクラス名を頼りにそちらに対し処理が行われる
こういう感じです。
lazysizesは私の要約テンプレートに既に含まれていますし、Axisテンプレートはこの方法で必須となるunveilhooksも含まれていますので割りと簡単に導入できると思います。
確かに警告は発生しますが、このコメントツールバーに関してはFC2の用意している変数をそのまま利用するのがベストだと思います。
筆者様には導入しやすく結果に繋がる良策をありがとうございます ('0')/
で、私個人についてはコメントツールバーの使用を辞めました (´・ω・｀)
このツールバーが何をしているかというと、「文字列の追加」なんですが、この文字列は要するに変数です。
ごく簡単な文字列なので辞書登録ですぐに呼び出せますし、スマホから使いづらいこともあり、もう無くてもいいやー (´・ω・｀) と ^^;
スクロールアンカーの使用を辞める
サイドメニューがスクロールで流れて行かずに留まるアレ。
不要と思われましたら削除するとJS及びhtmlの一部が減らせます。
webフォントの利用を辞める
webフォントはlinkで読みに行きますので、Windows, Mac双方にバンドルされている標準のフォントを利用することでページスピードが向上します。
ただ両OSの共通フォントはかなり少ないのと、Windowsははっきり言ってかっちょいいフォントが無い (∵`)
日本語フォントにwebフォントを利用しない、というのは基本かなと思います。
(欧文フォントと比較してかなりデータが大きくなるため)
Font Awesomeなどのwebアイコンの利用を辞める
なんか辞めてばっかなんですけど。
そりゃそうですよね。スピードを最重要とするならばhtml, CSS, JSを最小限にするのが一番効果があるのですから。
Font Awesomeのバージョン5、重たいですね。
使わない方が良いような気がしてきました。
いろんな意味で「あんま良くない」です。最近のは。デザイン面も含め。
バージョン5からは推奨のJS + SVGで利用する場合は 疑似要素での利用は非推奨 とのことですが、やはりその通りで使いづらいというよりも場面によっては「使い物にならない」ことも。
IEを捨てる
初回投稿内容にこの章を追加しています。結構大事だけど忘れてました。
IE不要 という場合にはもう切っちゃって良いと思います。
とはいえ日本ではまだまだ使用率が高いようではありますけれど。
それでも「IEなど要らん」という豪気な方は思い切って外してしまうという選択も。
ここでいうIEは当然ですが IE11 のみを対象として言ってます。
それ以下のバージョンとかマジでもう知らんし 
IE対応を辞める場合にはCSSのフォールバック及びJSのハックなど多くの内容を削減することができます。
SNS純正アイコンの使用を辞める
この章も追加。
FC2ブログでは個人設定で簡単にSNSボタンを表示させることができるようになってます。
設定ページ
これらのボタンも非常に「遅い」「重たい」のでいっそ辞めちゃう。
私のテンプレートの場合は記事下にリンクで飛ばすシェアアイコンが付けてあり、ほとんど負荷がありませんのでそちらを割り切って使って頂くか。
見た目が純正のそれと同じでなければ気が済まないという場合にはCSSでできますのでカスタマイズするとか。
いずれにしても個人設定のSNSボタンの使用を避けると負荷が下げられます。
「テンプレートが全文表示タイプ」「本文と追記を分けていない」「各記事下に純正ボタン」このコンボは最悪。
まとめ
とりあえず今のところはこんな感じですかね。
他にも気づけば書き足すかもです。
スクロール に注目していくとみなさんも何か思いつくかもしれませんよ。
今回は「それホントに要るの？ホントに使ってる？」という根本的な部分の検討も含め、極端な選択肢「辞める」も敢えて提案しています。
ということで、軽量化についてでした。
あー。あと書き忘れましたが
画像の容量削減は当たり前
ですので必ず行うようにしましょう。
これはもうやって当然。やってなきゃ「えぇ？！」ってなるレベル。
