Screw-Axis » Web

[Design] Responsive Layoutを学ぶ(2)

nao58 — Wed, 16 Feb 2011 15:14:46 +0000

前回で、レスポンシブなデザインがつまりどういうものであるかと、その基本技術であるメディア・クエリーについて見てきました。

簡単におさらいしておくと、次のようなページを
フレキシブル・グリッド・バージョン (A List Apart)
最終的には、次のようなレスポンシブ・レイアウトに
レスポンシブ・レイアウト・バージョン (A List Apart)
仕上げようという試みです。

基になるレイアウト

まずは、大まかなレイアウトの構造を確認しておきましょう。全体の構成は大きく分けて4つのブロックから出来ています。

mastはfloat: left、それ以外の3つはfloat: rightが指定されて、こうした段組になっています。
(これはあくまで、今回のサンプルの話です。レスポンシブ・レイアウトは、どんな段組にしようと基本的には実装可能です)

レスポンシブ初歩

では、これをウインドウサイズを縮めた時に、縦方向に並ぶよう記述してみましょう。

@media screen and (max-width: 600px) {
  .mast,
  .intro,
  .main,
  .footer {
    float: none;
    width: auto;
  }
}

非常に簡単なことで、各クラスのfloat指定を無くしてやるだけです。コードは「横幅が600pxより小さくなった場合、4つのクラスに対してfloat: noneとwidth: autoを指定する」という意味になります。

動作は、こちらから確認できます。いかがでしょうか。

画像の組み換え

次に、mainブロックにある画像に着目してみます。

現在、3×2のレイアウトになっていますが、スクリーンを小さくしていくと画像が小さくなりすぎてしまうので、ある地点から2×3のレイアウトに変えようと思います。

各人物のエリアには figure というクラスが割り当てられていて、約1/3の大きさになるように指定されています。そして、それぞれ右側にマージンをとっています。ただし、レイアウト上右端に来る2人(HOLMESとWINTER)は、右側のマージンが不要なので、id指定により除去しています。

.figure {
  float: left;
  margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
  width: 31.121642969984202211%;             /* 197px / 633px */
}

li#f-mycroft,
li#f-winter {
  margin-right: 0;
}

ここでスクリーンの横幅が400px以下だった場合には、figure の横幅が約半分になるようメディア・クエリーで指定します。

@media screen and (max-width: 400px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 48.341232227488151658%;          /* 306px / 633px */
  }

  li#f-watson,
  li#f-moriarty {
    margin-right: 0;
  }
}

更に、右側のマージンが不要になる人物(つまり右端に来る人物)も変わるので、そこの指定も行っています。

動作を確認してみてください。

大画面対応

さきほどのレイアウト組み換えは、逆にスクリーンが大きくなった際にも有効なテクニックです。

次のコードは、スクリーンの幅が1300pxを超えた場合に、人物を横一列に並べるよう指定しています。

@media screen and (min-width: 1300px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 13.902053712480252764%;          /* 88px / 633px */
  }
}

動作はこのようになります。

更に進んだ使い方

これらのテクニックを応用することで、更に進んだレイアウトが可能になります。

前回の冒頭で紹介した最終形では、次のような工夫をしています。

各メニューが、小さな画面では最上部に横並びになる (ナビゲーションはページの先頭にあった方が便利なはず)
小さくすると、ロゴがシンプルな小さいバージョンに換わる (余計なものを除去)
大きな画面では、メニューが右上に並ぶ (人物が横一列にならび高さが低くなるので、そちらに移してもレイアウト上問題ないはず)

あとはCSSのテクニックとの組み合わせばかりなので、コードを挙げての説明は割愛します。必要に応じて、サンプルのコードを直接開いてみてください。工夫次第で、かなり色々なことが出来ると思います。

古いブラウザへの対応

このようにメディア・クエリーは非常に強力な機能です。しかし、きちんと対応しているのは主なブラウザでは次のあたりになります。

Safari 3以上
Google Chrome
Firefox 3.5以上
Opera 7以上

何かと問題の Internet Explorer も、次のバージョン9からはメディア・クエリーに対応すると表明はしています。

実際のところ、メディア・クエリーが動作しないブラウザであってもフレキシブル・グリッドなどは機能するものが多いですし、極端に大きくしたり小さくした際に最適なレイアウトが得られないだけなので問題は無いかもしれません。しかし、せっかく用意したものなので少しでも多くのブラウザに対応させたいということであれば、次のような方法があります。

jQueryのMedia Queryプラグインを使う。非常に限定的な機能しか使えませんが、2007年からある便利なツールです。
Css3-mediaqueries-jsを使う。スクリプトがメディア・クエリーの記述を探し出して解析し、動作をエミュレートしてくれます。おかげでIE5以上、Firefox全般、Safari 2以上でもメディア・クエリーが使えるようになります。

これらを導入することで、古いブラウザ環境であってもJavaScritpが動作するようになっていれば、対応できるようになります。

レスポンシブ・レイアウトは、Webの閲覧デバイスが加速度的に多様化している現在、ユーザにとっても開発者にとっても重要なものになってくるでしょう。これからサイトデザインやリニューアルをする場合、最初から設計に組み込んでおくのが良いと思います。

[Design] Responsive Layoutを学ぶ(1)

[Design] Responsive Layoutを学ぶ(1)

nao58 — Wed, 16 Feb 2011 09:45:55 +0000

PCとスマートフォン両対応ページを作っていると、避けて通れないのがレイアウトの問題。昨年サンフランシスコのAdobe Maxで紹介していたResponsive Layoutが良いんだろうと思って調べたのですが、なかなか日本語でまとまった資料が見つからず。

どうも「Responsive Layout」を日本で何と呼んでいるか分からず、だから見つからないのだと思うのですが。海外にすごく良い記事があったので、こちらのサンプルを用いながら、自分用にまとめておきます。

なお、サンプルは元記事のものへのリンクですが、本文は自分のざっとの理解で書いていますので、翻訳にはなっていません。ご了承ください。

デバイスごとに個別にページを用意

サイトが世に必要とされはじめた頃は、これが定番でしたね。サブドメインで m.example.com とか mobile.example.com とか。最近になっても smartphone.example.com なんてのも見かけます。

日本のガラケー対応は、あまりにもPC向けページとは作りが異なるので、結局これしかない部分もあります。また、デバイスによって画面のステップ数を変えるようなこだわりがある場合は、必要かもしれません。

しかし、ほぼ同じアーキテクチャで閲覧できる最近のスマートフォンで、そうした手間をかけるのは面倒です。SEOやメディアからの被リンクにも、あまり良いことは無いですし。

