Stop loading a 400 KB script on pages with no password field
Disable Password Strength Meter removes the password strength library from every page that doesn't actually have a password field, while keeping it exactly where it's needed.
- Removes zxcvbn, its async loader, and the meter UI script.
- Kept on the WooCommerce account and checkout pages.
- Kept on the WordPress password reset screen.
- The largest script on many sites, gone from pages that never needed it.
What does Disable Password Strength Meter do?
When the disable_password_strength_meter module is active, TOWP_Disable_Password_Strength_Meter hooks into wp_enqueue_scripts at priority 99 and dequeues and deregisters three scripts, zxcvbn, zxcvbn-async and password-strength-meter, on every page that doesn't need them. Before removing anything, it checks whether the current page is WooCommerce's My Account page, WooCommerce's checkout page, or WordPress's native password reset screen, detected through the action=rp or action=resetpass query string; on any of those, the scripts are left in place exactly as WordPress would normally load them.
WordPress loads a 400 KB dictionary on pages with no password field
A library built for one narrow moment ends up shipped far wider than that moment ever occurs.
It's enqueued far more broadly than it's used
WordPress ships the password strength meter, and the roughly 400 KB zxcvbn dictionary behind it, on a wide set of front-end pages, most of which have no password field for it to evaluate.
It can end up the largest script on the page
On an otherwise lean, well-optimized page, this one library can quietly become the single heaviest script being downloaded, for a feature that page will never use.
Kept where it's needed, removed everywhere else
The module checks whether a page actually has a password field before deciding whether the library belongs there.
A large script removed from most pages
The roughly 400 KB zxcvbn dictionary and its supporting scripts stop loading on any page without a password field.
Kept exactly where it's needed
WooCommerce's account and checkout pages, and WordPress's password reset screen, still show the meter and its full evaluation exactly as before.
Detected automatically, not configured manually
The module checks the actual page context itself, so there's no list of URLs to maintain as the site changes.
Real context detection, not a static list
Every capability below is present in the supplied PHP class and its settings registration.
Three scripts, one purpose
zxcvbn, zxcvbn-async and password-strength-meter are dequeued and deregistered together, since all three exist to support the same feature.
wp_enqueue_scripts, priority 99
Runs late enough to override any earlier enqueue of these scripts by WordPress core, WooCommerce, or another plugin.
Kept automatically
Detected through is_account_page(), which also covers WooCommerce's lost-password and edit-account sub-views.
Kept for account creation at checkout
Detected through is_checkout(), since checkout can include an optional account-creation field with a password.
Detected via the reset query string
Identifies the native password reset screen through its action=rp or action=resetpass query parameter, even when reached through a redirected front-end page.
Dequeued and deregistered
Scripts are fully deregistered, not just dequeued, so nothing later in the page load can pull them back in by accident.
Where removing the meter helps most
The module supports any site where this one library has become disproportionately heavy.
General front-end performance cleanup
Remove one of the largest scripts many WordPress sites load, on the pages that never had a password field to evaluate.
WooCommerce stores
Keep the full password strength experience exactly where account creation actually happens, while trimming it everywhere else on the store.
Sites optimizing for page weight
Pair it with other unused-script removals for a meaningful cumulative reduction in what most pages download.
A big saving, with nothing lost where it counts
The module combines a genuinely large weight reduction with zero loss of functionality on password pages.
The single biggest saving in this cleanup family
The verified implementation removes genuinely significant weight with a lightweight check of its own.
Roughly 400 KB, removed from most pages
The zxcvbn dictionary alone accounts for the bulk of the weight being removed from pages that don't need it.
A late, deliberate override
Running at priority 99 ensures the removal happens after other enqueue logic, so it reliably overrides rather than racing against it.
A simple page-type check
Determining whether to keep the scripts is a handful of fast conditional checks, not a database query or a remote lookup.
No password protection is ever reduced
The code only touches which pages load an unused script; nothing about password validation is affected.
No reduction in protection where a password is set
Every page context that actually involves setting or changing a password keeps the full strength meter, unaffected by this module.
Administrator-only configuration
Only an administrator with access to TheOneWP settings can enable the module.
A read-only page-type check
The module only reads the current page's context to decide whether to keep or remove the scripts; it doesn't process or store any user input.
No effect on password validation itself
WordPress's own password requirements and validation logic are completely unaffected; only the visual strength meter and its supporting scripts are addressed.
Built around native WordPress and WooCommerce conditionals
The supplied code integrates through APIs present in WordPress and WooCommerce. No compatibility claim beyond the verified implementation is assumed.
is_account_page() and is_checkout()
Uses WooCommerce's own conditional functions to detect the exact pages where a password field can appear.
action=rp and action=resetpass
The two query string values WordPress uses to identify a password reset request, checked directly against the current request.
wp_dequeue_script and wp_deregister_script
The same pair of core functions any theme or plugin would use to remove its own scripts, applied here to the three password-meter scripts.
TheOneWP versus common alternatives
Compare the verified Disable Password Strength Meter implementation with a typical manual-exception snippet.
| Capability | TheOneWP Disable Password Strength Meter | Other common solutions |
|---|---|---|
| Removing the meter from unrelated pages | Detected automatically, no page list to maintain | Usually requires a manual list of exceptions |
| WooCommerce compatibility | Account and checkout pages both detected natively | Often overlooked by a generic front-end cleanup snippet |
| WordPress password reset page | Detected via its own query string, even off wp-login.php | Frequently missed since it isn't a fixed URL |
| Script removal method | Dequeued and deregistered, not just hidden | A partial removal can leave the dictionary still downloading |
| Administration | One toggle, nothing else to configure | Usually the same, when available at all |
Confirm the saving in four steps
Check both an ordinary page and a password-related one to confirm both sides of the behavior.
Enable Disable Password Strength Meter
Activate the module from the TheOneWP settings; there's nothing else to configure.
Check an ordinary page's network requests
Confirm zxcvbn and its related scripts no longer load on a typical post or page.
Check a password-related page
Visit the account, checkout or password reset page to confirm the meter still appears exactly as before.
Leave it on
Since there's no ongoing configuration, the module simply keeps working once enabled.
Low risk, meaningful upside
This is one of the highest-impact, lowest-risk cleanups available for most sites.
Enable it as routine cleanup
This is a low-risk removal with a clearly-defined, automatically-detected set of exceptions.
Verify WooCommerce pages specifically
If the site runs WooCommerce, check both the account page and checkout to confirm the meter still shows where expected.
Don't expect any change to password requirements
This module only affects the visual strength meter and its scripts; WordPress's own password rules are untouched.
No further configuration is needed
Since it's a single toggle, there's nothing to revisit once it's enabled.
Avoid assumptions that aren't quite accurate
The module's actual scope is easy to misjudge, especially around security.
Assuming it weakens password security
The module only removes an unused script from irrelevant pages; every page that actually sets a password keeps the full meter and WordPress's own validation.
Not checking WooCommerce pages after enabling
Since detection depends on WooCommerce's own conditional functions, it's worth confirming the account and checkout pages still show the meter as expected.
Looking for a settings screen that isn't there
Like other single-purpose modules, this one is a toggle by design, with no further configuration screen.
Disable Password Strength Meter FAQ
These answers come directly from the verified class and its settings registration.
What does Disable Password Strength Meter do?
It removes the password strength meter and its roughly 400 KB zxcvbn library from pages that have no password field, while keeping it on pages that do.
Which pages keep the strength meter?
WooCommerce's My Account page, WooCommerce's checkout page, and WordPress's native password reset screen.
Does this weaken password security anywhere?
No. Every page that actually involves setting or changing a password keeps the full meter and WordPress's own password requirements, unchanged.
How much does this actually save?
Roughly 400 KB from the zxcvbn dictionary alone, plus its supporting scripts, on any page that doesn't need them.
Does this work with WooCommerce automatically?
Yes. It uses WooCommerce's own conditional functions to detect the account and checkout pages without any manual configuration.
How does it detect the WordPress password reset page?
By checking for the action=rp or action=resetpass query string WordPress uses to identify that request, even when reached through a redirected front-end page.
Are there any settings beyond turning the module on?
No. It's a single toggle with no additional configuration.
Does this affect the WordPress admin area?
No. The module only runs through wp_enqueue_scripts, which is a front-end hook.
What happens if a custom page also has a password field?
The module only recognizes the specific WooCommerce and WordPress contexts it checks for; a custom password field elsewhere would need its own handling.
Who can turn this module on?
Only an administrator with access to the TheOneWP settings screen.
Stop shipping a 400 KB library to pages with no password field.Keep it exactly where it's actually used.
Use Disable Password Strength Meter to remove zxcvbn from irrelevant pages, while keeping it fully intact on account, checkout and password reset pages.