Should I Remove Polyfill from WordPress
Should you remove polyfill scripts from WordPress? The honest answer is: it depends on who actually visits your site, and most site owners have never checked. Polyfills are small JavaScript files that backfill missing browser features so older browsers can run modern code. WordPress ships one by default (wp-polyfill) because core and many plugins use JavaScript syntax and Web APIs that not every browser supports natively.
This guide walks through what the WordPress polyfill actually does, how to measure whether it is costing you anything, and the exact steps to remove it safely if your traffic no longer needs it.
What a Polyfill Actually Is
A polyfill is a piece of code that recreates a feature for browsers that don’t have it built in. If a script calls fetch() and the visitor’s browser has no native fetch implementation, the polyfill defines a version of fetch that behaves the same way. The browser never knows the difference; it just runs the substitute function instead of throwing an error.
WordPress bundles wp-polyfill, which is built on top of the popular core-js and regenerator-runtime libraries. It covers gaps like Promise, fetch, Array.from, Object.assign, and a handful of other ES6+ features that block editor, Gutenberg blocks, and many third-party plugins rely on. Core started shipping this after the block editor launched, because Gutenberg’s React-based interface needed guarantees that certain JavaScript methods would exist no matter what browser opened wp-admin.
Why WordPress Ships It in the First Place
Three separate concerns pushed WordPress toward bundling a polyfill instead of leaving compatibility up to individual plugin authors.
Browser compatibility. A meaningful slice of any large site’s traffic still comes from older Safari versions, older Android WebViews, and corporate machines running whatever browser IT locked down years ago. Without a polyfill, those visitors would hit broken JavaScript errors on pages using modern syntax.
A stable baseline for plugin authors. If every plugin developer had to write their own fallback code for missing browser features, the ecosystem would be a mess of duplicated, inconsistent shims. By loading one shared polyfill in core, WordPress gives every theme and plugin author the same safety net.
Admin dashboard reliability. The block editor is a JavaScript application. If a site administrator opens wp-admin on an old tablet browser and the editor silently fails because of a missing method, that’s a support nightmare. The polyfill exists partly to protect the editing experience, not just the public-facing site.
The Real Cost of Keeping It
None of this is free. wp-polyfill typically adds a request and roughly 30 to 40KB of minified, gzip-compressed JavaScript to page weight, depending on WordPress version. On a fast connection that’s nothing. On a slow mobile connection in a market with patchy 3G or 4G, every extra request adds real, measurable latency, especially when it blocks rendering.
More importantly, the polyfill loads unconditionally by default. WordPress does not sniff the visitor’s browser and skip loading the polyfill for someone running the latest Chrome, which already supports every feature the polyfill would provide. Every visitor downloads and parses the same script, whether they need a single line of it or none at all.
Run a Lighthouse audit or open Chrome DevTools’ Network tab on a fresh WordPress install and you’ll usually see wp-polyfill.min.js sitting in the waterfall. It’s rarely the biggest offender on a slow site (render-blocking CSS and unoptimized images tend to dominate), but on a site that has already fixed the big stuff, shaving a redundant script is one of the last remaining wins.
Should You Actually Remove It? A Decision Framework
Rather than a blanket yes or no, work through these three questions in order.
1. What browsers does your actual traffic use? Open Google Analytics (or whatever analytics tool you run) and check the Technology > Browser report for the last 90 days. If Internet Explorer and old Safari or Android WebView combined make up less than half a percent of sessions, the polyfill is very likely dead weight for your specific audience. If you’re running a government portal, an internal enterprise tool, or a site serving a region where older Android devices are still common, the calculus changes.
2. Is speed actually a bottleneck for you right now? If your Core Web Vitals are already solid and you’re mostly optimizing for the sake of optimizing, removing one 35KB script is a marginal win. If you’re an ecommerce store fighting for every 100 milliseconds of Largest Contentful Paint, or a news site competing for Google’s page experience signals, it’s worth doing alongside other JavaScript trimming.
3. Does your plugin stack depend on it? This is the step people skip, and it’s the one that causes support tickets. Some page builders, form plugins, and older third-party JavaScript still assume the polyfilled methods exist. Removing wp-polyfill blindly can break a checkout form or a page builder’s live preview on an otherwise modern browser, not because the browser lacks the feature, but because some other script relied on load order that included the polyfill.
Step 1: Measure Before You Touch Anything
Don’t remove the polyfill on a guess. Confirm the numbers first.
- Open your site in Chrome DevTools, go to the Network tab, filter by JS, and reload with cache disabled. Note the size and load time of
wp-polyfill.min.js. - Run a Lighthouse report (built into DevTools, under the Lighthouse tab) and check whether “Reduce unused JavaScript” or “Avoid enormous network payloads” flags the polyfill specifically.
- Pull your browser breakdown from Google Analytics or your analytics platform of choice, filtered to the last 90 days, sorted by session count.
- Cross-reference the browser list against caniuse.com for the specific features your theme and plugins depend on (Promise, fetch, and the block editor’s dependencies are the most common).
If your oldest supported browser in meaningful traffic volume already natively supports everything WordPress core needs, you have a reasonable case for removal. If you see meaningful traffic on Safari versions more than two or three years old, or old Android WebViews bundled into embedded apps, be more cautious.
Step 2: Test Cross-Browser Before You Ship
Once you’ve decided the removal makes sense, test the change before it goes live, not after a customer reports a broken form. A service like BrowserStack lets you spin up real and virtual devices covering older Safari, older Edge, and various Android versions without owning a device lab. At minimum, check:
- The block editor loads and saves a post correctly in wp-admin.
- Your checkout flow (if you run WooCommerce or any ecommerce plugin) completes end to end.
- Any interactive front-end elements, sliders, modals, AJAX-driven search, load correctly.
- Contact forms submit without JavaScript console errors.
Test with the browser’s developer console open so you actually see any errors that show up, rather than relying on visually spotting broken UI.
Step 3: Remove the Polyfill Safely
The cleanest method is dequeuing the script through a hook, in either a custom plugin or your child theme’s functions.php. Never edit WordPress core files directly; any change there gets wiped on the next update.
function remove_wp_polyfill_script() {
wp_dequeue_script( 'wp-polyfill' );
wp_deregister_script( 'wp-polyfill' );
}
add_action( 'wp_enqueue_scripts', 'remove_wp_polyfill_script', 100 );Note the priority argument of 100. wp-polyfill is often registered as a dependency of other scripts, so you want your dequeue call to run late enough that it isn’t re-enqueued by something else earlier in the load order. If you’re still seeing it load after adding this snippet, check whether a plugin is force-loading it as a hard dependency, in which case removing it cleanly may not be possible without also patching that plugin’s enqueue call.
If you only want to remove it from the public-facing site and keep it in wp-admin (a reasonable middle ground, since editors are more likely to be on modern machines than random site visitors), scope the hook with a front-end check:
function remove_wp_polyfill_frontend_only() {
if ( ! is_admin() ) {
wp_dequeue_script( 'wp-polyfill' );
wp_deregister_script( 'wp-polyfill' );
}
}
add_action( 'wp_enqueue_scripts', 'remove_wp_polyfill_frontend_only', 100 );This is generally the safer option for most sites: it protects the block editor experience for whoever logs in to write content, while trimming the payload for public visitors, who are statistically more likely to be on recent browser versions than a small internal editorial team using whatever laptop they were issued.
What Can Break, and Why
Removing the polyfill doesn’t just risk breaking things on old browsers. It can also break things on modern browsers if another script assumed the polyfill’s load order or its presence as a dependency. Watch for these specific failure modes:
Silent JavaScript errors with no visible symptom at first. A form might still render but fail to submit. Check the browser console, not just the visual page.
Page builder live preview breaking in the editor. Elementor, Divi, and similar builders sometimes lean on polyfilled methods inside their editing interface specifically, even if the published front-end page doesn’t need them.
Third-party embedded widgets failing. Chat widgets and review-and-rating snippets loaded via a tag manager sometimes assume a polyfilled environment because they were built against a broader baseline than “modern evergreen browsers only.”
If any of these show up after removal, the fix is usually to re-scope the dequeue (front-end only, as shown above) rather than abandoning the change entirely.
Progressive Enhancement as an Alternative
Instead of an all-or-nothing removal, some developers prefer a progressive enhancement approach: build the site so that core functionality works without relying on any JavaScript feature that needs polyfilling, and treat anything that does need it as an enhancement layer that gracefully degrades. This is more work upfront and mostly relevant if you’re writing custom theme JavaScript rather than relying entirely on third-party plugins, but it sidesteps the whole “will removing this break something” question because nothing critical depends on the polyfilled feature in the first place.
For most WordPress site owners running off-the-shelf themes and plugins, this level of custom engineering isn’t practical. The measure-then-remove approach above is the realistic path.
After You Remove It: What to Monitor
Removing a polyfill is not a one-time task you finish and forget. Browser support baselines shift, and so does your plugin stack.
Run PageSpeed Insights or GTmetrix again a week after the change to confirm the improvement actually shows up in the metrics, not just in DevTools. Watch your support inbox or contact form submissions for a spike in “the site isn’t working” reports over the following two to three weeks, since that’s usually when an edge-case browser combination surfaces. If you want to keep serving a fallback for the small remaining slice of older browsers without loading it for everyone, a browser upgrade notice plugin like WP BrowserUpdate can nudge outdated visitors to update instead of silently failing.
Re-check this decision whenever you make a major plugin change, switch themes, or install a new page builder. A dequeue rule you set up two years ago against last year’s plugin stack might not hold against a new one.
How This Fits Into Broader JavaScript Cleanup
Polyfill removal rarely happens in isolation. If you’re already in DevTools measuring wp-polyfill, you’re probably looking at the rest of your script waterfall too, and a handful of related habits are worth picking up at the same time.
Check for duplicate jQuery loads. Some themes and plugins each enqueue their own copy instead of relying on the one WordPress already registers, which is a bigger and more common waste than the polyfill ever is. Look for render-blocking scripts in the <head> that could be deferred or moved to the footer without breaking functionality. And audit which plugins are loading their assets site-wide versus only on the pages that actually use them; a contact form plugin loading its JavaScript on every single page, including ones with no form, is a far heavier tax than wp-polyfill.
Treat the polyfill dequeue as one line item on a short performance checklist rather than a standalone fix. On its own it rarely moves a Lighthouse score by more than a point or two. Combined with fixing duplicate scripts and unnecessary asset loading, the cumulative effect is worth the afternoon it takes to audit properly.
Frequently Asked Questions
Does removing wp-polyfill break the WordPress block editor?
It can, on older browsers that genuinely lack the JavaScript features Gutenberg depends on. On current versions of Chrome, Firefox, Safari, and Edge, the block editor works fine without it because those browsers already natively support the relevant features. If your editorial team all uses recent browsers, scoping the removal to front-end only (shown in Step 3) sidesteps this risk entirely.
How much page speed improvement can I actually expect?
It varies by site and by how much other JavaScript is already loading. On a lean site with few plugins, removing a 30 to 40KB script can produce a measurable, if modest, improvement in load time and script parsing cost. On a site already loaded down with page builder JavaScript and a stack of analytics tags, the polyfill removal will barely register against the bigger offenders. Measure your own site rather than assuming a fixed percentage gain.
Is there a way to load the polyfill only for browsers that need it?
Conditional loading based on user-agent sniffing is possible but fragile and generally not recommended, since user-agent strings are unreliable and easy to spoof or misparse. The more robust pattern used across the web is feature detection: check whether the browser already has the method (for example, typeof Promise !== 'undefined') before loading the polyfill script at all. This requires custom implementation work beyond WordPress’s default behavior and is really only worth it if polyfill loading is a demonstrated, significant cost on your specific site.
Will removing polyfills affect my SEO?
Indirectly, yes, in the same way any page speed improvement can help. Google’s page experience signals factor in Core Web Vitals, and trimming unnecessary JavaScript is one small lever among many that can nudge those metrics. It is not a targeted SEO fix on its own; treat it as part of general performance hygiene rather than a ranking silver bullet.
What if I don’t know how to edit functions.php or write a custom plugin?
Use a code snippets manager instead of editing theme files directly. It gives you a safe interface to add and remove PHP snippets like the dequeue function above without touching your theme’s core files, and it’s easier to disable a single snippet if something breaks than to hunt through functions.php for what you changed.
Does this apply to other polyfills besides wp-polyfill?
Many plugins and themes bundle their own polyfills separately from WordPress core’s wp-polyfill, often for specific features like IntersectionObserver or CSS custom property fallbacks. The same measurement-first approach applies: check your Network tab for other polyfill-named scripts, confirm whether your real traffic needs them, and dequeue the specific script handle rather than assuming removing wp-polyfill covers everything.
The Bottom Line
wp-polyfill exists to keep WordPress from breaking on the small but real slice of visitors using older browsers. For a lot of modern, JavaScript-heavy sites, that slice has shrunk to the point where the polyfill is doing very little useful work and mostly adding weight. But “very little” isn’t “zero,” and the cost of guessing wrong (a broken checkout, a support ticket queue full of “the form doesn’t work” complaints) usually outweighs the modest performance gain from removing it blindly.
Check your analytics first. Test the change in a real cross-browser environment before publishing it. Scope the removal to the front end if you want to keep protecting your admin dashboard. Do that, and removing the polyfill becomes a low-risk, genuinely useful performance tweak instead of a gamble.
Interesting Reads
