Should I Remove wp-polyfill From WordPress? We Tested It

On WordPress 7.1.3 wp-polyfill no longer loads from core at all. Most sites have nothing to remove. It only appears when a plugin such as WooCommerce asks for it, and removing it the popular way breaks the cart. You can drop it safely in about five minutes with one snippet.

I tested this in October 2026 on a local WordPress 7.1.3 store running WooCommerce 11.2 and Twenty Twenty-Five. I checked every page type logged out and logged in, measured the file, and ran Lighthouse three times before and after each change.

You get the pages where wp-polyfill loads, what each removal method breaks, the one snippet that works, and the measured gain. You also get the 2024 polyfill.io attack, which is a different script, and how to check your site for it.

Should You Remove wp-polyfill From WordPress?

You should remove wp-polyfill only if a plugin loads it on pages where speed matters, and only with the empty handle method shown below. WordPress 7.1.3 core loaded it on zero pages in my test. On a WooCommerce store it loaded on the block cart, checkout, dashboard and editor.

So the real question is which plugin pulls it in. Here is every page I checked, with and without WooCommerce active:

The gain is small. On my cart page it saved 29.9 KB of a 3 MB page and lifted the Lighthouse score by about two points on average.

For a blog without WooCommerce, the answer is simpler. There is nothing to remove, and a plugin that claims to remove it is doing nothing for you.

On a site with other plugins, find the culprit before you change anything. The dependency loop in the next section lists every handle that asks for wp-polyfill. The handle prefix usually names the plugin, such as wc- for WooCommerce.

Keeping it is the right call in two cases. If the file only loads in the admin, visitors never download it.

And if your analytics show real traffic from very old browsers, those visitors need it to run the cart.

What wp-polyfill Is and Why WordPress Ships It

The wp-polyfill script is a bundled copy of core-js that WordPress ships in wp-includes/js/dist/vendor. It adds modern JavaScript features to old browsers that lack them. Block code written for new browsers then still runs. On WordPress 7.1.3 the file is version 3.15.0 and weighs 29.9 KB.

The file header names its source: core-js 3.39.0. WordPress registers it under the handle wp-polyfill, and any script that lists that handle as a dependency makes WordPress print it on the page.

The same folder holds eight smaller polyfills for features like fetch, URL and FormData. I measured the main file and the two biggest of those, raw and with gzip:

So the main file shrinks to 10.7 KB with gzip, which is what a visitor downloads on most hosts. None of the smaller polyfills loaded on any page I tested. A Brotli versus GZIP comparison shows how much further Brotli can shrink files like these.

Then I listed every registered script that depends on wp-polyfill. With WooCommerce active, 19 handles did, and all 19 came from WooCommerce:

With WooCommerce off, the same loop returned 0. That count is why core alone never loads the file, since nothing in core asks for it any more.

Plugins keep asking for it because of their build tools. The @wordpress/scripts package can add wp-polyfill to a block’s dependency list on its own. A Gutenberg GitHub issue asks for that default to be removed from new blocks.

So a plugin can depend on wp-polyfill without its authors ever choosing it. That also means the dependency can vanish in a plugin update. Recheck after each major WooCommerce release.

What Breaks When You Remove wp-polyfill

Removing wp-polyfill the popular way, with wp_deregister_script(), broke the WooCommerce cart on my store. WordPress silently dropped every script that depended on it. The cart block never loaded. A plain dequeue did nothing, and only an empty replacement handle removed the file safely.

Most guides that tell you to remove polyfill from WordPress copy the same answer. The most shared one, a highly ranked Stack Overflow thread on wp-polyfill, gives the deregister method. I tested it against the other two common methods on a cart with one item in it:

The results split three ways:

• Dequeue: wp_dequeue_script() changed nothing because the 19 dependents pulled the file straight back in.
• Deregister: The page dropped from 66 scripts to 17, and the cart never rendered.
• Empty handle: The file disappeared, 67 scripts still loaded, and the cart worked.

Here is what the deregister method did to the cart page. The gray boxes are WooCommerce loading placeholders, and they never filled in:

No error showed in the browser console, which makes this one hard to spot. A shopper simply sees an empty cart with no checkout button.

The cause is how WordPress handles dependencies. It will not print a script whose dependency is missing. Deregistering one shared handle quietly removed 49 WooCommerce scripts along with it.

The admin breaks the same way. I deregistered wp-polyfill on admin_enqueue_scripts, and the block editor lost 136 scripts while the WooCommerce home screen lost 29:

The WooCommerce home screen then loaded as a blank gray page. Leave the admin alone, because nobody measures your dashboard speed.

How to Remove wp-polyfill Safely

To remove wp-polyfill safely, check which pages load it, add an empty handle on the front end only, and test the cart and checkout. Then measure the page before and after to confirm the gain. The four steps below take about five minutes on a staging copy.

