NeGiMeMo.net

ねぎさんのメモ帳。日常・メモ・ときどきWordPress。

【WPAC2014Solo】高速化への道

bell賞味期限切れコンテンツ

この記事は公開または最終更新から891日くらい経過しています。
このメッセージが表示されている記事(特にプログラミング系)は情報が古くなっている可能性があるので注意して下さい。

wpac2014head_day11

うぃーす。11日目でございまーす。

高速化のために初心者ができることを教えて下さい。

ということで今回は高速化に関するお話です。

…といっても正直なところ、うちのブログもすごい早いってわけではなく、どちらかというと遅い方かもしれません。

現在リニューアル中(というかホントはアドベントカレンダーまでに終わらせたかったんだけど…)のテーマではまた結果が変わるかもしれませんが、この記事を作ってる時点でのテーマにおける GTmetrix での結果は、 Page Speed の評価が B、 YSlowでの評価はなんと D という結果でした。

ngm_gtmetrix_result_141209

なので、あんまし偉そうなことはいえないんですが、それでも自分なりにあれこれ試してみたこと(進行中で実践してること)からいくつか紹介してみます。

どうして高速化するのか

そもそもなんで高速化についての話題があちこちで上がるのかというと、1つには「表示が遅いと表示し切る前に離脱される可能性が高い」ってことが挙げられます。

なかなか読み込みが終わらなくてカクカクしかスクロールしないようなページは読む側にしてもストレスですからね。

あともう1つの理由としては、「検索エンジンに対してもいい影響がある」というものがあるそうです。

このあたりもあまり詳しくはないので細かいことは書きませんが、人も、クローラ(検索エンジンのロボット)も早いほうが好き、ってことですね。

表示速度を左右する要素とは?

さて、表示速度に影響を与える要素というのはなんなのかというと、まぁいろいろあるんですが、テーマの見直しやプラグインなどである程度改善できる要素としては

  • 画像の最適化(でかすぎるものにしないとか、圧縮するとか)
  • ソースコードの記述内容(HTMLだけでなく、JSとかも)
  • キャッシュの有無

なんかが挙げられると思います。実際リニューアル中のテーマはかなりこの辺意識するようにしています。

画像の読み込み時間

Webサイトのコンテンツは乱暴な言い方をすれば、「テキスト」と「画像」でできています。え?動画…?[*1]

ブログにしても、それ以外のサイトにしても、これは変わらないと思います。

そして、テキストデータなんてどんなに長い文章でも容量なんてたかが知れています。

つまり、極端な話画像が全くないテキストだらけのサイトならば、速度はかなり上がると思います。

とはいえ画像がまったくないサイトというのも今どき考えられませんし、そうなると、読み込みをどうにかしないといけなそうですね。

やりかた

まず真っ先にとりかかるのが画像サイズの最適化です。ここでいうサイズは高さとか幅とかです。PCからの閲覧がメインだから小さいとちょっとなーって場合もあると思いますが、明らかにPCで見てもコンテンツエリアからはみ出すようなサイズの画像を縮小表示しててもあまり意味が無いですよね。

なので、PCテンプレートのコンテンツ幅くらいに合わせてつくるのがいいかと思います。もちろんそれより大きい画像を使うのも問題無いと思いますが、その場合は、ページの読み込み時には出さずに、ライトボックスなどで都度読ませるのがいいと思います。

つぎにやるのが画像データの圧縮ですね。

最近では画質をなるべく落とさずにサイズだけを落とせるツールがたくさん出ており、殆どの場合は1度設定してしまえばツールに画像をドロップするだけで圧縮できますのでやる価値はあると思います。

ツールもImageOptimのようなデスクトップアプリからTinyPNGのようなウェブサイトまでいろいろありますので好きなやつを選ぶといいと思います。

アップロード前に圧縮してしまうことでアップロード速度も向上しますし、ファイルサイズが減ればサーバーのストレージの節約にもなりますね。

でも、いちいちツールやウェブサービスを通してからアップするのめんどいなーって場合は、EWWW Image Optimizer というプラグインを利用するのがいいと思います。というかこれあれば上記のツールがなくても同じようなことができますので別で静的サイトとか運用しててそっちの速度対策も…とかって場合じゃなければこれだけでいいかも。

すでにアップロード済みのファイルも圧縮できるらしいのですでに大量の画像をアップしちゃってる人も安心ですね。

WordPress › EWWW Image Optimizer « WordPress Plugins

ここまでで画像のサイズは小さくなりましたが、それでもやはり画像は画像。読み込み時間が長くなる原因には違いありません。

そこでさらに速度を上げたい場合は、Lazy Load系のプラグインなりJSを仕込むことで画像の遅延読み込みをさせるという方法があります。

回線速度が上がり一度はもう不要だと思ってる人も少なく無いと思いますが、これも実は結構効果があるようですよ。

これも実は WordPress のプラグインがあるので、今のテーマはそのままで実現可能です。

これ以外にも Lazy Load系プラグインはたくさんあります。設定項目とか実際の動作とかと見比べながらお好みのやつを選択するといいと思います。

ソースコードの記述内容

ここでいうソースコードというのは、テーマ(テンプレート)ファイルのことです。

実際WordPressが重いのも事実なんですが、さすがにそっち(コアファイル)をいじるのはハードルが高く、またリスクも大きいです。なにより直接コアを弄ってしまうとバージョンアップでそれらが全部消えてしまいます。何にしても今回はコアに関してはとりあえずおいておきましょう。そもそも初心者向きでもありませんし、自分もいろいろ語れるほどコアの構造は知りませんので。

