VTuberになったプログラマーの魂の残滓

こいつ……もう意識が……！！

ハイパフォーマンスWeb再考 - 第1回 YSlowについて

performance

先日Yahoo!ニュースがリニューアルを行ったそうです*1
今回のリニューアルでは快適に使うことができるようパフォーマンスを重視したリニューアルを行った、とありました。

で、思ったのがWebにおけるパフォーマンス向上のためにどういうことができるのか。
そして、実際に書籍にもあるような内容を実施するために何に気をつける必要があるのか、について改めて考えてみました。

そもそもWebにおけるパフォーマンスとは何か

Webサイトにおけるパフォーマンスとはいったいなんなのでしょう。

個人的な考えですが、パフォーマンスとは大きく分けて

  • クライアントからサーバ、サーバからクライアントまでの手続きの短さ*2
  • サーバにおける処理の軽さ

なのではないかと考えています。

前者はとても分かりやすい部分だと思います。
ブラウザからとあるURLにアクセスがあったときにどれだけ速くページを表示させるか。

そして後者ですが、一言で軽さと言ってもいろいろあると思います。
例えばCPUの負荷であったり、メモリの消費量であったり、ディスクI/O処理であったり・・・。

ということで、こういったパフォーマンスを向上させるための自分なりの考えであったりノウハウについて複数回に分けていろいろと書いてみたいと思います。

YSlowのスコアは絶対的なモノではない

さて、ここで話は少し昔に戻って、以前こういうエントリを書きました。

で、これに対しての反応として

YSlow はあまり信じられない

YShow はあまり信じられない - #生存戦略 、それは - subtech

YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。

堀愚霊瑠の指摘で気付いた、はてなスターの静的ファイルとか想像以上にアレな件 - にぽたん研究所

YSlowは一つの指標としてはいいけど、Y!が出してるから信じられはするんですけど、個人的には絶対的なものとして捉えるのはアレかなって思ったりします。

YSlowの件 | アヨハタブログ

あとそもそも自分でも

すべてはケースバイケースのためこれらの手法が必ずしも正しいとも限りません

と書いてはいます。

ではYSlowをどう活用すべきなのか

YSlow（高速化のための14のルール）というのはそれぞれの項目を単体で実施することで高速化を行うことはできますし、正しい対応を全ルールで適用させることでさらなる高速化を見込むことができます。

YSlowを使うとウェブサイトのスコアを数字で出してくれるのですが

CSS のファイルが大量なのは favicon を background-image で読み込んでいるせいで、img タグで表示すれば、YShow自体の判定はあがるんですが、体感的にはかなり重くなります。

YShow はあまり信じられない - #生存戦略 、それは - subtech

にもあるように、「スコアを上げる＝高速化」は必ずしも正しくありません。

ここで指摘されているのは「大量のHTTPリクエストが発生している」という内容なので、大量にあるCSS背景画像をまとめてCSS Spriteを活用してリクエスト数を減らしたりだとか、Combo Handlerのようなものを用意して複数のJavaScriptファイルを1リクエスト内に収めたり、といった対応が求められています。*3

で、つまり何が必要なのかというとYSlowというツール上のスコアをあげるのではなく、ツールから導き出されたボトルネック部分を解消していくことが何よりも大切なんですね。

そうなってくるとYSlowを最大限に活用するためには是非一度
ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
の書籍に目を通してもらいたいと思います。

もしくは英語が苦でないのであれば

こちらのサイトに一度目を通した上で「なぜ遅くなってしまうのか」という部分を正しく理解をすることでYSlowのスコアスコアにとらわれず、ツールを活用したうえでハイパフォーマンスなウェブサイトを構築できるようになるのではないかと思います。

追記
YSlowの2.0betaがリリースされたようです。
遙かに使いやすく、そして見やすくなっています。

次回予告

さて、第1回と書いたはいいものの第2回の予定は未定なのですが一度「第1回」と宣言した以上は「パフォーマンス再考」という主題にそった記事を続けて書いていきたいと思います。

*1:[http://techblog.yahoo.co.jp/cat207/cat214/yahoo_3/:title]

*2:ユーザがあるページにアクセスしてから実際にブラウザでそのページが表示されるまでの速さ

*3:もちろん、件のエントリで例としてあげさせていただいたはてなブックマークにおけるお気に入りのアイコンの部分といった対応しきれない部分ももちろん存在しますし、じゃあそこにおけるHTTPリクエストの問題を解決するためだけに多くのコストをかけてお気に入りユーザのアイコンから自動的にSprite画像を生成してCSSも自動で割り当てて、といった対応をする必要があるのかというと、そんなことはないと思います。