彗星のように現れた新しいWordPress用のテーマ「SANGO」。洗練されたフラットデザインに魅了され、このテーマを採用したブログサイトがタケノコのようににょきにょきと急増しています。ミーハーな（いや、時代に敏感な）私もその例に漏れず、SANGOのデザインに惚れて早速、導入してみました。
SANGOのフラットデザインから醸し出される空気感を引き出すべく、サイトデザインを一新したい気持ちをおさえ、その前にこの記事を書きました。というのも、巷で評価されている「SANGOが速い」という噂を自分なりに検証してみたかったからです。
このサイトの以前のテーマは、みんな大好き「STORK」。もはや国民食とも言えるSTORKを適用した状態から、サイトを構成しているパーツや情報量はそのままにして、外観もだいたい同じになるようにして両者を比較します。
前提となる条件
- 使っている記事や画像、プラグインはそのまま
- そのままでは表示が崩れるショートコードなどは、SANGOのものに置き換え
- 人気記事の一覧だけはプラグインを停止してSANGOの標準機能を使う
- サムネイルのサイズが違うのでRegenerateをかけてSANGO用に最適化
（ ここで画像のデータ量は変わるがテーマの違いとする）
移行にあたって必要な措置をとった後ですので、まったく同じ条件での比較にはなりません。ですが、できるだけ見た目も似せて「テーマだけを置き換えた状態」を目指しました。STORKからSANGOへの移行を考えている人がいれば、、頭の体操に役立ててもらえれば幸いです。
なお、使用しているサーバーなどの諸条件は、この記事の一番下にまとめました
比較してみた
まずは、移行前の状態を紹介します。しばしばSTORKは「重い」とか「遅い」などと言われていますが、本当にそうなのでしょうか。ベンチマークツール（検証ツール）として代表的なGoogleの”Page Speed Insights”と”GTMetrix”、それにローカル環境での実測値(Chrome)を順を追って見ていきます。
参考 Page Speed Insightsgoogle 参考 GTMetrixSTORKをチューニングした結果
モバイル:69/100 PC:86/100
Page Speed Insights STORK(モバイル)
PageSpeed Score B(88%)
Yslow Score C(74%)
次に、新しいテーマSANGOに切り替えた上で、私なりのチューニングをほどこした状態を見てみましょう。
SANGOをチューニングした結果
モバイル:97/100 PC:97/100
PageSpeed Score A(90%)
Yslow Score C(70%)
どっちが速い？グラフで比較してみた
気をつけていただきたいのは、いずれのスコアも、プラグインによるラフなチューニング後の結果だということです。素のバニラ状態の比較ではありません。また、後述する理由でベンチマークは時間などを変えて何度も走らせ、GTMetrixにおいては計測サーバーの地域も変えながら、「最も良い」結果が出たときを拾いました。
この比較だけを見ると、PageSpeedInsightsにおいては、圧倒的にSANGOに軍配が上がります。モバイルとＰＣのいずれもほぼ満点が出ました。巷での評価は概ねその通りだと思います。その一方で、GTMetrixにおいては、両者のスコアは、ほぼ同じです。むしろYSlowではSTORKの方が良い結果がでました。
SANGOはチューニングを詰めやすい
なぜSANGOがPage Speed Insightsで「速く」なったかというと、高速化プラグインをそのまま使ってもエラーが出にくく、WEBエンジニアじゃない私でもプラグインの恩恵を享受できたからです。
素人にできることは限りがあります。ただのブロガーが、WEBページの構成要素を一つ一つ検証し、ミリ秒単位で改善してベストプラクティスを実践することは考えにくいです。（してもいいんだけど・・・）だから、高速化プラグインとテーマの馴染みが良いことはとても重要です。少なくとも、私の環境では、SANGOと高速化プラグインの組み合わせでベンチマークスコアは確実に上がりました。
じゃあSTORKは遅かったのか？
結論から言うと、そんなことありません。私は、STORKは決して「遅い」テーマだとは思っていません。ローカルブラウザ環境(Chrome)でのテストを見てみましょう。
グラフで比較すると、ここでもSANGOの優秀さが際立ちます。Load（データ受信完了）からFinish（ブラウザでの画作り終わり）までを見ると、SANGOは0.1秒しかかかっていません。対するSTORKは、1.71秒を要しています。データが手元に来てから、ブラウザの内部エンジンが仕事するのに時間がかかっている感じですかね。
それでは、この結果を単純に受け取って、「やっほー！SANGO最高だぜ！」と言えるのでしょうか。答えは「そうとは言えない」です。後で詳しく述べますが、Adsenseの広告を使う限り、毎回、計測値がかなり変動します。データ量の多い「重い」広告がセットされれば、この程度の差は簡単に覆るのです。
あくまでも、いろんなパターンで何度もベンチマークをかけて、「最も良かった状態」がこれなのです。「最も良かった状態」だけを比較すると差が出てきますが、私の環境における計測では、どちらかが常に優位と言えるほどの体感できる違いはありませんでした。
というのも、そもそも両テーマともに「十分に速い」からです。グーグルは3秒台を超えると「遅い」と言っているようですが、STORKでもSANGOでも3秒台が実現できているので、ペナルティを受けることはないでしょう。
STORKが遅いと言っている人やそう思い込んでいる人は、簡単にできることをちょっと怠っているだけかもしれません。
ベンチマークのための最適化は意味がない？
みんなが血眼になっているPage Speed Insightsは、実はもはや時代遅れとされています。
このツールが評価の対象としている項目は確かに重要なことばかりですが、HTTP/2をはじめ、サーバー側でより速くデータを送り出すための新技術も続々と登場しています。その結果、このツールによるスコアの善し悪しが、必ずしもユーザーが感じる「速さ」にはつながらなくなってきています。Page Speed Insightsで100点のサイトが必ずしも速いわけではないのです。
こうした問題は、当然グーグルも認識していて、新たなツールを提供し始めています。
参考 Test my sitegoogle新しいツールはサイトのスピードをより多面的に検証することで、従来のPage Speedのスコアよりも重要な指標として使われることになっています。WebPageTest.orgのSpeed Indexの計測なども取り入れながら、複雑にスコア付けしています。もはや、Page Speed Insightsだけを突き詰めても、グーグルに良い評価をしてもらえるわけではありません。
テーマよりも外部要因が大きすぎる
そんなこんなでベンチマークで100を目指したりＡを取るためにあまりにも突き詰めても骨折り損です。そもそもWordpressを筆頭としたCMSを使ったサイトでは、自分のサーバーからの読み込みに匹敵するほど、外部サーバーからの読み込みの量が多いことも珍しくありません。様々なスクリプトの複合体としてページを表示しているので、自分のチューニングではどうしようもない外部的な要因でページスピードが決まってきます。
Adsenseを使えば、正直、元も子もない
外部要因のうち最もインパクトがあるのが広告と言えるでしょう。広告もまたスクリプトで表示されますが、そのスペースにどんな広告が入るかはまちまちです。ですから、その時にどんな広告がセットされるかよって全体のページスピードは大きく左右されます。
プラグインによるチューニングをある程度してしまえば、最初のHTMLドキュメントの読み込みと解析が終わる「DOM」は、テーマによって体感できる差はほとんどなくなってしまいます。いや、そんなことはないですね。差は確実に生じて、それがテーマを作る人の腕なのでしょう。ただ、ページの読み込みをテーマ側で少しでも早くしようと試みる作者の方の努力よりも、「どんな広告が表示されるか」の影響の方がはるかに大きいことも強調しておきたい事実です。
そもそも「テーマ」に速いも遅いもあるのか？
WordPressが静的HTMLで作られたサイトに比べて「重い」のは、アクセスの度に内部処理を行いHTMLを吐き出すからです。それ故に、ユーザーがリクエストをしてからサーバーが応答するまでのいわゆる「ファーストバイト」がどうしても遅くなってしまいます。
この内部処理、つまりサーバーがHTMLを計算して出力するまでの時間が、テーマの作り方や、プラグインの有無に左右されます。シンプルな表示にすればするほど計算は早く終わりますし、複雑な要素を組み合わせたり、たくさんプラグインを使ったりすればそれだけ計算に時間がかかり、HTMLができあがるのが遅くなるという具合です。
一方で、今や「キャッシング」無しでWordpressを運用しているケースの方が珍しいのも考慮しなければなりません。キャッシュ技術を使えば、いったん計算されてできあがったHTMLをサーバーが保存しておくので、その後になされたアクセスは、サーバーとしてはできあがった「成果物」を渡すだけになり、改めて計算しなくてもすみます。こうなると、テーマの作り方やプラグインの有無の影響は受けにくくなります。
もちろん、どれだけキャッシュに食ってもらえるかや、キャッシュされると動作がおかしくなる要素の多少で結果は違ってきます。ただ、少なくとも、同じようなコンテンツで同じようなプラグインを使ってテーマだけを差し替えた場合は、キャッシュ後のページ読み込みは、実はそんなに変動する要素は見当たりません。
大事なのはWater Fallを眺めること
テーマ作家の方の努力で読み込みを高速化するには限界があります。それよりも、ユーザー側で、実際にページが読み込まれるまでの流れである「WaterFall」を眺めて、何がボトルネックになっているかを把握した方が、手っ取り早くスピードの改善につながります。HTTP/2を使って同時多発的にストリームを吐き出したり、画像を無料のCDNに置いたりと簡単にできるプラクティスは少なくありません。
そうしたユーザー側での努力をひととおり済ませ、改めて自分のWaterFallを眺めてみます。私の場合、「ファーストバイト」となるサーバーの応答速度は200ms台なので、これ以上の高速化には現実的には無理です。（やろうと思えば、AmazonやGoogleからとっても高いサーバーを借りなければいけません。）
また、CSSや画像もすべてCDNが喰っていて、HTTP/2でよーいドン！で同時に吐き出されています。もっと細かく言えば、使っている画像を数キロバイト単位でさらに圧縮していく余地は残されています。実際に、Page Speed Insightsからは「もっと画像を圧縮しなさい！」といつも怒られます。
しかし、商用サイトでもないので、「何もそこまでしなくてもいいや・・・」という割り切りもあって、手を付けていません。
さらに、WaterFallの後半、つまりDOMLoadedが発火して残りの処理をこなす段階に入ると、ほぼすべての時間がGoogle Adsenseに関する処理で占められています。じゃあ、Adsenseを切るか？というと、そういうわけにはいきません笑。一般的な「高速化」は結局、最後は外部要因の広告でつまづくのです。（広告なしの人は、仙人レベルに高速化かできるかも）
でもSEOを考えるとベンチマークも無視できない
評価サイトのスコアばかりを気にするのではなく、Water Fallを見て実測値に基づいた改善をしていくべきだと思いますが、しかし！ここで悩ましいのは、Googleがサイトの評価にページスピードも考慮していることです。前のパラグラフでも述べましたが、少なくともGoogleは、時代遅れのPage Speed insightsだけを見て評価付けしていないことは確かです。しかし、何をもってページの「速度」を測っているかは、公表されていない以上、中の人にしか分かりません
そうなると、ブロガーとしてはとりあえずGoogleが表に出しているツールで高得点を取れるようにする、そのためのいわばベンチマークのためだけのチューニングに走ることも「意味がないとは言えない」のも悲しい現実なんですよね。
こうした側面を考えると、実測値はさておきベンチマークで高得点がとりやすいテーマ、すなわちSANGOを使うのは合理的な選択なんでしょう。
多面的に考えよう
繰り返しになりますが、テーマによる「速さ」ってそんなに目くじら立てるほどでもないんじゃないかというのがこの記事の結論です。ものすご～くシンプルな構成のサイトならともかく、画像もプラグインもそこそこ使って、Google Analyticsでアクセス分析して、Adsenseで広告も入れるよ！という、まぁ私が考える今日で一般的なブログにおいては、テーマを変えただけで速くなるなんてことはありません。
結局は、テーマに応じてそこからチューニング努力をはじめるほかありませんね。
役立つツール
スタートの一歩としてとても役立つツールをご紹介します
参考 Sucuri Load Time Testerコネクションとサーバーの応答スピードを計測するサイトもとがポンコツの遅いサーバーではチューニングしても限界があります。借りているサーバーの基礎体力が分かります。
参考 WEB PAGE TESTページを読み込む全過程を非常に詳細に分析してくれます ChromeのDeveloperツールでもWater Fallは表示できますが、外のサーバーから見た分析は重要です。ボトルネックが何かを特定し、チューニングの出発点になるでしょう。とりあえずやったこと超簡略バージョン
ところで、この記事はどのようなチューニングをしたかはすっ飛ばして、「結果」だけをもとに書きました。SANGOで何をしたらPage Speed Insightsが最高で97になったかは別の記事にまとめたいと思います。といっても、ほかのブロガーの方の記事にもたくさんでてくるような基本的なことしかしていません。やや踏み込んだのは、CriticalCSSぐらいですかね。
ささっと列挙すると・・・
- 標準のリバースプロキシそのまま
- mod_page speedは切る（CloudFlareとバッティングするため)
CDN(CloudFlare)の設定
- HTTP/2
- gzip
- キャッシュ期限の管理
- 画像やCSSなどの静的コンテンツはすべてCDNに置く
ブラグインの設定（Autoptimize）
- CSSの圧縮とインライン化
- javascriptの圧縮
- HTMLの圧縮
ブラグインの設定(Above The Fold Optimization)
- Critical CSSを適用（非常に面倒くさいが効果大） 記事で検証が終わった今は止めた（笑）
- CSS読み込みの最適化
- javasvript読み込みの最適化
番外編：やっぱりＡＭＰは異次元の爆速だった
モバイル:90/100 PC:97/100
PageSpeed Score A(99%) Yslow Score A(96%)
これは自分のサーバーにアクセスさせた状態ですが、Loadまで614ミリ秒しかかかりません。実際にはAMPのページは、まるっとGoogleのCDNに置かれるのでもっと速くなります。
CDN：CloudFlare 無料プラン
ローカル環境：Win10, Corei7 7700K 4.8Ghz, Chrome(61.0.3163.100)
