Google reCAPTCHA can add unnecessary frontend JavaScript when it loads on every page of a WordPress site, even where no protected form is present. In this case, a custom must-use plugin was created to prevent the Gravity Forms reCAPTCHA Add-On from loading on pages that did not contain a Gravity Form. The result was a more targeted script-loading strategy without changing how reCAPTCHA worked on pages that actually required it.
Issue background
A WordPress site used Gravity Forms with the Gravity Forms reCAPTCHA Add-On to protect public forms from spam.
The reCAPTCHA assets were loading sitewide, including on pages that did not display a Gravity Form. This introduced additional third-party JavaScript on pages where it provided no functional benefit.
Sitewide loading can affect performance by adding:
- Additional network requests
- Third-party JavaScript execution
- Extra browser processing
- Potential conflicts with optimization or consent tools
- Unnecessary work on content-only pages
The goal was to preserve reCAPTCHA on relevant form pages while preventing the Gravity Forms integration from loading everywhere else.
Diagnosis
The issue was not that Gravity Forms or reCAPTCHA had stopped working. The problem was that the reCAPTCHA integration was being loaded too broadly.
Because Gravity Forms was only present on selected pages, the site did not need to request reCAPTCHA assets on every frontend route.
The team chose a custom must-use plugin because it provided a centralized, always-active place for the optimization logic. Unlike a standard plugin, code inside the WordPress mu-plugins directory loads automatically and cannot be accidentally deactivated through the normal Plugins screen.
The completed task confirmed one important limitation: the logic was written specifically for the Gravity Forms reCAPTCHA Add-On. It would not automatically support a different reCAPTCHA plugin added later.
Resolution steps
- Confirm which integration loads reCAPTCHA. Verify that the scripts come from the Gravity Forms reCAPTCHA Add-On rather than another form, security, or spam-protection plugin.
- Audit the affected pages. Compare pages with Gravity Forms against pages that contain only standard content.
- Inspect frontend requests. Use browser developer tools to confirm that reCAPTCHA assets are loading on pages where no form is present.
- Create a custom must-use plugin. Add the optimization logic inside
wp-content/mu-pluginsso it loads automatically. - Detect whether the current page uses Gravity Forms. Base the decision on the site’s actual form implementation rather than a broad sitewide assumption.
- Allow reCAPTCHA on form pages. Preserve the normal Gravity Forms reCAPTCHA behavior wherever a protected form appears.
- Prevent loading on unrelated pages. Remove or suppress the Gravity Forms reCAPTCHA assets when the current page does not contain a Gravity Form.
- Test embedded forms carefully. Review forms added through shortcodes, blocks, templates, widgets, popups, and reusable components.
- Test dynamic form loading. Confirm that forms inserted after the initial page load still receive the scripts they require.
- Verify form submission. Submit each protected form and confirm that reCAPTCHA validation continues to work.
- Test pages without forms. Confirm through the browser network panel that the reCAPTCHA assets no longer load unnecessarily.
- Clear all caches. Purge WordPress, hosting, CDN, optimization-plugin, and browser caches after deployment.
- Document the plugin-specific limitation. Note that the optimization applies only to the Gravity Forms reCAPTCHA Add-On.
- Revisit the logic if another reCAPTCHA plugin is added. A new integration may use different script handles, hooks, or loading conditions.
The implementation should use the actual hooks and script handles registered by the installed Gravity Forms reCAPTCHA Add-On. A simple shortcode check may not be sufficient on sites that render forms through blocks, page-builder modules, templates, or dynamic components.
Final outcome
A custom must-use plugin was created and deployed.
The plugin prevented the Gravity Forms reCAPTCHA Add-On from loading on pages that did not contain a Gravity Form. Pages with forms continued to load the reCAPTCHA integration normally.
This reduced unnecessary third-party script loading across the rest of the site while preserving spam protection where it was required.
The task also documented that the optimization was limited to the Gravity Forms reCAPTCHA Add-On. If another reCAPTCHA plugin is introduced later, the must-use plugin will need to be reviewed and extended.
The key lesson is that third-party security scripts do not always need to load sitewide. When the integration supports it, conditional loading can improve WordPress performance without weakening protection on the pages that actually use forms.
For help optimizing Gravity Forms, reducing unnecessary reCAPTCHA loading, or building a custom WordPress must-use plugin, contact Freshy.