かといって、PCそのままのページ構成では読みにくい場合があることも事実。そこでまず出てくるのがフレキシブル・レイアウトです(まだ、今回取り上げたい「レスポンシブ・レイアウト」ではないので、慌てずに)。

フレキシブルなレイアウト

フレキシブル・レイアウトがどういったものなのか、サンプルを見てみましょう。

フレキシブル・グリッド・サンプル (A List Apart)

PCブラウザで閲覧している場合、ウインドウサイズを大きくしたり小さくしたりすると、どういうものかすぐに分かると思います。いわゆる Fruid Grid (可変グリッド)と呼ばれる構造に、フレキシブル・イメージという親のグリッドにあわせて画像サイズが自動調整されるテクニックを用いた、まさに「フレキシブルな」レイアウトになっています。

可変グリッドやフレキシブル・イメージについては詳細な説明は割愛しますが(要望があれば、どこかで)、スクリプトは事実上IE対応のみで、マトモなブラウザ相手であればHTML+CSSだけでサクサク実装できるのが魅力です。

これで概ね幸せだったのですが、iPhoneサイズで見るには、まだ残念な感じです。極端にブラウザを細くすると、グリッドがヘシャげて読みにくくなることが分かるかと。

そこでレスポンシブ・レイアウトの登場です。

レスポンシブなレイアウト

レスポンシブ・レイアウトでは、フレキシブル・レイアウトのように画面サイズに対して線形比率でレイアウトするのではなく、一定の閾値(ブレーク・ポイント)を堺にスタイルを切り替えることで、更に柔軟な構成を実現します。

まずは、実際に動作するサンプルを見てみましょう。

レスポンシブ・レイアウト・サンプル (A List Apart)

ブラウザサイズを変えていくと、ある地点でレイアウトが変わることがわかると思います。たとえば小さくしていくとサイドバーとコンテンツが縦に並んだり、画像の配置が変わったりといった具合です。この切り替わる境界点が「閾値」の部分です。

更に注目して欲しいのは、依然としてフレキシブル・レイアウトの動作も残している点です。閾値内でのレイアウトには、また従来のテクニックを組み合わせることが可能になっています。

これであれば、例えば同じスマートデバイスでもiPhoneとGalaxy Tabのように大きさが異なるディスプレイで、あるいは縦横の切替で、それぞれに最適な見せ方をすることができます。

次に、具体的な実装を見て行きましょう。

メディア・クエリー

元々はCSS2.1から登場した登場したメディア・タイプが、「デバイスによってスタイルを切り替える」という発想のスタートだったと思います。

実際に多くのメディアタイプが定義され、可能性を感じさせる仕様でした。しかし、メディア側の実装がなかなか追いつかず、実質的にはprintくらいしか使われていないと思います。

そこで登場したのが、考え方を引き継いで、より柔軟な実装を可能にした「メディア・クエリー」です。

メディア・クエリーは、メディア・タイプのようにデバイス依存のクラスを作成するのではなく、レンダリングするデバイスのサイズや性能を調べ、それを基に適用するスタイルを切り替えるものです。例えば次のコードは、iOS、Android、PCなどを問わず、出力先がスクリーン(プリンタなどではなく)で、デバイスの横幅が480px以内であればshetland.cssを適用するという意味になります。

この例では、960×480のスマートフォンを縦に持っている時は、横幅が480pxなのでスタイルが読み込まれます。しかし、横に持ち替えると条件に合致しなくなるので、この行は無視されるようになります。

こうしたことは、近年はJavaScriptを用いて実現するのが常套でした。しかし、メディア・クエリーの実装が進んできたことで、こちらを使えば更に解像度や色数など、更に進んだ機能にも対応できます。

またメディア・クエリーは、スタイルシート自体を切り分けるだけでなく、CSSファイルの中に記述することも可能です。

@media screen and (max-device-width: 480px) {
  .column {
    float: none;
  }
}

更に、importの記述により切り分けることも出来ます。

@import url("shetland.css") screen and (max-device-width: 480px);

特定のデバイスを見分けて切り分けるよりも、その特性にあわせたスタイルを適用する方が合理的であるという考え方を基に、こうした機能は実装されました。

レスポンシブ・レイアウトは、このメディア・クエリーを活用して多種多様なデバイスで最適な表示を実現するようデザインします。

次回で、具体的な実装方法を見ていきます。

[Design] Responsive Layoutを学ぶ(2)

[css] 効率の良いcssを書くための7箇条

nao58 — Sun, 14 Jun 2009 16:44:15 +0000

スタイルシートをシンプルに効率よくすることは、ネットワーク転送量の低下、パース速度の向上、そしてHTMLとのマッチング効率化に繫がります。これはページのパフォーマンスを大きく向上させることに繫がります。

前回は大まかなブラウザの挙動を見ました。
今回は、そういった動きを踏まえた上で、やってしまいがちな非効率なスタイル指定を挙げてみます。そういった指定を避けることで、軽量で高速なスタイルシートを記述することができるでしょう。

なお、この記事は、Google Page Speedの”Use efficient CSS selectors“および、Mozillaの”Writing Efficient CSS for use in the Mozilla UI“などを元に書いています。

1. 不要なスタイルは書かない

言うまでもない大前提です。ですが、ちょっと調べてみると意外と多いのではないでしょうか。
例えばサイト内で幾つかのパターンのページがあります。しかしひとつの外部cssを使っているため、それぞれのページでは不要なスタイルを大量に読み込んでいるようなことは無いでしょうか。
または、ページを変更してコンテンツを入れ替えた場合、新しいコンポーネントのためのスタイルは当然追加しますが、削除した方のスタイルは削除しているでしょうか。

確かにファイルがキャッシュされれば転送時間は軽減できますが、それでも余分なスタイル記述はDisk I/Oの増加をもたらすだけでなく、ルールの多さはそのままマッチングコストの増加に繫がります。

Google Page Speedを用いれば、そのページで使っていないルールを確認できます。
スタイルはスクリプトに比べて分割ダウンロードもしやすいので、使いやすい単位にcssを分割するなどして、可能な限り不要なスタイルを書かないようにしましょう。

2. Universal Rulesを使わない (出来れば、Tag Rulesも)

前回説明しましたが、Keyセレクタによってルールは4種類に分けられます。その際に最も非効率なのが、Universal Rulesです。Universal Rulesはつまり、IDでもクラスでも要素でも無いルールです。これは全ての要素が常に立ち止まって確認するルールになってしまいます。
次にパフォーマンスの悪いのは、Tag Rulesです。これらを極力避けるようにしましょう。

3. IDをタグやクラス名とあわせない

