Railsでプロジェクトを組むと、JavaScriptやCSSの管理などもRailsに含まれたモジュールが行うようになりますが、デフォルトの設定がちょっと気になるもので、そのままレールに乗るべきなのか迷うものとなっていました。
#Rails4でのデフォルト設定
Sprockets
SprocketsはJS/CSSのコンパイル、依存管理などを行うツールです。それ自体はもちろん有用なのですが、デフォルトの設定で
//=require_tree .
というように、自分で用意したJavaScriptをすべて読み込むような動作となっていました。
Turbolinks
Turbolinksは、Rails 4から標準で読み込まれるようになったgemで、<a>タグのリンクを乗っ取って、CSSやJavaScriptが同じなら、<body>だけを差し替えることでHTML以外の読み込みをすっ飛ばして高速化する、というツールです。この高速化が全力を発揮するには、すべてのページでCSSやJavaScriptを揃える必要があります。
デフォルト設定の利害得失
このようなデフォルト設定を考えた時に、メリット・デメリットの双方があります。
書きやすさ vs 書きにくさ
どんなファイルを作っても読み込んでくれるということで、単位ごとにファイルに切り出して、見通しの良いコードを書くこともできるかもしれません。ただ、逆に言えば全ページで読み込まれてしまうので、JavaScriptにしてもCSSにしても、必要以上の場所に当たらないように気をつけてコードを書かないといけません。
遷移時間 vs ファーストビュー
Turbolinksが効くことで、サイト内のページ遷移速度は最高となりますが、サイトに入った際にすべてのJS・CSSを読み込むので、ファーストビューの表示には悪影響となります。ファーストビュー速度に注力したい場合は気をつけたほうがいいかもしれません。
TurbolinksとJavaScript
Turbolinksを有効にした状態でページ遷移が起きると、内部的な動きは通常と大きく違ったものとなります。JavaScriptを書く場合には、実行されない場合や多重実行されることがあるので、注意が必要です。
ケース・スタディ
大きくデザインが違うページの場合
ユーザー向け画面と管理画面など、レイアウトから取り替えるほどにデザイン・利用者が大きく違うページがある場合、それはアセットファイルを分けたほうがいいでしょう。無関係な2つの画面向けのファイルを連結することは、メリットよりデメリットが多いですし、両者の間でほぼ遷移しないならTurbolinksの悪影響もありません。
モバイルサイトの場合
モバイルサイトでは、最初に読み込むデータ量がファーストビューの速度に大きく効いてきます。自動で読み込みするのは最小限として、あとは遅延ロードで補うのが理想形ではあります。
管理画面の場合
管理画面では1人あたりページビューが多く、またファーストビューの速度がクリティカルとなる状況でもありませんので、デフォルト設定が最も威力を発揮すると感じました。ただ、バリデーションや入力補助でJavaScriptが増えがちなので、うまくTurbolinksと整合させる必要はあるでしょう。
#まとめ
Railsはシステムについてあらかじめレールを引いていてくれていますが、それは必ずしもあらゆる場合に最適だとは限りません。どのようなレールが敷かれているかを知った上で、時には意図的に分岐することも必要でしょう（もちろんそれは、レールに乗れないのとか脱線するのとはまた違った話です）。
妄想
最初は必要最低限のアセットを読み込み→ページを人間が見ている間にアセットを遅延ロード→Turbolinksで遷移する頃には揃っている、なんてようにすれば、ファーストビューと遷移速度を両立できそうだけど…うまく作れるかな？