Download as PDF, PPTX
ブラウザにやさしいHTML/CSS
- 1. HTML/CSS 〜 「お・も・て・な・し」をブラウザにも 〜 TAKEHARUIGARI Front-end Engineer / Evangelist ブラウザにやさしい <html5j パフォーマンス部 第⼀回勉強会 />
- 2. プロフィール • TAKEHARU IGARI猪狩 丈治 - 所属 • 株式会社 Lei Hauʼoli フロントエンドエンジニア - 略歴 • 表⽰速度、保守性、ブランディング、SEOを考慮したフロントエンドエンジニアリングを得意とし、 現在、各ナショナルクライアントのプロジェクトや、株式会社リクルートの主要サービスのフロント エンド開発に携わり、⾼速化コンサルティングも⾏う。 - 執筆 • 技術評論社「WEB+DB PRESS」 • Vol.66 〜我流コードからの卒業HTML構造化指南 • Vol.59 〜「Webサイト超⾼速化実況中継 ── スピードの鍵はフロントエンド！」
- 3. やさしすぎるCSSバリデータ つくりました 従来のCSSバリデータで検証できない範囲 を検証するバリデータ （バリデートルールも⾃分好みに作成可） •⽂法ではなくCSSの使い⽅が正しいか •JS実⾏後も問題ないか •メディアクエリのブレークポイント変 更後にも問題ないか ※2015年11⽉W3C TPACにて発表 現状Chromeのみ対応、⽀援があればもっと頑張ります・・ｗ 例） table >table-cellやflex parent > flex childなどの親⼦関 係、 trタグにmarginなど無効な間違ったスタイル指定のチェック
- 4. アジェンダ • はじめに • ブラウザにやさしいHTML/CSSとは？ •Webページが表⽰されるまでを知ろう • ブラウザとユーザーの気持ちをしろう • デモでわかるブラウザにやさしいHTML/CSS • イマドキのHTML/CSS⾼速化って？
- 5.
- 6. はじめに • 対象のブラウザは、IE/Chrome/Firefox/SafariでOperaは あまり知りません。ごめんなさい。 • ぶっちゃけ、これ⾒ればブラウザ仕組みを理解することがで きます。 http://www.html5rocks.com/ja/tutorials/internals/ howbrowserswork/ •でも、ちょっと難しいのと⾼速化に繋がる話ばかりではない ので、今回は⾼速化に特化し、より分かり易く紹介します。 • あと、デモを紹介して、体感してもらうことを⽬指します。
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. 1ホスト当たりの 各ブラウザの同時接続数 IE6 IE7 IE8+Firefox Chrome Safari 2 2 6 6 6 6 スマフォも６。⼀部古い機種で4。
- 25.
- 26.
- 27.
- 28. パース •DOM Treeがまずつくられ、Style情報を関連 付けて、Render Treeがつくり終えて、描画。 <!DOCTYPEhtml> <html> <head> <title>Web p…</title> </head> <body> <div> <h1>Web p…</h1> <p>This…</p> </div> </body> </html> DOM Tree Render Tree
- 29.
- 30. Render Tree •Style情報と関連付けられた、実際にレン ダリングする時の構造 •display: none;すると、RenderTreeに含 まれない •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 が 作成される条件 •3Dor 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.
- 35.
- 36.
- 37. JavaScriptの実⾏ •同期的に実⾏ ※WebWorkersを除く •パーサーが <script> タグに達するとすぐにスクリ プトが解析、実⾏ •<body>タグの中でかつ、外部スクリプトを読み込 む場合は、リソースを取得するまでレンダリングは 中断される -最近はブラウザは投機的解析を⾏い、解析だけ先にして おき、レンダリング時の負荷を下げる仕組みも
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47. DNSプリフェッチ 記述⽅法 <meta http-equiv="x-dns-prefetch-control" content="on"> <link rel="dns-prefetch"href="// www.spreadfirefox.com"> オンにする記述 ※デフォルトでONの場合もありますが、明⽰的に書くほうが良いと考えています 指定したドメインのプリフェッチを強制する
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. CSSエフェクト過多 •CSS3でエフェクトが多彩になったことで、画 像を使わずに、より多くのデザイン表現が可 能に •ただし、プロパティによっては、使いすぎる と重くなりすぎる opacity /gradient / box- shadow / text-shadow。
- 57.
- 58.
- 59. モバイルでもなめらかなアニ メーションにするために •absolute / fixedにする •アニメーション中だけ、translate3d(0,0, 0) などでハードウェアアクセラレーションを有 効にする ※そうじゃないと、特にiPhone/Androidで副 作⽤がありバグを⽣む。（Layerをつくりだす コストが起因か）
- 60.
- 61. イマドキの HTML/CSS⾼速化 • CSSスプライトはしない？ • CSSセレクタのパフォーマンスは気にしない？ •SVGってつかえるの？ • Webフォントって使えるの？ • パフォーマンス＜メンテナンス • PCのみ、モバイルのみ、レスポンシブで考えるこ とって？
- 62.
- 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.
- 68. 気にしないわけではないが、 必要以上に⼼配しない • 最近のブラウザのCSSエンジンがかなり⾼速 • ただ無駄に遅くする理由はないので、全称セレクタや⼦孫や⼦供 セレクタは極⼒避ける •メンテナンス性や耐久度のあるHTML/CSS構造をつくるためであ れば可。 • *などパフォーマンスが⾼いとも思われるものでも、体感速度で 差を感じるほどの影響度はないため、他でメリットがあるのであ れば使おう！ .heading + * { margin-top: 10px; } *, *:before, *:after { box-sizing: border-box; }とか
- 69.
- 70. ⾼解像度対応には必須 • モバイルで倍化した画像は、パフォーマンス劣化の 元に。 • 解像度は4Kなど進化がとまらない。スケーラブル なベクターが最適。 •フォールバックとして⾮対応ブラウザにはPNG • 対象ブラウザでの視覚的なテストは重要。SVGの形 式、書き出し⽅によって、表⽰が乱れる場合も。
- 71.
- 72. シンプルなものであれば、 イケるかも • 旧IEでジャギるケースもあり。 • Androidで表⽰されないケースもあり。 •元のベクター次第で、問題が起きる可能性がある • シンプルなものであれば使って良いが、対象ブラウザでの視 覚的なテストは必須 • 上⼿くいけば、パフォーマンスとメンテナンス向上を得られ る。※ただ、画像と違ってプログレッシブレンダリングでは ないため、体感速度においては画像より劣る可能性もあるた め注意する。
- 73.
- 74.
- 75.
- 76. 注意すべきこと • PCとMBでネットワーク事情が全く違うことを理解す べき。3Gかつ混戦時、障害物影響まで考える。Ajax もUX向上の銀の弾丸ではない。 • レスポンシブである以上、モバイルファーストになら ざるを得ない。 •MBとレスポンシブは、ファイルサイズ上限に注意 • MBとレスポンシブは、低スペックなマシンに対す る、処理の重さにも注意。
- 77.
- 78.
- 79. Service Worker •App Cacheのようなキャッシュの仕組み •様々な問題点のあったAppCacheの代替案と して提案されている •これで、Nativeアプリにパフォーマンスで戦 えることを期待されている。要チェックや！
- 80.
- 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