Airlift can significantly improve WordPress performance, but aggressive optimization and caching can sometimes conflict with dynamic functionality such as AJAX filters, product archives, search tools, or lazy-loaded content. In one performance project, Airlift substantially improved Lighthouse scores, but deployment also revealed conflicts with product filtering and archive pagination that required targeted exclusions and additional debugging.
The final approach was not simply to enable Airlift and accept its default configuration. The team tested it on staging, compared performance before and after, disabled overlapping caching from WP Rocket, reduced aggressive optimization settings where necessary, added exclusions for dynamic filters and product-category pages, and resolved server-side fatal errors before stabilizing the setup.
Issue background
The WordPress site had previously experienced crashes and had undergone extensive performance optimization. Airlift had been disabled while those earlier problems were addressed, so the next step was to create a staging environment and determine whether Airlift could now be used safely.
The main goals were to:
- Improve frontend performance beyond the existing setup.
- Verify that Airlift would remain stable under normal site usage.
- Compare performance with the site’s existing WP Rocket configuration.
- Confirm that dynamic functionality such as product filtering continued to work.
The site also used several plugins with overlapping security, caching, backup, and diagnostic roles, so the plugin stack was reviewed before deployment.
Diagnosis
The first staging tests showed that Airlift could provide a substantial performance improvement. With WP Rocket disabled and Airlift active, Chrome Lighthouse results improved from:
- Desktop: 85 to 100
- Mobile: 54 to 99
The largest improvements appeared to come from image delivery, cache efficiency, and reduced render-blocking requests.
However, performance scores were only part of the evaluation. The site contained dynamic product functionality, including category filters, AJAX behavior, and lazy-loaded product archives. Initial staging tests showed caching-related display inconsistencies, and some more aggressive Airlift optimization settings were reduced as a precaution.
After Airlift was deployed to production, a more serious problem appeared: product filtering worked for some users but failed for others. Investigation showed that Airlift was likely conflicting with previously implemented filtering fixes and was also associated with a fatal server-side error that was silently affecting functionality.
The issue was difficult to reproduce consistently because browser cache state mattered. In one test, the filter failed in a normal browser but worked correctly in incognito mode. That difference helped confirm that cached assets or cached page state were contributing to the behavior.
A second issue appeared later with automatic lazy loading on product-category and brand archive pages. The site’s theme was configured to load additional products as users scrolled, but that functionality stopped working after the optimization changes.
Resolution steps
The troubleshooting process provides a useful framework for implementing Airlift on WordPress sites with dynamic functionality.
- Create a staging environment before enabling Airlift. Test performance optimization away from production so caching, JavaScript changes, and dynamic site features can be evaluated safely.
- Establish a before-and-after performance baseline. Use tools such as Chrome Lighthouse, GTmetrix, or Google PageSpeed Insights. In this case, Lighthouse testing showed a large improvement after Airlift was enabled.
- Avoid overlapping page-optimization systems. WP Rocket was disabled while Airlift was tested and ultimately deployed. Running multiple tools that perform similar caching or optimization work can complicate troubleshooting and introduce conflicts.
- Reduce aggressive optimization when functionality is at risk. Some of Airlift’s more aggressive optimization features were disabled during staging because the site depended on interactive filtering and other JavaScript-driven behavior.
- Test dynamic features, not just performance scores. Product filters, AJAX menus, search tools, account-specific content, forms, and infinite scroll should all be tested after optimization changes.
- Use incognito testing to identify browser-cache effects. When functionality works in incognito but fails in a normal browser, stale browser cache or cached assets may be involved.
- Clear both server-side and Airlift caches. During troubleshooting, the team cleared the WP Cloud server cache and the Airlift cache to eliminate stale cached responses.
- Add exclusions for dynamic query parameters. Airlift exclusions were added for
filter_brand,min_price, andmax_priceso filtering requests would not be incorrectly cached or optimized. - Exclude problematic archive paths where necessary. An optimization exclusion was added for
product-categorypages after automatic product loading stopped working on archive pages. - Investigate silent server-side errors. The filtering issue was ultimately associated with fatal server errors that required a development fix. Performance plugins can expose or amplify compatibility problems that may not be visible in the browser alone.
- Allow existing browser caches to expire after the fix. After site data was cleared and the server-side fixes were deployed, users with older cached browser content were expected to recover automatically within the browser cache’s 24-hour lifetime.
The plugin review also helped reduce unnecessary overlap. BlogVault remained active for backup, security, and Airlift integration. Jetpack remained active, while Jetpack Protect, Jetpack VaultPress Backup, Query Monitor, and the full Wordfence Security plugin were left disabled where their functionality was unnecessary or overlapping. Wordfence Login Security remained in use for two-factor authentication.
Final outcome
Airlift was successfully deployed with WP Rocket disabled, and the site showed a substantial improvement in Lighthouse performance. The deployment was not completely plug-and-play: dynamic filtering and product archive behavior required additional debugging, cache clearing, server-side fixes, and targeted Airlift exclusions.
The final troubleshooting work restored automatic product loading on archive pages and improved the filtering behavior while retaining Airlift’s performance benefits. The project also reinforced an important WordPress optimization principle: a high Lighthouse score is only useful if the site’s real functionality remains intact.
When testing Airlift on an ecommerce or highly interactive WordPress site, treat filters, AJAX behavior, search tools, account-specific content, and infinite scroll as critical test cases. If a problem appears only for certain users, compare normal and incognito sessions and review browser cache, server cache, optimization exclusions, and PHP errors before assuming the underlying feature itself is broken.
If Airlift, WP Rocket, WooCommerce filters, or other WordPress performance tools are causing caching conflicts on your site, contact Freshy. Our WordPress team can help diagnose cache exclusions, plugin conflicts, fatal errors, dynamic filtering issues, and Core Web Vitals performance.
