ブラウザにやさしい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サイト超⾼高速化実況中継  　　　　　 ── スピードの鍵はフロントエンド！」

Lei Hau'oli co.,ltd. • 株式会社レイハウオリは2008年年創業のWeb制作会社です。 • おかげさまで先⽇日、第7期⽬目を迎えることが出来ました。 • 特にフロントエンドにおけるWPOを得意としています。 • ⼀一部では“レイさん”と呼ばれることが多いです。

アジェンダ • はじめに • ブラウザにやさしい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 0.5s 1s

1ホスト当たりの  各ブラウザの同時接続数 IE6 IE7 IE8+ Firefox Chrome Safari 2 2 6 6 6 6

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 / ﬁxedの場合、別コンテキストになる •イベントで何かがDOM構造が変わるとレイアウト / リペイント •一部のCSSプロパティに変更があると、レイアウト / リペイント、もしくはリペイントのみ

Render Layer • relative, absolute,ﬁxed, transformを使うと、レイヤーが⽣生まれる。消費コストは⾼高いが、⾮非同期処理理に。 • 特にabsolute/ﬁxedは、他要素との相対座標計算が省省かれ⾼高速 • transformはJSアニメーションより⾼高速

レイヤーの中でも Graphic Layerに注目 ! •いわゆるハードウェアアクセラレーション •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 ﬁlters •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;をアプライする div li {width: 100px; }

JavaScriptの実行 •同期的に実⾏行行　※WebWorkersを除く •パーサーが <script> タグに達するとすぐにスクリプトが解析、実⾏行行 •スクリプトが外部にある場合は、リソースを取得するまで解析は中断

ブラウザとユーザーの気持ちを知ろう

ブラウザの気持ち •⾒見見た⽬目から表⽰示したい  •時間がかかること⼤大変なことは、出来るだけ避けたい  •いろんなこと⼀一⽚片にしたくない  ! •他のブラウザいなくなれ

ブラウザの気持ち •⾒見見た⽬目から表⽰示したい  →順序の最適化 •時間がかかること⼤大変なことは、出来るだけ避けたい  →リクエスト、サイズ、消費メモリの最⼩小化 •いろんなこと⼀一⽚片にしたくない  →処理理の分散化 ! •他のブラウザいなくなれ

ユーザーの気持ち •速く⾒見見たい  •まちたくない  •スムーズであってほしい     

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

デモで分かるブラウザにやさしい HTML/CSS

DEMO一覧 http://goo.gl/zA4ZvQ ID: tech! PASS: tech-lab

DNSプリフェッチ

DNSのプリフェッチ •DNSルックアップ回数を減らすのもあるが、⼤大抵の場合現実的ではない　※広告など •先読みして、パフォーマンスを向上させるのが、DNSプリフェッチ　※Amazonでも利利⽤用デモでは上手く差をつくれませんでした。

DNSプリフェッチ  記述方法 <meta http-equiv="x-dns-prefetch-control" content="on"> <link rel="dns-prefetch" href="//www.spreadﬁrefox.com"> オンにする記述 ※デフォルトでONの場合もありますが、明示的に書くほうが良いと考えています指定したドメインのプリフェッチを強制する

WebPageTest計測結果プリフェッチなしプリフェッチあり http://www.webpagetest.org/result/140508_9W_C80/1/details/ http://www.webpagetest.org/result/140508_HP_C7Y/1/details/

画像サイズ  大きすぎ、  個数多すぎ

リクエストが多すぎると遅い •CSSスプライトなし、ありで、圧倒的な体感スピードの差がある

リソースの  読み込み順間違い

リソースの読み込み順間違い •NGパターン

リソースの読み込み順間違い •OKパターン

レンダリング  ブロッキング

JSによるブロッキング •特に外部スクリプトは、レンダリングをブロックする •なので、原則</body>直前に配置すべき  ※これが無理理な場合は、defer属性を指定したら良良さそうだが、全てのブラウザで実⾏行行順序が保証されていないため、注意が必要＝オススメできない

CSSエフェクト過多

CSSエフェクト過多 •CSS3でエフェクトが多彩になったことで、画像を使わずに、より多くのデザイン表現が可能に •ただし、プロパティによっては、使いすぎると重くなりすぎる opacity / gradient / box-‐‑‒ shadow / text-‐‑‒shadow。

アニメーションがカクカク

特にモバイル •原則JSアニメーションより、CSSアニメーションが⾼高速 •なので、CSSアニメーション使おう •ただ！モバイルでは、使いこなすにはコツが必要。

モバイルでもなめらかなアニメーションにするために •absolute / ﬁxedにする •アニメーション中だけ、translate3d(0, 0, 0) などでハードウェアアクセラレーションを有効にする  ※そうじゃないと、副作⽤用がありバグを⽣生む。（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で計測してみたので、これについては後ほどブログ記事などで公開予定。

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にも利利⽤用されている •操作可能になるまでの時間や、動いているものに対して、リアルタイムに計測できるのが素敵

まとめ •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-‐‑‒reﬂowrelayout-‐‑‒restyle/ • https://dvcs.w3.org/hg/webperf/raw-‐‑‒ﬁle/tip/specs/ NavigationTiming/Overview.html • http://www.html5rocks.com/en/tutorials/webperformance/basics/ • https://developer.mozilla.org/ja/docs/Controlling_̲DNS_̲prefetching

http://wp-e.org	979
http://localhost	158
http://0.0.0.0	36
https://twitter.com	20
http://lei-frontendoc.herokuapp.com	14
http://feedly.com	10
http://s.deeeki.com	6
http://www.slideee.com	6
https://www.chatwork.com	4
http://www.feedspot.com	1
https://www.linkedin.com	1

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

by Takeharu Igari, Manager / Evangerist / Front-end Engineer at 株式会社レイハウオリ

on May 10, 2014

Statistics

Views

Actions

11 Embeds 1,239

Accessibility

Categories

Upload Details

Usage Rights

Report content

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