Do we need Turbo Drive in 2025?

The other week I was trying something in a new Rails app and noticed the page transitions were very smooth - but I had turned off Turbo.

I thought I needed Turbo Drive for smooth navigation, but as I switched it on and off many times, I couldn't see any difference. What was going on?

What is Turbo Drive?

Turbo Drive is a part of Hotwire, the default front-end solution for Ruby on Rails applications.

Hotwire, or HTML over the wire, has three parts: Turbo, Stimulus and Native. And Turbo has four parts:

  1. Turbo Drive
  2. Turbo Frames
  3. Turbo Streams
  4. Turbo Native

Frames are used to divide complex pages into components. Streams make partial page updates. Native is for transitions between web and native iOS and Android apps. And "Turbo Drive accelerates links and form submissions by negating the need for full page reloads".

A short, but loaded sentence. Are full page reloads bad for performance, and are we better off not making them?

How does Turbo Drive work?

Turbo Drive works by:

  • Taking over links and form submissions, turning them into fetch requests.
  • During rendering, Turbo Drive replaces the contents of the <body> element and merges the contents of the <head>.
  • Then, to make it seem like a regular page reload to the user, it changes the browsers URL using the History API.

With this approach the JavaScript window and document objects, and the <html> element, persist from one rendering to the next.

Why use Turbo Drive?

From everything I've read, people use Turbo Drive because it makes their app feel faster. Or, to be more specific, makes it feel like a single-page application (SPA).

This part of the Turbo handbook explains it best:

A key attraction with traditional single-page applications, when compared with the old-school, separate-pages approach, is the speed of navigation. SPAs get a lot of that speed from not constantly tearing down the application process, only to reinitialize it on the very next page.

Turbo Drive aims to give you the "same speed by using the same persistent-process model".

Another, perhaps older claim, is that full page reloads cause a flash of un-styled content that can be jarring. And Turbo Drive avoids this by not making a full page reload.

What are the costs?

To avoid a full page reload Turbo Drive has to do a lot of the work of a browser, such as:

  • Update the browser history.
  • Cache pages.
  • Merge the resources in the <head>.

Also, by avoiding page reloads, you'll find standard browser APIs like DOMContentLoaded don't work. Which, when also combined with custom Turbo events, makes Turbo Drive incompatible with many JavaScript packages.

A recent example of this is the Turbo Mount package, which is needed because DOMContentLoaded isn't available when using Turbo Drive.

Are the benefits real in 2025?

The costs are real - are the benefits?

The problem with the earlier statement about the "old-school, separate-pages approach" is that is doesn't consider where the code runs. Browsers are incredibly powerful and keep getting better.

To decide whether we still need Turbo Drive we'll have a quick look at modern browser caching and rendering, and then do a side-by-side comparison.

Modern browsers have a back/forwards cache known as the bfcache.

The bfcache provides instant back and forward navigation between previously-visited pages. This is possible because the browser stores a snapshot of the entire page in memory, including the JavaScript heap. It even pauses code when you navigate away from a page, and resumes it if you return.

Because of the bfcache there is no advantage to using Turbo Drive for navigating between previously-visited pages.

Caching resources in the <head>

As browsers cache resources in the <head>, effectively there is no difference with or without Turbo Drive. In both cases:

  • The resources in the <head> are loaded on the first page visit.
  • Cached local resources are used for other pages.
  • If a resource changes, a new resource is downloaded and used.

Avoiding flashes of un-styled content

The key difference between Turbo Drive and a full page load is that Turbo Drive maintains the application process between pages. By maintaining the application process, when Turbo Drive loads a new page all the styling is loaded and available, so there will be no un-stlyed content as the new page loads.

Whether or not you use Turbo Drive, there may be a flash of un-styled content on the first page load (this excellent talk explains more about how browsers load pages). With Turbo Drive there won't be any un-styled content on subsequent page visits - but because of the critical rendering path, there won't be any un-styled content with full page loads either.

Before the browser renders anything to the screen it will parse the HTML, CSS and JavaScript. It does this in the five steps of the critical rendering path. Parsing the CSS used for styling occurs in step 2. And as we're focused on visits after the first page load, the CSS in the browser's local cache will be executed before the browser renders pixels to the screen. As a result there will be no flash of un-styled content.

The above may not be true if a CSS file changes after the first page visit as the new file will need to be retrieved over the network, and therefore might not be available when the page is first rendered. But Turbo Drive does a similar thing, retrieving the new CSS file, merging it into the <head>, then applying the new styles.

But does Turbo Drive feel faster?

To find out if Turbo Drive feels faster, we'll do a head-to-head comparison.

Below I've made a simple todo app, and have recorded checking off items, un-checking an item, and adding a new item. One version uses Turbo Drive, the other full page reloads. I've used the lovely shade of lime-green as a background to highlight any flash of un-styled content, which will have the default white background.

My timing isn't perfect, but the actions are at similar times. Can you tell which one is using Turbo Drive?

I've left the answer at the end of the article. But to me there's no difference - they both look and feel the same. Although, there is one subtle giveaway if you watch it again and focus on the browser's nav bar.

Turbo Drive is no longer needed for the web

Browsers are incredibly powerful and keep getting better. Wherever we're recreating their functionality we should ask why, and regularly check if our assumptions are still valid. And to me, Turbo Drive fails that test in 2025.

Maybe it's time to think about whether Turbo Drive, and all it's complexity, should be a part of Turbo. And if it's needed for mobile apps, maybe it belongs in a separate Native library.

* The app on the left was using full page reloads, the app on the right was Turbo Drive.