Short answer: to show a live “visitors currently online” count, install a lightweight online-counter plugin such as WP-Online or use a multi-purpose widget tool like MyStickyElements, then drop its block or widget where you want the number to appear. The catch is that every accurate live counter has to record each visitor as they arrive, and on a busy site that write happens on every pageview – which adds load and quietly breaks page caching. If you only need the number for yourself, skip the plugin entirely and read it from Google Analytics Realtime or a self-hosted analytics tool, which counts visitors without touching your database on every request.
This guide covers the plugins that display a live count, exactly why they slow a site down, how to limit the damage if you still want a public counter, and the analytics alternatives that give you the same number without the performance cost.
Decide first: who is the number for?#
Before installing anything, answer one question – who needs to see the count?
- Visitors (social proof). You want “47 people are reading this right now” displayed on the page to build trust or urgency. This needs a front-end counter, and that is where the performance cost lives.
- Just you (curiosity or capacity planning). You want to know how many people are on the site right now, but no visitor ever needs to see it. This does not need a plugin at all – an analytics dashboard already has the number.
Most people who search for this want the first one and assume a plugin is the only option. It usually is the wrong first instinct, because the “social proof” use case is exactly the one that costs the most. Decide which camp you are in, then pick the matching path below.
The plugins that show a live count#
If you genuinely need a visible, public counter, these are the common options.
WP-Online and similar online-counter plugins#
Small single-purpose plugins (WP-Online, “Visitors Online”, “WP Users Online” and several near-identical clones) do one thing: track which sessions have been active in the last few minutes and display the total. You install the plugin, add its shortcode, block, or widget, and a number appears. Setup takes a couple of minutes.
How they work under the hood matters, because it explains the performance cost later: on each request the plugin writes a timestamped row (an IP or session token plus “last seen” time) to the database, then counts how many of those rows fall inside a short window – usually three to five minutes. Anyone seen inside that window is “online.”
To place the count, most of these plugins give you a shortcode like
[wp_online]
that you can paste into a Custom HTML or shortcode block, or a widget you can drop into a sidebar or footer widget area.
MyStickyElements and floating-bar tools#
MyStickyElements is a floating contact/social bar that includes a live-visitors counter as one of its widgets. It is heavier than a single-purpose counter because it loads a whole interactive bar, but if you already want a floating call-to-action element, the counter comes along for free rather than as a second plugin. Configuration is done in the plugin’s own dashboard rather than with a shortcode, and the counter renders inside the floating element.
A note on "fake" counters#
Some plugins offer a counter that is not real at all – it shows a random or steadily climbing number to fake social proof. These have zero database cost because they count nothing, but they also tell your visitors nothing true, and a sharp-eyed user who refreshes and watches the number behave impossibly will trust your site less, not more. If you use one, know that you are displaying decoration, not data.
Why live counters slow a site down#
This is the part the plugin listings rarely explain, and it is the single most important thing to understand before you ship a public counter.
A static WordPress page can be cached. The first visitor generates the HTML, your host or caching plugin stores it, and every visitor after that gets the stored copy without WordPress, PHP, or the database doing any work. That is what makes a cached page load in tens of milliseconds instead of hundreds. The mechanics of those layers are covered in how to clear the WordPress cache: every layer explained.
A live online counter fights that model directly, for two reasons:
- It writes on every pageview. To count you as online, the plugin has to record that you arrived. That is a database write per request. Reads scale comfortably; writes do not – they lock rows, they cannot be served from a read cache, and on a site getting thousands of views an hour they pile up into real database load. The counter “makes a write per pageview” is not a minor footnote; it is the whole cost.
- It makes the page uncacheable, or forces it dynamic. A number that changes every few seconds cannot sit inside a fully cached HTML page, because the cached copy would freeze the count. So either the plugin loads the count over a separate request (an extra round trip on every page, often polling every few seconds to keep it “live”), or it marks the whole page as dynamic and skips the page cache entirely – which means every visitor now pays the full PHP-and-database cost that caching was supposed to eliminate.
Either way, the counter trades your fastest, cheapest delivery path for a constantly-updating number. On a small site with light traffic you may never notice. On the kind of site where a “47 people online” badge is worth showing – one with enough traffic for the number to be impressive – that is precisely where the write load and the lost caching hurt most. If your site is already feeling sluggish, a live counter is one of the things worth ruling out; the broader hunt is in why is my WordPress site so slow? A diagnostic guide.
If you still want a public counter, limit the damage#
A visible counter is a legitimate choice. If you want one, these steps keep it from dragging the whole site down:
- Load it asynchronously, not inline. Prefer a counter that fetches the number over a small background request (AJAX or the REST API) and leaves the rest of the page fully cacheable. Then only the counter is dynamic, not the entire page.
- Widen the polling interval. A counter that refreshes every two seconds writes and reads far more than one that refreshes every thirty or sixty. Visitors do not need second-by-second accuracy on a “people online” badge. Pick the longest interval that still feels live.
- Cap the tracking window sensibly. A three-to-five-minute “online” window is standard. A longer window inflates the number; a shorter one writes and recounts more often. Three to five minutes is the right balance.
- Watch the tracking table size. Some of these plugins log every visit forever and never prune old rows, so the tracking table grows without bound and slowly bloats the database. Confirm the plugin clears rows outside the online window, and if it does not, look for one that does.
- Run only one. Two counters means double the writes for the same number. Pick one and delete the rest. Leftover, deactivated counter plugins still add to the plugin surface you have to keep updated.
- Keep your stack fast underneath it. A counter adds load on top of whatever your site already does, so the rest of the stack needs headroom. The full playbook is in how to speed up WordPress: a complete optimization guide.
The better answer for most sites: read it from analytics#
If the number is for you and not for visitors, you do not need a counter plugin at all. Your analytics already track it without writing to your WordPress database on every request.
Google Analytics Realtime#
If the site runs Google Analytics (GA4), the Realtime report shows users active in the last 30 minutes, which pages they are on, and where they came from – updated continuously. This is the “currently online” number, and it costs your server nothing, because the counting happens on Google’s side from a small tracking script, not in your database. For anyone doing capacity planning or just watching a launch, this is the simplest answer. The only thing it cannot do is display the number to your visitors, which for most people is fine.
Self-hosted and privacy-friendly analytics#
Tools like Matomo (self-hosted), Plausible, or Fathom also show live visitor counts. Self-hosted Matomo keeps the data on your own infrastructure rather than sending it to Google; the lightweight hosted options (Plausible, Fathom) are built around a small script and a privacy-first model. All of them count visitors out of band rather than on every WordPress request, so they avoid the per-pageview write that makes plugin counters expensive. Several of them can also expose the live count over an API if you later decide you do want to surface it on the page – at which point you are back to the “limit the damage” rules above, but from a system designed for counting rather than a bolted-on plugin.
The trade-off is honest: analytics gives you the number cheaply but privately. A front-end plugin shows it to visitors but charges you in writes and lost caching. Choosing between them is really just choosing who the number is for.
Common mistakes#
- Installing a counter on a high-traffic site and then wondering why it got slow. The counter is doing exactly what it was built to do – a write per pageview – and the cost scales with the traffic that made you want the badge in the first place.
- Running two counter plugins at once. Double the writes, same number. Keep one.
- Letting the tracking table grow forever. A plugin that never prunes old rows turns a small counter into a steadily bloating database.
- Treating a fake/random counter as real data. It is page decoration. Do not make capacity decisions from it, and know your visitors may catch the illusion.
- Reaching for a plugin when you only needed the number yourself. GA4 Realtime or a self-hosted analytics dashboard already has it, for free, with no database cost.
- Forgetting the counter when debugging speed. When an otherwise-cached site suddenly serves pages dynamically, an always-live element like an online counter is a prime suspect.
How Hostney handles this#
Hostney does not bundle a built-in visitors-online widget – this is a WordPress and analytics topic, not a hosting feature, and the right tool depends entirely on whether the number is for your visitors or for you. What hosting affects is how much a live counter actually costs you.
On Hostney, every site runs in its own isolated container with its own PHP and database resources, and server-level edge caching serves the static parts of your pages fast. That means if you do run a counter that loads asynchronously and leaves the rest of the page cacheable, the dynamic counter request hits an isolated, modern stack rather than competing for shared resources – and the cached portions of the page keep their speed. It does not erase the per-pageview write cost of a public counter, but it gives that counter room to run without dragging the rest of the site down with it. For sites where the live count exists because traffic is genuinely high, the relevant infrastructure question is covered in WordPress high-availability and high-traffic hosting.
Quick reference#
- A real “visitors online” count needs a write on every pageview – that is the performance cost, and it scales with traffic.
- Live counters also fight page caching: the page either goes dynamic or fetches the count separately on every load.
- If the number is for visitors, use a single lightweight counter, load it asynchronously, widen the polling interval, keep a 3-5 minute window, and make sure old rows get pruned.
- If the number is for you, skip the plugin: Google Analytics Realtime or self-hosted analytics (Matomo, Plausible, Fathom) show the same count with no database cost.
- Never run two counters, and never trust a fake/random counter as data.