Advertisement
ブラウザにやさしいHTML/CSS
May. 10, 2014•0 likes•71,209 views
317 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Engineering
Takeharu IgariFollow
Lei Hau'oli Co., Ltd. ー CTO at Lei Hau'oli Co.,Ltd.Advertisement
Advertisement
Advertisement
ブラウザにやさしいHTML/CSS
- HTML/CSS 〜 「お・も・て・な・し」をブラウザにも 〜 TAKEHARU IGARI Front-end Engineer / Evangelist ブラウザにやさしい <html5j パフォーマンス部 第⼀回勉強会 />
- プロフィール • TAKEHARU IGARI 猪狩 丈治 - 所属 • 株式会社 Lei Hauʼoli フロントエンドエンジニア - 略歴 • 表⽰速度、保守性、ブランディング、SEOを考慮したフロントエンドエンジニアリングを得意とし、 現在、各ナショナルクライアントのプロジェクトや、株式会社リクルートの主要サービスのフロント エンド開発に携わり、⾼速化コンサルティングも⾏う。 - 執筆 • 技術評論社「WEB+DB PRESS」 • Vol.66 〜我流コードからの卒業HTML構造化指南 • Vol.59 〜「Webサイト超⾼速化実況中継 ── スピードの鍵はフロントエンド！」
- やさしすぎるCSSバリデータ つくりました 従来のCSSバリデータで検証できない範囲 を検証するバリデータ （バリデートルールも⾃分好みに作成可） •⽂法ではなくCSSの使い⽅が正しいか •JS実⾏後も問題ないか •メディアクエリのブレークポイント変 更後にも問題ないか ※2015年11⽉W3C TPACにて発表 現状Chromeのみ対応、⽀援があればもっと頑張ります・・ｗ 例） table > table-cellやflex parent > flex childなどの親⼦関 係、 trタグにmarginなど無効な間違ったスタイル指定のチェック
- アジェンダ • はじめに • ブラウザにやさしいHTML/CSSとは？ • Webページが表⽰されるまでを知ろう • ブラウザとユーザーの気持ちをしろう • デモでわかるブラウザにやさしいHTML/CSS • イマドキのHTML/CSS⾼速化って？
- はじめに
- はじめに • 対象のブラウザは、IE/Chrome/Firefox/SafariでOperaは あまり知りません。ごめんなさい。 • ぶっちゃけ、これ⾒ればブラウザ仕組みを理解することがで きます。 http://www.html5rocks.com/ja/tutorials/internals/ howbrowserswork/ • でも、ちょっと難しいのと⾼速化に繋がる話ばかりではない ので、今回は⾼速化に特化し、より分かり易く紹介します。 • あと、デモを紹介して、体感してもらうことを⽬指します。
- ブラウザにやさしい HTML/CSSとは？
- ⾼速化の３原則
- Web⾼速化の３原則 • 少なくする（数） • 軽くする（量） • 近くする（距離）
- もはや基本的なテクニック達 縮⼩化CSSスプライト&ファイル結合 画像圧縮 テキスト圧縮 キャッシュ利⽤
- これだけでも素敵ですが、 もっと詳しい理解を得て、 応⽤⼒をつけましょう
- - ウェブ開発者は、ブラウザの内部動作 を学ぶことで、より適切な判断ができ るようになり、開発のベスト プラク ティスの根拠を理解することができま Paul Irish
- Webページが表⽰されるま でを知ろう
- まずはリクエストして ダウンロード
- HTTPリクエスト① 最初にHTMLのみ をリクエストする www.leihauoli.comのHTMLくれーーーー！ PC サーバ
- DNS解決① ドメインのIPアドレスを調べ る キャッシュされていたり実際 は、もっと簡潔な場合が多い が、クライアント端末とサー バーの間で、これだけのやり とりがある
- TCP接続 IPがわかったら、ついに 標的のサーバーに接続を⾏う
- HTTPリクエスト② HTMLのダウンロード後、 ブラウザでパースを⾏う パースされた結果に基づ き、各リソース（CSS/JS/ 画像など）のHTTPリクエ ストをする src / hrefなどのリソースをリクエスト
- も 原則、 上から順にリクエスト ① ② ③ ④ ⑤
- もちろん、HTML以外のリ ソースのURLも別ドメイン の場合はDNS解決している ドメイン毎にDNS解決され ることになる DNS解決② ①と同じ
- TCP接続② 全てのリソース読み込み時 に、⾏われる このTCP接続〜リクエスト〜レ スポンスまでの過程に 意外と時間がかかる。 だから、リクエスト数を減ら すことが有効であるというこ と。
- html css js png png png png png png ダウンロードは並列で 6本づつ逐次的に⾏われる time 0.5s 1s 9ファイルの場合
- ダウンロードは並列で 6本づつ逐次的に⾏われる 19ファイルの場合のイメージ time 1s 1s
- 1ホスト当たりの 各ブラウザの同時接続数 IE6 IE7 IE8+ Firefox Chrome Safari 2 2 6 6 6 6 スマフォも６。⼀部古い機種で4。
- html css js png png png png png png IE6~7の場合は、 同時接続数が2本なので遅い time 0.5s 1s
- パースしてレンダリングす る
- レンダリングプロセス •本当はもっと細かいですが、説明のため簡略 化した図です
- パース •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
- DOM Tree •HTMLタグの階層構造 •CSSやJSでセレクトす る時に利⽤する機構
- Render Tree •Style情報と関連付けられた、実際にレン ダリングする時の構造 •display: none;すると、Render Treeに含 まれない •visibility: hidden;は含まれる •absolute / fixedの場合、別コンテキスト になる •イベントで何かがDOM構造が変わるとレ イアウト / リペイント •⼀部のCSSプロパティに変更があると、 レイアウト / リペイント、もしくはリペ イントのみ
- Render Layer • relative, absolute, fixed, transformを使うと、レイヤーが⽣ま れる。消費コストは⾼いが、⾮同期処理に。 • 特にabsolute/fixedは、他要素との相対座標計算が省かれ⾼速 • transformはleft等より⾼速
- レイヤーの中でも Graphic Layerに注⽬ •いわゆるハードウェアアクセラレーション •GPUに処理を任せて、レンダリングを⾼速化できる •元々は3Dをレンダリングする⽤だが、応⽤としてアニメーション を⾼速化させることも出来る •DevTools の設定(⼩さな⻭⾞のアイコン) から “rendering” 配下 の “show composited layer borders” フラグを有効にすると、 視覚的に確認出来るようになる •あるCSSプロパティが指定されると有効に
- 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)
- DevToolsで確認できる • オレンジのボーダーの部分
- CSSセレクタマッチング •プログレッシブ（逐次的）に⾏われる、レン ダーツリーをつくりあげていく
- CSSセレクタマッチング •右辺から評価していく •↓ <li>をDOMツリー全体から探す •↓ それぞれのliを基点にDOMツリーを遡る •↓ <div>が⾒つからなければ、異なるパスを遡る •↓ ⾒つかるまでループする •↓ ⾒つかり次第、⼦孫の<li> 全てにwidth: 100px;をアプライする •↓ <li>の数だけ上記を⾏う div li {width: 100px; }
- JavaScriptの実⾏ •同期的に実⾏ ※WebWorkersを除く •パーサーが <script> タグに達するとすぐにスクリ プトが解析、実⾏ •<body>タグの中でかつ、外部スクリプトを読み込 む場合は、リソースを取得するまでレンダリングは 中断される - 最近はブラウザは投機的解析を⾏い、解析だけ先にして おき、レンダリング時の負荷を下げる仕組みも
- ブラウザとユーザーの気持 ちを知ろう
- ブラウザの気持ち •⾒た⽬から表⽰したい •時間がかかること⼤変なことは、出来るだけ避けたい •いろんなこと⼀⽚にしたくない •他のブラウザいなくなれ
- ブラウザの気持ち •⾒た⽬から表⽰したい →順序の最適化 •時間がかかること⼤変なことは、出来るだけ避けたい →リクエスト、サイズ、消費メモリの最⼩化 •いろんなこと⼀⽚にしたくない →処理の分散化 •他のブラウザいなくなれ
- ユーザーの気持ち •速く⾒たい •まちたくない •スムーズであってほしい
- ユーザーの気持ち •速く⾒たい →順序の最適化 •まちたくない →リクエスト、サイズ、消費メモリの最⼩化 •スムーズであってほしい →処理の分散化
- デモで分かる ブラウザにやさしい HTML/CSS
- DEMO⼀覧 http://goo.gl/zA4ZvQ ID: tech PASS: tech-lab
- DNSプリフェッチ
- DNSのプリフェッチ • DNSルックアップ回数を減らすのもあるが、⼤抵の場合現実的ではな い ※広告など • 先読みして、パフォーマンスを向上させるのが、DNSプリフェッチ ※Amazonでも利⽤ デモでは上手く差をつくれませんでした。@tokkonoさんのブログが良くまとまってます http://tokkono.cute.coocan.jp/blog/slow/index.php/programming/boostup-socials-
- DNSプリフェッチ 記述⽅法 <meta http-equiv="x-dns-prefetch-control" content="on"> <link rel="dns-prefetch" href="// www.spreadfirefox.com"> オンにする記述 ※デフォルトでONの場合もありますが、明⽰的に書くほうが良いと考えています 指定したドメインのプリフェッチを強制する
- 画像サイズ ⼤きすぎ、 個数多すぎ
- リクエストが多すぎると遅い •CSSスプライトなし、ありで、圧倒的な体感 スピードの差がある
- リソースの 読み込み順 間違い
- リソースの読み込み順間違い •NGパターン
- リソースの読み込み順間違い •OKパターン
- レンダリング ブロッキング
- JSによるブロッキング •特に外部スクリプトは、レンダリングをブ ロックする •なので、原則</body>直前に配置すべき ※これが無理な場合は、defer属性を指定した ら良さそうだが、全てのブラウザで実⾏順序 が保証されていないため、注意が必要＝オス スメできない
- CSSエフェクト過多
- CSSエフェクト過多 •CSS3でエフェクトが多彩になったことで、画 像を使わずに、より多くのデザイン表現が可 能に •ただし、プロパティによっては、使いすぎる と重くなりすぎる opacity / gradient / box- shadow / text-shadow。
- アニメーションがカクカク
- 特にモバイル •原則JSアニメーションより、CSSアニメー ションが⾼速 •なので、CSSアニメーション使おう •ただ！モバイルでは、使いこなすにはコツが 必要。
- モバイルでもなめらかなアニ メーションにするために •absolute / fixedにする •アニメーション中だけ、translate3d(0, 0, 0) などでハードウェアアクセラレーションを有 効にする ※そうじゃないと、特にiPhone/Androidで副 作⽤がありバグを⽣む。（Layerをつくりだす コストが起因か）
- イマドキのHTML/CSS ⾼速化って？
- イマドキの HTML/CSS⾼速化 • CSSスプライトはしない？ • CSSセレクタのパフォーマンスは気にしない？ • SVGってつかえるの？ • Webフォントって使えるの？ • パフォーマンス＜メンテナンス • PCのみ、モバイルのみ、レスポンシブで考えるこ とって？
- CSSスプライトはしない？
- CSSスプライト⽐較① スプライト無し スプライト1枚 42K スプライト2枚 21KB 2 num : 40個 / size : 42K 計測ツール：WebPageTest Video Comparisonモード 計測地点：Dulles, VA - Cable
- CSSスプライト⽐較② num : 120個 / size : 140K スプライト無し 70kb 2 140kb 1 約23kb 6 計測ツール：WebPageTest Video Comparisonモード 計測地点：Dulles, VA - Cable
- まとめすぎず、 分割しすぎずが⼤事 • 数字が全てではない • ネットワークを考慮して、適切なサイズ にすることが⼤切 • 体感速度が重要 • 同時接続数と、プログレッシブレンダリ ングを活かす
- 本当はもっと、ちゃんと計測 するべき • 瞬間的な計測では、パフォーマンスの品質 は計れない。 • Keynoteなどの計測ツールを利⽤して継続 的に計測することが⼤切。 • 実はKeynoteで計測してみたので、これに ついては後ほどブログ記事などで公開予 定。
- CSSセレクタのパフォーマ ンスは気にしない？
- 気にしないわけではないが、 必要以上に⼼配しない • 最近のブラウザのCSSエンジンがかなり⾼速 • ただ無駄に遅くする理由はないので、全称セレクタや⼦孫や⼦供 セレクタは極⼒避ける • メンテナンス性や耐久度のあるHTML/CSS構造をつくるためであ れば可。 • *などパフォーマンスが⾼いとも思われるものでも、体感速度で 差を感じるほどの影響度はないため、他でメリットがあるのであ れば使おう！ .heading + * { margin-top: 10px; } *, *:before, *:after { box-sizing: border-box; }とか
- SVGって使えるの？
- ⾼解像度対応には必須 • モバイルで倍化した画像は、パフォーマンス劣化の 元に。 • 解像度は4Kなど進化がとまらない。スケーラブル なベクターが最適。 • フォールバックとして⾮対応ブラウザにはPNG • 対象ブラウザでの視覚的なテストは重要。SVGの形 式、書き出し⽅によって、表⽰が乱れる場合も。
- WebFontって使えるの？
- シンプルなものであれば、 イケるかも • 旧IEでジャギるケースもあり。 • Androidで表⽰されないケースもあり。 • 元のベクター次第で、問題が起きる可能性がある • シンプルなものであれば使って良いが、対象ブラウザでの視 覚的なテストは必須 • 上⼿くいけば、パフォーマンスとメンテナンス向上を得られ る。※ただ、画像と違ってプログレッシブレンダリングでは ないため、体感速度においては画像より劣る可能性もあるた め注意する。
- パフォーマンス＜メンテナンス
- メンテナンスは犠牲にしない • メンテナンス性が失われれば、将来パフォー マンスが失われる可能性も⽣む • 極めて、複雑でやることの多いフロントエン ドにおいて、メンテナンスが失われるのは致 命的である
- PCのみ、モバイルのみ、レスポ ンシブで考えることって？
- 注意すべきこと • PCとMBでネットワーク事情が全く違うことを理解す べき。3Gかつ混戦時、障害物影響まで考える。Ajax もUX向上の銀の弾丸ではない。 • レスポンシブである以上、モバイルファーストになら ざるを得ない。 • MBとレスポンシブは、ファイルサイズ上限に注意 • MBとレスポンシブは、低スペックなマシンに対す る、処理の重さにも注意。
- おまけ
- Navigation Timing API •ブラウザに実装されたパフォーマンス計測⽤ のAPI ※KeynoteやGAにも利⽤されている •操作可能になるまでの時間や、動いているも のに対して、リアルタイムに計測できるのが 素敵
- Service Worker •App Cacheのようなキャッシュの仕組み •様々な問題点のあったApp Cacheの代替案と して提案されている •これで、Nativeアプリにパフォーマンスで戦 えることを期待されている。要チェックや！
- まとめ •Web⾼速化においてボトルネックは、1つでもあって はならない •そのためにも、ブラウザの処理プロセスを知ることが ⼤事 •CSSスプライト / ファイル結合では、サイズに注意す る。（MBなら30kb、PCなら300kbなどを上限にす るなど） •モバイルのアニメーションはコツをつかんで滑らかに
- ご清聴ありがとうございました
- 参考⽂献 • 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
Advertisement