Why WordPress loads a 400 KB password script everywhere

Why WordPress loads a 400 KB password script everywhere sounds like one of those strange performance problems where a website downloads hundreds of kilobytes of JavaScript for a feature that does not even exist on the page.

The script involved is zxcvbn, a password-strength estimation library originally developed by Dropbox.

WordPress ships the library because it powers the familiar password-strength meter used when users create or change passwords.

The surprising part is its size.

The official zxcvbn project documentation describes the bundled library as roughly 400 KB compressed, with much of that weight coming from dictionaries used to detect weak and predictable passwords.

On a password form, that can be useful.

On a blog post, product page, landing page or homepage containing no password field whatsoever, downloading the same library achieves very little.

There is an important distinction, however:

WordPress ships zxcvbn
≠
WordPress core necessarily enqueues zxcvbn on every frontend page

WordPress registers the password-strength scripts as dependencies that themes and plugins can enqueue when needed. WooCommerce, membership plugins, custom themes or other frontend functionality can then cause that dependency chain to appear on public pages.

So when you discover zxcvbn.min.js across large portions of a WordPress site, the correct question is not simply:

Why did WordPress add this?

It is:

Which script requested the password-strength meter,
and does this page actually need it?

This guide explains what zxcvbn does, why it is unusually large, how WordPress loads it, how WooCommerce uses it, why it can unexpectedly appear on frontend pages, how to identify what enqueued it, and how to remove it safely without breaking password forms.

What is zxcvbn?

zxcvbn is a JavaScript password-strength estimator.

Instead of evaluating passwords using only simple rules such as:

at least 8 characters
one uppercase letter
one number
one symbol

it attempts to estimate how difficult a password would actually be to guess.

The library can identify patterns such as:

• common passwords;
• dictionary words;
• names;
• dates;
• repeated sequences;
• keyboard patterns;
• common substitutions;
• predictable combinations.

The official zxcvbn documentation explains that the library uses pattern matching and frequency lists rather than relying exclusively on arbitrary password-composition rules.

Why is zxcvbn so large?

The main reason is not complicated application logic.

It is data.

zxcvbn includes dictionaries and frequency information that help it identify passwords built from predictable words and patterns.

The upstream project describes the bundled minified version as approximately:

~400 KB compressed
~800 KB uncompressed

although the exact transfer size observed on a WordPress site depends on the WordPress version, asset version, server compression and measurement method.

This is much larger than many ordinary frontend utility scripts.

400 KB is substantial for one frontend feature

Consider a relatively lightweight page with:

HTML           30 KB
main CSS       70 KB
theme JS       80 KB
images        250 KB

Adding another approximately:

400 KB

for a password-strength library can materially increase the JavaScript payload.

That becomes especially questionable if the page contains:

zero password fields

Removing unused assets is therefore a legitimate part of WordPress frontend optimization. See How to Remove Unused WordPress Scripts for the broader process.

WordPress includes a password-strength meter

WordPress core registers several scripts involved in password-strength evaluation.

The relevant script handles include:

zxcvbn-async
password-strength-meter

The current WordPress core implementation can be inspected in the official wp_default_scripts() documentation.

WordPress registers:

zxcvbn-async
→ /wp-includes/js/zxcvbn-async.js

and:

password-strength-meter
→ /wp-admin/js/password-strength-meter.js

The password-strength meter has dependencies

The important part of the WordPress registration is the dependency relationship.

Conceptually:

password-strength-meter
        ↓
jquery
        +
zxcvbn-async
        ↓
zxcvbn.min.js

The official WordPress script registry currently registers password-strength-meter with dependencies on jQuery and zxcvbn-async.

This means enqueueing:

password-strength-meter

can result in WordPress loading its supporting dependency chain as well.

WordPress does not need to load every registered script

This distinction is fundamental to understanding WordPress asset loading.

A script can be:

registered
but
not enqueued

Registration tells WordPress:

