Webサイトを高速化をする事によって得られるメリットは様々あると思いますが、ユーザーエクスペリエンスの改善といった話とは別に、個人的にはサーバの台数が減らせるというのも大きなメリットだと思っています。サーバサイド側のエンジニアとしてはやはりサーバの台数が減ればコストも下がるし、運用も楽になりますので、SEOに関わらず努力したいところではありますね。
しかしながら、「高速化しよう」「表示速度を改善しよう」といっても、実際にどういうところに高速化を阻害するような要因があるのか、ということを知っていなければそもそもどう取り組んで良いか分かるはずもありません。
ということで今回は、技術者の方でなくともサイト高速化のポイントがある程度理解できる（多分）ように、最低限「こんなことがあるのね」というポイントを大まかにまとめてみました。
高速化のための基礎知識
高速化という言葉の中には、大きく分けて２種類の概念が存在します。
- フロントエンド側での高速化
- サーバサイド（バックエンド）側での高速化
フロントエンドとは
ここで定義したいフロントエンドとは「HTML・CSS・JavaScriptなどの技術」と解釈してください。噛み砕いて言えば、「ページがブラウザに表示される」という部分に関する部分がフロントエンドということです。フロントエンドの領域では、ある程度HTMLが書ける方ならポイントさえつかめれば誰でも高速化する事が可能です。
サーバサイド（バックエンド）とは
サーバサイド（バックエンド）側、というのは文字通りサーバー側での最適化なのですが、状況によって見るべきポイントが異なりますし、ある程度は専門的な知識が求められるので、誰でも簡単に高速化、というのは難しいことも場合と思いますので、今回はいくつかの要素について掻い摘んでお話しようと思います。
フロントエンドの高速化
これに関しては様々な方法があると思いますが、シンプルに考えて以下の3つを注意した上で高速化を行っていけばいいと思います。
- サーバーへの通信の回数を減らす
- サーバーへの通信量を減らす
- レンダリングの速度を低下させない
1.サーバーとの通信の回数を減らす
まず、普段ウェブサイトを表示する時のブラウザの動作を考えてみましょう。ウェブページにアクセスする際には、ブラウザに「http://xxxx.○○.html」などといったURLを入力したり、リンクをクリックしたりすると思いますが、このサイトを開く場合にサーバへのアクセスは何回になるか？
と聞くと、意外に「１回しか通信しない」と思っている人も多いのではないでしょうか。
実は「http://xxxx.○○.html」を開いて中のHTMLを確認するまで、実際に何回サーバーとの通信が発生するかはわかりません。
なぜ開くまでわからないのか？といえば、それはHTML書かれている内容によって通信回数が異なるからです。通信回数はHTMLの中に記述されている、画像、外部CSSファイル、外部Javascriptファイルの数によって変わってきます。
単純に考えて画像の数だけ、CSSの数だけ、Javascriptの数だけ通信が発生していまします。
※304を返す場合は通信は発生しません。ステータスコードに関しては「よく見るHTTPステータスコード一覧とその意味を理解する」を参照してもらえればいいのかなと思います。
通信回数が多いということは、その分だけ表示が遅れることにつながりますので、なるべく少ない通信回数で表示が完了できるようにするという事がまず大切です。もちろん、決して「通信を１回に押さえろ」というわけではなく、あくまで無駄な通信をしないということです。
2. サーバーへの通信量を減らす
通信の回数、ではなく「通信量」を減らすということをイメージすると、例えば画像ファイルの容量を減らすことが思い浮かぶ方が多いと思いますが、そういうことです。画像や動画ファイルはファイルサイズがとても大きいので、通信量が増えます。
この点では、本当に基本的な事かもしれませんが、読み込むファイルのサイズを減らすということが重要になります。一番多くのサイトに関係があるのはやはり画像ファイルだと思います。
「これ以上は画質を荒くしたくない」という事情は多々あると思いますので、そんなときは、画質を落とさずにファイルサイズを減らす「画像の最適化」を行います。
通常の画像データにはウェブページとしては不必要なデータが含まれている事があります。それらを排除することで、ファイルサイズを軽くする事が出来ます。画像によっても変わってきますが、相当ファイルサイズが減るのでおすすめです。
最適化する際は専用のソフトウェアがあるので、そちらを使いましょう。
ちなみに、余力があれば、CSSとJavascriptのファイルサイズも少なくした方が良いと思います。もともと、画像に比べたらファイルサイズは小さいのですが、それでも軽量化をするべきだと私はを思います。
ある程度ウェブサイトを長年運用していると、CSSやJavascriptが徐々に追加され、気づいたら容量が増えていたなんてことがあります。また、簡単に軽量化できるので、導入しやすさもあります。
ただし、不必要なJavascriptやCSSは削除してしまえばいいんじゃないの？って思う方もいるかもしれませんが不必要だと思ってたら、必要だったCSSの記述だとか、使っていないと思っていたJavascriptの関数を削除してしまったり…と、もちろん不必要な記述は削除するべきですが、現実的にはなかなか難しいと思います。
そんなときは「ファイルの圧縮」を行います。不必要な空白や改行を削ってCSSファイルや、Javascriptファイルを軽量化する手法です。
もちろんエディタ等の置換機能を駆使して、消していく事もできますが、何千行なんてCSSやJavascriptファイルだった場合はとても大変なので自動で変換してくれる便利なツールがたくさんあるのでそちらを使いましょう。
- YUI Compressor
- Compressor
- Closure Compiler(javascriptのみ)
- ProCSSor - Advanced CSS Prettifier(CSSのみ)
3.レンダリング（≒HTML解析～ブラウザ表示）の速度を低下させない
ブラウザの表示速度を遅くしてしまう要因は通信だけではありません。HTMLの記述のしかた一つでブラウザの表示速度も下がってしまう場合もあります。
例えば一昔前はよくJavascriptをheadタグのなかに記述している事が多かったと思いますが、最近ではbodyの閉じタグの直前に記述するのが主流です。（ただし、Google アナリティクスの計測用コードなどはhead内に記述したほうがより正確な計測が出来るといった事情もあるように、必ず・全てということではありません。）
headタグ内への記述を推奨されない理由は、ブラウザの表示速度が低下してしまうからです。たとえばheadの中に外部Javascriptの読み込みがあると、その時点でJavascriptの読み込み、実行がされてしまいます。その間ブラウザは表示に関する処理は止まってしまうので、ユーザーに取ってはその分表示されるのが遅く感じてしまいます。
そこで、先にブラウザに表示できるものを表示させて、あとからJavascriptの処理をさせるという順序にすれば、体感的にユーザーに遅さを感じさせないようにすることができます。
もちろん1つ2つの処理であればそこまで影響が出ることは無いと思いますが、大量にJavascriptファイルがある場合などは大きな影響が出る可能性があります。
サーバサイド（バックエンド）側での高速化
さて、ここからは簡単にサーバサイド側の高速化の話を軽く触れていきたいと思います。どうしても技術よりの話題になりますので普段全く技術に関わらない方はナナメ読みで良いと思います。
サーバサイドは本当に様々な条件によって変わってきますので、状況によって高速化の手法はバラバラです。Ruby、Python、NodeJS、Perl、Java、PHPなどプログラミング言語によってももちろん違いますし、BtoCなウェブアプリケーション、BtoBなアプリケーションなど、ターゲットによっても変わります。また、サーバのスペックなどによっても変わってしまいます。非常に複雑で、ある程度以上の専門的な知識が必須になります。
とは言っても、高速化に関してサーバサイドで重要な事は、突き詰めていけばたった一つだけ。「ブラウザに返すレスポンスの速度を上げる」ということです。
特に速度が遅くなりやすい部分、アプリケーションによるデータベースの扱い方について私が意識的に注意している部分に関して簡単に掻い摘んで説明します。
使わなくてよい物はDBを使わない
Webアプリケーションではほとんどの場合、何かしらのデータベースが使われています。データベースは非常に強力なソフトウェア（ミドルウェア）ですが、アプリケーションから使い方を間違えると速度の低下につながります。
ついつい、データベースで何でも管理したくなってしまいがちですが、データベースに入れなくていいデータを入れるのはやめましょう。特にセッションデータをデータベースに入れているケースをたまに見かけますが、なるべく控えたほうがいいです。
このセッションデータと呼ばれる物は、ユーザーがアクセスする度にデータを取得して、更新して書き込むということが発生します。リクエストが発生する度に、データベースへの書き込み処理、読み込み処理が発生してしまうので、データベースに不要な負荷を与えてしまいます。
キャッシュを活用する
当たり前の事かもしれませんが、データベースは呼ばれれば呼ばれるほど、速度が低下します。小さい事かもしれませんが、比較的変更の少ない固定されているデータ「商品マスタ」「ユーザー情報」などはキャッシュしておくべきです。ユーザー数やアクセス数が多いサービスにはかなり有効な方法です。
※ただし、キャッシュを多様しすぎると、正しくないデータがブラウザに表示されてしまうなんて事もあるので使用する際は注意してください。
実行しているSQLの最適化
データベースを使う場合に、本当に最適なデータベースの使い方をしているのか見直しましょう。データを取得する際にSQLを使用しますが、その際に実行されているSQLが意図としたSQLになっているのか？見直してみると無駄がある事も多いので、ここは慎重に確認するべきです。
データベースのインデックスの見直し
データベースの高速化の技術の一つにインデックスという物が存在します。本で言うところの「索引」と同じような物ですが、このインデックスの設定の仕方で速度が何倍も変わってきます。
良いインデックスというのはデータベースの設計やアプリケーションによって変わってきますが、インデックスがしっかり使われているかを確認しましょう。
非同期処理でデータを保存する
データベースにデータを保存する際に、「保存しました」というレスポンスをデータベースから帰って来るのを待っていると速度が遅くなってしまいます。書き込む量が多くなれば多くなるほど速度は遅くなってしまいます。
大切なデータに関しては同期的に対応するべきですが、そこまで重要じゃないデータに関しては非同期で保存するという方法は有効です。
不必要なデータは保存しない
データベースはデータ量が多くなれば多くなるほど、速度が低下してしまいます。不必要なデータを保存するのは避けた方がいいです。
分割を意識した設計
データ量が多くなってしまうデータベースでは、データベースやテーブルが分割されても大丈夫なような設計をするべきです。
、、など、見るべきポイント、高速化を阻害する要因というのは様々あります。
まとめ
ウェブサイトの高速化というと例えば「CSSスプライトを使いましょう！」などのフロントエンド寄りの話が話題になりやすいですが、こういったサーバサイドでもしっかりと対応するために、どの程度のユーザーが使うのか、どの程度の規模のサービスなのか？といったあたりも意識しながらウェブサイトを設計・構築することが重要です。
サイトの高速化について大まかに掻い摘んで書きましたが、まだまだやらなければ行けない事はたくさんあります。今回紹介したポイントを意識して最適化することにより、確実に高速化できるのではないでしょうか。
ヴォラーレ株式会社 望月