ブラウザにやさしいHTML/CSS

59,828 views

Published on

Published in: Engineering
0 Comments
313 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
59,828
On SlideShare
0
From Embeds
0
Number of Embeds
19,607
Actions
Shares
0
Downloads
258
Comments
0
Likes
313
Embeds 0
No embeds

No notes for slide

ブラウザにやさしいHTML/CSS

  1. 1. HTML/CSS 〜 「お・も・て・な・し」をブラウザにも 〜 TAKEHARU IGARI Front-end Engineer / Evangelist ブラウザにやさしい <html5j パフォーマンス部 第⼀回勉強会 />
  2. 2. プロフィール • TAKEHARU IGARI 猪狩 丈治 - 所属 • 株式会社 Lei Hauʼoli フロントエンドエンジニア - 略歴 • 表⽰速度、保守性、ブランディング、SEOを考慮したフロントエンドエンジニアリングを得意とし、
 現在、各ナショナルクライアントのプロジェクトや、株式会社リクルートの主要サービスのフロント エンド開発に携わり、⾼速化コンサルティングも⾏う。 - 執筆 • 技術評論社「WEB+DB PRESS」 • Vol.66 〜我流コードからの卒業HTML構造化指南 • Vol.59 〜「Webサイト超⾼速化実況中継
       ── スピードの鍵はフロントエンド!」
  3. 3. やさしすぎるCSSバリデータ
 つくりました 従来のCSSバリデータで検証できない範囲 を検証するバリデータ
 (バリデートルールも⾃分好みに作成可) •⽂法ではなくCSSの使い⽅が正しいか •JS実⾏後も問題ないか •メディアクエリのブレークポイント変 更後にも問題ないか 
 ※2015年11⽉W3C TPACにて発表 現状Chromeのみ対応、⽀援があればもっと頑張ります・・w
 例) table > table-cellやflex parent > flex childなどの親⼦関 係、 trタグにmarginなど無効な間違ったスタイル指定のチェック
  4. 4. アジェンダ • はじめに • ブラウザにやさしいHTML/CSSとは? • Webページが表⽰されるまでを知ろう • ブラウザとユーザーの気持ちをしろう • デモでわかるブラウザにやさしいHTML/CSS • イマドキのHTML/CSS⾼速化って?
  5. 5. はじめに
  6. 6. はじめに • 対象のブラウザは、IE/Chrome/Firefox/SafariでOperaは あまり知りません。ごめんなさい。 • ぶっちゃけ、これ⾒ればブラウザ仕組みを理解することがで きます。
 http://www.html5rocks.com/ja/tutorials/internals/ howbrowserswork/ • でも、ちょっと難しいのと⾼速化に繋がる話ばかりではない ので、今回は⾼速化に特化し、より分かり易く紹介します。 • あと、デモを紹介して、体感してもらうことを⽬指します。
  7. 7. ブラウザにやさしい HTML/CSSとは?
  8. 8. ⾼速化の3原則
  9. 9. Web⾼速化の3原則 • 少なくする(数) • 軽くする(量) • 近くする(距離)
  10. 10. もはや基本的なテクニック達 縮⼩化CSSスプライト&ファイル結合 画像圧縮 テキスト圧縮 キャッシュ利⽤
  11. 11. これだけでも素敵ですが、 もっと詳しい理解を得て、 応⽤⼒をつけましょう
  12. 12. - ウェブ開発者は、ブラウザの内部動作 を学ぶことで、より適切な判断ができ るようになり、開発のベスト プラク ティスの根拠を理解することができま Paul Irish
  13. 13. Webページが表⽰されるま でを知ろう
  14. 14. まずはリクエストして
 ダウンロード
  15. 15. HTTPリクエスト① 最初にHTMLのみ をリクエストする www.leihauoli.comのHTMLくれーーーー! PC サーバ
  16. 16. DNS解決① ドメインのIPアドレスを調べ る キャッシュされていたり実際 は、もっと簡潔な場合が多い が、クライアント端末とサー バーの間で、これだけのやり とりがある
  17. 17. TCP接続 IPがわかったら、ついに
 標的のサーバーに接続を⾏う
  18. 18. HTTPリクエスト② HTMLのダウンロード後、
 ブラウザでパースを⾏う パースされた結果に基づ き、各リソース(CSS/JS/ 画像など)のHTTPリクエ ストをする src / hrefなどのリソースをリクエスト
  19. 19. も 原則、
 上から順にリクエスト ① ② ③ ④ ⑤
  20. 20. もちろん、HTML以外のリ ソースのURLも別ドメイン の場合はDNS解決している ドメイン毎にDNS解決され ることになる DNS解決② ①と同じ
  21. 21. TCP接続② 全てのリソース読み込み時 に、⾏われる このTCP接続〜リクエスト〜レ スポンスまでの過程に
 意外と時間がかかる。
 
 だから、リクエスト数を減ら すことが有効であるというこ と。
  22. 22. html css js png png png png png png ダウンロードは並列で
 6本づつ逐次的に⾏われる time 0.5s 1s 9ファイルの場合
  23. 23. ダウンロードは並列で
 6本づつ逐次的に⾏われる 19ファイルの場合のイメージ time 1s 1s
  24. 24. 1ホスト当たりの
 各ブラウザの同時接続数 IE6 IE7 IE8+ Firefox Chrome Safari 2 2 6 6 6 6 スマフォも6。⼀部古い機種で4。
  25. 25. html css js png png png png png png IE6~7の場合は、 同時接続数が2本なので遅い time 0.5s 1s
  26. 26. パースしてレンダリングす る
  27. 27. レンダリングプロセス •本当はもっと細かいですが、説明のため簡略 化した図です
  28. 28. パース •DOM Treeがまずつくられ、Style情報を関連 付けて、Render Treeがつくり終えて、描画。 <!DOCTYPE html> <html> <head> <title>Web p…</title> </head> <body> <div> <h1>Web p…</h1> <p>This…</p> </div> </body> </html> DOM Tree Render Tree
  29. 29. DOM Tree •HTMLタグの階層構造 •CSSやJSでセレクトす る時に利⽤する機構
  30. 30. Render Tree •Style情報と関連付けられた、実際にレン ダリングする時の構造 •display: none;すると、Render Treeに含 まれない •visibility: hidden;は含まれる •absolute / fixedの場合、別コンテキスト になる •イベントで何かがDOM構造が変わるとレ イアウト / リペイント •⼀部のCSSプロパティに変更があると、 レイアウト / リペイント、もしくはリペ イントのみ
  31. 31. Render Layer • relative, absolute, fixed, transformを使うと、レイヤーが⽣ま れる。消費コストは⾼いが、⾮同期処理に。 • 特にabsolute/fixedは、他要素との相対座標計算が省かれ⾼速 • transformはleft等より⾼速
  32. 32. レイヤーの中でも Graphic Layerに注⽬ •いわゆるハードウェアアクセラレーション •GPUに処理を任せて、レンダリングを⾼速化できる •元々は3Dをレンダリングする⽤だが、応⽤としてアニメーション を⾼速化させることも出来る •DevTools の設定(⼩さな⻭⾞のアイコン) から “rendering” 配下 の “show composited layer borders” フラグを有効にすると、 視覚的に確認出来るようになる •あるCSSプロパティが指定されると有効に
  33. 33. Graphics Layer が
 作成される条件 •3D or perspective transform CSS properties •3D or perspective transform CSS properties •<video> elements using accelerated video decoding •HWデコーダを使⽤した<video> 要素 •<canvas> elements with a 3D (WebGL) context or accelerated 2D context •3D (WebGL) コンテキスト、もしくはHWアクセ ラレーションを有効にした状態での2Dコンテキス トを使⽤した<canvas> 要素 •Composited plugins (i.e. Flash) •Compositorを利⽤するプラグイン(例:Flash) •Elements with CSS animation for their opacity or using an animated webkit transform •透過⾊もしくはwebkit-transformを使⽤したCSS アニメーション •Elements with accelerated CSS filters •CSS Filterを使⽤した要素 •Element has a descendant that has a compositing layer (in other words if the element has a child element thatʼs in its own layer) •Element has a sibling with a lower z-index which has a compositing layer (in other words the itʼs rendered on top of a composited layer)
  34. 34. DevToolsで確認できる • オレンジのボーダーの部分
  35. 35. CSSセレクタマッチング •プログレッシブ(逐次的)に⾏われる、レン ダーツリーをつくりあげていく
  36. 36. CSSセレクタマッチング •右辺から評価していく •↓ <li>をDOMツリー全体から探す •↓ それぞれのliを基点にDOMツリーを遡る •↓ <div>が⾒つからなければ、異なるパスを遡る •↓ ⾒つかるまでループする •↓ ⾒つかり次第、⼦孫の<li> 全てにwidth: 100px;をアプライする •↓ <li>の数だけ上記を⾏う div li {width: 100px; }
  37. 37. JavaScriptの実⾏ •同期的に実⾏ ※WebWorkersを除く •パーサーが <script> タグに達するとすぐにスクリ プトが解析、実⾏ •<body>タグの中でかつ、外部スクリプトを読み込 む場合は、リソースを取得するまでレンダリングは 中断される - 最近はブラウザは投機的解析を⾏い、解析だけ先にして おき、レンダリング時の負荷を下げる仕組みも
  38. 38. ブラウザとユーザーの気持 ちを知ろう
  39. 39. ブラウザの気持ち •⾒た⽬から表⽰したい
 •時間がかかること⼤変なことは、出来るだけ避けたい
 •いろんなこと⼀⽚にしたくない
 •他のブラウザいなくなれ
  40. 40. ブラウザの気持ち •⾒た⽬から表⽰したい
 →順序の最適化 •時間がかかること⼤変なことは、出来るだけ避けたい
 →リクエスト、サイズ、消費メモリの最⼩化 •いろんなこと⼀⽚にしたくない
 →処理の分散化 •他のブラウザいなくなれ
  41. 41. ユーザーの気持ち •速く⾒たい
 •まちたくない
 •スムーズであってほしい
 
 

  42. 42. ユーザーの気持ち •速く⾒たい
 →順序の最適化 •まちたくない
 →リクエスト、サイズ、消費メモリの最⼩化 •スムーズであってほしい
 →処理の分散化
 

  43. 43. デモで分かる ブラウザにやさしい HTML/CSS
  44. 44. DEMO⼀覧 http://goo.gl/zA4ZvQ ID: tech PASS: tech-lab
  45. 45. DNSプリフェッチ
  46. 46. DNSのプリフェッチ • DNSルックアップ回数を減らすのもあるが、⼤抵の場合現実的ではな い ※広告など • 先読みして、パフォーマンスを向上させるのが、DNSプリフェッチ  ※Amazonでも利⽤ デモでは上手く差をつくれませんでした。@tokkonoさんのブログが良くまとまってます http://tokkono.cute.coocan.jp/blog/slow/index.php/programming/boostup-socials-
  47. 47. DNSプリフェッチ
 記述⽅法 <meta http-equiv="x-dns-prefetch-control" content="on"> <link rel="dns-prefetch" href="// www.spreadfirefox.com"> オンにする記述 ※デフォルトでONの場合もありますが、明⽰的に書くほうが良いと考えています 指定したドメインのプリフェッチを強制する
  48. 48. 画像サイズ
 ⼤きすぎ、
 個数多すぎ
  49. 49. リクエストが多すぎると遅い •CSSスプライトなし、ありで、圧倒的な体感 スピードの差がある
  50. 50. リソースの
 読み込み順 間違い
  51. 51. リソースの読み込み順間違い •NGパターン
  52. 52. リソースの読み込み順間違い •OKパターン
  53. 53. レンダリング
 ブロッキング
  54. 54. JSによるブロッキング •特に外部スクリプトは、レンダリングをブ ロックする •なので、原則</body>直前に配置すべき
 ※これが無理な場合は、defer属性を指定した ら良さそうだが、全てのブラウザで実⾏順序 が保証されていないため、注意が必要=オス スメできない
  55. 55. CSSエフェクト過多
  56. 56. CSSエフェクト過多 •CSS3でエフェクトが多彩になったことで、画 像を使わずに、より多くのデザイン表現が可 能に •ただし、プロパティによっては、使いすぎる と重くなりすぎる opacity / gradient / box- shadow / text-shadow。
  57. 57. アニメーションがカクカク
  58. 58. 特にモバイル •原則JSアニメーションより、CSSアニメー ションが⾼速 •なので、CSSアニメーション使おう •ただ!モバイルでは、使いこなすにはコツが 必要。
  59. 59. モバイルでもなめらかなアニ メーションにするために •absolute / fixedにする •アニメーション中だけ、translate3d(0, 0, 0) などでハードウェアアクセラレーションを有 効にする
 ※そうじゃないと、特にiPhone/Androidで副 作⽤がありバグを⽣む。(Layerをつくりだす コストが起因か)
  60. 60. イマドキのHTML/CSS ⾼速化って?
  61. 61. イマドキの
 HTML/CSS⾼速化 • CSSスプライトはしない? • CSSセレクタのパフォーマンスは気にしない? • SVGってつかえるの? • Webフォントって使えるの? • パフォーマンス<メンテナンス • PCのみ、モバイルのみ、レスポンシブで考えるこ とって?
  62. 62. CSSスプライトはしない?
  63. 63. CSSスプライト⽐較① スプライト無し スプライト1枚 42K スプライト2枚 21KB 2 num : 40個 / size : 42K 計測ツール:WebPageTest Video Comparisonモード 計測地点:Dulles, VA - Cable
  64. 64. CSSスプライト⽐較② num : 120個 / size : 140K スプライト無し 70kb 2 140kb 1 約23kb 6 計測ツール:WebPageTest Video Comparisonモード 計測地点:Dulles, VA - Cable
  65. 65. まとめすぎず、
 分割しすぎずが⼤事 • 数字が全てではない • ネットワークを考慮して、適切なサイズ にすることが⼤切 • 体感速度が重要 • 同時接続数と、プログレッシブレンダリ ングを活かす
  66. 66. 本当はもっと、ちゃんと計測 するべき • 瞬間的な計測では、パフォーマンスの品質 は計れない。 • Keynoteなどの計測ツールを利⽤して継続 的に計測することが⼤切。 • 実はKeynoteで計測してみたので、これに ついては後ほどブログ記事などで公開予 定。
  67. 67. CSSセレクタのパフォーマ ンスは気にしない?
  68. 68. 気にしないわけではないが、 必要以上に⼼配しない • 最近のブラウザのCSSエンジンがかなり⾼速 • ただ無駄に遅くする理由はないので、全称セレクタや⼦孫や⼦供 セレクタは極⼒避ける • メンテナンス性や耐久度のあるHTML/CSS構造をつくるためであ れば可。
 • *などパフォーマンスが⾼いとも思われるものでも、体感速度で 差を感じるほどの影響度はないため、他でメリットがあるのであ れば使おう! 
 .heading + * { margin-top: 10px; } *, *:before, *:after { box-sizing: border-box; }とか
  69. 69. SVGって使えるの?
  70. 70. ⾼解像度対応には必須 • モバイルで倍化した画像は、パフォーマンス劣化の 元に。 • 解像度は4Kなど進化がとまらない。スケーラブル なベクターが最適。 • フォールバックとして⾮対応ブラウザにはPNG • 対象ブラウザでの視覚的なテストは重要。SVGの形 式、書き出し⽅によって、表⽰が乱れる場合も。
  71. 71. WebFontって使えるの?
  72. 72. シンプルなものであれば、
 イケるかも • 旧IEでジャギるケースもあり。 • Androidで表⽰されないケースもあり。 • 元のベクター次第で、問題が起きる可能性がある • シンプルなものであれば使って良いが、対象ブラウザでの視 覚的なテストは必須 • 上⼿くいけば、パフォーマンスとメンテナンス向上を得られ る。※ただ、画像と違ってプログレッシブレンダリングでは ないため、体感速度においては画像より劣る可能性もあるた め注意する。
  73. 73. パフォーマンス<メンテナンス
  74. 74. メンテナンスは犠牲にしない • メンテナンス性が失われれば、将来パフォー マンスが失われる可能性も⽣む • 極めて、複雑でやることの多いフロントエン ドにおいて、メンテナンスが失われるのは致 命的である
  75. 75. PCのみ、モバイルのみ、レスポ ンシブで考えることって?
  76. 76. 注意すべきこと • PCとMBでネットワーク事情が全く違うことを理解す べき。3Gかつ混戦時、障害物影響まで考える。Ajax もUX向上の銀の弾丸ではない。 • レスポンシブである以上、モバイルファーストになら ざるを得ない。 • MBとレスポンシブは、ファイルサイズ上限に注意 • MBとレスポンシブは、低スペックなマシンに対す る、処理の重さにも注意。
  77. 77. おまけ
  78. 78. Navigation Timing API •ブラウザに実装されたパフォーマンス計測⽤ のAPI ※KeynoteやGAにも利⽤されている •操作可能になるまでの時間や、動いているも のに対して、リアルタイムに計測できるのが 素敵
  79. 79. Service Worker •App Cacheのようなキャッシュの仕組み •様々な問題点のあったApp Cacheの代替案と して提案されている •これで、Nativeアプリにパフォーマンスで戦 えることを期待されている。要チェックや!
  80. 80. まとめ •Web⾼速化においてボトルネックは、1つでもあって はならない •そのためにも、ブラウザの処理プロセスを知ることが ⼤事 •CSSスプライト / ファイル結合では、サイズに注意す る。(MBなら30kb、PCなら300kbなどを上限にす るなど) •モバイルのアニメーションはコツをつかんで滑らかに
  81. 81. ご清聴ありがとうございました
  82. 82. 参考⽂献 • http://www.html5rocks.com/ja/tutorials/internals/ howbrowserswork/ • http://taligarsiel.com/Projects/howbrowserswork1.htm • http://www.html5rocks.com/ja/tutorials/speed/layers/ • http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/ • https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ NavigationTiming/Overview.html • http://www.html5rocks.com/en/tutorials/webperformance/basics/ • https://developer.mozilla.org/ja/docs/Controlling_DNS_prefetching

×