Load WordPress forms without unnecessary JavaScript

A simple contact form should not load scripts for features it does not use. The useful performance question is what reaches the visitor, not whether the admin editor includes a visual builder.

Inspect the actual form page before drawing conclusions. A plugin’s bundle size changes with the version, enabled features, compression, and page configuration.

Check which features account for the scripts

Look for code that belongs to a feature absent from the page:

• datepickers when the form has no date input;
• payment SDKs on a form that takes no payment;
• CAPTCHA libraries from unused providers;
• duplicate framework or validation libraries;
• editor assets that should stay in the admin.

A file name or a large decoded size is a starting point, not proof that it is unnecessary. Check its purpose and transferred size before removing it.

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.

A production handler also needs validation, accessible feedback, recovery from errors, and protection against accidental duplicate submissions.

Core Forms’ core frontend is written without a jQuery dependency. Its total page payload depends on enabled features: accessibility, analytics, multi-step forms, calculations, and payments can require additional assets. Measure the form you are deploying rather than treating one minified file as the full cost.

Separate editing tools from visitor assets

The visual builder runs in the WordPress admin. Its React editing interface is not the form visitors complete. The block and shortcode render the form through the plugin’s frontend asset rules.

For a useful audit:

• Compare a page with the form and a page without it.
• Check both transferred bytes and decoded resource size.
• Identify which assets come from enabled features.
• Distinguish optional presentation CSS from required navigation and behavior styles.
• Test validation and submission after disabling any asset.

Some features need extra assets

Payment fields and CAPTCHA providers can load third-party SDKs. Multi-step navigation and calculations also need their supporting code.

Use the protection and payment workflow the form actually requires. For example, compare the configured reCAPTCHA or Turnstile flow under real page conditions instead of relying on a fixed library-size ranking. Disabling required code can make a page lighter while leaving the form unusable.

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 loads on a homepage without a visible form, check for a popup, footer form, or dynamically inserted embed. If none needs it, investigate why that asset is present.

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.

Repeat the check after adding a payment field, analytics, CAPTCHA, or another feature. Core Forms pricing.

The Mailchimp signup piece is the worked example: 4 KB instead of 90.

The honest case for AJAX submission covers the one script that earns its place.