If somebody needs this script, here is where it is and here are its dependencies.

Enqueuing tells WordPress:

This page actually needs the script.

The official wp_enqueue_script() documentation covers WordPress’s dependency-aware script loading system.

For a deeper explanation of the frontend hook normally used for this work, see wp_enqueue_scripts Explained.

So does WordPress core load zxcvbn on every page?

No, not by itself.

WordPress core registers the password-strength infrastructure, but registration alone does not mean every anonymous frontend visitor downloads it.

The library appears when some code enqueues a script that requires it.

That distinction matters because otherwise troubleshooting tends to begin with the wrong assumption.

The useful model is:

WordPress registers zxcvbn
↓
plugin/theme requests password-strength-meter
↓
dependency resolver sees zxcvbn
↓
browser downloads zxcvbn

Why can zxcvbn appear across the frontend?

There are several possibilities.

• a plugin enqueues the password-strength meter globally;
• a theme enqueues it globally;
• custom code enqueues it without checking the current page;
• a customer-account system uses it;
• a membership or registration plugin uses it;
• WooCommerce requires it on relevant account or checkout contexts;
• another script depends on password-strength-meter.

Before removing anything, identify which of these situations applies to the actual site.

WooCommerce is a common reason the script appears on the frontend

WordPress itself primarily needs password-strength functionality around account-management interfaces.

WooCommerce extends account creation and password management into the public frontend.

This creates legitimate frontend use cases such as:

• customer registration;
• editing an account password;
• lost-password workflows;
• checkout account creation.

If you need the underlying WooCommerce page architecture first, see WooCommerce Account and Checkout Pages, Explained.

How WooCommerce currently decides whether to load it

WooCommerce’s frontend script loader contains conditional logic for the password-strength meter.

The current WooCommerce source loads its own wc-password-strength-meter script only in relevant account and checkout contexts.

Its source explicitly describes the intended use as:

checkout
account login
edit account
lost password

You can inspect the current implementation in WooCommerce’s frontend script loader.

WooCommerce does not intentionally enqueue it on every page

This is another important correction to a common assumption.

Current WooCommerce checks whether the request represents:

Cart
Checkout
My Account

before handling several account-related frontend assets.

The password-strength script receives additional conditions.

Therefore, if a modern WooCommerce site loads zxcvbn on:

homepage
blog articles
ordinary product pages
static landing pages

you should investigate whether another plugin, theme customization or optimization interaction is responsible rather than assuming WooCommerce intentionally loads it globally.

Why Checkout may legitimately need a password-strength meter

WooCommerce can allow customers to create an account while checking out.

Depending on configuration, the checkout can therefore contain a password field.

The flow can be:

customer checks out
↓
creates account
↓
chooses password
↓
password strength evaluated

In that situation, removing the meter globally would disable functionality on a page where it is actually useful.

Why My Account may legitimately need it

The WooCommerce My Account area can include:

• registration;
• password changes;
• password resets.

These are exactly the scenarios for which a password-strength estimator exists.

That is why optimization should usually be contextual:

remove where unused
keep where needed

rather than:

find large file
↓
delete everywhere

WordPress password reset also legitimately needs it

WordPress’s native account-management interface includes functionality for creating and changing passwords.

The current WordPress user-edit interface includes password controls such as:

Set New Password

and a password-strength result area.

The implementation can be inspected directly in the official WordPress core user-edit source.

Password strength is not password authentication

Removing the frontend strength meter does not remove WordPress authentication itself.

These are different responsibilities.

The strength meter:

evaluates password quality
and displays feedback

WordPress authentication:

receives credentials
↓
validates them
↓
authenticates user

If you are reviewing login security more broadly, see WordPress Login Security Layers, Explained.

Password strength is also different from brute-force protection

zxcvbn attempts to help users choose less predictable passwords.

It does not:

• limit login attempts;
• rate-limit authentication;
• hide the login URL;
• implement multi-factor authentication;
• block credential stuffing;
• monitor failed logins.

