Railsアプリケーションのturbolinksを有効化する

時短シリーズ　スタート！

自分が開発しているwebサービスの体感速度をあげるべく、以下の修正を加えていきました。
その方法を何回かに分けてまとめてみます。

www.rep-rikkyo.com

時短のためにやったこと

• turbolinksの再活性
• assetをブラウザキャッシュ
• assetのgzip配信
• 画像の圧縮

以上により、毎回レンダリングまで2.5sほどかかっていたサイトが、1sを切るようになりました。

今回はturbolinksの有効化についてです！

速度は大事

ユーザーを引き止め、気持ちよく使ってもらうためにサイトの速度向上は言うまでもなく重要です。

速度が大事

とまでは言いませんが。

速度は大事

だと考えています。

dev.toに憧れて

つい先日、The DEV Communityの速度が早すぎて話題になりました。
Twitterではさまざまな名言が生まれ、あらゆるエンジニアが関心を寄せた出来事でした。

自分もその例にもれず、「速度あげてー」と画策。
まずはdev.toのことを調べてみました。

dev.toの速さ

• PRPL
• CDN

ざっくりいうとこの二つがポイントのようですが、残念ながらパッと実現できるような代物ではなさそう。
最新のweb技術をフルで駆使してアプリケーションレイヤーからインフラまでを大きく変更する必要があります。

しかし参考になる点は多くありました。
まず「PRPL」の一要素である「Pre Cache」です。

これはざっくり言うと、

必要になる次の画面をバックグラウンドで先にロードしておくこと。 リンクがクリックされると、ロードしておいたhtml要素を必要なところにレンダリングする。

ここで気づきました！

Railsにはturbolinksがあったよな・・・

開発初期で盲目的に無効化していましたが、その思想はPre Cacheそのもの！

turbolinksの再活性

turbolinksは嫌われがちです。なぜなら既存のjsがうまく動かなくなったりするから。
盲目的に無効化する人は多いはず。

Gemfileの編集

gem 'turbolinks'

を追記。そして $ bundle install 。

stylesheetとjsの読み込み方を変更

- = stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true
- = javascript_include_tag 'application', 'data-turbolinks-track' => true
+ = stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload'
+ = javascript_include_tag 'application', 'data-turbolinks-track': 'reload'

この 'data-turbolinks-track': 'reload' というのは、turbolinks5による変更です。

qiita.com

にしても、 'data-turbolinks-track' => true になっていたと言うことは、turbolinksは消したけど有効化するコードが残っていたのでしょうか・・・🤔

既存のjsの書き換え

幸いにも今回取り組んだサイトはjsをあまり使っていません。
これを機に。と使ってないjsをちゃんと消したり、使っていても不必要なjsはガンガン消していきました。

jsが動くところ全てを手動チェックしてみましたが、結果的に書き換えをする必要はありませんでした。

効果

以上でturbolinksの有効化が完了しました。

• 遷移が速くなった感
• ブラウザバックは完全にキャッシュから持ってきている感

この 感 というのが肝なのですが、本当に有効化されているのかいまいち分かりません。確かに速くなっている感じはするのですが・・・。
どなたか確認方法を教えてください🙇

まとめ

turbolinksはキャンセリングされがちですが、せっかくあるのだからこれからも使っていきたいです。
速度がユーザーに与える影響は、言語化されづらいですが、きっと大切なんだと思います🙂