- 3 : Expires Header を追加しよう
- 4 : Gzip 化しよう
- 5 : CSSはページの上に配置しよう
- 6 : スクリプトはページの下に配置しよう
- 7 : CSS expressions の使用は控えよう
- 8 : CSSとscriptは外部ファイルにしよう
- 9 : DNS lookups を減らそう
- 10 : Javascriptを最小化しよう
- 11 : リダイレクトを控えよう
- 12 : 重複するscriptを削除しよう
- 13 : ETags を設置しよう
YSLOWの勉強のまとめ。最後に自分の所感をまとめておきます。
YSLOWにおける13の評価基準を一つずつ見てきてわかったことは、YSLOWとは、HTTPの応答を減らせる余地があるかないかを評価するためのツールだということ。それは1の解説にあった「「ユーザーの待ち時間の大半は画像やCSS、javascript、Flashなどのページの構成要素のダウンロードに費やされている」という原則を根本としている。
評価基準はHTTPの応答を減らせるアイデアを13個連ねたといった体裁で、それぞれの難易度がまちまちです。7 : CSS expressions の使用は控えようのように比較的簡単なものから、2 : CDNを利用しようのように対応が開発的にも・コスト的にも難しいものまであるし、10 : Javascriptを最小化しようのように、対応は難しくなくても、メンテナンスが猥雑になる懸念があるものもある。すべてを「A」にするよう努力するよりは、全体の利益とコストを鑑みて、ケースバイケースで最適な対応を考えるのが肝要なのかと思います。
13の評価基準をオペレーション作業とHTMLコーディング作業のふたつに分けるとしたら、2、3、4、9、11、13がオペレーション作業で、1、5、6、7、8、10、12はHTMLコーディング作業に分けられるかと思います。
HTMLコーディングを業務の一部にしていたものとしては、やはり後者の方がより興味がそそられました。どれもわりと普通のことが書かれている感がありますが、たとえば「大規模な集客を想定しているポータルサイトだから、画像の点数を減らしてサイトが重くならないようにしよう」とか、そういったソリューションを持ったHTMLコーディングなどを頭に妄想させていると、わくわくしますね。たぶん誰も気がつかないと思いますが、サーバーの負荷を少し減らして、そして最終的には地球に優しいHTMLになっている、はず（かなあ）。
最後に、この勉強を書き連ねている最中に見つけた、日本語でより詳細に記しているサイトを紹介しておこうと思います（勉強始める前に探しておけばよかった）。