IDはページ内で完全に一意なものなので、そこにタグやクラス名を重ねることは全くの無駄です。
場合によっては、スクリプトなどでクラス指定を切り替え、それによって動きを変えたい場合があるかもしれません。しかしその場合でも、クラス名の方をユニークにすることで無駄な評価を避けられるはずです。
また、ひとつのcssファイルを複数ページで使いまわし、その時にページによって同じIDのあたるタグが変わることでルールを変えるような運用も、前述のような理由で避けるべきです。

  ×  button#backButton { ... }
  ×  .menu-left#newMenuIcon { ... }
  ○  #backButton { ... }
  ○  #newMenuIcon { ... }

4. 子孫セレクタを使わない

次のようなセレクタを、descendant(子孫)セレクタと呼びます。

body * {...}
#footer h3 {...}
* html #atticPromo ul li a {...]

これは関係を辿るセレクタとしては最低ｊといってよいほどにかかるので、極力避けましょう。
と書くと、ショックを受ける人もいるのではないでしょうか。(自分は最初にこれを聞いた時、少なからずそうでした)
CssはCASCADE Styele Sheetです。「カスケード」はまさに、こういった入れ子での制御を使いこなすことだと思っていました。
しかし、前回のエントリを見ていただいたら分かるのではないかと思うのですが、要素がマッチする限りDOMツリーを辿ることを繰り返さなければなりません。この上でKeyセレクタがTagもしくはUniversalであれば、まさに最悪です。(先ほど挙げた例は、まさにそれです)

要素の関係性で表現するのではなく、クラス指定などを用いて効率の良いマッチングが行えるようにしましょう。
例えば次のようなスタイルを書くよりも、

.side-menu ul li { ... }
.side-menu ol li { ... }
.top-menu ul li { ... }

各li要素にクラス指定を行った方が、マッチングコストは安くあがります。

.side-menu-list { ... }
.side-menu-list { ... }
.top-menu-list { ... }

5. 子セレクタを使わない

子孫セレクタほどではありませんが、child(子)セレクタも非常に高コストです。
特にTag RulesやUniversal Rulesと組み合わせてはいけません。特にルールが頻繁にマッチしてしまうと、辿る回数はその分だけ増えていきます。例えば次のようなルールは、その親要素であることが稀であり、無駄にコストを上げてしまう一例です。

form > input { ... }
dl > dt { ... }
table > thead > tr > th { ... }

前の子孫セレクタ同様に、クラス指定などでの直裁的な指定をするようにしましょう。

6. :hover擬似セレクタを使わない

:hover擬似セレクタの指定は、どんな場合であれパフォーマンスに悪影響を与えますが、特にアンカー(aタグ)でない要素に対して用いると問題が多くなります。

div:hover
* div:hover

出来るならば、擬似セレクタではなく javascript の onmouseover などによる制御を行いましょう。

7. 継承に委ねる

親要素から自動的に継承されるスタイルをきちんと理解して、無駄な指定を省きましょう。
例えば list-style-image スタイルは親要素から継承されます。これを知っているかどうかで、場合によっては次のようなスタイルルールを作ってしまうかもしれません。

div.star-list ul li { list-style-image: url( star.gif ); }

しかし、これは次のような指定で充分です。

div.star-list { list-style-image: url( star.gif ); }

些細なことのようですが、ここでulブロックやli要素が数百あったらどうでしょう。上の例では、その数百の要素に対して「先祖がulで、その先祖がstar-listというクラスを持つdiv要素であるか」という評価を繰り返すことになってしまいます。しかし下の例であれば、その数百のli要素群は全くマッチングコストをかけることなく、同じ効果を与えられます。

なお、ここで言う「効率が良い」とは、あくまで実行時のパフォーマンスにフォーカスしたものです。開発やメンテナンスなどの管理効率などとは相反するような場合もあるかもしれません。
しかし、ここで挙げられていることはよく読めば、「直接指定」や「重複を避ける」など、スタイル指定のスパゲティ化を避ける方法とも言えます。
ページの高速化は何よりのユーザビリティ向上なので、うまくバランスをとりながらパターンを確立していきましょう。

[css] ページにスタイルがあてられる仕組みを学ぶ

[css] ページにスタイルがあてられる仕組みを学ぶ

nao58 — Sun, 14 Jun 2009 16:30:31 +0000

Google Page Speedの記事から始まってしまったサイト高速化関連記事。
今回は、効率の良いスタイルを書くために、ブラウザがHTMLを解析してDOMツリーをつくり、そこにスタイルをあてていく過程を見ていきましょう。

基本的な手順がわかると、どういったcssの書き方が効率が良く、どういった書き方では迂遠であったり冗長であったりするのかが、理解できるようになると思います。

この記事は、Google Page Speedの”Use efficient CSS selectors“および、Mozillaの”Writing Efficient CSS for use in the Mozilla UI“などを元に書いています。そのため、この仕組みは主にMozillaエンジンについてです。IEやWebKitでは若干異なった動作をする部分もあるようです。

マッチングの回数

ブラウザは、読み込んだHTMLをパースしてDOMツリーを作成します。
その後、ツリーを辿りながらそれぞれの要素について、各スタイルが合致するかどうかを検証することになります。検証はルールのグルーピング(後述)などにより効率化はされていますが、基本的には全ての要素を駆動表に、全てのスタイルルールを検証する作業になります。つまり、端的には次のような計算数分だけ、マッチングが行われるわけです。

HTML中の全要素数 × スタイル上のルール数

例えば、次のようなシンプルな文書があったとします。


  


  タイトル
   ... 
  
     ...

この中に、要素は5つ(body, h1, div x 3)あります。スタイルは3つです。5つの各要素に対して3つのルールがマッチするかを検証するわけですから、マッチング数としては 5 x 3 となり、計15回のマッチングが行われる計算になります。

マッチングの詳細

では、今度は各マッチングを見ていきます。
まず”Keyセレクタ”という言葉を覚えてください。これは、単純に「ルールの一番右側にあるセレクタ」を指します。例えば次のようなスタイルがあった場合、

  #id { ... }
  .class div, .class p { ... }
  div.class form input[checked="checked"] { ... }

Keyセレクタは上から順に、#id、divとp、input[checked="checked"]です。
このKeyセレクタが次のいずれに該当するかで、スタイルルールをまず大きく4つに分類します。

ID Rules
KeyセレクタがIDであるもの。

button#backButton { }
#urlBar[type="autocomplete"] { }
treeitem > treerow > treecell#myCell:active { }

Class Rules
Keyセレクタがクラス指定であるもの。

button.toolbarButton { }
.fancyText { }
menuitem > .menu-left[checked="true"] { }

