Init Reading Position – Remember, Return, Continue

Yes. For logged-in users, scroll position is stored in a dedicated database table, saved separately for each device type (PC, Mobile, Tablet).

Yes. You can enable it for any public post type in the plugin settings page.

No. It only runs a small JS script on enabled single pages and stores data efficiently in a dedicated table with indexed queries.

Yes. When a post is permanently deleted, or a user account is permanently deleted, any reading positions pointing to it are automatically removed in the background — no leftover rows for content or accounts that no longer exist.

Not unless you turn it on. Two housekeeping options are available under Settings → Reading Position, both disabled by default:

• Clean up abandoned progress — removes a single saved position only when it hasn't been touched in a long time (configurable, default 365 days) and progress on it is very low (configurable, default under 10%). A position with high progress is always kept, no matter how old, since the reader may still come back to finish it.
• Clean up inactive accounts — removes all saved positions for an account once none of its reading positions, across every post, have been updated in a long time (configurable, default 730 days).

If your site has a persistent object cache (Redis, Memcached…), enable Buffer writes in object cache under Settings → Reading Position (disabled by default). Every save and clear from readers is then stored in the object cache and queued; a background job (every 5 minutes by default) writes the queue to the database using one multi-row query per batch instead of one query per request. Saving the same post on the same device many times between two runs only results in a single database write. While a position is waiting to be written, it is read straight from the cache, so readers who reload the page always resume from their latest spot. Things to know before turning it on:

• It needs a persistent object cache shared by all of your web servers. Without one, the option has no effect and positions are written directly to the database as usual.
• Positions saved after the last background run can be lost if the object cache is flushed or evicts them before they are written. The settings page shows how many positions are pending and when the last run happened.
• If the background job stops running (for example WP-Cron is disabled with no system cron), the plugin detects it and automatically falls back to writing directly to the database. For busy sites, running WP-Cron from a real system cron job is recommended.
• Turning the option off, or deactivating the plugin, writes any pending positions to the database first.