For those risks, see:

• WordPress Brute-Force Attacks, Explained;
• How to Limit Login Attempts in WordPress;
• How to Monitor WordPress Login Attempts.

A strong password meter does not make a weak authentication system secure

A site could display an excellent password-strength estimator while still allowing:

unlimited login attempts
+
known usernames
+
no rate limiting
+
reused credentials

Likewise, a site could remove the visual password meter from irrelevant pages without weakening the authentication process on those pages because no password is being created there anyway.

Why zxcvbn uses asynchronous loading

WordPress registers:

zxcvbn-async

rather than making every script reference the full dictionary library directly.

The asynchronous loader is designed to load the larger:

zxcvbn.min.js

resource when the password-strength system requires it.

The current implementation is visible in wp_default_scripts().

Why does a password estimator need dictionaries?

Consider these two passwords:

P@ssw0rd123!

vQ7#xP4!mL9@tZ2

A simplistic rules-based test might approve both because they contain:

• uppercase letters;
• lowercase letters;
• numbers;
• symbols.

But the first is based on an extremely predictable word and substitution pattern.

zxcvbn’s dictionary-heavy approach helps distinguish between structural complexity and actual guessability.

That intelligence is useful, but those dictionaries are also the reason the browser payload is substantial.

Is 400 KB always 400 KB over the network?

No.

Several measurements can be confused:

source size
minified size
compressed transfer size
decoded resource size

Chrome DevTools can show different numbers depending on which column or panel you inspect.

Server compression such as Brotli or gzip also changes the transferred number.

The correct conclusion is therefore not:

every visitor always transfers exactly 400000 bytes

but:

zxcvbn is unusually large compared with many frontend utility scripts
and can materially increase page weight

Browser caching changes repeat visits

If the browser successfully caches the library, a visitor may not download the complete resource again for every page.

That reduces repeated network transfer.

However, caching does not make unnecessary loading free.

The browser may still need to:

• discover the asset;
• check cache validity;
• read it from cache;
• parse JavaScript;
• evaluate supporting code;
• retain associated memory.

And first-time visitors still pay the initial transfer cost.

CDN delivery does not make unused JavaScript necessary

A CDN can improve asset delivery.

It cannot change this basic relationship:

unused script
=
unused script

If a page does not require password-strength estimation, delivering that library more efficiently is usually less useful than avoiding the unnecessary request in the first place.

For the wider asset-delivery question, see CDN vs. Self-Hosted Assets in WordPress.

How to check whether zxcvbn is loading

Open the page in your browser and launch Developer Tools.

In Chromium-based browsers:

Developer Tools
→ Network

Reload the page and search for:

zxcvbn

You may see a request resembling:

/wp-includes/js/zxcvbn.min.js

Also search for password-strength-meter

Search the Network panel for:

password-strength-meter

You may encounter WordPress or plugin-specific assets related to the strength meter.

Finding the visible file is only the first step.

The more important question is:

what requested it?

Check the page source and script dependencies

Look for script URLs containing:

zxcvbn
password-strength-meter

Then inspect which plugin or theme scripts are present on the same page.

This can help distinguish:

WordPress core asset
requested by WordPress functionality

from:

WordPress core asset
requested by plugin/theme code

A WordPress core URL does not prove WordPress core enqueued it

This is a common debugging mistake.

If the browser downloads:

/wp-includes/js/zxcvbn.min.js

the file clearly belongs to WordPress core.

But the request may still have been triggered because a plugin called:

wp_enqueue_script( 'password-strength-meter' );

WordPress then resolves the registered dependencies and loads the core files.

Use wp_script_is() while debugging

WordPress provides:

wp_script_is()

to inspect the state of a registered script.

For example:

if ( wp_script_is( 'password-strength-meter', 'enqueued' ) ) {
    // The password strength meter is currently enqueued.
}

The official wp_script_is() documentation describes the available script states.