Tag Rules
Keyセレクタがタグ指定であるもの。

td { }
treeitem > treerow { }
input[type="checkbox"] { }

Universal Rules
Keyセレクタが、つまり上記3つのいずれにも当てはまらないもの。
```
[hidden="true"] { }
* { }
tree > [collapsed="true"] { }
```

このようなグループ分けをした上で、マッチングは該当要素に合致するかどうかを、ルールの右(Keyセレクタ)から順に左方向に確認していきます。合致しなくなったところで検証を止めます。

具体的に見てみましょう。
次のようなスタイルがあったとします。

div.cls fieldset > input { ... }

HTMLは、次のようにします。

ここで6行目のcheckboxを、前述のスタイルルールにマッチングしてみます。

Keyセレクタである”input”がタグなので、このルールはTag Rulesに分類されています。この要素はまずTag Rules中のinputにマッチするかを確認し、検証を始めます。
ひとつ左に行くと、これは「1つ親の要素がfieldsetである」という意味です。そこでDOMツリーでひとつ上を確認(5行目)すると、確かにfieldsetです。
そこで次のルールを確認します。次は「先祖にclsという名前のクラスを持つdiv要素があること」です。DOMツリーを順に辿っていくと(4→3→2行目)、該当するものが見つかりました。
全てのルールに合致したので、このスタイルを適用します。

では次に、次のようなルールを検証してみましょう。

#id { ... }

これは当然、ID Rulesにカテゴライズされています。

idというidを持つ要素であるので、合致する

終わりです。

これは極端な例ですが、スタイル指定の効率の良し悪しが想像つくと思います。
次は、具体的に効率の悪いスタイル記述を挙げてみます。そういった記述を極力避けることで、スタイルの適用を高速化することができます。

[Web] Google Page Speedでサイトを高速化

nao58 — Sat, 13 Jun 2009 19:01:08 +0000

3～4回で書けると思ったGoogle Page Speedについて。

ひとつの項目について思った以上に長くなってしまっているので、順番を間違えた気もしますが、ここでインデックス的に全体をまとめておきます。

おさらいしておくと、このツールはFirebugと組み合わせて使う、ページのボトルネック調査ツールです。
Page Speedを実行したからといって、自動的にページの表示スピードが速くなるようなことはありません。リストアップされた問題点を理解し、自分の環境にあわせた対応策をとって、はじめてページは高速になります。

自サイトに対して挙げられた項目であれ、そうでなくても、注意すべき点として基本的な内容を理解しておくことは有益です。

キャッシュの最適化 – Optimizing caching

ネットワーク転送量を減らすことは、ページの表示速度を劇的に速められます。ブラウザやプロキシのキャッシュの仕組みを学び、効率良くデータを交換しましょう。

Leverage browser caching

ブラウザキャッシュを有効にして、データの再送を減らします。
キャッシュを使うには、HTTPレスポンスヘッダにExpireやETagなどを付けてやる必要があります。キャッシュの方法には一定期間無条件でキャッシュをする方法と、データに変更が無いかどうかの通信を行い、必要な場合だけ内容を転送する方法があり、当然ながら前者の方が高速です。
ヘッダを付与するのは、ほとんどの場合Webサーバの役目です。
» 詳細

Leverage proxy caching

プロキシサーバにキャッシュをさせると、各クライアントからネットワーク的に近いところでキャッシュが行われ、高速化やサーバの負荷軽減に役立ちます。
HTTPヘッダへの記述や静的ファイルのURL記述方法によって、キャッシュされるかどうかが変わってきます。逆に効果測定用のリクエストなど、プロキシにキャッシュさせたくないものもあります。ケースを学び、正しくコントロールできるようにしましょう。

往復遅延時間の最小化 – Minimizing round-trip times

キャッシュは主に再訪者に効果があるものですが、RTTを軽減することは全てのケースで有効です。
無駄を省き、パラレルに効率良くダウンロードすることで、根本的な高速化を図ることが出来ますが、若干高度なトピックが多いかもしれません。

Minimize DNS lookups

HTTPで通信する際、ホスト名毎にDNSルックアップと呼ばれる作業が必要になります。例えば”screw-axis.com”と通信したい場合、そのままでは接続先を見つけることができません。DNSに問い合わせて、”112.78.113.31″というIPアドレスであることを教えてもらわなければなりません。
同じホスト名であれば何度もルックアップする必要はありませんが、例えば1つのページに20種類のホストがあれば、20回の問い合わせが必要になります。可能な範囲でこの数を減らすことは、無駄を省き、RTTの最小化に役立ちます。
後述するように、必ずしもホスト数を最小にすることがイコール最適化ではないのですが、不要な呼び出しは減らしていきましょう。

Minimize redirects

サイトがリダイレクトを使う理由は様々です。サイトの移転、多重ドメイン、アクセスのトラッキングなど、それぞれの理由でリダイレクトを行っていると思いますが、可能な限りこれを避ける方法を講じるべきです。
単に不要なものを除外する他にも、リダイレクトではなくリライトを用いたり、トラッキングをバックグラウンドで非同期に行うなどの工夫をしていきましょう。

Combine external JavaScript

外部Jsファイルはモジュール毎に分割されがちですが、1つにまとめてもコード量は同じです。
特にJavascriptはパラレルダウンロードが行われないブラウザが多いため、接続の初期化やHTTPヘッダの往復が細かいボトルネックになります。
管理の利便性などとのトレードオフになりますが、Minify、結合、圧縮を行って通信できる管理運用方法を確立しましょう。
» 詳細

Combine external CSS

スタイルシートもJs同様に、まとめることでボトルネックを軽減できます。
しかしCSSに関してはパラレルにダウンロードできるブラウザが殆どなので、ケースによっては分かれていた方が高速な場合もあります。(そのケースはトータルでかなり巨大なスタイル群になっているはずなので、そもそも避けるべき事態ですが)
その際でも、指定の仕方によってはパラレルに走らないこともあるので注意してください。
» 詳細

Optimize the order of styles and scripts

ダウンロードの手順で、同時に走る通信量は大きく変わります。
head要素内のファイル指定順、インラインスクリプトのタイミングなど、原理を理解してセオリーを身につけましょう。
» 詳細

Parallelize downloads across hostnames

ひとつのブラウザが、あるホストと同時に作れる接続は限られています。
平行ダウンロード数を増やすため、ホストを敢えて分散させるテクニックも学びましょう。
» 詳細

リクエストサイズの最小化 – Minimizing request size

HTTPはリクエスト毎にヘッダを送受信します。
このサイズを減らすことは、ひとつひとつは小さくても、回数が非常に多いのでトータルで大きな転送量を減らすことに繋げることが出来ます。