HTMLを構成する要素というのは主に大きく3つに分かれていて、

  • テキストデータ(HTML文やコンテンツの本文など)
  • スタイルシート(CSS)
  • JavaScript(jQueryなどのライブラリも)

でできています。

そのうち JavaScript が非常に厄介で、重いページというのはだいたいここで止まっているらしいです。

なので、JSの読み込み位置を変更してあげるだけでかなり改善が見込めるようです。

WordPressの場合、wp_enqueue_script で JS を読み込んでいる場合は、第5引数($in_footer)を true にするだけで body タグ終了直前に移動することができます。

また、外部のデータを取ってくる系のJSや各種ソーシャル系のプラグインも非同期読み込みモードにしてあげると、読み込みが終わるまでそこで待つ、ということがなくなるのでさらに表示速度改善が見込めると思います。

ついでに、読み込むJSもミニファイ化するなどして容量をさげてあげることで読み込み時間の改善もできます。テストがおわって本番にあげるときにでも圧縮してあげるといいんじゃないんでしょうかね?

codekit とかなら自動でプロジェクト内のJSを監視してバリデートしてくれるだけでなく、ミニファイ版も出してくれますのでそれを使うと便利です。もちろん他のツールを使っても全然OKです。

ローカル時とデバッグ時で読み込むファイルをかえる方法ですが、ローカル開発中はデバッグモードをONにしておくことが強く推奨されてますので、それがONになってるかどうかで判断すればいいのではないでしょうか?

ちなみにデバッグモードにするには、wp-config.php に

と書くだけです。

というか、インストール直後で既に

というふうに、オフ状態に設定済みなのでここをfalse から true に書き換えるだけでOKです。

ちなみにどうしてもデバッグモードにしたくない理由があるのならば、別の方法として $_SERVER[‘SERVER_NAME] の値を見るという方法もあります。

バーチャルホストを設定して構築している場合は後ろの「wp.local」を自分が設定したものに差し替えてください。

あとは、ミニファイ版の有無を確認して、ミニファイ版があればそっちを適用し、なければ通常版…みたいな方法も多分できなくはないです。がんばれば。

この辺はだいたいのことがCSSでも言えると思いますので余裕があればそちらも試してみてはどうでしょうか?

SASSとかのメタ言語を使ってる場合は出力形式で「Compressed」とかそんな感じのを指定しておけばミニファイ版が出力されます。

あとで読み返したり、デベロッパーツールで出るエラー行がわかりにくくなるって?
そういうときはソースマップを利用するといいみたいですよ。

 キャッシュの有無

キャッシュってのは、一度表示したページを別のところに保管しておいて次に開いた時にそれを使うことで表示を早くする仕組みです。

ホームページを更新している時に、アップロードしたのに内容が古いままだったけど何度かリロードしたら反映した、みたいな経験を一度はしてるとおもいますが、これもキャッシュが残っていてそちらが表示されるために起こる現象です。

さて、WordPress で扱うキャッシュとしては、主に4つのタイプがあります。

  • ページキャッシュ
  • データベースキャッシュ
  • オブジェクトキャッシュ
  • ブラウザキャッシュ

それぞれの詳しい説明とかは端折りますが、 WordPress がデータベースと通信して、PHPに値を格納して、それを表示して…みたいな各工程に対して機能して高速化に貢献してくれます。

こういうキャッシュ機能を提供してくれるプラグインをよく「キャッシュ系プラグイン」と呼んだりしますので、プラグイン選びで迷ったりしたらこれで検索するといいことあるかも。

またこれ以外にも、言語ファイルをキャッシュするMO Cache や 001 Prime Strategy Translate Accelerator といったプラグインもありますよ。

また、それ以外に CDN(コンテンツデリバリーネットワーク)という仕組みを使う方法もあります。無料で使えるものとしては、 Cloud Flare や Jetpack についている Photon などがそれですね。

画像のところでも話しましたが、画像はとにかく重いわけです。で、CDNってのは、そういう重いファイルを配信するためのネットワークでして、そちらにキャッシュを作成し、重いファイルはそっちから配信させることで負荷を分散させ、結果的に高速化につながるというわけです。

以前はここも Cloud Flare を使ってましたが、現在は Photon に切り替えています。

その他

余裕があればCDNとかも使うといいかもしれませんね。
CDNというのはコンテンツデリバリーネットワークの略で、画像など大きなデータを別のサーバーにキャッシュしてそこから配信することでサーバーの負荷を抑える仕組みです。

無料で使えるところでは Cloud FlareJetpack についている Photon などが挙げられますが、特に Photon がおすすめです。自分もかつては Cloud Flare を使用していましたが、現在は Photon に切り替えています。

というのも、 Jetpack をインストールして WordPress.com につくった自分のアカウントと接続するだけで準備が完了し、あとは Jetpack の管理画面から「Photon」を有効化すればそれだけで使えるという手軽さ[*2] と、なによりも作っているのが WordPress とおなじ Automattic 社だから安心して使えるというのがありますね。

おまけ

これでもだめならば…。

レンタルサーバーで運用している場合、もしかしたらサーバーの同居人の影響を受けてたりする可能性もあります。特に安いレンタルサーバーなんかはものすごい量のサイトを1つのサーバーに収容しますので。

余裕があるならば、サーバーの見直しなんかも視野にいれてみるのもいいのかもしれませんね。

 

これはWordPressひとりアドベント・カレンダー2015の記事です。
WPAC2015Soloについてはこちらをご覧ください。

TAGS