Inspect the enqueue stack instead of guessing

When performance debugging, do not assume the largest script came from the plugin whose name seems most plausible.

Build an asset inventory.

See How to Remove Unused WordPress Scripts for the broader workflow.

How scripts should normally be loaded in WordPress

Frontend scripts should normally be registered and enqueued through WordPress’s script API.

The standard frontend hook is:

wp_enqueue_scripts

For example:

add_action(
    'wp_enqueue_scripts',
    function () {
        wp_enqueue_script( 'my-script' );
    }
);

The hook is explained in detail in wp_enqueue_scripts Explained, while the official API is documented under wp_enqueue_script().

The problem is often overly broad enqueue logic

Imagine a plugin needs the strength meter only on:

/register/

but uses:

add_action(
    'wp_enqueue_scripts',
    function () {
        wp_enqueue_script( 'password-strength-meter' );
    }
);

That code tells WordPress:

every frontend page needs this

even though the actual requirement is:

registration page needs this

Conditional loading is better

A better design is conceptually:

if current page has password interface
    enqueue password strength meter
else
    do not enqueue it

The exact conditional depends on the site architecture.

It might involve:

• a specific page;
• a shortcode;
• a block;
• WooCommerce conditionals;
• a membership route;
• a custom endpoint.

Do not dequeue it globally without checking the site

This optimization can easily be implemented badly.

A rule such as:

wp_dequeue_script( 'password-strength-meter' );

on every frontend request may remove the meter from legitimate password interfaces.

Potentially affected pages include:

• customer registration;
• WooCommerce account editing;
• checkout account creation;
• password reset;
• membership registration;
• custom account forms.

Removing the wrong dependency can break other scripts

WordPress resolves script dependencies automatically.

If another script explicitly depends on:

password-strength-meter

removing or deregistering the dependency can affect that parent script.

Always test the dependency graph, not just the visible network request.

wp_dequeue_script() and wp_deregister_script() are different

WordPress provides:

wp_dequeue_script()
wp_deregister_script()

wp_dequeue_script() removes a script from the current queue.

wp_deregister_script() removes the registered script definition.

The official documentation covers both wp_dequeue_script() and wp_deregister_script().

Dequeueing late can matter

If a plugin enqueues the password script during:

wp_enqueue_scripts
priority 10

your removal logic must run after that enqueue occurs.

For example:

add_action(
    'wp_enqueue_scripts',
    function () {
        // Conditional removal here.
    },
    99
);

Using a later priority gives earlier enqueue callbacks a chance to finish first.

Do not copy a generic removal snippet without context

The correct rule differs between:

blog
WooCommerce store
membership site
LMS
client portal
registration site

A normal publishing site may have no public password creation form at all.

A WooCommerce store may legitimately need the strength meter on several customer routes.

A membership platform may expose password forms in entirely custom locations.

WooCommerce deserves explicit exceptions

If the site uses WooCommerce, relevant exceptions commonly include:

My Account
Checkout

because those areas can contain password-related functionality.

This is exactly why understanding WooCommerce Account and Checkout Pages, Explained is useful before applying global frontend asset rules.

Password reset deserves an explicit exception too

A password-reset page is one of the few places where the strength estimator directly serves its intended purpose.

Removing it from a homepage can be sensible.

Removing it from the page where a user is choosing a new password defeats the purpose of the optimization.

Custom registration pages require testing

A plugin may implement:

/register/
/signup/
/join/
/create-account/

without using WordPress’s native login or WooCommerce account route.

A cleanup rule that recognizes only native contexts can therefore break custom registration systems.

Always audit the actual site before defining exceptions.

Password-protected posts are unrelated

WordPress supports password-protected posts and pages.

Those forms are conceptually different from user-account passwords.

A post password controls access to specific content.

A user password authenticates a WordPress account.

The presence of a password-protected post does not automatically mean the account password-strength estimator is required.

Does removing zxcvbn improve Core Web Vitals?

