Don't throw the baby out with the bathwater maybe? Here's a fixed version of your statement:

"The default Turbolinks progress bar that can be removed with one line of CSS gives the impression that things are slow on slow connections."

Turbolinks is not perfect and has some drawbacks, but it also makes things faster in 99% (100%?) cases in my experience for almost 0 development effort.

I haven't tried out Turbolinks yet, however wouldn't the developer implementing Turbolinks make sure they don't have a progress bar along the top for another purpose first?

I think users would understand it is a loading bar and not a reading progress bar if it only appears after a link is clicked.

Also, if Turbolinks is implemented will Firefox on Android still display a second progress bar?

I ask these questions as I'm thinking of using Turbolinks myself and your comment does make me doubt.

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).

I guess that Turbolinks is used by Basecamp 2 and it sucks a lot. Search takes seconds to load for me, without any loading feedback.

Turbolinks is also used by Basecamp 3, I assure you.