Minimize cookie size

cookieのサイズは極力小さくしましょう。
例えばユニークなIDを発行してcookieに入れ、データの中身はサーバ側で持つような工夫も有効です。

Serve static content from a cookieless domain

静的ファイルを大量に扱うようなサイトでは特に、リクエストに付随するcookieの転送量は馬鹿にならなくなってきます。
スタティックなファイルを置く専用のドメインを用意することで、完全にcookieの送受信を無くす方法も検討しましょう。

データ本体のサイズ最小化 – Minimizing payload size

静的なファイルであれ動的なファイルであれ、データ本体のサイズが通常は最も大きくなります。
このサイズを減らすことは、極めて本来的・直観的にページを「軽く」することに繫がります。

Enable gzip compression

最近はほとんどのブラウザはgzip圧縮されたコンテンツを解凍することが出来ます。
基本的にdeflateは圧縮時に比較的コストがかかり、解凍が非常に高速なアルゴリズムです。HTML、Css、Javascriptのようなテキストベースのコンテンツは特に圧縮効果が高いので、ネットワーク転送量軽減のために積極的に活用しましょう。

Remove unused CSS

使わないスタイル定義は削除しましょう。
効率の良いスタイルを書くことは、単に転送量だけでなくパースやレンダリングの速度向上にもつながります。
複数のページにまたがったスタイルシートを使う場合、ファイルをパーツに分割して必要なものだけを取り込むような工夫をしましょう。
Page Speedは該当ページで使われていないスタイルを洗い出してもくれるので、最適化に役立つでしょう。
» 効率の良いcssを書くための7箇条

Minify JavaScript

スクリプトをコーディングする際、可読性のために改行やインデントは欠かせません。しかし、そういった改行や空白をネットワーク転送し、パースする際に読み込むことはコンピュータにとっては無駄です。
JSMinやYUI Compressorを使い、整形用文字の除去や変数・関数名の圧縮などを行いましょう。

Defer loading of JavaScript

ブラウザはスクリプトが実行されるまで、ページをレンダリングせずに待機します。これは、スクリプト内でページを変更する可能性があるからです。
ユーザはレンダリングが先に行われると、体感速度が上がったように感じるものです。
明示的に「このJsファイルはページのレンダリングに不要」と指定することで、ブラウザの処理の順番を制御することが出来ます。

Optimize images

それほど画質を落とさずに画像のファイルサイズを減らすための軽減ツールや圧縮ツールも数多くあります。
必要性と許容できる画質のバランスをとりながら、極力ファイルサイズを軽くするようにしていきましょう。

Serve resources from a consistent URL

キャッシュを有効に使うため、同じファイルは常に同じURLを使うようにしましょう。
例えばa.example.comとb.example.comに同じJsファイルがあった場合、二重に置かずにb.example.comからもa.example.comを参照した方が効率が良いはずです。

ブラウザのレンダリング最適化 – Optimizing browser rendering

ダウンロードが終わってからも、ページが表示されるまでにブラウザはパース、レンダリング、実行を行います。
クライアント側での処理を最適化することで、ページを軽くすることが出来ます。

Use efficient CSS selectors

CSSの指定は基本的にセレクターを用います。しかし一概にセレクターと言っても、効率の良い指定と悪いものがあります。
極力非効率なCSSセレクター指定を避ける記述を覚えましょう。
» ページにスタイルがあてられる仕組みを学ぶ
 » 効率の良いcssを書くための7箇条

Avoid CSS expressions

Internet Explorer 5～7向けに、CSS Expressionを使っているサイトもあるでしょう。しかし、これはレンダリングのパフォーマンスを下げてしまいます。
IEも8以降は機能自体が非推奨になることもあり、他の方法で実現できる方策を練りましょう。

Put CSS in the document head

body内などでstyle要素を使わないようにしましょう。
可能な限りheadタグ内にlink要素を記述し、@importは使わないようにしましょう。

Specify image dimensions

imgタグに画像のサイズは必ず指定しましょう。
サイズがわかれば、画像のダウンロードが終わる前にも正しい位置でレンダリングが可能です。

今後も時間があれば、ピックアップして詳しく取り上げようと思います。

[Web] Google Page Speedでサイトを高速化(4)

nao58 — Thu, 11 Jun 2009 16:42:37 +0000

パラレルダウンロードについて、更にもうひとつ。今度は、JsやCssなどのテキスト系外部ファイルだけでなく、画像なども含めた全ての外部ファイルに関する話題です。

今、皆さんが管理しているページは、画像やFlashなども含めた「外部ファイル」を幾つくらい必要としているでしょうか？
私が今、チューニングを求められているページは、1ページ表示しようとしただけで、もろもろ含めて150以上のファイルをダウンロードしてしまいます。
当然、css spriteなどでファイル数そのものを減らすことを考えなければいけませんが、それでも限界がある数です。

なるべく多くのファイルを、同時並行でダウンロードしてきて欲しい。こんな場合に考えなければいけないのが、ホスト毎に貼れるセッションの数です。

ホストごとのダウンロード数 – Parallelize downloads across hostnames

ブラウザがひとつのホストとの間に同時にはれるセッション数は、2から多くても6程度です。（正確には、例によってUA Profiler参照）
これは技術的な限界ではなく、HTTP1.1で策定された取り決めです。攻撃まがいの行為を防ぐなどの目的で、ひとつのホストと同時に接続要求できるのは「2」までとされましたが、現在はハードウェアの性能やネットワークの帯域が向上したことで、もう少し多くの接続が許されるようになってきています。

現在の主流ブラウザを「6」とすれば、それでも6つのファイルしか同時にダウンロードすることは出来ないということになります。
前述のページであれば、どんなに効率が良くても25回(150/6)分のロード時間が必要になってしまいます。
これを増やすために、セッション数の制限があるのは「あるホストと」であることに注目してみましょう。

例えば”example.com”というサーバにあるページを表示する場合、”example.com/img”のような場所に画像を置くことが多いかと思います。
しかしその場合、前述のように同時にはれるセッションは多くて6つまでです。仮に30のファイルが必要だとすれば、第5陣まで取得しなければなりません。

では、この画像類が”img1.example.com”,”img2.example.com”…というような、複数のホストに振り分けられていれば、どうでしょう。
img1に6ファイル、img2にも6ファイルと同時にとりにいけば、30ファイルを同時並行で一斉にダウンロードすることも可能です。
このような「トリック」を使うことは、サイトの高速化に非常に重要です。

ホストは、必ずしも物理的/IP的に異なるものである必要はありません。実体として同一の、ヴァーチャルホストなどであったとしても、ブラウザは名前が異なれば別々のホストとして認識します。