Run each step on staging first if your store takes live orders. A broken checkout costs more than 30 KB ever saves.

Step 1: Check Which Pages Load It

Open each page type logged out and search the HTML for the script tag. A cookie with one cart item matters here, because WooCommerce changes what it prints once the cart is not empty:

With an item in the cart, every page printed a low priority prefetch link for the file. Only the block cart and checkout printed the real wp-polyfill-js script tag.

Step 2: Add the Empty Handle on the Front End

The fix replaces the real script with an empty handle of the same name. The wp_register_script() reference says a source of false makes the handle an alias. Dependents still load and no file is printed.

Add this to a small custom plugin or your child theme’s functions.php:

add_action( 'wp_enqueue_scripts', function () {
	wp_deregister_script( 'wp-polyfill' );
	wp_register_script( 'wp-polyfill', false );
}, 100 );

The wp_enqueue_scripts hook never runs in the admin. The editor and dashboard keep the real file. Priority 100 makes it run after plugins have registered their own scripts.

Warning: Never use wp_deregister_script( 'wp-polyfill' ) on its own. As the test above showed, it takes every WooCommerce block script down with it.

With the snippet active, the cart loaded 67 scripts with no wp-polyfill among them, and the cart block rendered in full:

Step 3: Test the Cart and Checkout

Add a product to the cart, open the cart page, and go through checkout to the payment step. The cart should show the line item, the totals and the Proceed to Checkout button:

Then try one real browser you care about, such as Safari on an iPhone. The only visitors who could lose features are those on browsers too old for what core-js fills in.

Step 4: Measure the Difference

Run Lighthouse on the cart page three times before and three times after, since single runs swing by several points. My results came from Lighthouse 12.2.1 on a local server with no compression:

The score moved from 57 to 61 up to 61 to 62. Total Blocking Time dropped from 124 to 236 ms down to 51 to 66 ms, though some of that gap is run-to-run noise.

Page weight fell by about 30 KB, or 1% of the page. On a host with gzip the saving is closer to the 10.7 KB compressed size.

Bigger wins usually sit elsewhere. A chat widget, for example, often loads far more code than wp-polyfill.

Check the scripts behind the WordPress chatbot plugins you use before you trim core files. A WordPress care plan that reviews scripts after every update catches these early.

If you would rather have someone audit every script on your store and remove only what is safe, our WordPress speed optimization service covers it. Each change is tested on staging before it reaches your live cart.

The polyfill.io Attack Is a Different Script

The polyfill.io attack of June 2024 hit the external cdn.polyfill.io service, and WordPress core’s wp-polyfill was never part of it. Core serves its own local file from wp-includes, while the attack spread through sites that embedded the third-party domain. Removing wp-polyfill does nothing about polyfill.io.

The two names cause most of the confusion around this topic. One is a file on your server, and the other was a CDN that rewrote its code for each visitor.

Sansec published its polyfill.io supply chain report on June 25, 2024. It said a Chinese company bought the domain and GitHub account in February. The domain was then caught injecting malware on mobile devices through more than 100,000 sites:

The response came fast. Cloudflare rewrote polyfill.io links to its own cdnjs mirror on June 26, 2024, turned on by default for free plan sites.

Fastly had already posted new options for polyfill.io users on February 28, 2024, offering polyfill-fastly.io as a free drop-in mirror. The flaw also got a CVE: CVE-2024-38526 covers a Python documentation tool that linked to polyfill.io, which NVD says “now serves malicious code”.

Check Your Site for polyfill.io

Search your theme, your plugins, your database and the rendered page for the domain. Old themes and page builder snippets sometimes pasted the CDN link into a header field:

My test site returned 0 matches in all four places. If yours finds one, delete the script tag, or swap it for a self-hosted copy of only the features you need.

Deleting the tag is the quick fix, but test the pages that used it right after. Open each one with the browser console showing, and look for errors about missing functions.

After you remove it, clear every cache layer: the page cache plugin, the host cache and any CDN. A cached copy of the old page keeps serving the tag until it expires.

The rendered page check matters most, since WordPress builds every front-end page through index.php in WordPress and a header field can inject the tag there. A search of files alone can miss it.

Conclusion

On WordPress 7.1.3, wp-polyfill is a plugin question, because core loaded it on zero pages in my test. WooCommerce loads it on the block cart, checkout, dashboard and editor.

If you remove it, use the empty handle on wp_enqueue_scripts and leave the admin alone. Deregistering it breaks the WooCommerce cart, and dequeuing it does nothing.

Expect a small gain: about 30 KB raw, 10.7 KB with gzip and about two Lighthouse points. The polyfill.io attack is a separate problem. Search your site for that domain even if you keep wp-polyfill.

Frequently Asked Questions (FAQs)