Load a WordPress form without 200 KB of JS

A typical WordPress forms plugin ships a 200 KB JavaScript bundle to your visitors so they can fill in name, email, message. Open the network tab on any popular forms plugin’s demo and you’ll watch it land before the form is even visible.

The form is six fields. Four kilobytes of HTML. The bundle is fifty times the size of the thing it renders.

This is fixable.

What’s actually in that bundle

Decompose a 200 KB forms-plugin bundle and you get roughly:

• jQuery (90 KB minified, often a copy WordPress already loads).
• A spinner animation library.
• A form validator that does what <input required> does for free.
• A datepicker for the one form on your site that doesn’t need dates.
• A signature pad for the one form that doesn’t need signatures.
• Translation strings for 40 languages.
• A polyfill kit for browsers that died in 2017.

Every bundle is different. Most have at least four of those.

What a form actually needs

For a normal “submit on click and POST it” flow:

1. A click handler that prevents default form submission.
2. A fetch() call to a server endpoint.
3. Display the response message inline.

That’s twenty lines of JavaScript. Maybe forty if you want optimistic UI.

Core Forms ships its frontend in 4 KB minified. No jQuery dependency. No bundled libraries. The submit handler, the response renderer, and the field-error painter, that’s all that’s in there.

Why this matters past “page weight”

Three reasons. None of them are “Lighthouse score.”

Caching plugins choke on jQuery loaded twice. If your forms plugin enqueues a second copy of jQuery (it happens), your homepage loads two jQuery cores. Caching plugins won’t combine them safely. WP Rocket, for instance, will skip combination on duplicates and fall back to original delivery.

Mobile networks. Real ones. A 200 KB bundle on a 3G connection is two seconds of staring at “loading…” before anyone can interact. Most analytics dashboards don’t expose that segment well, but it’s the segment that converts the worst.

Client perception. When a client opens DevTools and sees their /wp-content/plugins/forms-thing/ directory loading 800 KB, they ask why. You don’t want to spend a meeting defending it.

The Core Forms checklist

If you’re building (or auditing) a forms setup, here’s the minimum you should look for in the network tab:

• One JS file under 10 KB minified.
• No bundled jQuery, no Vue, no React shipped to the visitor.
• One CSS file (the form theme) optional, around 5 KB.
• No external requests during render unless the form actually has a captcha.

Core Forms hits all four. The block doesn’t change the math; the editor preview is the only place React is in play.

Where you can’t avoid weight

Some features genuinely need bytes. If you use:

• reCAPTCHA v3 — Google’s library is 100+ KB.
• hCaptcha — closer to 80 KB.
• Cloudflare Turnstile — about 60 KB, the lightest of the three.
• File uploads with chunking — adds 20-30 KB.

Pick one. Don’t enable all three “just in case.” A site with reCAPTCHA, hCaptcha and Turnstile loaded on the same page is a real thing I’ve audited, and the fix was deleting two of them.

The thirty-second test

On any WordPress site you didn’t build:

1. Open the homepage.
2. Open DevTools → Network → JS filter.
3. Hard reload.
4. Sort by size descending.
5. Look at the top three.

If a forms plugin appears in the top three on a homepage that doesn’t render a form, the plugin is loading on every page. That’s almost always wrong.

Core Forms doesn’t enqueue its JS on pages where no form is present. The [cf_form] shortcode and the Gutenberg block flag the page; everything else gets a clean homepage.

The next step

Audit one site. Find one bundle to remove. Ship the fix in one commit.

That’s how you reclaim a homepage. Not by adding a perf plugin on top of a heavy stack, but by removing the heavy stack underneath.

If you want a starting point that doesn’t need this audit in six months, Core Forms is what I’d point you at. Pricing here.