フロントエンドカンファレンス福岡 雑多メモ #fec_fukuoka

2019.11.16

フロントエンドカンファレンス福岡行ってきました。発表者の方々、運営の方々おつかれさまでした。良い刺激になりました。

Frontend Conference Fukuoka 2019

聞いた発表の雑多なメモのまとめです。雑多なので正確性は保証できません。。。

『HTML Optimization for Web Performance』by 泉水 翔吾 氏

パフォーマンスのメトリクスの種類と計測方法の紹介。将来的に実装されるAPIなども紹介。

以下、発表中にとった雑多メモ

  • クリティカルレンダリングパス

    • CSSSOM

  • パフォーマンスメトリクス

    • 元来はLoadとかDOMContentLoadedとか使ってた
    • youtubeならvideoが表示されたタイミングが大事
    • でもそれはDOMContentLoadedでは取れないよね
  • Time to interactive demo

  • User体験に基づいたパフォーマンスメトリクスを取ろうね

    • First contentful paint
    • first meaningful paint
  • Speed Index

  • long tasks があると　time to interactive が悪くなる

    • まだ標準化されていない

  • PerformanceObserver ってどういう使い方するんだろう

    • ユーザのクライアントで動かしてパフォーマンスを取ることができる
    • 例えばどういう使い方があるか

  • All (sub-)resources should be minified

    • 圧縮せよ

  • CSSのlinkタグをheaderタグに書く

    • CSSを分割してても良くなってきてる

  • JS最適化

    • 3rd partyのスクリプトには defer をつける
    • asyncは評価されてしまう

  • preload

    • rel="preload" で優先的にダウンロードしてくれる
    • es modulesはrel="modulepreload"

  • Native lazy-loading

    • src="image.png" loading="lazy"

  • Resource Hints

    • DNS Prefetch
    • Resolves DNS
    • Preconnect
    • Creates TCP connection
    • Prefetch
    • Fetches resources
    • Prerender
    • Renders HTML page

『世界を変えるためのデザインシステム』by 山本 伶 氏

freeeのデザインシステムVibesがどのように生まれたのか、そしてそれを社内に広めるための苦労など。デザインシステムを作る理由がかっこよかった。

以下、発表中にとった雑多メモ

  • freee

    • エンジニア: フロント/サーバの区別があんまない
    • デザイナー: UXデザイナー

  • フロントエンド

    • UIデザインはUXデザイナーが行う

  • 問題点

    • デザイナーごとにUIの差異が大きくなってきた
    • 画面モックと実装にも差が生まれる
    • 画面モックを再現するCSSが足りて無くてコピペしてしまう
    • CSSの配置や書き方の指針が無くて、stylesheetsディレクトリがカオスになる
    • 見た目が揃っていない/同じ見た目でも違う挙動をするUIが大量発生
    • それっぽいCSSを毎回探したり、コピペしたりしていて生産性も低下

  • AG部

    • freee共有のUI基盤を作っていく
    • Hack Day (一日10%は好きなことに使ってい)やつで始めた

  • vibes

    • 当初はAtomic Designだった
    • SketchライブラリとCSS/React Component実装

  • 目指すもの

    • 高品質で統一感のあるUIを爆速で実装できること
    • CSSを書かずにコンポーネントを使える
    • デザイナーとエンジニアのコンポーネントの共通言語ができた
    • アクセシビリティの担保
  • Atomic Design
  • Sketchライブラリをデザイナーに提供している

  • アクセシビリティ

    • 社内用のガイドライン
  • eslintのa11yのプラグイン
  • storybookのa11yチェック

  • カラーパレットをWCAGの基準を満たすように調整

    • googleスプレッドシートでコントラスト比の計算をやる

  • a11yチェック内容の定義を社内でやる

    • 社内当事者のチェックもある

  • ほかチームが使う上での問題点

    • 想定しない使われ方
    • 実装を無視したリサイズなど発生
    • コンポーネント自体がなかったり機能不足があったときに改善できない
    • PRを投げてほしいんですがうまく使ってもらうコミュニケーションが必要

  • Vibesの設計思想を文章化する

    • 長文のkibera
    • (導入のコストが高いように見える)
    • (アンチVibesみたいな勢が出てきそう)
    • issueを立てやすくする工夫 issue template

  • Material Designでよくない？

    • 自分たちで構築する意味は？
    • 会社のビジョン/ミッションを実現するためにデザインシステムを作っている
    • 高品質なプロダクトを高速にリリースしていける必要がある
    • どんなユーザーでも排除せず誰でもものを作る必要がある
    • freeが提供する価値を世界に伝えられるUIである必要がある
    • (かっこいい)
  • freeeのリブランディング
  • UI/UXのガイドライン『Grooves』

  • freeeがvivesを使うのは

    • freeeが作っているのは世界を変えるプラットフォームだから
    • 他のデザインシステムを流用したりすると、どこかで犠牲を払う必要がある
    • UIの最適化を諦めたり、どれを選べば最適なのかを毎回探さないといけない
    • a11yの対応がまちまち
    • ブランドイメージをUIで伝えることができる
  • 『世界を変えるデザイン』
  • Lightning Design System

