pirosikick's diary

君のハートにunshift

第51回html5とか勉強会行った #html5j

勉強会 html5 javascript

第51回 HTML5とか勉強会 - connpass

パフォーマンスに関するWeb標準についてとか、Web Animation APIとかは知らなかったのでちゃんと追わないと。。。

Chrome Dev Toolsの使い方とか、やらねばやらねばと思いつつも、FluxとかRact.jsとか、 ものを作るために必要な技術の勉強を優先してしまっているので、 会社で勉強会開くとか無理やりでも時間作らないとなーと思いました。

以下、メモ

ブラウザのパフォーマンスを限界まで高める、HTMLコーディングの考え方

ブラウザのパフォーマンスを限界まで高める HTMLコーディングの考え方

  • 川田寛さん
  • HTML5expoerts.jpとかに書いた記事、半年くらいでレガシー化した
  • 戦略の立て方
    • Webを取り巻く環境は最近ひどくなった
      • ナビゲーション（リンク遷移）が遅い→Wifi、ネットワーク環境
      • ランタイム→クソAndroid端末
    • パフォーマンスを意識せんとアカンで！
    • 戦略で重要なこと→頑張りすぎない
      • 作り込み過ぎはエンジニアを不幸にする
      • 時間を書けるほど得られる効果は低い
    • どれくらいやりゃいいのか？
      • 「90%タイルで1秒以下」のような感じ
      • パーセンタイル
        • レアケースを取り除く
        • データの特徴みて、特定のエラー等起きてないかみる
        • ボトルネックを探す
  • 改善の方法
    • Google I/O 2014のPaul Lewis氏
    • Initial Rnnder
      • 最初のレンダリングを開始するまでの時間
      • 最初のレンダーされるまで
        • リンククリック
        • 名前解決
        • Webサーバへリクエスト
          • ここでリダイレクトされたりとかすると、
          • もう1度名前解決から
        • バッファされてブラウザへ
          • バッファサイズのデフォルトは8KBのことが多い
            • 要するに最初の8KBが大事でござる
        • 対策
          • DNSの最適化
          • リダイレクトの最適化
          • TCP/SSLの最適化
          • ファーストバイトダウンロード
            • HTMLファイル8KB分
    • Visually Complete
      • 見た目が完成している
      • Speed Indexを使え
        • Webページを表示される過程を評価
        • 結果は同じでも、途中でどこまでレンダーされてるかは重要
          • ずっと真っ白で3秒でレンダーされるよりも
          • ちょっとずつレンダーされて3秒で完成するほうが
          • UX的に優れている
      • JS, CSS, imageの最適化
        • Grunt, Gulpでやってくれる
      • Critical Rendering Path
        • 全体の対策
        • ネットワークの最適化
          • HTTP 1.1は
          • 一度に6つのDLしかできないので、
          • タグを書く順序でちょっと変わったりする
          • SPDYはもうちょっと複雑
      • Load Complete
        • 大して重要じゃないけど
        • Load後に、次のページのリソースを読み込んどくテクニックある
  • Web標準
    • Web Performance Working Group
      • public-web-perf@w3.org
      • ブラウザから情報とって最適化しよう
        • Navigation Timing, Resource Timing, User Timing
      • それらをサーバに送る → Beacon
    • Page Visibility
    • requestAnimationFrame
    • Resource Hints
      • Resource Priorities, Prefetch/Prerenderを統合

ブラウザーに優しくして、アニメーションを滑らかに

ブラウザーに優しくて、アニメーションを滑らかに

  • Brian Birtlesさん
    • Mozilla Japan
    • オーストラリアの方
    • 10年くらいアニメーションの開発に関わってる
  • アニメーションは多くの情報を伝えるが、
  • パフォーマンスが悪いと不快になる、
  • DOMツリーとレンダーツリー
    • FirefoxではFrame Tree
    • display: noneするとレンダーツリーから外れるので速くなるとか
  • スタイル決定とレイアウト（リフロウ）
    • 高さとかは相対で決まったりするのでレイアウトで決まる
    • FirefoxではReflowの時間見れる
    • リフローを避ける
      • transformを使う
      • 配置と関係ないプロパティを使う
      • font-sizeよりtransform: scale
      • 適用されているスタイルの取得もリフロー発生する
  • 描画のコスト＝描画の領域ｘ描画の重さ
    • SVGのフィルタ、box-shadowとかコスト高い
    • svg画像はiframe, objectよりimgタグで。最適化してくれるから
  • レイヤー
    • レイヤー化はブラウザが勝手にやってる
    • Firefox aboudt:config>layer.draw-borders = true
      • どこがレイヤ化されてるか可視化できる
    • will-changeプロパティでレイヤ化する
  • コンポジター上のアニメーション

部分最適化から全体最適化へ ― Webの情報品質管理手法

  • 竹洞陽一郎さん
    • 株式会社Spelldata 代表取締役社長
    • html5j パフォーマンス部部長
    • Spelldataのサイトは世界最速
    • キャリアとして低から高レイヤまで経験してる
  • SoftBank回線は勝手に画像圧縮してる
    • だいたい夜の9時から12時に高負荷で、圧縮処理が重くなる
  • パフォーマンスと情報品質の関係
  • そもそも価値のある情報を送っているか考えろ
    • 「速さ」は情報の質の1つ
    • そもそもの情報の内容が悪ければ
    • コミュニケーションという目的を達成するパフォーマンスは悪い
  • シャノンの情報理論
    • 情報源符号化定理 − 情報をどのように区切れば効率が上がるか
    • 情報路符号化定理
  • 通信路の容量を超えるスピードで情報が入ってくると処理できない
    • 誤りを減らすためにはどう送ればよいか
  • 情報エントロピー
  • 情報の分類
    • 知ってることを知ってる、知らないことを知ってる、知らないことを知らない
    • 「知らないことを知らない」を解決するのが広告
  • トピックに対して意識が高い層、低い層で「言葉」を変えないといけない
  • 情報の三要素
    • 整合性、完全性、アバウトネス
    • コンテキストに合った情報
  • 情報の価値
    • 決定を可能とする情報を提供する
    • on time（時間通りに）, in time（時間内に）
  • ダイレクトメールをもっとも活用してるのはGoogle
  • 「情報は関心を消費する」ハーバート・サイモン
    • 情報を適切に配置しないとだめ
  • 選択肢が多いほど決断できない
  • 画像のコスト
    • 「1の写真は1,000言葉にまさる」ジブコーレン
    • Webは見た目の画像が多い。情報じゃない
    • 無線網は有限なので、画像は出来る限り使わない方がいい
  • まとめ
    • パフォーマンスイコール速さではない
    • 情報品質も高めて、全体最適化しよう！