以下はGoogle Mapsでのタイルレイヤー画像のダウンロード状況を示してくれたグラフです。

赤枠で囲ったあたりだけでも10以上のファイルが、複数のホストから同時にダウンロードされていることが分かるでしょう。

但し、だからといって闇雲に増やせば良いというわけではありません。
ホストとの接続には新たなTCP接続のための初期化や、名前解決のためのDNS Lookupなどの処理が必要になります。更に同時にあまりにも多くのファイルダウンロードが実行されれば、今度はクライアント端末のCPUなどが高負荷になりすぎる可能性もあります。
Googleによれば、経験則上でホストの数は2～5くらいとしておくのが良いようです。

注意点が2点あります。

まず、JavaScriptファイルは多くのブラウザでパラレルダウンロードが出来ない件。
このため、複数のホストにJsファイルを分散することは無意味です。ここでは、前回で説明したようにスタイル等との指定順に配慮したり、外部ファイルをひとつに結合することが、より重要です。

次に、あるファイルは、同じサーバから再度取得されるようにしなければならないということ。
例えばランダムに、ある時は a.gif を img3 で取得し、同ファイルを次は img2 に取得しにいくようにするようなことは、決してやってはいけません。初回で見たようなブラウザキャッシュを有効活用できなくなってしまいます。

最後に、このトリックを用いると、静的画像のcookieヘッダの利用を制限することも容易になります。
これについては、また別途。

[Web] Google Page Speedでサイトを高速化(3)

nao58 — Thu, 11 Jun 2009 12:26:47 +0000

なかなか更新する時間がとれないですが、今回は外部ファイル取り込み時間の圧縮の続きで、パラレルダウンロードに焦点をあてます。

JsやCssなどの外部ファイルは、ブラウザによりますがパラレルに平行してダウンロードすることが可能です。1つより2つ、2つよりも更に多くのファイルを同時にダウンロードさせることは、トータルのRTT軽減に直接役立ちます。
しかし記述方法によっては、パラレルダウンロードが全く行われなくなってしまうこともあります。
ダウンロードジョブを効果的に並べて、ページの表示速度を向上させる方法を見ていきましょう。

CssやJsの並びを最適化 – Optimize the order of styles and scripts

まず覚えておくべきなのは、「外部Jsファイルを取り込むページでは、そのダウンロードが終わるまで、HTMLのレンダリングやページ内のscriptタグの実行を行わない」ということです。
これはスクリプトが(X)HTMLやスタイルを変更する可能性があるためです。

そしてRTT軽減のために更に重要なことは、「多くのブラウザは、スクリプトのダウンロードが始まると他の外部ファイルのダウンロードを待たせる」点です。
一方、既にダウンロードしているファイルがあれば、ブラウザはそれと平行してスクリプトのダウンロードを開始します。

GoogleはPage Speedのドキュメント中で、これをわかりやすく説明する実験をしています。

まず、次のようなコードでページを表示します。

これらを踏まえ、次のような基本ルールでのぞみましょう。

外部スクリプトは、外部スタイルシートの後に読み込む
可能な限り、この順番を守るべきです。仮にスクリプトが実行された結果をうけてはじめて結果が変わるようなスタイルの設定をしない限り、このルールを徹底させましょう。
インラインスクリプトは、外部ファイルの指定後に記述する
これも可能な限り、このルールで書くべきです。
但し、外部スクリプトがインラインスクリプトの記述いかんで動作を変えるような場合、これが難しいこともあるでしょう。その場合は逆に、インラインスクリプトをスタイルシートも含めた全ての外部ファイル指定の前に持っていくべきです。

但し、ここまで見てきた「スタイルシートはパラレルダウンロード可能」「スクリプトは他のファイルのダウンロードを待たせる」といった動作は、あくまで「現時点での多くのブラウザで」という注釈がつきます。
UA Profilerなどで確認すれば、Chrome2やFF3.1、IE8などの最新ブラウザでは、スクリプトのパラレルダウンロードもサポートしはじめています。
こういったブラウザが主流になってくれば、ここで挙げたセオリーも変わってくるでしょう。
しかしそれまでは、高速なサイトを作るためには、こういったことへも意識を保っておくことが重要です。

[css] @importを使うべきでない理由

nao58 — Sun, 07 Jun 2009 07:04:25 +0000

実は以前に別の場所でも書いたのですが、今回Google Page Speedの方でも少しだけ触れられていたので、改めてまとめ。

自分でも経験があることなのですが、開発をやっているとどうしても、構造をモジュール化して複数のファイルに分割して管理したくなります。
StyleSheetにおいても同様で、プレゼンテーション層のコンポーネントにあわせてCSSを用意し、ページ構成にあわせて取り込むようなことをやりたくなるでしょう。

しかしその際、@import構文を使うのはパフォーマンスと挙動の両方に有害である可能性が高いと、「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」の著者としても知られるSteve Souders氏が警鐘を鳴らしています。

使うべきでないポイント

@importは、大きく分けて2つの観点で「使うべきでない」とされています。

ひとつは、パフォーマンスの問題。StyleSheetはほぼ全ての主要ブラウザでパラレルロードがサポートされています。これにより、例えば取得に1秒かかるファイルを3つ使うにも、3ファイルを平行して取得できるのでトータル1秒で済みます。
しかし、@importを使うことで、パラレルにダウンロードが出来なくなるケースがあります。その結果、3つのファイルは順に取得され、計3秒かかることになってしまいます。

次に、挙動の問題。こちらはある意味、パフォーマンスよりも深刻です。
ある条件下で@importを使うと、CSSの読み込み順序が変わってしまうことがあります。スタイルシートは読み込まれる順番によって適用スタイルの優先度が変わるため、結果として「ある特定のブラウザで、挙動が変わることがある」という非常に再現性の悪い不具合を内包させてしまうことになってしまいます。

検証1: @import x 2

まず、a.cssとb.cssという2つの外部ファイルを、HTML内で直接、共に@importで取り込む場合の検証をしてみましょう。

この方法であれば、2つのCSSは並行してダウンロードされ、パフォーマンスの問題は発生しません。
# 後述するように、JavaScriptとあわせた場合にエラーの原因となる可能性はありますが。

検証2: linkと@import

次に、HTMLでa.cssをlinkで、b.cssをインラインstyle要素の@importで呼び出すようにしてみます。

この場合、Internet Explorerの6～8では、次のようにシーケンシャルにダウンロードされるようになってしまいます。

結果、パフォーマンスの劣化を招きます。

検証3: link中で@import

