- HTML5 Conference 2018に参加してきました。
- 全部で30セッション以上あるカンファレンスでしたが、ほとんどが興味のある内容でとても充実したイベントでした。
- Webパフォーマンスや最新のWebAPIやHTTP/3等、最前線の情報をキャッチアップできました。
- このカンファレンスは全て有志で成り立っているとのことで、機器トラブル等あっても丁寧に対応していただき問題なくセッションに参加することができました。スタッフの皆さんありがとうございました。
タイムテーブルと資料のリンク
10:00 - 10:50
| タイトル | 発表者 |
|---|---|
| 基調講演 | 吉川徹、えーじ、岩井将行 |
11:20 - 12:00
| タイトル | 発表者 |
|---|---|
| ZOZOのグローバルECのフロントエンドアーキテクチャ設計 | 権守健嗣 |
| 光を超えるためのパフォーマンスチューニング/アーキテクチャ | mizchi |
| TypeScript Evolution | 倉見洋輔 |
| 持続可能なプロダクト開発のために - フロントエンドと新陳代謝の話 | 花谷拓磨（potato4d） |
| ブラウザでARとAIを動かした話 | 杉井庸一 |
| デザインを共有するための言語化あれこれ | 長谷川恭久 |
13:20 - 14:00
| タイトル | 発表者 |
|---|---|
| 「それ、AMPで作りませんか？」--- RichでResponsiveかつPWAなAMPの作り方 | 宇都宮佑亮 |
| FIDO認証によるパスワードレスログイン実装入門 | 合路健人 |
| 2018年のHTMLやCSSやAPIとか | 矢倉眞隆 |
| 組み込みブラウザとMediaの仕様あれこれ | 梅田雅士 |
| 使い倒そうVisual Studio Code! | さっくる（本間咲来） |
| アクセシビリティ、はじめよう! 〜「できない」から脱出するための20（仮）のネタ🍣〜 | 山本和泉、太田良典 |
14:20 - 15:00
| タイトル | 発表者 |
|---|---|
| Yahoo! JAPANアプリ上で動くWebVIewサービス開発〜Web技術で動くライブクイズ「ワイキュー」〜 | 石井直矢 |
| PWAの導入で得られた成果と見えてきた課題 | 宍戸俊哉 |
| Web Components のリアル | aggre |
| TechFeedのつくりかた 2018 | 白石俊平 |
| VOXELCANVAS：WebGLでのボクセルモデリングツール開発 ~ 開発ノウハウとブラジルの小学校で使ってもらえた話 | 津田良太郎 |
| 「セマンティクスの作り方、これまで、今、そして未来」 | 伊藤由暁（越智）、桝田草一 |
15:20 - 16:00
| タイトル | 発表者 |
|---|---|
| コンパイルターゲット言語としてのWebAssembly、そしてLINEでの実践 | Jun、kawasako |
| Node.js まとめ | 古川陽介 |
| Web プラットフォーム再考 ～PWA のもたらす未来の光と影 ～ | ものえおさむ、eegozilla、chikoski |
| Angularを使用したWebアプリケーションの最新設計手法 | 松本洸 |
| あんずフォト：PlayCanvasでリッチアドコンテンツを開発して発信してみた | 宗形修司、津田良太郎 |
| 開発体制に合わせたCSS設計 | 吉川雅彦 |
16:20 - 17:00
LT
| タイトル | 発表者 |
|---|---|
| 1000万以上のWebページを AMPにした話 | Masashi Hirano |
| slamdata/purescript-halogen の紹介 | @e_ntyo |
| CSS組版の救世主 Vivliostyle | @spring_raining |
| ビルドプロセスから考えるCSSアンチパターン | Kenji Imamula |
基調講演
テーマ
- The Web is shifting to the next gear
- Webの進化がはやい
- WebXR
- Web Authentication
仕組みを作る仕組みを、作る仕組みを作る
- 1ヶ月にWebにアクセスするデバイスの数 -> 50億
- web is an infrastructure
- 蛇口をひねれば水が出るのと同じ
- ブラウザを開けばWebが見られる
- 最新の技術
- Video + Picture in Picture
- WebRTC
- WebXR
- WebAuthentication
- Web Asesmbly + Web Audio
- 仕様の議論
- github上でオープンに議論される
- 各ブラウザベンダが最新仕様のステータスをオープンにしてる
- Extensible Web Manifest
- 低レベルのAPIをまず用意するという考え方
- AMP
- Web is thhe only platdorm no one owns
光を超えるためのパフォーマンスチューニング/アーキテクチャ
- mizchiさん
大前提
- この宇宙では光が遅すぎる
- 海外と通信すると特に
フロントエンドのキャッシュ設計
フロントエンド技術の目的
- 小さいスコープ
- 部分的に60fpsを達成
- 大きいスコープ
- 通信を含めて遅延を抑える
16ms以上の世界
- 構築済みHTMLをCDNで返すと速い
- キャッシュがいろんな層にある
- EdgeCacheにキャッシュしておく
- 参照はキャッシュから返す
- 更新されたらサーバがキャシュを更新
- 小規模開発だと
先読み
- https://guess-js.github.io/
- GAのデータを元にpreloadを挿入してくれる
- データがたくさんあると効果的
まとめ
- ネットワークにアクセスしたら負け
- CDNより先にアクセスしたら負け
- DBでクエリ発行したら負け
16ms未満の世界
- 途切れず連続していると感じる時間
最適化
- 単純にライブラリの量を減らす
- 展開する時間に1秒とかかかることも
- ダウンロードの時間だけなく展開の時間も削ることを考える
- lodashとかmomentとかでかいものを入れない
- Dynamic Importを使う
- レイアウト抑制
- ヘッダーの連続性が重要
マイクロチューニング指針
楽観的UI
クライアントファースト
- クライアントのデータ処理を優先する
- サーバは単にsyncするだけ
- 扱うデータが自己完結するケース
- ゲームとかツールとか
- firebase(firestore)と相性良し
- Webはクライアント改ざんに弱い
Off the main thread
- UIスレッド以外に処理を逃がす
- 自然とViewとデータを分離できる
FIDO認証によるパスワードレスログイン実装入門
- 合路健人さん(Yahoo)
パスワード認証の課題
- 利便性
- サービスごとにパスワード
- 複雑なパスワードの入力
- 安全性
- パスワードを盗まれる
FIDO
- Fast Identity Online
- 従来は利便性と安全性がトレードオフ
- FIDOはどちらも向上させる
- 公開鍵暗号方式
- 公開鍵をオンラインサービスに登録
- RP
- Relying Party
- 認証器
- Authnticator
FIDOの特徴
- 利便性
- 生体認証なので認証行為が容易
- 指紋・声紋・虹彩・顔
- 認証器の多様性
- パスワードを記憶しなくて良い
- 本人のみが記憶してる情報 -> 本人のみが所持している情報
- 生体認証なので認証行為が容易
- 安全性
- ネットワーク上に流れるのはクレデンシャル情報だけ?
- リスト攻撃を受けない
- フィッシング攻撃もできない
FIDOの技術仕様
FIDO UAF
- パスワードレス
- 主にスマホを利用
- 生体認証
FIDO U2F
- パスワード補完型(記憶 + 所持)
- PCのWebブラウザで利用
- 着脱式/無線式
FIDO2
- Webも対応
- ブラウザでもパスワードレスに
- Web Authntication API
- CredentialWebAPIの拡張
まとめ
- パスワード認証は利便性安全性に問題
- FIDO認証は公開鍵暗号方式で課題を解消
- FIDO2
PWAの導入で得られた成果と見えてきた課題
- 宍戸俊哉さん(日本経済新聞)
PWA導入したせいか
- 日経電子版
- SPAではない
- PWA化から１年たった
- パフォーマンス
- SpeedIndexで2倍
- ビジネス指標も向上
- PWA化だけでなくリニューアルによってUXが向上した
- ヘビーな使い方にも応えやすくなった
- 再訪の仕組み
- A2HS
- Push通知
- 再訪の仕組み
リリース後の取り組み
CSSのインライン化
- レンダリングブロックさせない工夫
- first viewのCSSだけheadに
- 本題はlazy loading
- First Meaningful Paintが1秒改善
- デバイスサイズやユーザ属性によってスタイルが違う
- マニュアルでメンテしてる
A2HSのタイミング
- いつホームに追加のプロンプトを出すかABテスト
- 記事の読了を判定し表示
- 押してもらえる率は高いが回数が少ない
- ブラウザ任せ
- こっち採用
- 記事の読了を判定し表示
ServiceWorkerの起動待ち問題
- 起動までに50ms(モバイルは250-500ms)待たされry
- NavigationPreload
- sw起動待たずにfetchできる仕組み
速度を維持する取り組み
- サイトは絶対に遅くなっていく
モニタリング
- Speedcurve
- 毎日測定
- ダッシュボード用モニタを置いて可視化
- 短期(1w-1m)
- 特定のリリースでの劣化を検知
- 長期(3m-1y)
- 気づいたら遅くなっていたを検知
ツール
- 導入済み
- SpeedCurve(webpagetest)
- PageSpeed Insights
- Atlas(内製ツール)
- 導入したい
- Chrome Experience Report
- Lighthouse CI
Paformance Badget
- パフォーマンス関連のメトリクスい対するBadget
- ファイルサイズ
- ファイル数
- 表示時間
- 数値で定義しオーバーしないようにつとめる
- 目標とする値をどうやって決める？
- web.devに記事が上がってる
- 現実的に取り組める値を設定してやっていくとよい
- ダイエットと一緒
現状の課題
- js/cssの最適化
- devtoolsでカバレッジ取ると8-9割使われてない
- Named Export
- Code Splitting
- Dynamic Import
- devtoolsでカバレッジ取ると8-9割使われてない
- さらなるキャシュ活用とオフライン対応
- 朝夕刊の一括ダウンロード
- アプリでは持ってる機能
- オフライン対応
- 日本では需要少なめなので後回しになってる
- BackgroundSyncとIndexedDBでできる
- RequestオブジェクトごとIndexedDBに入れる
- 朝夕刊の一括ダウンロード
- iOS Safari PWA
- 課題が山積み
- プッシュ通知できない
- A2HSのプロンプトでない
- バグ
- 等々
- その他
- 実装当時はキャッシュ周りライブラリなかったので自前
- workboxで書き直してる
- ServiceWorkerの更新
- 前回の更新確認から24時間以上経つと更新確認される
- importScriptsで読み込まれるファイルのみ変更した場合更新確認が行われない
- 実装当時はキャッシュ周りライブラリなかったので自前
PWAの今後の展望
まとめ
- PWA導入でエンゲージメント高められる
- 速度はUX向上の1手段
- モニタリング/Paformanec Badget
- iOS課題多いがServiceWorkerだけでも恩恵ある
- フレームワーク/プラットフォームがもっと整備されていきそう
Node.js まとめ
Node v11
- chengelog見ても変更少ない
- nodeのポリシー
- small core, less is more
- Long term support
- 偶数バージョン
- 2年間は保障 + 1年間セキュリティ保障
- LTSあると運用面で嬉しい
- 新しいバージョンでてもいきなり追従しなくていい
- VUP戦略を企業毎にとれる
- V8
- v8はNode非互換の修正をするときは事前に通知する
- v8がnodeをforkして確認してる
- CI回してる
- PRごとに全CPU・プラットフォームででビルドを確認
- Stability
- CPUのプロファイラとれる
- メモリリークを確認するする仕組み
- devtoolsでheapdumpとれる
- paformance priority is high
- 便利だけどパフォーマンス落ちるっていう機能は入れない
- ベンチマークをとってる
- マイクロベンチマークだけでなくExpressを使ったベンチマークもとってる
- https://benchmarking.nodejs.org
- https://yosuke-furukawa.hatenablog.com/entry/2017/12/05/125517
- keep v8 fresh
- 新しい(Stable Chromeに使われてる)v8を取り込むようにしている
- Worker
- Threeadを使えるようにするためのもの
- NodeはWebpackやbabelでの需要が高まってる
- multi threeadでやりたい
- llhttp
- TSからllvm bitcode生成してCからも呼べるようにする
- 従来のhttp_parserよりも高速化
- まだexperimental
- セキュリティ
- Security Releaseは脆弱が報告される度に修正パッチ
- ソーシャルハッキング的なことは防げない
npm audit,yarn audit- 脆弱性があるパッケージ使ってないかチェックできる
Web Standards
- Http/2
- ES Modules
.mjsはexperimental
- Promise
- Nodeの非同期処理
- callback, Promise, Stream
- util.promisify
- callbackをPromise化
- fs.promises(experimental)
- Promise返す
- Promise使えればasync/awaitで×
- StreamとPromise
for await (constt k of readable) { }
- stream -> callback -> promisifyする -> Promiseとして扱える
- Nodeの非同期処理
Node.js Futuer
- Node.js Foundation と JS Foundationの統合
- W3CとNodeの歩み寄り
- 共通部分をECMAで標準化
- WebAPIもNodeAPIもECMAもユースケースを求めてる
- 仕様策定側よりも利用してる開発者の方が知ってる
- 開発者がユースケースを作っていく
HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで
- 浅井智也さん(WebDINO Japan)
- 永井泰裕さん(ソフトバンク)
イントロ
- 2015/2
- HTTP/2
- 2019/XX
- HTTP/3
- HTTP over QUIC -> HTTP/3
5Gの世界
5Gにおけるネットワークの進化
- 4G -> 5G
- 遅延を小さくすることに特化させると
- 隊列走行による無人走行を実現し流通効率化
- 建設機器の遠隔監視制御
- 大容量に特化させると
ターゲット
- 3G
- 音声ネットワーク
- 4G
- データネットワーク
- 5G
- サービスネットワーク
5Gの実用化
- 2018年~
- 実証実験
- 2020年頃~
- 5G実現
- 2022年以降~
- 5G高度化
開発者にとって
- Web for 5Gの課題
- 5Gの性能を活かしきれない場面
- MEC(Multi-access Edge Computing)
- クライアントとサーバの間で受け取って処理する
- 5Gの性能を活かしたアプリ提供が可能に
- Web屋とインフラ屋でサービスを共創
HTTP/2 & TLS1.3
HTTP1.1 + TLS/1.2の課題
HTTP/2
- 単一TCP接続上で非同期並列通信
- ヘッダ圧縮による通信効率向上
TLS1.3
- 速い
- 0-RTT
- 安全
- 安心
