Restoring Gravity Forms UI after performance optimization removed required styles

What was happening

The WordPress theme used page-specific asset combining, aggressive dequeueing, inline styles, and Gravity Forms CSS suppression to keep front-end payloads controlled. On one environment the date picker rendered as an almost unstyled browser/plugin default because the Gravity Forms theme and date-picker styles expected by the component were no longer present.

Why the obvious solution was not enough

Turning every Gravity Forms stylesheet back on globally would solve the visual symptom but weaken the reason the theme had scoped assets in the first place. The fix needed to identify the exact dependency the active form required and restore it only where the form was present.

How the solution works

1. Compare the network and computed styles between the working and broken environments before changing markup.
2. Identify which Gravity Forms or date-picker stylesheet provides the missing component rules instead of adding replacement CSS by eye.
3. Trace the theme's dequeue and disable-CSS logic to understand why the dependency disappeared on the affected template.
4. Add a narrowly scoped enqueue or optimization exception for pages that actually render the relevant form or date field.
5. Preserve the site's custom visual overrides after the base component CSS is restored so the form matches the design system rather than the plugin default.
6. Verify the form with JavaScript/AJAX enabled because date-picker assets can load through a different path from static input styles.
7. Re-run performance checks to confirm the repair restores only the required asset instead of reintroducing the plugin's full stylesheet stack sitewide.

add_action('wp_enqueue_scripts', function () {
    if (!is_page_template('templates/contact.php')) {
        return;
    }

    // Restore only the component stylesheet this form depends on.
    wp_enqueue_style(
        'project-form-datepicker',
        get_theme_file_uri('/assets/css/form-datepicker.css'),
        [],
        null
    );
}, 30);

What should be verified before shipping

• Open the form on staging and production and compare the same date-picker state side by side.
• Test default, hover, keyboard-focus, selected-date, validation-error, and mobile states.
• Confirm the required style is loaded only on templates that use it.
• Submit the AJAX form after the asset change to ensure the visual fix did not hide a functional regression.
• Re-run the page-size and performance checks that originally motivated CSS dequeueing.

What changed

The form UI regained the expected styling without abandoning template-scoped asset loading. The dependency became explicit, making future performance work less likely to remove it accidentally.

Reusable lesson

Asset optimization should remove proven waste, not unknown dependencies. When a plugin component is still part of the user journey, make its minimum required CSS an intentional dependency instead of relying on whatever happens to survive dequeueing.