a.cssをlinkで呼び出し、その中でb.cssを@importで呼んでいた場合はどうでしょうか。

[HTML]

[a.css]

@import url('b.css');

この場合、ブラウザはまずa.cssを読み込み、次にようやくb.cssを取り込むことを通知されます。
結果、先ほどの例のようにIEだけでなく、全てのブラウザでシーケンシャルロードになってしまいます。

検証4: linkブロック中で@import

では、少し変えて、今度は非常に軽量なc.cssを用意してみます。そしてc.cssが@importでb.cssを読み込みます。a.cssとc.cssをlinkで読み込んでみると、どうなるでしょうか。
[HTML]

[c.css]

@import url('b.css');

実行前に少し考えてみましょう。まず、a.cssとc.cssは並行して読み込まれるはずです。そして非常に小さなc.cssを読み込んだところで、b.cssの読み込みが始まります。トータルでかかる時間は、c.css+b.cssになると予想されます。

結果は、次のようなものでした。2行目から順にa, c, bの読み込みを表します。

予測した通りの結果です。

ところが、同じコードをIEで実行すると、次のようになってしまいます。

a.cssとc.cssは平行してダウンロードされていますが、a.cssのダウンロードが終わるまでb.cssの取得が開始されていません。
どうやらIEでは、パラレルダウンロードされるファイルの最も遅いものに引き摺られてしまうようです。

検証5: 大量の@importとscript

今度は、検証1で少し触れた@importとscriptの組み合わせを試してみます。

IEでの実行結果を見てください。

上から2行目の、最も長いのがone.jsのダウンロードです。
この例のようにスクリプトタグを一番最後に書いても、IEでは真っ先にダウンロードが始まってしまいます。
このため、このスクリプトがスタイルが当たっていることを前提としている場合（cssによって指定される位置や色、形状などを元にしたエフェクトなど）、予期しない動作を招いてしまう可能性があります。

検証6: link x 2

linkだけを並べたケースは、最も問題が起きにくい優れた記述です。

検証5で既に部分的に見ていることですが、IEであっても期待通りに平行してダウンロードが行われます。

検証7: linkと@imporブロック

では、linkを並べる形をとれば、その中で@importをネストしても大丈夫なのでしょうか？
a.cssとb.cssを並べて読み込み、a.cssからは多くの他のファイルを@importで読み込むようにしてみます。

[b.css]

@import url('c.css');
@import url('d.css');
@import url('e.css');
@import url('f.css');

期待通りにa.cssの読み込みが終わったところで、他のファイルのダウンロードが始まっています。

検証8: 大量のlinkとscript

最後に、検証5で問題だったスクリプトとの実行順序を確認します。

IEで検証しても、期待通りの動作をします。

まとめ

スタイルシートから他のスタイルシートを読み込むことは、どんな方法であれ2つのCSSのロードをシーケンシャルに行わせることになります。
インラインで@importを使うことは、IEではパフォーマンスの劣化と異常動作を招くことになります。

以上のことから、可能な限り@importは用いず、linkを使ってパラレルに読み込むことが最も推奨されます。
既に稼動しているシステムで使ってしまっている場合、急に変更することは難しいと思いますが、せめてHTMLからの呼び出しは全てlinkに統一しておきましょう。

[Web] Google Page Speedでサイトを高速化(2)

nao58 — Sun, 07 Jun 2009 02:39:19 +0000

前回のブラウザキャッシュの最適化に引き続き、今回は外部ファイルの取り込み時間の圧縮をやってみましょう。

最近立ち上げたサイトはこの辺の対応もしっかりしているのですが、ちょっと昔に作った管理サイトを見てみると、上位に要対応とされたのが実はこの2つ。

CSSやJsなど、ページがリッチになっていくにつれて取り込む外部ファイルも増えていきます。これらを小さくまとめて転送量を減らす工夫をすることは、ちょうどバイキングで何度も取りに行くよりも、一度に山盛りに盛ってきた方が効率が良いようなものです。
（そもそも、量を減らすことも考えなければいけませんが）

外部JavaScriptの結合 – Combine external JavaScript

開発をやる人ならわかると思いますが、Javascriptを記述する場合も、きちんとモジュール化すればファイルは多くなってしまうものです。例えばjQueryでサイトを作る場合、coreに加えてuiやpluginsを組み合わせていけば、すぐに10くらいのjsファイルを使うことになってしまいます。
開発効率やメンテナンス性を考えれば間違いなくそうすべきなのですが、実際にページをブラウザで表示する段になると、細かいダウンロードが大量に発生することになってしまいます。

ここで、Google Page Speedでは1つの例を示しています。

これは13個の異なった.jsファイルを使ったページをFirefox 3.0系のブラウザで取り込んだ様子を、FirebugのNetパネルで観察したものです。
各ファイルの総量は729KB。それらが全てロードされるのに要した時間は、4.46秒となっています。Javascriptだけで約5秒かかるページを、我慢強く見てくれるユーザは多くは無いでしょう。
見て分かるように、ブラウザは複数のファイルをひとつひとつ順に、シーケンシャルにロードしています。これは、Firefox3.0がJsのパラレルダウンロードをサポートしていないためです。ひとつのファイルを読み込み、パースし、次のファイルを読むということを、13回繰り返しているのです。
最新のブラウザでは、これらを並列に行うことができるものも出てきています。UA Profilerの「|| Scripts」の列に「yes」とあるものがパラレルダウンロード対応のブラウザですが、まだまだ数が少ないことがわかると思います。

Googleの実験では次に、先ほどの13ファイルを2つのファイルに結合してリロードしています。

結合というのは、つまり単純に並べただけです。特別な圧縮処理などは行われておらず、ファイルの総量は729KBで変わっていませんが、所要時間は1.87秒に激減しています。
これは、各ファイルをロードする際にはリクエスト/レスポンスヘッダが転送されている分が無くなっているために実際には転送量が減っているためでもありますし、パケットやレンダリングエンジンの効率など要因は様々ですが、端的に「何度も取りに行くよりも、一度にたくさん持ってきた方が早い」と思っておけば良いでしょう。

但し、全てを単純にひとつにまとめれば良いというわけにもいかない、幾つかの要因があります。

defer loading
そのJsファイルの実行がページの見栄えに影響を与えない場合、defer属性をつけておけば、ブラウザはスクリプトのパースを後回しにしてHTMLをレンダリングします。これはユーザの体感速度を大きく向上させます。
複数のJsファイルを、deferで呼べるものとそうでないものに分けられるならば、それぞれのグループでまとめるべきです。
プラグインのバージョン
あるプラグインやモジュールに異なったバージョンが存在し、ページによって使い分けたいような場合は、そのファイルを別にしておきたいでしょう。
結合できない種類のファイル
例えば効果測定用や広告表示用のスクリプトなど、このようにコントロールできないファイルもあると思います。

