I've used turbolinks in production and it is great. The progress bar is clunky, but it is optional, and not needed anyway if your pages render in a reasonable amount of time (100ms to 200ms is "instant" to most people). I can't really fathom how the parent to your post saw a slowdown using turbolinks - because the server doesn't know the difference, and the client does less work.

Turbolinks is often a terrible user experience. The user doesn't measure page load in seconds, but in the perceived load in seconds. Turbolinks on slow connections feels painful, including on big sites with fast servers, like YouTube and Github.

Can you define what do you mean by slow connection?

I often work at cafes. Sometimes the connections are slow. I sometimes middle-click the links open (new tab) to avoid having to wait for turbolinks.

You know you'll wait the same amount of time, right?

My comment above mentions that. It's about perceived page load time. There are small tricks that sites do to make UIs appear faster, even if they aren't really faster. Turbolinks has the opposite effect, making the loading appear to be worse on bad connections or when there are other rendering problems.

I doubt that people think much when they implement Turbolinks. It's built into rails by default so you have to go out of your way to disable it (--skip-turbolinks).

I think that a loading bar across the top of a web page shouldn't have multiple meanings. For consistent signaling to the user about what the browser is doing, the browser should take care of telling the user what action is being performed (loading).