By default, all internal links will be funneled through Turbolinks, but you can opt out by marking links with data-no-turbolink.
How much faster is it really?
In any case, the benefit ranges from twice as fast on apps with little JS/CSS, to three times as fast in apps with lots of it. Of course, your mileage may vary, be dependent on your browser version, the moon cycle, and all other factors affecting performance testing. But at least it's a yardstick.
No jQuery or any other framework
Turbolinks is designed to be as light-weight as possible (so you won't think twice about using it even for mobile stuff). It does not require jQuery or any other framework to work. But it works great with jQuery or Prototype or whatever else have you.
Since pages will change without a full reload with Turbolinks, you can't by default rely on
page:fetch...starting to fetch the target page.
page:load...fetched page is being retrieved fresh from the server.
page:restore...fetched page is being retrieved from the 10-slot client-side cache.
page:change...page has changed to the newly fetched version.
So if you wanted to have a client-side spinner, you could listen for
page:fetch to start it and
page:change to stop it. If you have DOM transformation that are not idempotent (the best way), you can hook them to happen only on
page:load instead of
page:change (as that would run them again on the cached pages).
Triggering a Turbolinks visit manually
You can use
Turbolinks.visit(path) to go to a URL through Turbolinks.
Available only for pushState browsers
Like pjax, this naturally only works with browsers capable of pushState. But of course we fall back gracefully to full page reloads for browsers that do not support it.
gem 'turbolinks'to your Gemfile.
- Restart your server and you're now using turbolinks!
Work left to do
- CSS/JS asset change detection and reload
- Add proper unit tests