Potentially, but do not promise a specific score increase.

Removing unnecessary JavaScript can reduce:

• network transfer;
• JavaScript parsing;
• JavaScript evaluation;
• main-thread work;
• memory usage.

Whether this materially changes a particular Core Web Vital depends on the rest of the page.

A site dominated by several megabytes of images and third-party scripts will not suddenly become fast because one WordPress asset disappears.

Page weight still matters even when Lighthouse barely moves

Optimization should not be reduced to chasing a single Lighthouse number.

If a page downloads:

400 KB of JavaScript

for functionality that cannot possibly be used on that page, removing it is architecturally cleaner even if the synthetic performance score changes only slightly.

The biggest gains come from cumulative cleanup

One unnecessary asset may not destroy performance.

But WordPress websites often accumulate many small or medium inefficiencies:

emoji script
+
legacy jQuery compatibility
+
unused password meter
+
plugin CSS
+
unused widgets
+
third-party trackers
+
page-builder assets

The cumulative result can become significant.

For another example of default frontend cleanup, see Why WordPress Loads an Emoji Script on Every Page.

jQuery can also enter the dependency chain

WordPress currently registers:

password-strength-meter

with jQuery as a dependency.

Therefore, on a page that otherwise has no need for jQuery, loading the password-strength system can potentially contribute to a larger dependency footprint.

This does not mean jQuery itself is inherently a performance problem.

It means dependency chains matter.

Do not remove jQuery because zxcvbn exists

jQuery may be required by:

• themes;
• WooCommerce;
• forms;
• sliders;
• older plugins;
• custom scripts.

Removing dependencies requires a separate audit.

If you are reviewing legacy JavaScript specifically, see What Is jQuery Migrate, and Do You Need It? and Checking Your Site for Legacy jQuery Dependencies.

Should you replace zxcvbn with a smaller library?

Possibly, but that is a different architectural decision.

The first question should be:

Does this page need password-strength estimation at all?

If the answer is no, replacing a 400 KB unused library with a 20 KB unused library is still unnecessary work.

If the answer is yes, then evaluating alternative implementations becomes reasonable.

WooCommerce itself has considered lighter alternatives

WooCommerce development discussions have explicitly acknowledged that WordPress’s zxcvbn implementation is heavy.

For example, a WooCommerce Checkout development issue discussing a password field component noted that WordPress uses zxcvbn but that the library is heavy, and considered lighter alternatives.

This reinforces the underlying tradeoff:

better password estimation
vs.
frontend asset weight

Security and performance are not opposites here

The sensible goal is not:

remove password-strength checking to make site faster

It is:

keep password-strength checking
where passwords are actually created

remove its assets
where no password can be entered

That preserves the useful security guidance while reducing unnecessary frontend weight.

How TheOneWP handles the password-strength scripts

Disable Password Strength Meter in TheOneWP is designed specifically for this problem.

The module removes the password-strength assets from frontend pages where they are not required while preserving them in recognized password-related contexts.

The verified implementation handles:

• zxcvbn;
• zxcvbn-async;
• password-strength-meter.

TheOneWP does not simply remove the scripts everywhere

The module checks whether the current request represents a context where password functionality can actually be needed.

It keeps the scripts on:

• WooCommerce My Account;
• WooCommerce Checkout;
• WordPress native password-reset requests.

On other frontend requests, the relevant password-strength assets are dequeued and deregistered.

WooCommerce detection uses WooCommerce conditionals

The verified module uses:

is_account_page()
is_checkout()

to recognize relevant WooCommerce contexts.

This avoids relying on hardcoded URLs such as:

/my-account/
/checkout/

which can be changed by store administrators.

WordPress password-reset requests are preserved

The module also recognizes native reset requests through WordPress’s password reset actions:

action=rp
action=resetpass

so the strength meter remains available when a user is actually setting a replacement password.

The module runs late in wp_enqueue_scripts

TheOneWP uses:

wp_enqueue_scripts
priority 99