これらのことを鑑み、Googleでは出来れば2つ、多くて3つのファイルにまとめることを推奨しています。

まとめとして、JavaScript結合のちょっとしたルールを次のように定めるよう推奨されています。

JavaScriptは2つのファイルに分ける。1つはページのレンダリング開始前にロードされていることが必要な、最低限のスクリプトをまとめたもの。もうひとつは、ページのロードが終わってから取り込まれれば良いファイル群。
head要素内に書かれるスクリプトファイルは可能な限り少なく、小さなサイズにする。
滅多に使われないファイルはそのまま持ち、リクエストがあった場合のみ取り込む。
キャッシュされたくない種類の小さなスクリプト（効果測定や広告など）は、外部ファイルではなくHTML内に直接記述することを検討する。

最後に、スクリプトと他の外部ファイルがロードされる順番にも注意を払わなければなりません。
これについては、別途説明します。

外部CSSの結合 – Combine external CSS

外部CSSに関しても、前項のJs同様にひとまとめにすることでRTT(Round Trip Time)を軽減できます。

概要はJsとほぼ同じなので省きますが、UA Profilerを見ればわかるように、CSSの方がJsに比べてパラレルダウンロードに対応されています。
そのため比較的まとめ効果は出にくい面もありますが、逆にそれを活かすために注意すべき点もあります。
最も重要な点は、@importを使わないこと。これについては、Google Page Speed上には詳しい説明が無いので、別途説明しようと思います。
→しました。「CSSで@importを使ってはいけない理由」

[Web] Google Page Speedでサイトを高速化(1)

nao58 — Sat, 06 Jun 2009 09:15:36 +0000

つい先日Googleから公開されたPage Speedは、彼らが社内で使っていたページを高速化するためのチェックツールです。Yahoo! YSlowのGoogle版と思えば良いのだと思います。

これらはあくまで「チェック」ツールなので、診断結果を自分で最適化しなければなりません。
YSlowでも「へー、知らなかった」と思うチェックポイントが幾つかありましたが、今回も考えていなかったようなポイント、知っていたものの徹底していなかった点などがあったので、そういった部分を中心に、自分の経験も踏まえてメモ。

まずは基本の「キ」である、ブラウザキャッシュについて。

ブラウザキャッシュの利用 – Leverage browser caching

基本的なことで忘れられがちですが、やはりブラウザキャッシュは最も効果的な高速化策のひとつです。
特にほとんど変更されない画像やCSS、Js、PDFなどの静的なコンテンツにはとても有効です。
また、HTMLファイルを静的コンテンツとみなすことも可能ですが、内実としては動的に作られていることも多く、細かな変更や修正も入るために一般的にはブラウザキャッシュはさせない方が良いでしょう。

ブラウザキャッシュを有効にする方法は、大きく分けると次の2種類があります。

ExpireとCache-Control: max-age
これらのヘッダで提供されるキャッシュは、最新ファイルの確認すら行わないので、非常に高速です。一方で当然ながら、サーバ側で更新があってもクライアント側でそれが反映されません。
Last-ModifiedとETag
こちらはExpireなどに比べれば弱いキャッシュで、ブラウザは2回目以降のリクエストでサーバにLast-ModifiedやETagを送信します。サーバ側ではこれらのリクエストが送られてくると手元のファイルと比較し、ブラウザが現在キャッシュしているコンテンツを使えば良いと判断した場合はステータス304を返し、コンテンツの内容は送信しません。これにより、サーバ側のディスクIOやネットワークトラフィックを軽減することができます。

これに対して、推奨される対応は次のようなものです。

全ての静的コンテンツにキャッシュ用ヘッダをつける
Googleは最低でも1ヶ月、出来れば1年以上の期間、ブラウザキャッシュを有効にするよう推奨しています。
これは、特にCSSやJsのようなファイルに対しては抵抗がある人も居ると思います。レイアウトが大きく狂ったり、スクリプトエラーが発生することを嫌って、全くキャッシュを効かないようにしているサイトもあるでしょう。
しかし、そういった場合でもfingerprintアルゴリズムなどを使って、ファイル名が変わるような対処をすべきとしています。
また、そのようにキャッシュを増やすとブラウザ側を汚してしまう懸念もありますが、通常は使われていないキャッシュは削除されていく仕組みがあるので、問題にはならないはずということです。
fingerprintingを使った動的キャッシュ
ファイルが変更されるまで変わらないURLを用意してやれば、キャッシュ期間を大きくとってしまうことができます。
サーバ側でファイルが変更された場合にURLを変更（当然、呼び出す側のHTMLのscriptやlinkタグも変える）すれば、自動的にブラウザは新しいファイルを要求してきます。
この仕組みをどのように管理サイトに組み込むかは、各サイトの作り方によって工夫が必要です。
多少は運用が難しくなりますが、これを実装すればETagなどによる毎回の確認も不要になるので、トライする価値は大きなものがあります。
VaryヘッダをInternet Explorer対応
Proxyサーバでのキャッシュを制御するためのVaryヘッダがありますが、IEでは問題があり、Accept-EncodingとUser-Agent以外のヘッダを指定するとブラウザで一切のキャッシュが行われなくなります。
Varyヘッダから他のフィールドを全て除去するか、Varyヘッダそのものを外してしまう必要があります。
Firefoxでのキャッシュ衝突に注意
Firefoxのキャッシュファイル生成ロジックでは、パスの前後4文字ずつの計8文字しか使われません。そのため、比較的容易にハッシュ値が衝突してしまう可能性があります。前述のfingerprintingやアプリケーションでURLをジェネレートするような場合、この8文字ラインが異なるようにする必要があります。
複数サーバでのETag作成方法
ETagを用いる場合に、複数のWebサーバをロードバランシングしている環境では注意が必要です。多くのWebサーバではデフォルトの設定でETagの生成にi-nodeを用いるために、各サーバで同一ファイルに異なったETagをジェネレートします。結果、ラウンドロビンで割り振るとETagが全く役に立たない（転送量と確認が増える分だけ、むしろボトルネックになる）ようなことになります。そういった環境ではNASなどを用いてソースファイルを共有しているのでない限り、ETagの生成にはinodeではなくmtimeなどを利用するように設定すべきです。

これらの設定をApacheなどで行うドキュメントは山ほどあると思いますので、必要なら探してみてください。
このサイトではlighttpdを用いているので、せっかくですからlightyでのExpire設定方法を別途簡単に説明しておきます。