LoginSignup
5

More than 5 years have passed since last update.

Sprockets, Turbolinks…あらかじめ敷かれたRail

Last updated at Posted at 2015-05-20

Railsでプロジェクトを組むと、JavaScriptやCSSの管理などもRailsに含まれたモジュールが行うようになりますが、デフォルトの設定がちょっと気になるもので、そのままレールに乗るべきなのか迷うものとなっていました。

Rails4でのデフォルト設定

Sprockets

SprocketsはJS/CSSのコンパイル、依存管理などを行うツールです。それ自体はもちろん有用なのですが、デフォルトの設定で

application.js
    //=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で遷移する頃には揃っている、なんてようにすれば、ファーストビューと遷移速度を両立できそうだけど…うまく作れるかな?

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5