ラック
Home > ブログ > 記事 > 2017年9月 > HTML5 Conference 2017 参加レポート

HTML5 Conference 2017 参加レポート

カテゴリ: ホームページ,プログラム

9/24(日)に開催されたHTML5 Conference 2017に参加してきましたので、そのレポートを書き留めておきます。

Webフォント最新事情2017~導入事例も一挙紹介~

  • Webフォント使用率: 聴衆の8割
  • 6年前 Webフォントスタート: 自身でサブセット作って使う人たちしかいなかった
  • 昨年「NHKプロフェッショナル」で筑紫フォントの、今年「マツコの知らない世界」など、フォントの存在が身近になってきた
  • 質問: 止まれの標識
    • 「止まれ」の"止"の横棒、上に向いている
  • 人間は0.1秒で好き・嫌いなどの感情判断をする。色もそうだが、フォントもその要素。そのため、フォントはデザインで重要
  • 書体には適材適所がある
    • 例: 創英角ポップ体
      • 裁判結果で上訴の写真でdisられた
      • Wordのフォント一覧で目立つので選ばれてしまったのでは?
  • サインシステム(案内板)はゴシック
    • 明朝体やポップ体は連想イメージが強いので、「案内」の目的にはそぐわない
  • まとめ
    • ゴシック体: 見やすさ・視認性
    • 明朝体: 読みやすさ・可読性
  • Webフォントの背景
    • css3でWebフォント仕様が定義された
    • 縦書きも可能に
  • 日本語Webフォント百花繚乱
    • TypeSquare
    • FONTPLUS
    • Google Fonts
    • etc.
  • この1~2年が結構転機
    • 2年前: IE8がお亡くなり
    • JSで表示速度改善
    • アンチエイリアス・カーニングも可能に
  • 日本語フォント遅くね?
    • そうでもなくなってきた: 比較動画あり
  • 実装: 各社サービスでできる
    • 簡単
    • 非同期の場合はAPIで
  • FONTPLUSの場合、cssでカーニングする・しない切り分けできるようにした
  • 各社導入実績あり
    • 三井不動産
      • 中黒(・)が良い、ということで採用
    • etc.
  • 開運タテくじ
    • JSで裏文字も映してる
  • サブセットしたものを埋め込んでIoTなどで使う、というのが今後増える可能性
  • アクセシビリティ・ブランディングを説得する
    • え、Webフォント使わないの?
    • みんな使ってますよ?
    • Webサイトが素敵になるフォント、入れておきました
    • みたいに煽る(
  • Tips: font-familyで英語日本語両方書くとWebフォントは2回取に行くので片方だけで

まとめ

Webフォントの経緯と技術の進化を目の当たりにすることができました。それを踏まえた上で、画像認識による自動altタグの正確性も向上しているため「何が何でもすべてテキスト」というわけでもないですが、適材適所でテキストの画像とWebフォントによるテキストを使い分けられると良いと感じました。

最近の Web パフォーマンス改善について知っておきたいコト

  • 佐藤 歩
  • 株式会社サイバーエージェント
  • パフォーマンスは重要?
    • 重要
  • むしろネゴ(工数獲得・説得)が重要
  • サードデータ: 3秒越えたら53%が離脱する
  • KPI云々は記事を参照
  • 今回は情報量優先
  • パフォーマンスの基本的な考え方
    • 観点は大きく2つ
      • ページロード: URLアクセス~ページが表示されるまで
      • ランタイム: ページを開いた後のUIの応答速度
        • グラフィック、アニメーション
        • ボタンを押したときの反応
        • etc.
        • Chrome開発者ツールのパフォーマンスタブなどで確認
    • パフォーマンスとクライアント環境の多様性
      • 数年前のスマホ、地下鉄、SNSタイムラインから閲覧
      • 最新のスマホ、田舎の電波が弱いところ、ブックマーク(キャッシュありそう)
      • 1年前のスマホ、飲食店の絶望的なWiFi、調べ物から検索(キャッシュ微妙、AMP対応していれば……)
      • 環境は多種多様
        • マシンスペック
        • ブラウザの種類(SNS内臓か、OS標準か。キャッシュあるかどうか等)
        • 電波状況
        • 人間の性格(ゆったり許容?せっかち?)
        • 本当にユーザ環境は色々
      • あらゆる多様性の中に遅い、使いづらい、使えない、が潜む
      • 最初に離脱するとそもそもアクセス解析にすら乗らない離脱もありうる
      • RAID: Response, Animation, Idle, Load
        • googleの基準。どの程度の応答速度が適切と言えるか?
          • ページロードすら1秒。非常に厳しい基準
  • ページロード
    • 動作
      1. URLアクセス
      2. リソースをダウンロード
      3. Webページを実行(レンダリング, 描画, 実行)
    • クリティカルレンダリングパスを最適化しよう
    • 簡単な例
      • js読み込みをasync or deferで非同期にする
      • 無駄なものは読み込まない
      • 圧縮できるリソースは圧縮: gzip使う
    • ネットワーク: リソースの数とサイズと距離
    • あえて取り上げたいJS
      • 1MB越えるJS
      • クライアントサイドに処理が寄っている弊害
      • npmで依存パッケージの追加も簡単に
      • etcetc. でどんどん大きくなる
    • とあるSPAの例
      • JSの評価で1.4s。CPUで計算。デバイス固有なので、これが絶望的なラグになる可能性が……
    • とあるSSR(Server Side Rendering)+SPAの例
      • SPAとして動かすまでの時間: 結局JSの評価を待たなければならない→早く見えるが、操作ができないで待たされる可能性……
    • JSの初期化コスト怖い
      • 100KBの画像よりも100KBのJSの方が殺傷力を持つ場合も
    • JS Start-up Performance: googleの人の記事。参考に
  • HTTP/2
    • ただ入れるだけでは誤差の範囲内になってしまう可能性が(JSライブラリ一発で狐者異)
  • zopfli, brotli: スイスのパンの名前
    • 圧縮率が高い
  • ES Modules
    • import mod from './mod.js'をブラウザでも解決可能になる
    • 1つのファイルに無理に圧縮しなくても良くなる
    • HTTP/2の並行処理と併せて効果が出るかも
  • Preload, Resource Hints:
    • Preload: 現在のページのために指定リソースを優先ロード
      • Webフォント待ちのブロックを軽減
    • Resource Hints: 次ページのために先行ロード
      • dns-prefetch
      • preconnect
      • prefetch
      • etc.
  • 計測と評価指標
    • しっかり計測を
    • Synthetic Monitoring
      • 特定環境からWebサイトにアクセス
      • 端末や回線を条件指定できる
      • 詳細な情報が取れるので開発者にはありがたい
    • Real User Monitoring
      • 実際のユーザの値を取得
      • KPIなどはこちらを見た方が良い
    • ざっくり分かった気になれる指標: ざっくり見られるので重宝される
      • 今はUXに直結する指標が重要視される
  • プロダクトによって本当に必要な指標は個別対応になるかも
    • USer Timing APIで計測
  • 予算の設定と定常的な計測
    • 予算と基準に合わせて、運用するのがベースライン
    • SpeedCurveは有料だがお手軽で開発者が好きそうな感じ
  • ランタイム
    • シングルスレッドな世界と向き合って生きる
    • ブラウザはシングルスレッド
      • とにかく処理を軽く、短く
      • 他の処理が割り込めるようにぶつ切りにするなど
  • 一般的な問題: HTML5 Conference 2013で発表した内容が未だに有効……そちらを参照
  • Intersection Observer: スクロール同期処理の救世主
    • 画像の遅延読み込みとかで使える
  • requestIdleCallback: 何もしていないときに発火。暇なときに処理してね的な
    • timeRemainingで残り時間カウント
  • ブラウザは知らないけど開発者は知っている要素の変更などを、予めブラウザに教えるためのAPIや仕様が最近増えている
  • 他色々
  • まとめ
    • とにかく最近のでかいJSに注意
    • 計測指標を知っておくと「何が速いのか」を判断できる
    • ランタイムはAPIが充実してきているのでキャッチアップしておくと良い

まとめ

全体的に情報量が多く、追いきれませんでしたが、とりあえず計測は大事ということと、計測した上で的確に原因を潰せるか、が肝だと感じました。

ECMAScript and Babel's role

  • Diango Franco
  • ピクシブ株式会社
  • ブラジル出身
  • WebpackやBabelにもコミット
  • ECMAScriptの仕様はTC(Technical Committee)39で規定される
    • 会議の様子や結果はGithub上にあるので、それを追っていくと見えてくる
  • TC39のプロセス: 2014/1に告知あり、2015に公表
    • 現在もこのプロセスに則って会議されている
    • Stage-3("candidate")まで来ると、ブラウザで実装してほしい、という段階。だいぶ現実味が出てくる。
    • Stage-4("finished")になるには、2つのブラウザで実装される必要がある
  • Babelはどう関係するか?
    • Babelができるまで: ECMAScript6ができていなかったころ、ECMAScript6をECMAScript5にコンバートすることだった。
    • みんなの強敵: IE, Androidのブラウザ
      • これに対応させるためにコンバート機能が求められたという一面も
    • ECMAScript6が実装されても、未だにBabelは必要とされた
  • Babelには4つのコアコンポーネント(プラグイン)がある
    • babylon: 最初にコードが通る。babelが使うJSパーサ
    • babel-traverse: 実際のソースコードの変換
    • babel-generate: 新しいソースコードを生成
    • babel-types:
  • Polyfills
    • 実際のブラウザに実装するときに必要なことが多い
    • IEにPromiseがないのでそれを補完する、過去のSafariのPromiseのサブ関数でおかしい部分があったのを修正、など
  • Useful API
    • Scope
    • babel-template
  • BabelにTypeScriptのパーサ入った
    • Microsoftからプルリクがあって、入れることになったらしい
  • BabelはTC39のStageに入った仕様をプラグイン化、すぐに対応できるように
  • OpenCollective
    • googleがメジャースポンサー

まとめ

Babelの経緯をざっと知ることができました。Babelはどこかで当たる可能性があるので、最新動向はチェックしておきたいと思います。

コンセプトのつくりかた — アイデアをかたちにする技術

  • 白石 俊平
  • 株式会社オープンテクノロジーCEO

  • 誰でもイベント・グループを作れるようになった
  • Techfeed, HTML5 Experts.jp, html5jの運営などに携わる
  • 趣味は企画
    • 10年やって得たもの
    • コンセプト・メイキング
  • コンセプト・メイキング
    • アイディアをかたちにする技術
    • 外向きの螺旋のイメージ: 巻き込む人が増えつつ外側に広がっていく
      1. アイディアは始点: 不可欠だが無価値
      2. 最初の円形は小さい: 少人数
      3. 円は回りながら大きくなる: 小さく作って大きくする
  • アイディアは始点
    • 無いと始まらないが、それだけでは価値を生まない
    • 誰も巻き込んでいない: googleの創業者も「アイディアは無価値」と言っている
    • アイディアの作り方: アイディアは新しい組み合わせ
      • 組み合わせの片方は、よく知られているものを
        • 新しいもの同士では理解されづらい
        • 例: 一平ちゃん*ショートケーキ味、など
          • インパクトが強い
      • アイディアが出ないとき: 不謹慎になろう
        • タブーは邪魔になることがある
        • 「ここまで言っていい」という空気が必要
      • ついでに「3ない」も捨てよう
        • 金、モノ、人
  • まずは複数形になろう
    • 最初は少人数
    • 2人or3人ぐらいになろう
    • TED, リーダーシップ、で検索すると引っかかる3分の動画が参考になる
    • どうやって人を巻き込むか?
      • モノがない状態から人を誘わなければならないという困難
      • 面白さが伝わるまで一人で作る
        • 完成度は低くても良い
        • ギリギリ動くソフト、仮だらけの企画書など
    • それでも、伝わらないのが当たり前
      • それでも、やりたいアイディアは本物
  • 小さく作って大きく育てる
    • できるだけ素早く、後戻りしないように
    • どんな大きさの円にするかはコンセプト次第
      • ものによっては大きくするだけとは限らない
  • コンセプトの4要素
    • CCMM
      • C: Copy: 名前、キャッチコピー
      • C: Contents: コンテンツ、中身
      • M: Mission: 社会的意義、ミッション
      • M: Motivation: やる気
    • ユーザの見る順番:
      1. Copy: 名前などを見る
        • とにかく大事
        • 0.1秒で好き嫌いの判断がされる
        • 一度名付けると非常に変えにくい
        • リズム・インパクトが大事
          • 一度聞いたら忘れない
          • 誰も否定しない
      2. Contents: 内容を見る
        • 中身。コンテンツ。
        • 「具体的には何?」に答えるもの
        • 一番大事で作るの大変
        • でも、名前さえあれば伝わるので集まったりする
      3. Mission: 社会的意義を見る
        • コンセプトの社会的意義、目的、存在意義
        • 「目的は?」という疑問に答えるもの
        • 何のためにやってる?と立ち返ることができる。道標
        • 人を動かしやすい
          • 人間は意味・意義を感じられる活動をしたいから
      4. Motivation: モチベーション
        • 「何故それを作りたいの?」という疑問に答えるもの
        • 下手に言語化しない方が良いことも
          • 「だって楽しそうだから」は最強
          • どうしても語る必要があるときだけ考える
            • それがストーリー
    • Founder: 人
    • Idea: 基本アイディア
    • Copy
    • Contents
    • Mission
    • Motivation
    • という感じで分解すると整理できそう

まとめ

人を動かすような話の仕方が上手く、説明も分かりやすくて、話の内容もさることながら資料作りや話し方も参考になると感じました。 プロジェクトを動かす際の要点を押さえて話をされていたので、今後何かの折につけて参考にしようと思いました。

テクニックではなく、今、本気で取り組むべきWebパフォーマンス

  • 竹洞 陽一郎
  • 株式会社Spelldata
  • html5j パフォーマンス部

  • 日本でも火が付いた
    • パフォーマンスが重要なことが分かっている
    • が、経営層やマネジメント層が理解してくれなくて困ってる
    • という問題
  • 顧客体験が重要と答えた日本のCEO: 5%
    • 説得材料を共有したい
    • お金の話、競合他社の話をするのが速い
  • Webパフォーマンス計測ツール
    • Dynatrace
    • Catchpoint Systems
    • SpeedCurve
    • etc.
    • 市場規模: 1102億円
      • 年18.1%の伸び
      • 2021年までに2362億円に伸びる予定
        • 海外はパフォーマンスを計測しており、市場が拡大している
      • 欧米: 合成計測(Synthetic Monitoring)がメイン
        • お金がかかる: 計測機器には精密さが求められている: 法的保証
        • "garbage in, garbage out": ゴミデータからはゴミしか生まない
    • 何故計測するか?
      • Webサイト運用の基本だから
      • トラフィックは常に変化する。8/25のgoogleのルーティング設定のミスのように、時々刻々とネット回線は変化する
      • Webサイトにはサードパーティ製プラグインが大量に20~30入っている
        • 自分のコンテンツしか管理していなければ、よそに原因があるときに言及できない
      • 品質管理は利益の源泉
        • 品質管理をちゃんとやるともうかる
      • 海外では数千万~1億円使うのが普通
        • 何事も分布
          • 自社は品質管理の取り組みの分布においてどの位置にいるか?
    • googleが去年から広告・マーケター関連に直接「表示速度」について営業している
      • 大企業は動き始めている
  • Webパフォーマンスにおいて、日本は15年遅れている
  • 民法改正
    • 5月に可決、来年に施行されるかも
    • 品質保証が必須になる
    • 品質テストしてから納品しないと重過失
    • SaaS、Webサービス: SLA(Service Level Agreeement)を決めないといけない。満たさない場合返金
  • Webサイトの三大品質
    • アクセシビリティ
      • 法律は既に通っている
    • セキュリティ
    • パフォーマンス
  • パフォーマンスの話
    • 実際は技術ではなく、人間の問題
      • 売り上げが上がるわけではない
      • あくまで機会損失を防ぐだけ
    • 大きい原因を潰して、結果を示す
      • 結果を示せば後が付いて来やすくなる
  • 一旦テクニックは忘れましょう
    • 遅延の原因さえ分かれば解決策が出る
  • 無知の知
    • 「知らないと言うことを知っている」
  • 思い込みを止める
    • 画像,css,jsだ、と決めつけるのを止める
  • 第一段階
    • 全数調査
    • 目的: 把握していない遅延を捉える
  • 第二段階
    • 計測
      • 結果、どうなったかも
    • 原因にアタリを付ける
    • 詳細調査
    • 改善
  • 高速化
    • 本質は計算量を減らすか
    • アルダームの法則
      • 2つの要因のうち、影響が大きい方に注力する
  • Google PageSpeed Insightsの問題
    • レンダリング関係しか見ない
    • ネットワーク側が見えない
      • WordPressのテーマがこれでスコアが悪かったから買わなかった
        • 実際は速かった
          • サードパーティ製プラグイン、CDNなど
  • 高速化の3つの方策
    1. 追加
      • リソースの追加
    2. 交換
      • 計算量の少ない方法に変える
        • WPプラグイン入れて画像などを圧縮: 代わりに今までなかった計算が増えるので、コストを見比べる
    3. 削除
      • 計算量を減らす
  • 80:20の法則
    • 全体の8割の遅延を占める2割の原因を解決する
  • まずは秒の遅延をどうにかしよう
    • ページロードまで
  • システムの5つの要素
    • External Input
    • Internal Logical Files
    • External Output
    • External Interface Files
    • External Inruires
    • これらに分解して、どこがボトルネックになっているか考える
  • 調査は下から上
    • ネット、ハード、OS、アプリ、……
  • 次世代へ:5Gネットワーク
    • ネットワークスライス
    • 指向性アンテナ
    • Mobile Edge Computing
      • 分散コンピューティングが可能に

まとめ

日本でもようやく火が点いてきたWebパフォーマンスの分野。それでもまだまだ温度が低く、人への説得が難しいのが現状ということを踏まえて啓蒙的な内容が多かったです。現状をどう変えるか、少しでも説得材料にしたいです。

あと計測大事。計算量減らすのも大事。

全体のまとめ

初めての参加でしたが、Webと言いつつ非常に多くの分野のセッションがあり、1つの時間枠で2~3つ聞きたいセッションがあるのがデフォルトのような状態でした。
聞けなかった内容は資料や動画、反応などから拾って補完しつつ、聞くことができた内容も今後に向けての自分の糧にしたいです。

とりあえずコンセプトを作ることとWebフォントの縦書きは使いたい場面があるので、そこに活用したいです。

メモ

[HTML5 Conference] ウェブのための次世代決済法 - Google スライド

HTML5 conference 2017 room C 14:20-15:00 · GitHub

HTML5 Conference 2017:多様なユーザーニーズに応えるフロントエンドデザインパターン 〜書籍「インクルーシブ HTML + CSS & JavaScript」より - Google スライド

詳解 WebRTC · GitHub

タグ: その他,css,javascript,jQuery,イベント,html,フォント

 



関連する記事一覧