Someone is following a recipe on your WordPress site with flour on their hands. Mid-step, the phone dims and locks. They unlock, lose their place, and swear at the screen. The same failure hits workout timers, airport queue pages, slide decks in a meeting, and long how-to guides people read while standing. Progressify’s Screen Wake Lock prevents screen dimming so the installed PWA (or the browser tab running as an app-like experience) stays readable until the visitor is done.
Progressify is the DaftPlug PWA plugin. This post stays on Screen Wake Lock / Prevent screen dimming only. Not pull to refresh, not haptic feedback, not shake to refresh, not dark mode, not the bottom tab bar, not push notifications, not offline cache, not autosave forms, not background sync, not the native share button, not Android or iOS store builds, not idle detection, not skeleton loaders, not toast messages, not QR install prompts. Pull to refresh and haptics are siblings on the same app-feel list. A combo post may already cover that cluster elsewhere. This article is wake-lock-only. For navigation feel after you ship wake lock, keep smooth page transitions nearby as a separate enablement.
What Progressify actually ships here
Stay inside the real feature set:
- Screen Wake Lock so the display does not dim while someone is actively using the experience
- Prevent screen dimming as the product-facing promise for recipes, workouts, queues, and long on-screen instructions
- A PWA-layer behavior that sits with Progressify’s broader installable stack, without a separate wake-lock script that ignores your manifest and install path
- Clear separation from pull to refresh, haptic feedback, and shake to refresh, which change gesture and feedback feel, not display timeout
This post does not invent undocumented per-URL allowlists Progressify does not publish, battery override dashboards, OS-level permission managers inside wp-admin, or promises that every browser and OS honors wake lock forever without user or system policy. The product promise is Screen Wake Lock: prevent screen dimming. Stay there. Push, offline page cache, tab bar, dark mode, shake, pull, haptics, share, store builds, transitions, idle, skeletons, toasts, QR, autosave, and background sync are parallel tools, not this article’s job.
Why Screen Wake Lock matters on WordPress
Phones are aggressive about sleep. Battery policies dim the screen after a short idle window. “Idle” to the OS often means “no taps,” even when someone is still reading, cooking, or watching a timer.
Hands-busy use cases are the whole point of a PWA for many sites. Recipe blogs, fitness programs, classroom materials, event agendas, and service-status pages are used while the phone sits on a counter or in a stand. A lock screen mid-task feels broken.
Wake lock is not the same as “keep the tab open forever.” It is a focused display policy for moments when looking away from the keyboard is normal. Visitors still close the tab when they are done. You are not promising infinite battery life.
Sibling app-feel features solve different friction. Pull to refresh and haptics make interaction feel native. Wake lock keeps the pixels on. Shipping all three in one untested hour makes regression hunting painful. Enable wake lock, verify the dimming path, then add gesture features on their own day.
Trust is quiet. People rarely write a review that says “my screen stayed on.” They finish the recipe or the set. The metric you care about is completed tasks and fewer mid-flow unlocks, not applause for the Screen Wake Lock API.
How to enable Screen Wake Lock in wp-admin
Assume Progressify is installed and the site runs over HTTPS in production. Wake lock is a front-end, secure-context story. You will verify on a real phone with the screen timeout you actually use, not only in a desktop customizer preview.
1. Pick the pages where dimming hurts
Walk the real paths: a long recipe, a workout or timer page, a queue or waiting-room view, a multi-step guide people follow without typing. Note where support already hears “my phone locked while I was reading.” That is your first verification set. Do not enable every experimental PWA toggle in the same hour.
2. Open Progressify and find Screen Wake Lock
In wp-admin, open Progressify. Locate Screen Wake Lock (Prevent screen dimming) among the feature list Progressify exposes alongside pull to refresh, haptics, shake to refresh, and the other app-like tools. Turn Screen Wake Lock on for a first pass. Leave pull, haptics, shake, dark mode, tab bar, push, offline cache strategy, autosave forms, background sync, share, transitions, idle, skeletons, toasts, and QR alone until this path is verified.
3. Keep pull to refresh and haptics as siblings, not substitutes
If someone already enabled pull to refresh or haptic feedback, leave those as-is or schedule a separate test. Screen Wake Lock does not replace gesture UX. Mentally label the three:
- Screen Wake Lock: display stays awake so dimming does not interrupt hands-busy reading
- Pull to refresh: a familiar mobile gesture to reload content
- Haptic feedback: tap feedback that feels closer to a native app
Document all three in the runbook so the next teammate does not disable wake lock while debugging a pull-to-refresh layout fight.
4. Smoke-test on a real phone
- Open a public HTTPS URL that people use hands-busy (recipe, guide, or timer page).
- Note your phone’s auto-lock or screen timeout setting (or temporarily set a short timeout so the test is fast).
- With Screen Wake Lock enabled, leave the page on-screen without tapping for longer than that timeout.
- Confirm the screen stays on (or dimming is prevented as Progressify’s wake lock behavior presents it on that browser).
- Navigate away or close the tab and confirm normal sleep behavior returns when you leave the experience.
- Repeat once in the installed PWA window if visitors commonly install the app.
If the screen still locks immediately, confirm Screen Wake Lock is actually enabled, confirm you are on a front-end HTTPS URL the feature applies to, confirm the browser supports the Screen Wake Lock API on that OS version, and confirm a power-saving profile is not overriding site requests. Do not invent undocumented Progressify “force wake on every admin page” toggles that are not on the product page.
5. Smoke-test a second content type
Repeat on a different template: a long-form guide after a recipe, or a status page after a workout view. Wake lock that works on one template and fails on another often points to a conflicting script, a fullscreen video player policy, or a theme that tears down the page in a way that releases the lock. Note the URL and the browser in the runbook.
6. Document the enablement for the next teammate
Write one line in your internal runbook: “Progressify Screen Wake Lock enabled on [date]. Verified on [URLs] with [phone/OS/browser]. Pull to refresh and haptics are separate. Re-test after theme or Progressive Web App redesigns.” Display policies get blamed when a redesign swaps the primary reading template and someone assumes wake lock still attaches.
Who this is for
Recipe, cooking, and DIY publishers whose readers follow steps with dirty or busy hands and cannot unlock every thirty seconds.
Fitness, wellness, and coaching WordPress sites that show timers, circuits, or form cues while the phone sits on the floor or on a rack.
Event, travel, and queue-status pages people stare at while waiting in a line, a gate, or a lobby.
Education and training sites with on-screen instructions used during labs, workshops, or classroom demos.
Agencies shipping PWAs for clients who asked for “app-like” behavior and still lose readers to aggressive screen timeouts.
This is less urgent for short marketing landing pages where the visit is a ten-second skim, or for desktop-only admin tools where the user is typing constantly. Even then, Screen Wake Lock is cheap insurance when a later content type introduces hands-busy reading.
What good looks like
- A visitor following a recipe can leave the phone on the counter without the screen locking mid-step.
- Workout or timer pages stay visible for the full set without constant taps to keep the display alive.
- Queue or status pages remain readable while someone waits without interacting.
- Screen Wake Lock is enabled without requiring pull to refresh, haptics, dark mode, QR, or store builds.
- Pull to refresh and haptics remain optional siblings, not confused with wake lock.
- You did not invent battery override dashboards or claim every OS honors wake lock without testing.
- Support stops getting “my phone locked while I was following your guide” for the URLs you verified.
If dimming never changes, confirm Screen Wake Lock is on, confirm a supporting browser on HTTPS, confirm no OS battery saver is blocking site wake locks, and re-test in a clean browser profile in case an extension interferes.
Pitfalls (the ones that bite)
Confusing wake lock with pull to refresh. Wake lock keeps the screen on. Pull reloads content. Debugging one while expecting the other wastes a day.
Enabling every PWA toggle with Screen Wake Lock. If wake lock, tab bar, dark mode, and shake all land together, you cannot tell which change moved completion rate or caused a layout fight. Enable Screen Wake Lock, verify, then add the next piece.
Testing only on desktop. Desktop screen timeouts and mobile OS policies differ. Verify on the phones your audience actually uses.
Assuming wake lock means infinite battery. Be honest in QA notes: wake lock prevents dimming while the feature is active. Visitors and OS power policies still matter. Do not market “never sleeps, ever” if the product does not promise that.
Ignoring fullscreen video and third-party embeds. Some players manage their own keep-awake behavior. Note conflicts instead of blaming Progressify for an embed policy you did not test.
Forgetting to re-test after a theme update. Template wrappers and SPA-like navigations can release locks. Behavior that worked last month can silently stop.
Practical checklist before you call it done
- Confirm Progressify is installed and production URLs are HTTPS.
- List the recipe, workout, queue, or guide URLs where dimming hurts today.
- In Progressify, enable Screen Wake Lock (Prevent screen dimming) only for this pass.
- Leave pull to refresh, haptics, shake, dark mode, tab bar, push, offline page cache, autosave, background sync, share, store builds, transitions, idle, skeletons, toasts, and QR alone if they are not already stable.
- Treat pull to refresh and haptics as siblings: mention them in the runbook, do not confuse them with wake lock.
- On a real phone, open a hands-busy page, wait past the normal screen timeout, confirm the display stays awake.
- Leave the page and confirm normal dimming returns.
- Repeat on a second template and, if relevant, in the installed PWA window.
- Spot-check on a second device or OS when you can.
- Re-test after the next theme or PWA redesign.
- Write the enablement date and verified URLs in the team runbook.
- Only then consider enabling other Progressify features that change front-end UX.
Takeaway
People cook, train, and wait with the phone facing up. Screens that dim mid-task punish that reality. Progressify’s Screen Wake Lock prevents screen dimming so WordPress PWA experiences stay readable through recipes, workouts, queues, and long guides. It is not pull to refresh, not haptics, and not an install prompt. It is the quiet display fix for hands-busy use.
Progressify handles Screen Wake Lock alongside the rest of the PWA stack, without asking you to maintain a third-party wake-lock script that knows nothing about your installable site. Enable it once. Test with a real phone and a real hands-busy URL. Keep sibling PWA features as separate enablement work. For navigation feel after wake lock is stable, use the related smooth page transitions guide when you are ready.
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 screen should stay awake for the tasks your visitors already do.
Turn Screen Wake Lock on. Put the phone down on purpose. When the display is still on at the next step, the PWA finally respects how people actually use the page.