Someone opens your installed WordPress PWA on the train, reads for two minutes, then locks the phone and walks into a meeting. Twenty minutes later the app is still “open” in the OS sense, but nobody is there. Background timers keep ticking. A media player you hoped would pause does not. A soft lock screen you planned for sensitive account pages never appears. The session looks active to your product logic even though the human left.
Native apps notice when the user goes idle. Progressify ships Idle Detection (detect user inactivity) as part of its app-like interface, so your WordPress PWA can respond to quiet sessions instead of pretending every open window still has a reader behind it.
Progressify is the DaftPlug PWA plugin. This post is only about Idle Detection: detecting user inactivity in the installed / app-like experience. Not wake lock, not haptics / vibrations, not shake to refresh, not pull to refresh, not dark mode, not the bottom tab bar, not push notifications, not offline sync, not Android or iOS store builds. Those live elsewhere. For adjacent app chrome (system-aware dark mode), keep WordPress PWA dark mode that follows the system nearby.
What Progressify actually ships here
Stay inside the real feature set:
- Idle Detection listed on the product feature grid as detect user inactivity
- Part of Progressify’s app-like interface family alongside wake lock, haptics, pull to refresh, and related UI controls
- Meant for the installed / app-like experience where the site should behave more like a native shell than a forgotten browser tab
- Theme-agnostic layering: Progressify sits over the themes and plugins you already run
- A settings-level capability you enable from Progressify rather than inventing your own idle timer in the theme
This post does not invent specific idle thresholds, exact event names, browser Idle Detection API promises, or claims that Progressify exposes every native platform idle signal. The product promise is detect user inactivity as a Progressify capability for app-like WordPress experiences. Your own product rules (what happens after idle) still belong to you.
Why detecting inactivity matters on a WordPress PWA
Installed apps inherit session expectations. When someone adds your site to the home screen, they stop thinking “tab I forgot” and start thinking “app I left open.” Apps that ignore idle state feel careless: video keeps playing in a bag, dashboards stay unlocked on a shared tablet, or “live” widgets burn battery for nobody.
Standalone removes the browser’s soft boundaries. In a normal browser tab, people often close the tab or switch away with visible chrome. In standalone PWA mode the chrome is gone. Inactivity becomes your problem to notice, not the browser chrome’s.
Membership, WooCommerce, and content apps all care differently. A membership library may want a soft re-auth after quiet time. A store may want to pause aggressive cart upsells when nobody is browsing. A long-form reader may want to pause autoplay. Idle Detection is the shared signal. What you do with it is still your product decision.
It completes the app-like UI story without mixing features. Progressify groups Idle Detection with wake lock, haptics, and related interface tools. This post is only inactivity detection. Treat wake lock (keep the screen awake) as the opposite problem, and treat haptics as feedback, not idle sensing.
You avoid a fragile custom timer. Hand-rolled inactivity scripts in the theme fight page builders, conflict with caching, and break when someone opens DevTools. Progressify’s Idle Detection is meant to live in the PWA UI stack instead of another snippet in footer.php.
How to enable Idle Detection in wp-admin
Assume Progressify is installed, HTTPS works, and the PWA already installs (manifest, icons, service worker, display mode).
1. Confirm you are testing the app-like experience
Idle Detection matters most after install, when the site launches without browser chrome. Smoke-test Add to Home Screen on a phone before you design complex “after idle” flows. If you only test in a desktop browser tab, you can still enable the feature, but the real UX win shows up on a device people treat as an app.
2. Open Progressify app-like UI / Idle Detection controls
In wp-admin, open Progressify settings and find the app-like interface controls. Enable Idle Detection (detect user inactivity) where Progressify exposes it. Keep platform support aligned with where you already allow other Progressify chrome: phones, installed apps, or both.
Do not turn on wake lock, haptics, pull to refresh, and Idle Detection in the same panicked pass. Ship the idle signal first. Add motion and feedback after you know inactivity is detected the way you expect.
3. Decide what “idle” should unlock for your product
Progressify detects inactivity. You still decide the response:
- Soft lock for account, member, or checkout-adjacent screens
- Pause autoplay media or background refresh that only makes sense with a human present
- Quiet analytics or live widgets that burn battery for empty sessions
- A gentle “still there?” prompt on long-running tools or editors
- Nothing visible yet, only logging, while you learn how often people go idle on your site
Start with one response. Bundling five idle reactions makes failures hard to attribute.
4. Pair with related UI intentionally, do not conflate them
Wake lock keeps the screen awake for active use (recipes, presentations, long reads). Idle Detection notices when that active use stopped. They are neighbors on the product page and opposites in intent. Enable wake lock only where continuous attention is the point. Enable Idle Detection where absence of attention should change behavior.
Dark mode, tab bar, skeletons, and toasts solve color, wayfinding, loading, and feedback. None of them detect inactivity. Leave them alone during this pass unless they are already stable.
5. Test on a real phone you hold
- Install the PWA and open a typical deep page (article, product, account).
- Interact briefly so the session is clearly active.
- Stop touching the device and leave it open without locking the OS yet.
- Confirm your chosen idle response fires when Progressify detects inactivity.
- Touch again and confirm the experience returns to an active state without a broken shell.
- Repeat once with the phone locked by the OS so you understand the difference between OS lock and Progressify idle awareness.
If a custom theme script also watches mouse and keyboard events, disable or reconcile it. Two idle systems fighting each other create flicker and false positives.
6. Keep sensitive flows honest
Login walls, member libraries, and checkout should be the first places you validate. Idle Detection is not a security audit by itself. It is a product signal. Pair it with WordPress auth, HTTPS, and your existing session policies. Do not treat “we detected idle” as a substitute for proper logout or nonce handling.
What good looks like
- Installed PWA can detect user inactivity as a Progressify Idle Detection capability.
- Your product has one clear response to idle (pause, soft lock, quiet refresh, or measure-only).
- Active sessions still feel snappy. Idle handling does not stutter navigation while people are reading.
- Wake lock, haptics, pull to refresh, and dark mode were not required for this win.
- You did not invent undocumented threshold APIs or claim Progressify implements every native Idle Detection platform detail.
- A teammate can open the installed app, leave it alone, and recognize the idle behavior you documented.
- Sensitive screens were tested on a real phone, not only in a desktop browser tab.
If DevTools looks perfect but a real device never seems idle because a background video or live chat keeps “activity” alive, trust the device. Fix the noisy scripts before blaming Idle Detection.
Pitfalls (the ones that bite)
Conflating Idle Detection with wake lock. One notices quiet users. The other fights screen sleep during active use. Enabling both without a product story creates contradictions (screen stays awake while you also treat the user as gone).
Shipping five idle reactions at once. Soft lock plus pause media plus toast plus analytics pause plus a full reload is how you create support tickets. One reaction per release.
Testing only in a browser tab. Idle expectations differ in standalone. Validate on an installed PWA.
Assuming Progressify invents your security policy. Detecting inactivity is not multi-factor auth. Keep WordPress sessions, cookies, and role checks intact.
Fighting a theme idle script. Duplicate timers cause double prompts. Pick Progressify or the theme script, not both.
Ignoring media and chat widgets. Players and live chat can keep a page “busy” in ways that confuse naive idle logic. Spot-check those templates.
Bundling every app-like UI toggle. Turning on haptics, skeletons, tab bar, and Idle Detection together makes failures hard to attribute. Enable Idle Detection, verify, then add the next piece.
Promising exact millisecond thresholds in marketing copy. Stay at product level: detect user inactivity. Configure and verify on your stack instead of inventing API details the product page does not list.
Practical checklist before you call it done
- Confirm the PWA installs and launches (ideally standalone) on a real phone.
- Enable Progressify Idle Detection under app-like interface controls.
- Choose one product response to inactivity and document it for the team.
- Test an article, a shop or pricing page, and an account or member URL.
- Confirm active use still feels normal after idle handling returns.
- Leave wake lock, haptics, pull to refresh, dark mode, and tab bar for separate passes if they are not already stable.
- Remove or reconcile any custom theme idle timer that duplicates the signal.
- Ask one teammate to leave the installed app alone for a few minutes and report what they saw.
- Note which templates include autoplay or live chat so future audits stay honest.
- Re-test after the next theme or page-builder update. Inline scripts regress.
Takeaway
A WordPress PWA that installs cleanly still fails the app test if it treats every open session as an attentive user. People lock phones, walk away, and come back later. Native apps notice. Your installed site should too. The fix is not another fragile timer in the theme. It is Progressify Idle Detection: detect user inactivity as part of the app-like interface.
Progressify adds Idle Detection alongside wake lock, haptics, pull to refresh, and the rest of the app-like UI family, without asking you to rebuild navigation or ship a custom React shell. Pair it with one clear product response. Test on a phone you actually hold. Keep other UI features as separate enablement work.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when the installed app should notice quiet sessions instead of pretending someone is still there.
Enable Idle Detection. Install once. When inactivity is a first-class signal instead of an afterthought, the PWA finally behaves like it belongs on the home screen.