SlimStat on Managed WordPress Hosting

SlimStat runs on your own hosting, so every recorded pageview uses your server in three places: the tracking request, the database row, and the reports that read it later. This page shows where each cost comes from and which setting controls it.

What one pageview writes

In Client mode, the default, the tracker script sends a request when the page loads and usually another when the visitor leaves the page, to record time on page. WordPress handles each request through the Tracking request method set under Settings → General (Admin-AJAX by default). Tracked clicks and downloads send their own requests.

The pageview becomes one row in the stats table (wp_slim_stats with the default prefix). Tracked interactions are stored in wp_slim_events. The database tables reference lists every table.

Retention decides how large the tables grow

The tables grow with traffic until the purge removes old rows. Settings → Maintenance → Retention period is 420 days on a new install, and the purge runs twice a day through WordPress cron. With Archive mode on, old rows move to archive tables, which still take up space.

Data retention and auto-purge explains each choice and includes a query that shows how much space each table uses.

Keep Client mode behind a page cache

Most managed hosts serve cached pages. Server mode records the visit while PHP builds the page, and a cached page never runs PHP, so those visits are missed. Client mode records through the tracker script, so it keeps working behind a full-page cache.

Keep the tracker script out of minification and combination rules, and keep the tracking request itself uncached. Exclude SlimStat from caching and minification has the details.

Async mode for slow reports

Settings → Reports → Async mode is on by default. It splits report loading into several smaller requests, which helps when large date ranges hit memory or time limits. It changes how reports load, not how visits are tracked.

A separate analytics database (Pro)

Pro’s Custom DB settings store analytics in a separate MySQL-compatible database. Turn on External DB, enter the External DB host, External DB name, External DB user and External DB password, then use Check DB connection. Your WordPress site still handles the tracking requests; only the storage moves.

What v6 changed

The v6 development benchmark compared database work on a 150,000-row reference corpus. For the measured weekly chart, row reads fell from 304,454 to 152,227 and sort rows from 212,301 to 106,141. The release notes also report option writes falling from 2.83 to 1.07 per stored pageview, and from 1.75 to 0.07 per refused bot.

These are database operation counts, not page-load timings or a promise about your host. The upgrade guide explains what they measure.

When to ask your host

Tracking requests fail. The browser’s Network panel shows the tracking request blocked or returning an error, or a security layer blocks admin-ajax.php or the REST API. Check the Last tracker message under Settings → Maintenance first, then ask your host to allow the request.
The purge never runs. WordPress cron depends on visits unless the host runs it on a schedule. Ask for a server cron job if purges fall behind.
Database storage is close to your plan’s limit. Run the size query from the retention guide and share the result with your host before changing retention.
You want a separate database. Ask whether your plan allows remote MySQL connections and which host name to use.
Reports hit memory or time limits. Check that Async mode is on, try a shorter date range, then ask about PHP limits.

For missing visits, start with the tracker troubleshooting guide.