読み書きプログラミング

日常のプログラミングで気づいたことを綴っています

JavaScriptパフォーマンスベストプラクティスその9

Nokia Developerより

スタイル

CSSを最適化すること
  • 部品ライブラリを作ること
  • 一貫した意味論的スタイルを使うこと
  • 内部で透明性を持つようにモジュールを設計すること
  • 柔軟に
  • グリッドが好きになるように学ぶこと
  • セレクタを最小化すること
  • 構造とスキンを分離すること
  • コンテナと中身を分離すること
  • 要素に複数のクラスを適用することでオブジェクトを拡張すること
  • YUIからリセットとフォントを使用すること

ソース: Object Oriented CSS

  • Create a component library
  • Use consistent semantic styles
  • Design modules to be transparent on the inside
  • Be flexible
  • Learn to love grids
  • Minimize selectors
  • Separate structure and skin
  • Separate container and content
  • Extend objects by applying multiple classes to an element
  • Use reset and fonts from YUI
  • Source: Object Oriented CSS
DOMツリーの端近くでCSSクラスを変更すること

リフローのスコープを可能な限り少しのノードに限定するために、多くの子ノードの表示に影響するラッパ(やbody)要素のクラスを変更することを避けるべきだ。加えて、これはドキュメント全体に渡るスタイルの再解決を引き起こすかもしれない。大きなDOMではこれはブラウザをしばらく硬直させる。

To limit the scope of the reflow to as few nodes as possible you should avoid changing a class on wrapper (or body) element(s) which affects the display of many child nodes. Additionally, that may result in re-resolving style on the entire document and for a large DOM that could lock up the browser for a while.

ソース:
Dave Hyatt on CSS Selectors

レイアウトのためのテーブルを避けるかtable-layout: fixedを使うこと

レイアウトのためのテーブルを避けること。それらを避ける別の理由が必要なら、それらは要素がDOM上のそれらの前に来た別の要素の表示に影響するまれなケースの1つだからテーブルはレイアウトが完全に確立する前にしばしば複数のパスを必要とする。テーブルの終わりにあるとても広い中身を持つセルを想像して。それは列を完全にリサイズさせる。すべてのブラウザで、これがテーブルは逐次的にレンダリングされない理由であり、それらがレイアウトのためには悪いアイデアである別の理由だ。

Avoid tables for layout. As if you needed another reason to avoid them, tables often require multiple passes before the layout is completely established because they are one of the rare cases where elements can affect the display of other elements that came before them on the DOM. Imagine a cell at the end of the table with very wide content that causes the column to be completely resized. This is why tables are not rendered progressively in all browsers and yet another reason why they are a bad idea for layout.

データテーブルがより効率的なレイアウトアルゴリズムを許すように、fixedレイアウト (table-layout: fixed)を使うことを推奨する。
これで、テーブルは CSS 2.1仕様に従って行毎にレンダリングできる。

It is recommended to use a fixed layout ( table-layout: fixed) for data tables to allow a more efficient layout algorithm. This will allow the table to render row by row according to the CSS 2.1 specification.

ソース:

画像を最適化すること
  • 似た色を組み合わせること
  • スプライトでの空白を避けて、代わりにCSSを使うこと
  • 水平は垂直よりよい
  • 色の数を制限すること
  • 最初に個々の画像を最適化して次にその中のスプライトを最適化すること
  • サイズや整列を通じてアンチエーリアスピクセルを減らすこと
  • 画像サイズが増えるので対角グラディエントを避けること
  • アルファ透過を避けること(IEがサポートしていない)
  • グラティエントの色を2-3ピクセル毎に変えること
  • Combine similar colors
  • Avoid whitespace in sprites, use CSS instead
  • Horizontal is better than vertical
  • Limit the number of colors
  • First optimize individual images, next sprites in it
  • Reduce anti-aliased pixels via size and alignment
  • Avoid diagonal gradients due to increased image size
  • Avoid alpha transparency (IE does not support)
  • Change gradient color every 2-3 pixels

ソース: