Quick answer: show a reading time estimate and a scroll progress bar together, not just one. The estimate sets expectations before someone commits to an article. The progress bar keeps them oriented once they’re in it. They solve two different moments in the reading experience, and using only one leaves the other moment unhandled.
Two different jobs, often confused as one
It’s easy to lump “reading time” and “progress bar” into the same mental bucket because they usually show up in the same plugin settings screen. But they answer different questions for a reader.
A reading time estimate answers a before-you-click question: is this worth my next four minutes? It’s a small piece of information that helps someone decide whether to commit, the same way a video’s runtime helps someone decide whether to hit play.
A progress bar answers a during-reading question: how much further do I have to go? It’s not a decision tool, it’s an orientation tool. Long-form content without any visual marker of progress can feel like scrolling into a void, especially on mobile where you can’t glance at a scrollbar the way you can on desktop.
Why pairing them beats using just one
If you only show a reading time estimate, a reader commits based on a number, then loses track of that number the moment they start scrolling. Was this the “6 minute” article? Am I close to done? They have no way to check without scrolling back to the top.
If you only show a progress bar, a reader has no upfront signal at all. They click in cold, with zero sense of whether the piece is a two-minute skim or a fifteen-minute deep read. Some visitors will bounce immediately simply because they can’t gauge the commitment, even if they’d have happily read the whole thing.
Together, the two create a loop: the estimate sets the expectation, the bar confirms the site is tracking toward it. That consistency is quietly reassuring, even if most readers never consciously notice it.
Where this actually moves the needle
- Blogs and news sites with mixed content length, where readers can’t predict a post’s length from the title alone.
- Tutorial and documentation sites, where knowing “this is a 12 minute read” helps someone decide whether to start now or bookmark for later.
- Long-form guides and pillar pages, where a progress bar gives visual proof that scrolling is actually accomplishing something.
Short posts under 300 words don’t need either feature. If everything on your site is a quick news blurb, skip both and save the extra element on the page.
Adding both in WordPress
You don’t need custom development for this. A number of WordPress reading time plugins bundle a progress bar as part of the same feature set, which means one install handles both jobs instead of stacking two separate plugins.
- From your dashboard, go to Plugins > Add New Plugin and search for a reading time plugin that lists a progress bar in its feature list.
- Install and activate it.
- Open its settings page, usually found under Settings or as its own menu item in the sidebar.
- Turn on the reading time display and choose where it appears: above the title, below the title, or inline with the byline.
- Turn on the scroll progress bar and pick its position, typically fixed to the top of the viewport.
- Set which post types it applies to. Most sites only want this on blog posts, not pages like Contact or About.
- Save, then open a published post in a new tab to check both elements render the way you expect on mobile and desktop.
A note on how it should behave technically
A progress bar needs to update on scroll, which means it’s running JavaScript on every scroll event unless it’s coded carefully. Poorly built versions can cause visible jank on longer pages or add unnecessary weight to every page load, even pages where the bar isn’t needed. Look for a plugin that scopes its script to loaded pages only, uses passive scroll listeners, and doesn’t pull in a large external library just to move a colored bar across the top of the screen. This is a simple visual effect and the code behind it should be simple too.
Caching also matters here. Reading time is calculated from word count, so if a plugin recalculates it dynamically on every page load instead of storing it, that’s extra unnecessary work happening on a page that’s supposed to be served from cache. A plugin built to be cache-safe stores the count once and reads it back, rather than rerunning the calculation for every visitor.
What to look for if you want a lightweight option
ReadyGo Reading Time is a free plugin that bundles reading time and a scroll progress bar in one lightweight package, without loading extra libraries or breaking page caching. It’s a reasonable place to start if you want both features without adding noticeable weight to your pages, and being free means there’s no reason not to test it against whatever you’re currently running.
Wrapping up
Reading time and a progress bar aren’t competing features, they’re complementary ones. One helps a reader decide to start, the other helps them see it through. If your site publishes anything longer than a quick update, pairing both is a small change that removes friction at two separate points in the reading journey, and it takes about five minutes to set up.