『Visual Regression Testing in Action』by 倉見 洋輔 氏

『これからのフロントエンドセキュリティ』by 長谷川 陽介 氏

フロントエンドで考慮すべき具体的なセキュリティ対策の紹介。XSSをどのように防ぐのか、安全にクロスオリジン間通信を行うための仕組みなど。

以下、発表中にとった雑多メモ

  • オリジンとは？

    • same origin policy
    • プロトコル + ホスト + ポート
    • http:// + nulab.com + : 8080
    • オリジンが異なればCORSエラー
    • http https でオリジンは異なる

  • DOM based xss

    • decodeURIComponent で評価されてしまう
    • cookieを盗む、画面内のクレカ情報を抜き取る
    • 攻撃者の与えた文字列(ソース)をもとにHTMLを操作(シンク)することで発生
    • location.href, location.searchなどを使って混入させる
    • eval, innerHTMLなどを使って実行させる

  • 対策はDOM操作関数を使う

    • textContent, setAttributeなどを使う
    • jsなどでリンク生成する時はhttp:// などに限る
    • JSライブラリを最新にする

  • mXSS

    • HTMLElement -> String -> HTMLElement という変換をさせるところ
    • div1.innerHTML = div2.innerHTMLとか文字列でコピーしたらバッククオートとか駆使すればJSが実行できてしまう
    • 対策
    • innerHTMLではなく、cloneNodeなどでHTMLの構造的にコピーする
    • iframeのsandbox属性を使う
    • DOMPurifyなどのmXSSを考慮したライブラリを使う

  • open redirect

    • 攻撃者が指定した任意のサイトにリダイレクトをさせられる脆弱性
    • locations.hrefにlocation.hasとかを突っ込んでるところに/example.comとか入れたらリダイレクトする
    • 対策
    • URLインターフェースを使うnew URL()でoriginが同じであればリダイレクトさせて良い

  • x-frame-options

    • クリックジャッキングを防ぐためのレスポンスヘッダー
    • 徐々に規格が縮退方向へ…
    • これからはCSPのframe-ancestorsへ

  • CSP(Contents Security Policy)

    • コンテンツセキュリティポリシー (CSP) - HTTP | MDN
    • レスポンスヘッダーを指定することでリソースの読み込み元を制限できる
    • 指定したオリジンからのjsなどは読み込まれなくできる
    • 攻撃されたときにレポートを送ることができる
    • report-uriを指定してpostすることができる
    • frame-ancestors: どこへ埋め込まれるかを指定できる
    • フォームの送信先の制限
    • ブロックすることもできるし、ブロックさせないけどレポートだけ送ることもできる

  • CSPでXSSの脅威を大きく低減することができる

    • 許可しているドメイン上に古いJSライブラリとかがあればそれを経由してXSSしたりできる

  • CORS(Cross-Origin Resource Sharing)

  • CORP(Cross-Origin Resource Policy )

  • CORB(Cross-Origin Read Blocking )

  • CSP〜CORB

    • 攻撃者の作成した罠サイト経由でデータを読み込まれることへの防御機構が充実

  • Same Site Cookie

    • Cookieの送信を同一サイト内に限定する仕組み
    • strict
    • クロスサイトでのCookieを一切送信しなくなる
    • lax
    • リンククリックでのページ遷移(top-level navigation)などを除き、Cookieを送信しない
    • 罠ページからのiframeやscript, form postなどでCookieが送信されなくなる
    • samesite=laxがデフォルトになる

  • 今日紹介できなかったもの

    • SRI, Fetch, metadata, XS-Search, XS-Leaks
© 2019-2024 kwst.site.