Quick answer: the fastest way to add a reading time progress bar in Gutenberg is a plugin that hooks into the block editor’s post rendering, so you don’t have to touch a single line of code. Below is the exact setup, step by step, plus a worked example and where things commonly go wrong.
Before you start
You’ll need:
- Admin access to your WordPress dashboard.
- The block editor (Gutenberg) as your default editor, which is the WordPress default since version 5.0.
- Five minutes.
You do not need a page builder, a child theme, or custom CSS knowledge, though we’ll cover optional styling near the end. If your site is still running the Classic Editor plugin, this still works, since the progress bar reads the rendered page rather than the editor interface itself. The only thing that changes is Step 6, where the live editor preview panel won’t appear.
Step 1: Install a reading time plugin
In your dashboard, go to Plugins > Add New Plugin. Search for a plugin that offers both reading time and a progress bar as a single feature set. Look for one described as lightweight or cache-safe, since progress bars run on scroll and a poorly coded one can add lag to every page.
Two things worth checking on the plugin listing page before you install anything: the last updated date, and whether the changelog mentions compatibility with the current WordPress version. A reading time plugin is a small, single-purpose tool, so there’s no reason to accept one that hasn’t been touched in two years when actively maintained alternatives exist.
Click Install Now, then Activate.
Step 2: Open the plugin’s settings
Most reading time plugins add a settings screen, either under Settings in the main sidebar or as a top-level menu item. Open it. Take a moment to scan every tab before changing anything. Some plugins split reading time and progress bar controls onto separate tabs, and it’s easy to toggle one on, assume the whole feature is live, and miss the second half entirely.
Step 3: Turn on the progress bar
Look for a toggle labeled something like “Enable progress bar” or “Show scroll indicator.” Switch it on. You’ll usually get a few options:
- Position: fixed to the top of the browser window is the standard choice, since it stays visible regardless of scroll position.
- Color: pick something that matches your site’s accent color so it doesn’t look like a stray element bolted onto the theme.
- Height: a thin bar, 3 to 5 pixels, reads as intentional. Anything thicker starts competing with your header.
- Z-index or stacking: a few plugins expose this, which matters only if you have a sticky header, since the bar needs to sit above it, not behind it.
Step 4: Turn on the reading time estimate
This is usually a separate toggle on the same screen. Choose where it displays: above the post title, below it, or next to the author byline. Below the title next to the publish date is the most common placement and tends to read naturally without extra design work.
Some plugins also let you set the words-per-minute rate used for the calculation. The default is almost always 200 to 238 words per minute, which is the commonly cited range for adult silent reading. Leave it at the default unless you write for a niche where your readers genuinely read faster or slower than average, such as technical documentation versus casual lifestyle content.
Step 5: Set which content types get it
Most plugins let you restrict the feature to specific post types. For a standard blog, enable it for Posts and leave Pages unchecked, since your About or Contact page doesn’t need a reading time badge.
If you’re running WooCommerce or a custom post type for guides, you can usually enable those individually here too.
Step 6: Check it in the block editor
Open any post in the Gutenberg editor. Some plugins add a sidebar panel showing the calculated reading time for that post as you write, which updates as you add or remove content. If you see that panel, it confirms the plugin is correctly hooked into the editor.
If your plugin doesn’t add an editor panel, that’s fine too. Not all of them do, and it doesn’t affect whether the feature works on the live site.
Step 7: Preview and publish
Click Preview on a longer post, or open a published one in a new tab. Scroll down and confirm the progress bar fills as you move through the content, and that the reading time number near the top matches roughly what you’d expect for the word count.
A worked example
Say you’re publishing a 1,400 word how-to guide. At the default 220 words per minute, that lands at just under 6 and a half minutes, which most plugins round to “6 min read” or “7 min read” depending on how they handle rounding. Publish the post, open it in a new tab, and scroll slowly from top to bottom while watching the bar. At the halfway point of the page, the bar should sit at roughly 50 percent, not 30 or 80 percent.
If the bar reaches 100 percent long before you hit the bottom of the article, the plugin is likely measuring against the visible content area rather than the full page, which can happen when a theme adds a large footer, related-posts block, or comment section after the article body. Check the plugin’s settings for an option to target a specific content container, often labeled something like “Track only post content” versus “Track full page.”
Common issues and quick fixes
The progress bar doesn’t appear at all. Check that the post type toggle in Step 5 actually includes the content type you’re testing on. Also clear any page cache, since a cached version of the page may have been generated before you turned the feature on.
The reading time shows 1 minute for everything. Some plugins calculate word count from the raw block content and can be thrown off by heavy use of custom blocks, embeds, or shortcodes that don’t contain readable text. Test on a plain paragraph-and-heading post to confirm the base calculation works, then investigate specific blocks if the number still looks wrong elsewhere.
The bar looks fine on desktop but jumps on mobile. This is usually a CSS unit issue in the plugin’s stylesheet, using viewport units that behave differently on mobile browsers with dynamic address bars. Try a different bar height or check for a mobile-specific setting.
The bar reaches full width before the article actually ends. As covered in the worked example above, this usually means the tracking target is set to the whole page instead of just the article content. Look for a content-selector setting.
Page speed dropped after activating. A well-built progress bar plugin should add a negligible amount of script, generally a few kilobytes, and shouldn’t load anything render-blocking. If you see a meaningful drop in your PageSpeed score, that’s a sign the plugin is heavier than it needs to be for what is fundamentally a small visual feature.
Optional: matching it to your theme
If your plugin allows custom CSS or a color picker, set the bar color to match your primary button or link color rather than leaving it at a default blue or green. This one small tweak makes the feature look like it was built into your theme rather than added on top of it.
A lightweight option worth trying
ReadyGo Reading Time is a free plugin built specifically to keep this kind of setup fast and cache-safe, with reading time and the progress bar handled in one lightweight package instead of two separate installs. It works directly with the block editor and doesn’t require any code.
FAQ
Does the progress bar slow down my site? A well-built one shouldn’t. The script only needs to track scroll position and update a width value, which is a tiny amount of work for a browser. If you notice a slowdown, check whether the plugin is loading extra assets on every page rather than only where the feature is enabled.
Can I use a progress bar without showing the reading time number? Yes, most plugins let you enable the two features independently. Some sites prefer just the visual bar without the text estimate, especially on longer editorial pieces where the number feels unnecessary.
Will this work with AMP pages? It depends on the plugin. AMP has strict rules about custom JavaScript, so a progress bar built with a standard script may not render on AMP versions of your pages. If AMP matters to your site, check the plugin’s documentation specifically for AMP support before installing.
Does it work with cached pages? Yes, in most cases. The reading time number is usually calculated once and stored, and the progress bar itself runs client-side on scroll, so full-page caching shouldn’t interfere with either feature.
Wrapping up
Adding a reading time progress bar in Gutenberg is a settings-panel job, not a development project. Install a plugin, flip two toggles, pick a color, and you’re done. The steps above, including the worked example, should take less time to run through than it took to read this article.