webpack を使った code splitting のベストプラクティスとして，v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました． これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching  |  Web Fundamentals  |  Google Developers でも説明されている通り，「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで，キャッシュ効率をよくすることが主な目的でした． しかし時は流れ，いつしか「ライブラリのコー

タイトルはやや誇張気味ですが，最近某所で differential serving を導入しようとして考えたことのまとめです． なお，differential serving の概念には CSS や画像なども含まれることがありますし，実現方法にも polyfill.io などの外部ソリューションが存在しますが，本稿では JS の bundle を自前でなんとかする場合に絞って議論することをあらかじめお断りしておきます． TL;DR module-nomodule pattern は differential serving を始める一歩としてはよいが，長期的には負債になる可能性がある きちんとやるなら UA sniffing なり feature detection なりで分岐させるべき Differential Serving とは そもそも differential serving と