はてなブックマーク

"module"フィールド対応 パッケージはBundleを配布しないで重複した依存ライブラリは削減できました。 Tree Shaking webpack、rollup.js、ParcelといったBundlerではTree shakingと呼ばれる不要なコードを削除する仕組みを実装しています。 Tree Shaking Reduce JavaScript Payloads with Tree Shaking | Web Fundamentals | Google Developers Tree Shakingはモジュール間の構造を静的に解析して（副作用がない）不要なコードを削除する手法です。 Tree Shakingを行うには、モジュール間の依存関係を静的に解析できるようにしなければなりません。 CommonJSで広く使われているrequire()とmodule.exportsでのモジュール

パッケージはBundleを配布しない ニコニコ生放送 PCのHTML5プレイヤーは、基本的にはTypeScriptで書かれていてビルドにはwebpack + tsloaderという構造になっています。 webpackでビルドされているのでWebpack Bundle Analyzerを使い、ビルドしたパッケージの依存をビジュアライズして調査しました。 Webpack Bundle Analyzer 実際の改善前のbundleしたファイル構造は次のような形でした。 @nicoliveから始まるものは社内のnpmレジストリに公開されている社内モジュールです。 この社内モジュールがlib/index.jsという大きな1つファイルしか持っていないことがわかります。 これは、各パッケージがbundle済みのファイルをlib/index.jsとして配布するようになっていたためです。また、そのbundl

計測 ページロードのパフォーマンスを計測については、すでに多くのツールやサービスが存在します。 以下はパフォーマンス計測を行えるサービスの例です。 WebPagetest（無料） SpeedCurve（有料） Calibre（有料） New Relic Synthetics（有料） CatchPoint（有料） 今回の対象のサイトはログインが必須であったことと、とりあえずないよりはあったほうがいいという考えであったため、 手軽に使えるWebPagetestで計測を行うことにしました。 （環境によって左右されにくいファイルサイズをメインとしてのも理由の1つです） WebPagetest WebPagetestはOSSとして公開されていてプライベートインスタンスを立てることもできます。 また、ホスティング版では制限はありますが、API経由でパフォーマンス計測を行いその結果を取得できます。 しか

パフォーマンスの計測の仕方 計測できないなら安易に直さない パフォーマンスの計測の仕方はさまざまです。 計測方法はボトルネックとなる部分（ネットワークやレンダリングといった箇所）によって異なります。 計測方法も大事ですが、計測する環境も重要です。 スロットリング 開発に使うようなマシンはハイスペックです。 パフォーマンスの計測を行う際は、必ずCPUスロットリングなどのスロットリングを行った状態で一度計測するべきです。 CPUスロットリングを行う 6x 6倍遅い状態 ネットワークスロットリングを行う 実際に利用した設定 この視聴中のパフォーマンス改善では次のような設定を利用して計測しています。 ネットワークスロットリングについてはランタイムではあまり関係ないものが多かったため特に設定していませんでした。 値の計測: Chrome CPUスロットリング: 6x ネットワークスロットリング: な

Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間