Overview
This article explains how NitroPack’s caching and optimization features can interfere with Gravity Forms, and how to identify and resolve the conflict.
NitroPack works differently from a normal caching plugin. The WordPress plugin only connects your site to NitroPack’s service; the optimization itself happens on NitroPack’s servers, and the page your visitor receives is built there. That means the settings affecting your form are in the NitroPack dashboard rather than in WordPress.
Symptoms
- Conditional logic or other JavaScript-driven features don’t respond.
- Fields display incorrectly.
- Forms fail to submit, or show submission errors.
- Blank screens appear after submission.
- Form data doesn’t process correctly.
- Save and Continue behaves unexpectedly.
- Conversational Forms or other add-on functionality breaks.
- Forms behave differently for logged-in users than for cached public visitors.
Note: NitroPack automatically detects forms and excludes them from optimization. Gravity Forms is listed among the plugins it supports out of the box. That works for most embeds, but you should test the form rather than assuming the automatic exclusion applies.
Why It Happens
Cached HTML
It’s generated once on NitroPack’s servers and served to later visitors from its network. A nonce from that render is reused until the cache is rebuilt, so Ajax submissions and forms that require the visitor to be logged in fail once the session has expired.
NitroPack dashboard › Caching Settings › Cache
JavaScript Optimization and Delayed Loading
These are the more aggressive optimization modes, and they delay non-critical scripts until the visitor interacts with the page. Gravity Forms relies on its scripts running to handle conditional logic, multi-page navigation, and submission, so these delays can break those features.
NitroPack dashboard › JavaScript settings
reCAPTCHA Scripts
This is a documented conflict. NitroPack’s own guidance notes that Gravity Forms with Google reCAPTCHA can break under its more aggressive JavaScript optimization, with the reCAPTCHA failing to display or verify, and recommends excluding the captcha scripts from optimization.
NitroPack dashboard › Caching Settings › Cache › Excluded Resources
Delayed Scripts and Spam Detection
The Gravity Forms honeypot expects a version hash and submission timing that the form’s JavaScript adds at submission. If that script is delayed or never runs, those values are missing, and the submission is flagged as spam: the visitor sees a normal confirmation, but the entry appears in the Spam view rather than your entry list.
Confirm the Issue
- Add
?nonitroto the end of the form page’s URL and load it. This serves the unoptimized page. If the form works there and not on the normal URL, NitroPack is involved. - Open both versions in separate tabs and compare them, rather than relying on memory of how the page looked.
- Test while logged out, in a private window. NitroPack doesn’t serve its optimized pages to logged-in users, so a form that works while you’re signed in to WordPress hasn’t been tested yet.
- If submissions seem to be going missing, open Forms › Entries and check the Spam view. The entry notes name the filter that flagged it.
How to Fix It
- Log in to the NitroPack dashboard and purge the cache for the site, then retest the form with a private window.
- If the form uses reCAPTCHA, add the captcha scripts to Excluded Resources at Caching Settings › Cache. Wildcards are accepted, so a pattern matching the captcha script path works.
- If the form still misbehaves, add the page to Excluded URLs in the same section. This turns off optimization for that page, so use it for form pages rather than site-wide.
- Retest after each change. NitroPack rebuilds its cached copy in the background, so allow time for the new version to be generated before judging the result.
- If exclusions don’t resolve it, contact NitroPack support. The optimization runs on their infrastructure, and they can inspect what their service produced for the page in a way you can’t from WordPress.