so earlier WordPress, WooCommerce or plugin enqueue operations have already had an opportunity to run.

This is important because attempting removal before another component enqueues the asset would achieve nothing.

TheOneWP feature has one important limitation

Its verified exceptions recognize WordPress’s native password-reset flow and WooCommerce account and checkout contexts.

If another plugin provides a completely custom password form on:

/custom-registration/

that custom context needs to be reviewed separately.

No automatic cleanup system can safely infer every custom application architecture without knowing what the site has added.

Do not confuse this with disabling password security

The module does not disable:

• WordPress authentication;
• password hashing;
• login validation;
• password requirements enforced elsewhere;
• WooCommerce account security.

It changes whether the frontend password-strength JavaScript is loaded on pages that do not need it.

How to audit the password-strength script safely

1. Open the homepage in a logged-out browser.
2. Open Developer Tools.
3. Open the Network panel.
4. Reload the page.
5. Search for zxcvbn.
6. Search for password-strength-meter.
7. Record the transferred and resource sizes.
8. Check whether the page contains any password field.
9. Repeat on representative posts and pages.
10. Repeat on WooCommerce product pages where applicable.
11. Repeat on My Account.
12. Repeat on Checkout.
13. Repeat on password reset.
14. Repeat on custom registration or membership forms.

Build a simple asset matrix

For example:

Page	Password field?	zxcvbn loaded?	Expected?
Homepage	No	Yes	Investigate
Blog post	No	Yes	Investigate
Product page	No	Yes	Investigate
My Account registration	Yes	Yes	Expected
Edit Account	Yes	Yes	Expected
Password reset	Yes	Yes	Expected

If it loads everywhere, identify who enqueues it

Do not stop at:

zxcvbn is present

Determine whether the enqueue comes from:

• the active theme;
• WooCommerce;
• a membership plugin;
• a registration plugin;
• a security plugin;
• custom code;
• another script declaring the strength meter as a dependency.

Temporarily isolate plugins on staging

If the source is unclear, use a staging site and disable components systematically.

For example:

baseline
↓
disable suspected plugin
↓
reload Network panel
↓
zxcvbn disappears?
↓
identify dependency

Do not perform this experiment casually on a live store.

Use WordPress Staging Site Best Practices for a safer environment.

Test logged-in and logged-out states separately

WordPress can enqueue different assets depending on authentication state.

Test:

anonymous visitor
subscriber/customer
administrator

An administrator viewing the frontend may receive assets that anonymous visitors do not.

Clear caches before drawing conclusions

After modifying enqueue behavior, clear the relevant caches.

Depending on the stack, this may include:

• page cache;
• server cache;
• CDN cache;
• browser cache;
• asset optimization cache.

A stale combined JavaScript bundle can otherwise make a removed dependency appear to remain present.

Asset optimization plugins can hide the original source

A performance plugin may combine scripts into a file such as:

/cache/js/bundle-12345.js

In that situation, searching the Network panel for:

zxcvbn.min.js

may no longer reveal a separate request.

You may need to:

• temporarily disable JavaScript combining;
• inspect bundle contents;
• review the plugin’s asset report;
• check the WordPress script queue directly.

Measure before and after

Once the unnecessary script is removed from irrelevant pages, compare:

• number of JavaScript requests;
• transferred JavaScript bytes;
• total resource size;
• main-thread JavaScript work;
• page-load waterfall.

Do not rely only on a performance score.

A useful before-and-after model

Before:

Homepage
↓
jQuery
↓
password-strength-meter
↓
zxcvbn-async
↓
zxcvbn
↓
no password field exists

After:

Homepage
↓
password scripts absent

My Account
↓
password scripts present

Password reset
↓
password scripts present

That is the intended optimization.

Common mistakes when removing the password script

Assuming WordPress core enqueues it everywhere

Core registers the scripts. Another component may be responsible for enqueueing them on the frontend.

