- 概要
- 時間はただの幻想である… JavaScriptにおいては
- WEB の自重
- GraphQLを用いたECサイトにおけるパフォーマンス改善
- JavaScriptのままでTypeScriptを始める
- Your Benchmark May Not Guide a Real Application Performance
- Recruit Speed Hackathon（ワークショップ）
- 持ち帰ったアクション
概要
JSConf JP 2019に参加してきました。
https://jsconf.jp/2019/
自分用メモとしてブログに残します。
Day1はこちら
JSConf JP 2019 Day1参加記録 - tom-256.log
以下スケジュールです。
時間はただの幻想である… JavaScriptにおいては
まとめ
- JavaScriptのDateオブジェクト(https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date)についての歴史
- 今はmoment.js(https://momentjs.com/)使おう
- 今後はtemporalという新しい仕様になるかもhttps://github.com/tc39/proposal-temporal
WEB の自重
まとめ
- ブラウザは追加仕様を受け入れることでどんどん肥大化している
- ブラウザの多様性はあるが、ブラウザエンジンの多様性が減っている
- レイヤを下げ、責務をアプリに移すことでブラウザの仕様を小さくしていけるのではないだろうか
https://mozilla.github.io/standards-positions/
GraphQLを用いたECサイトにおけるパフォーマンス改善
まとめ
- 継続的な観測を行うことでパフォーマンスを改善した
- パフォーマンス改善のアプローチをフロントエンド、サーバサイド、GraphQLの３つに分けて説明した
- GraphQLのデメリットをカバーするポイントについて説明した
資料
マイクロフロントエンドについての話
マイクロフロントエンドについて雑に話してきました
https://speakerdeck.com/nobuhikosawai/the-theory-and-practice-of-micro-frontends
Q.ログに関して
A.統合レイヤーにイベント送信したほうが責務が統一されて良さそう
Q.バンドルサイズ調整の事例
A.toBのシステムなのである程度諦めている。
マイクロフロントエンドアーキテクチャは開発スピードとアプリケーションの速度はトレードオフだと思う
thoughtworksの資料があるのでそれを参考にすると良さそう（ベストプラクティスかは怪しい,資料見つけられず）
JavaScriptのままでTypeScriptを始める
まとめ
- JavaScriptに決まった形式でコメントを書いておくとTypeScriptの型チェック、サジェストができる
https://www.typescriptlang.org/docs/handbook/compiler-options.html
資料
https://speakerdeck.com/ginpei/start-typescript-leaving-javascript-as-js
Your Benchmark May Not Guide a Real Application Performance
まとめ
- アプリケーションに沿ったパフォーマンス計測指標を見つけよう
- LightHouse出でてくる指標は一般的な静的なサイト向け
- パフォーマンス指標を見つけるにはドメイン知識とユースケースの理解が必要
資料
https://speakerdeck.com/tetsuharuohzeki/your-benchmark-may-not-guide-real-application-performance
Recruit Speed Hackathon（ワークショップ）
まとめ
- Lighthouseで100点出せた
- Lighthouseはv6でスコアの項目と重みが変わる予定
- 40％のサイトは改善後6ヶ月で性能が戻ってしまう→継続的な計測・改善が必要
- パフォーマンスハッカソンの良さ→Biz要件（制約）を一旦無視して考える事ができる
資料
- パフォーマンスの重要性について：https://www.awwwards.org/brainfood-mobile-performance-vol3.pdf
- Webのページサイズについてのレポート：https://httparchive.org/
- パフォーマンスの重要性について：https://web.dev/why-speed-matters/
- サイトのパフォーマンスとは：https://web.dev/what-is-speed/
- 計測ツールの種類と違いについて：https://web.dev/how-to-measure-speed/
- Reactの改善例：https://web.dev/five-ways-airshift-improved-their-react-app/
リクルートのパフォーマンス改善について
ワークショップが終わったあと講師の https://twitter.com/maxmellon_9039 さんにインタビューしてきました
Q.パフォーマンスバジェットで読み込みにかかる時間が3秒とのことだったが妥当性は？
A.Googleが提唱している資料から決めた
Q.パフォーマンスバジェットはいつ決めた？
A.機能を全部入れてから。目標値があるわけではなく、これ以上悪くならないように意識する目的。
Q.Real User Monitoringどうやってる？
A.独自基盤を作っている
reduxのアクションの間の時間を記録
CPUの負荷が低いときにLambdaでデータを送信する
ElasticSearch,Kibanaで可視化
一般的な指標では足りなかったので自分たちで改善指標を決めた
持ち帰ったアクション
- 独自のパフォーマンス指標を４つほど考えてみた（ブログでは書けないので内容は省略）
