Do note that this of course means that you'll have a long-running, persistent session with maintained state. That's what's making it so fast. But it also means that you may have to pay additional care not to leak memory or otherwise bloat that long-running state. That should rarely be a problem unless you're doing something really funky, but you do have to be aware of it. Your memory leaking sins will not be swept away automatically by the cleansing page change any more.
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.
The best way to find out just how fast it is? Try it on your own application. It hardly takes any effort at all.
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:fetchstarting to fetch the target page (only called if loading fresh, not from cache).
page:loadfetched page is being retrieved fresh from the server.
page:restorefetched page is being retrieved from the 10-slot client-side cache.
page:changepage 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).
page:load event is triggered by Turbolinks, and will help to quickly restore functionality of some libraries.
jquery.js but before
//= require jquery.turbolinks
Additional details and configuration options can be found in the jquery.turbolinks README.
Opting out of Turbolinks
By default, all internal HTML links will be funneled through Turbolinks, but you can opt out by marking links or their parent container with
data-no-turbolink. For example, if you mark a div with
data-no-turbolink, then all links inside of that div will be treated as regular links. If you mark the body, every link on that entire page will be treated as regular links.
Note that internal links to files not ending in .html, or having no extension, will automatically be opted out of Turbolinks. So links to /images/panda.gif will just work as expected.
Also, Turbolinks is installed as the last click handler for links. So if you install another handler that calls event.preventDefault(), Turbolinks will not run. This ensures that you can safely use Turbolinks with stuff like
data-confirm from Rails.
Asset change detection
When this happens, you'll technically be requesting the same page twice. Once through Turbolinks to detect that the assets changed, and then again when we do a full redirect to that page.
Evaluating script tags
Triggering a Turbolinks visit manually
You can use
Turbolinks.visit(path) to go to a URL through Turbolinks.
Full speed for pushState browsers, graceful fallback for everything else
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!
Thanks to Chris Wanstrath for his original work on Pjax. Thanks to Sam Stephenson and Josh Peek for their additional work on Pjax and Stacker and their help with getting Turbolinks released. Thanks to David Estes for handling the lion's share of post-release issues and feature requests. And thanks to everyone else who's fixed or reported an issue!