Your SlideShare is downloading. ×
0
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
ブラウザにやさしいHTML/CSS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

39,886

Published on

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

No Downloads
Views
Total Views
39,886
On Slideshare
0
From Embeds
0
Number of Embeds
34
Actions
Shares
0
Downloads
229
Comments
0
Likes
289
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. HTML/CSS   〜~  「お・も・て・な・し」をブラウザにも  〜~ TAKEHARU  IGARI Front-‐‑‒end  Engineer  /  Evangelist ブラウザにやさしい <html5j パフォーマンス部 第一回勉強会 />
  • 2. プロフィール • TAKEHARU  IGARI  猪狩  丈治   -‐‑‒ 所属   • 株式会社  Lei  Hauʼ’oli  フロントエンドエンジニア   -‐‑‒ 略略歴   • 表⽰示速度度、保守性、ブランディング、SEOを考慮したフロントエンドエンジニアリングを得意とし、
 現在、各ナショナルクライアントのプロジェクトや、株式会社リクルートの主要サービスのフロント エンド開発に携わり、⾼高速化コンサルティングも⾏行行う。   -‐‑‒ 執筆   • 技術評論論社「WEB+DB  PRESS」   • Vol.66  〜~我流流コードからの卒業HTML構造化指南   • Vol.59  〜~「Webサイト超⾼高速化実況中継
             ──  スピードの鍵はフロントエンド!」
  • 3. Lei Hau'oli co.,ltd. • 株式会社レイハウオリは2008年年創業のWeb制作 会社です。   • おかげさまで先⽇日、第7期⽬目を迎えることが出来 ました。   • 特にフロントエンドにおけるWPOを得意として います。   • ⼀一部では“レイさん”と呼ばれることが多いです。
  • 4. アジェンダ • はじめに   • ブラウザにやさしいHTML/CSSとは?   • Webページが表⽰示されるまでを知ろう   • ブラウザとユーザーの気持ちをしろう   • デモでわかるブラウザにやさしいHTML/CSS   • イマドキのHTML/CSS⾼高速化って?
  • 5. はじめに
  • 6. はじめに • 対象のブラウザは、IE/Chrome/Firefox/SafariでOperaは あまり知りません。ごめんなさい。   • ぶっちゃけ、これ⾒見見ればブラウザ仕組みを理理解することがで きます。
 http://www.html5rocks.com/ja/tutorials/internals/ howbrowserswork/   • でも、ちょっと難しいのと⾼高速化に繋がる話ばかりではない ので、今回は⾼高速化に特化し、より分かり易易く紹介します。   • あと、デモを紹介して、体感してもらうことを⽬目指します。
  • 7. ブラウザにやさしい   HTML/CSSとは?
  • 8. 高速化の3原則
  • 9. Web高速化の3原則 • 少なくする(数)   • 軽くする(量量)   • 近くする(距離離)
  • 10. もはや基本的なテクニック達 縮小化CSSスプライト&ファイル結合 画像圧縮 テキスト圧縮 キャッシュ利用
  • 11. これだけでも素敵ですが、 もっと詳しい理解を得て、 応用力をつけましょう
  • 12. - ウェブ開発者は、ブラウザの内部動作 を学ぶことで、より適切な判断ができ るようになり、開発のベスト プラクティ スの根拠を理解することができます。 Paul Irish
  • 13. Webページが表示されるま でを知ろう
  • 14. まずはリクエストして
 ダウンロード
  • 15. HTTPリクエスト① 最初にHTMLのみ をリクエストする www.leihauoli.comのHTMLくれーーーー! PC サーバ
  • 16. DNS解決① ドメインのIPアドレスを調べ る キャッシュされていたり実際 は、もっと簡潔な場合が多い が、クライアント端末とサー バーの間で、これだけのやり とりがある
  • 17. TCP接続 IPがわかったら、ついに
 標的のサーバーに接続を行う
  • 18. HTTPリクエスト② HTMLのダウンロード後、
 ブラウザでパースを行う パースされた結果に基づき、 各リソース(CSS/JS/画像 など)のHTTPリクエスト をする src / hrefなどのリソースをリクエスト
  • 19. も 原則、
 上から順にリクエスト ① ② ③ ④ ⑤
  • 20. もちろん、HTML以外のリ ソースのURLも別ドメイン の場合はDNS解決している ドメイン毎にDNS解決され ることになる DNS解決② ①と同じ
  • 21. TCP接続② 全てのリソース読み込み時に、 行われる このTCP接続∼リクエスト∼ レスポンスまでの過程に
 意外と時間がかかる。
 
 だから、リクエスト数を減ら すことが有効であるというこ と。
  • 22. html css js png png png png png png ダウンロードは並列で
 6本づつ逐次的に行われる time 0.5s 1s 9ファイルの場合
  • 23. ダウンロードは並列で
 6本づつ逐次的に行われる 19ファイルの場合のイメージ time 1s 1s
  • 24. 1ホスト当たりの
 各ブラウザの同時接続数 IE6 IE7 IE8+ Firefox Chrome Safari 2 2 6 6 6 6 スマフォも6。一部古い機種で4。
  • 25. html css js png png png png png png IE6 7の場合は、 同時接続数が2本なので遅い time 0.5s 1s
  • 26. パースしてレンダリングする
  • 27. レンダリングプロセス •本当はもっと細かいですが、説明のため簡略略 化した図です
  • 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. DOM Tree •HTMLタグの階層構造 •CSSやJSでセレクトす る時に利用する機構
  • 30. Render Tree •Style情報と関連付けられた、実際にレ ンダリングする時の構造 •display: none;すると、Render Treeに 含まれない •visibility: hidden;は含まれる •absolute / fixedの場合、別コンテキス トになる •イベントで何かがDOM構造が変わると レイアウト / リペイント •一部のCSSプロパティに変更があると、 レイアウト / リペイント、もしくはリペ イントのみ
  • 31. Render Layer • relative,  absolute,  fixed,  transformを使うと、レイヤーが⽣生ま れる。消費コストは⾼高いが、⾮非同期処理理に。   • 特にabsolute/fixedは、他要素との相対座標計算が省省かれ⾼高速   • transformはleft等より⾼高速
  • 32. レイヤーの中でも Graphic Layerに注目 ! •いわゆるハードウェアアクセラレーション   •GPUに処理理を任せて、レンダリングを⾼高速化できる   •元々は3Dをレンダリングする⽤用だが、応⽤用としてアニメーション を⾼高速化させることも出来る   •DevTools  の設定(⼩小さな⻭歯⾞車車のアイコン)  から  “rendering”  配下 の  “show  composited  layer  borders”  フラグを有効にすると、 視覚的に確認出来るようになる   •あるCSSプロパティが指定されると有効に
  • 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. DevToolsで確認できる • オレンジのボーダーの部分
  • 35. CSSセレクタマッチング •プログレッシブ(逐次的)に⾏行行われる、レン ダーツリーをつくりあげていく
  • 36. CSSセレクタマッチング ! ! ! •右辺から評価していく   •↓  <li>をDOMツリー全体から探す   •↓  それぞれのliを基点にDOMツリーを遡る   •↓  <div>が⾒見見つからなければ、異異なるパスを遡る   •↓  ⾒見見つかるまでループする   •↓  ⾒見見つかり次第、⼦子孫の<li>  全てにwidth:  100px;をアプライする   •↓  <li>の数だけ上記を⾏行行う div  li  {width:  100px;  }
  • 37. JavaScriptの実行 •同期的に実⾏行行  ※WebWorkersを除く   •パーサーが  <script>  タグに達するとすぐにスクリ プトが解析、実⾏行行   •<body>タグの中でかつ、外部スクリプトを読み込 む場合は、リソースを取得するまでレンダリングは 中断される   -‐‑‒ 最近はブラウザは投機的解析を⾏行行い、解析だけ先にして おき、レンダリング時の負荷を下げる仕組みも
  • 38. ブラウザとユーザーの気持 ちを知ろう
  • 39. ブラウザの気持ち •⾒見見た⽬目から表⽰示したい
 •時間がかかること⼤大変なことは、出来るだけ避けたい
 •いろんなこと⼀一⽚片にしたくない
 ! •他のブラウザいなくなれ
  • 40. ブラウザの気持ち •⾒見見た⽬目から表⽰示したい
 →順序の最適化   •時間がかかること⼤大変なことは、出来るだけ避けたい
 →リクエスト、サイズ、消費メモリの最⼩小化   •いろんなこと⼀一⽚片にしたくない
 →処理理の分散化   ! •他のブラウザいなくなれ
  • 41. ユーザーの気持ち •速く⾒見見たい
 •まちたくない
 •スムーズであってほしい
 
 

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

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

×