Removing zxcvbn without finding the parent dependency

The parent script may continue expecting the library.

Removing the strength meter from password-reset pages

Those pages actually use it.

Breaking WooCommerce registration

WooCommerce customer account workflows can legitimately require password evaluation.

Breaking checkout account creation

A checkout can include account creation depending on store configuration.

Ignoring custom registration forms

Membership and LMS plugins can create their own password contexts.

Checking only while logged in as Administrator

Frontend assets can differ by authentication state.

Looking only at filenames

A WordPress core filename does not tell you which plugin requested it.

Comparing uncompressed size with transferred size

Use consistent measurements.

Assuming browser caching makes unused assets irrelevant

First visits and JavaScript processing still matter.

Removing unrelated dependencies such as jQuery globally

Audit them separately.

Testing directly on production

Account and checkout regressions belong on staging, not in a customer’s shopping session.

Password strength script audit checklist

• Search the Network panel for zxcvbn.
• Search for password-strength-meter.
• Record transferred size and decoded size separately.
• Check whether server compression is enabled.
• Test as a logged-out visitor.
• Test as a logged-in user.
• Test the homepage.
• Test representative posts.
• Test representative pages.
• Test WooCommerce product pages where applicable.
• Test WooCommerce My Account.
• Test WooCommerce Checkout.
• Test WooCommerce lost-password behavior.
• Test WordPress password reset.
• Test custom registration forms.
• Test membership forms.
• Identify which component enqueues the strength meter.
• Inspect script dependencies.
• Do not assume a core asset was enqueued by core.
• Check wp_script_is() when debugging.
• Use wp_enqueue_scripts correctly.
• Prefer conditional loading over global enqueueing.
• Prefer conditional removal over global removal.
• Keep the script on actual password forms.
• Review WooCommerce exceptions.
• Review custom plugin exceptions.
• Clear optimization caches after changes.
• Inspect combined JavaScript bundles if necessary.
• Test changes on staging.
• Compare network waterfalls before and after.
• Check that account creation still works.
• Check that password changes still work.
• Check that password reset still works.
• Check WooCommerce checkout account creation.
• Check browser console errors.
• Measure total JavaScript reduction.
• Do not treat this cleanup as a replacement for login security.

Related guides

• How to Remove Unused WordPress Scripts
• wp_enqueue_scripts Explained
• Why WordPress Loads an Emoji Script on Every Page
• What Is jQuery Migrate, and Do You Need It?
• WooCommerce Account and Checkout Pages, Explained
• WordPress Login Security Layers, Explained

Final recommendation

Do not treat zxcvbn.min.js as a mysterious 400 KB file that WordPress simply forces every visitor to download for no reason.

The real architecture is more precise:

WordPress ships and registers
password-strength functionality
↓
a page, plugin or theme enqueues
the password-strength meter
↓
WordPress resolves dependencies
↓
zxcvbn becomes available
↓
password quality can be evaluated

The library is large because it uses substantial dictionary and pattern data to make password-strength estimation more realistic than a simple checklist of uppercase letters, numbers and symbols.

That cost can be justified where users actually create or change passwords.

It is much harder to justify on:

homepage
blog
ordinary landing pages
product pages
static content

that contain no password interface at all.

The correct optimization is therefore not:

disable password-strength functionality everywhere

but:

identify where it is enqueued
↓
identify where it is actually needed
↓
keep it on password workflows
↓
remove it from irrelevant frontend pages
↓
test account and checkout behavior
↓
measure the reduction

For sites where the password-strength assets are being loaded unnecessarily, TheOneWP Disable Password Strength Meter applies that contextual approach automatically for the WordPress and WooCommerce contexts it recognizes.

And for manual optimization, use the official WordPress script registry, enqueue API, and dequeue API to understand the dependency chain before modifying it.

A 400 KB script is not automatically bad because it is large.

It becomes wasteful when the browser downloads it on a page where its only possible job is to wait patiently for a password field that does not exist.