FlyingPress - WordPress Plugin

FlyingPress Guide: configuring cache, optimizations, and validating the results

FlyingPress is best understood not as a "speed up your site" button, but as a set of connected WordPress rules: page caching, preloading, CSS and JavaScript optimization, image and font handling, media optimization, external cache integration, and real user metrics. This guide walks through the process from installation to result validation without blindly turning on every option at once.

This guide is written for site owners, editors, technical administrators, and developers who already know site speed affects user behavior, but do not want to break menus, carts, forms, sliders, or account areas just to get a green report. What matters here is not some abstract idea of the "best FlyingPress settings," but the sequence: enable a feature, understand how it works, check the public-facing site, identify the symptom, and roll back only the questionable setting.

This guide does not repeat the product's marketing copy. Instead, it focuses on practical steps: what to verify before installation, how to enable settings in groups, how to work with WooCommerce and dynamic pages, how to inspect cache headers, how to troubleshoot common issues, and when it makes sense to compare FlyingPress with other solutions.

What problem FlyingPress helps solve

FlyingPress is primarily designed to move a standard WordPress site toward predictable performance. In practice, that means more than just static HTML caching. The plugin also controls which CSS is needed above the fold, when scripts should run, which images should load immediately, which media should be deferred, how the cache should be preloaded after changes, and where to review actual Core Web Vitals data.

The official site describes FlyingPress as a lightweight WordPress speed optimization plugin, but its feature page shows a broader scope: page cache, cache preloading, image optimization, Core Web Vitals monitoring, Cloudflare integration, unused CSS removal, delayed script execution, minification, lazy loading for media, Google Fonts optimization, resource prioritization, and layout shift reduction. The important point is that each feature affects a specific part of the page load path, so configuration should move from simple to risky.

If the site is simple - a blog, landing page, informational project, or catalog without heavy personalization - FlyingPress can often be configured quickly. If the site is dynamic - an online store, course platform, account area, membership site, multi-currency setup, filtered catalog, form-heavy interface, chat widgets, or marketing scripts - the same plugin requires a careful exclusion map. Cache speeds up repeatable HTML, but personal states cannot be cached blindly.

Another key aspect of FlyingPress is its reliance on cloud-based optimization. According to the preload documentation, starting with the 5.x line, pages may be fetched from cloud servers and analyzed in a real browser environment. That allows FlyingPress to more accurately detect used CSS, above-the-fold images, important fonts, background images, third-party scripts, and elements that should be deferred. But that power comes with a requirement: the site must be publicly reachable, and its protection rules, WAF, and REST API must not block service requests.

Who this plugin is a good fit for, and who should be cautious

FlyingPress is a strong fit for sites that need a single control center for performance. Instead of using one plugin for caching, another for lazy loading, another for font optimization, another for minification, and another for images, you can manage most of those rules from one interface. That is especially useful for agencies or administrators who maintain multiple projects and want a repeatable setup process.

The product's strength is the balance between automation and manual exclusions. For example, Remove Unused CSS tries to identify the styles needed above the fold, but the documentation explicitly mentions safelisting for dynamic elements such as popups, tabs, dropdown menus, sliders, and blocks that only appear after user interaction. Delay All JavaScript should not be enabled as a universal aggressive mode either: the Load after interaction strategy can produce strong lab results, but it is risky for menus, sliders, forms, payments, and interface elements above the fold.

The plugin may not be a good "set it and forget it" option if the site is locked behind HTTP authentication, sits on a private network, runs in a local environment, blocks the REST API, or cannot write files to the required directories. The system requirements documentation specifically calls out public accessibility, a standard WordPress file structure, and write permissions for wp-content/, as well as wp-config.php in certain advanced cases.

Caution is also warranted if the site already uses multiple optimization plugins. FlyingPress recommends against running an additional page cache or page optimization plugin alongside it, because duplicated minification, lazy loading, or caching can break layouts, increase load, and make troubleshooting harder. If the site already relies on LiteSpeed Cache, SiteGround Optimizer, Breeze, Perfmatters, EWWW Image Optimizer, or similar tools, decide first which tool is responsible for each layer of optimization.

What to check before installation

You do not need to conduct an endless technical audit before installing FlyingPress. But there are a few conditions without which it may behave unpredictably or fail to preload pages at all. It is better to review these before uploading the ZIP file, because this step can save hours of troubleshooting later.

Public site accessibility

The system requirements and the troubleshooting guidance for stalled preloading both point to the same requirement: the site must be accessible from the internet. A local project, password-protected staging site, VPN-only domain, HTTP Basic Authentication, or aggressive firewall can prevent FlyingPress cloud servers from fetching pages and running analysis. If you are testing on staging, make sure it is not password-protected and is not blocking external requests.

For private test environments, this is inconvenient but logical. Cloud Optimizer has to see the page the same way a visitor's browser sees it. If the page is only available after you log in, there is nothing for the automation to analyze. In that case, it is better to postpone full configuration until the site is on public staging, or at least run basic checks on a copy of the site with temporary external access enabled.

Versions and write permissions

FlyingPress system requirements define minimum WordPress, PHP, and database versions, along with write access to wp-content/. That matters because the cache, optimized files, and some internal data must be written to disk. If the hosting environment blocks writes, the cache may never be created, images may not be saved, and troubleshooting can look like the plugin itself is broken.

Do not change file permissions blindly to unsafe values. Check this in your hosting panel or with your administrator: WordPress should be able to write to its working directories, but you do not need public write access for every user on the server. If the site uses a nonstandard directory structure, symlinks, or a renamed wp-content, document that before configuration, because the official docs warn about possible unexpected behavior with custom structures.

List of current optimization tools

Before activation, make a short list of what is already optimizing the site: which plugins minify CSS/JS, cache pages, manage lazy loading, optimize images, modify Heartbeat, disable emojis, handle Google Fonts, or integrate with Cloudflare. The goal is not to remove everything. The goal is to eliminate overlap. If FlyingPress delays JavaScript while another plugin is combining and moving the same scripts, the failure will be difficult to trace.

Practical rule: use one primary tool for page cache and front-end optimization. Additional plugins are fine only when their roles do not overlap or are explicitly supported by the documentation.

Installation and initial validation

FlyingPress is installed as a premium WordPress plugin by uploading a ZIP file through the admin dashboard. The documentation notes that it will not appear in the regular WordPress plugin search. This guide does not cover purchasing, payment, or licensing; the focus here is the working setup after the installation file is already in the administrator's hands.

General installation flow

1. Open the WordPress admin dashboard using an account with administrator privileges.
2. Go to Plugins - Add New - Upload Plugin.
3. Select the FlyingPress ZIP file and click Install Now.
4. After installation, click Activate Plugin.
5. Make sure the FlyingPress section appears in the left WordPress menu.

After activation, do not enable the entire optimization stack at once. First confirm that the site opens normally, the admin dashboard still works, and the plugin can save settings. If you see a REST API error immediately after installation, do not move on to cache settings yet: FlyingPress relies on the WordPress REST API to save settings, purge cache, and manage the preload queue.

How to verify that cache is actually working

The official documentation suggests several methods. The clearest one is to open a public page in an incognito window, launch browser developer tools, go to the Network tab, reload the page, and inspect the main HTML request. A cached page should return the header X-Flying-Press-Cache: HIT. A MISS usually means the page has not been preloaded yet or should not be cached.

Additional signs include a comment in the page source and strings containing flying-press, but those should not be treated as the only proof. The documentation warns that the comment may be missing if HTML minification or an external service modifies the code. So the best order is this: check headers first, then review the page source, then inspect the wp-content/cache/flying-press/ directory if you have file access.

If the site uses Cloudflare or another external caching layer, validate both levels separately. First confirm that FlyingPress returns HIT on the WordPress side, then inspect Cloudflare headers such as cf-cache-status. Otherwise you can confuse a situation where the WordPress cache is not ready, but the external proxy is still serving an older response.

Initial setup after installation: a safe sequence

FlyingPress includes many features, but the safest configuration logic is usually the same: enable the base cache first, then preloading, then resource optimizations, then media settings, then external integrations and real metrics. That order reduces risk because you always know which settings group caused the change.

Base cache and preloading

Start with page caching and preloading. Page cache turns public HTML into static files that can be served faster than rebuilding the page through PHP, plugins, the theme, and the database on every request. Preloading matters because you do not want a real visitor to be the first person who gets a slow MISS after the cache is cleared.

For a standard site, leave automatic purging and preloading after content changes enabled if the plugin is running reliably. For a large site with thousands of pages, weak shared hosting, or frequent bulk product updates, do not chase maximum preload speed. The FlyingPress changelog puts a lot of attention on reducing load during preloading, but that does not replace basic judgment: if the server is overloaded, increase the delay between requests or preload the most important pages first.

What counts as a successful result

After you purge the cache, the first check may show MISS and the second one may show HIT. That is normal. A successful setup is not one where every URL instantly becomes HIT. It is one where key pages consistently move into cache, dynamic states remain intact, and the server does not become overloaded in the process.

Cache exclusions

FlyingPress lets you exclude pages using URL keywords. Regex is not supported; it uses plain text matching. That is convenient, but it requires precision. If you add an overly broad fragment such as /, you can exclude the entire site. If you add the word page, you may accidentally bypass cache for many URLs that happen to contain it.

For dynamic pages, use specific fragments such as checkout, account, dashboard, results, or quote. FlyingPress automatically excludes WooCommerce cart, checkout, and account pages, but for other e-commerce, membership, or LMS scenarios, you still need a manual URL map.

Cookies and query parameters

If the content changes based on a cookie, the cache must account for that state or bypass cache for it. The documentation for Bypass Cache for Cookies explains the principle simply: if a request includes a specified cookie, the page is not served from cache, WordPress handles it normally, and the static HTML is skipped. This is useful for carts, language selection, currency switching, personalization, and some filtered experiences.

The downside is obvious: the more bypasses you add, the lower your cache hit ratio becomes. That is why cookie exclusions are not a universal fix. First check whether the issue can be solved in the theme or script layer instead. For example, a WooCommerce cart counter should usually update through AJAX; if the theme does not do that, the woocommerce_items_in_cart cookie can serve as a temporary fix, but the documentation warns that it will reduce the share of cached responses.

CSS and JavaScript: where optimization most often breaks the interface

CSS and JavaScript optimization usually has a noticeable effect on LCP, INP, and overall page responsiveness, but it is also the most common source of breakage. FlyingPress can remove unused CSS, minify assets, delay scripts, and load them at different moments. The trouble begins when those features are treated as automatically safe in every case.

Remove Unused CSS and selector safelisting

According to the documentation, Remove Unused CSS extracts the CSS needed for the initially visible viewport, inlines it into the HTML, and loads the remaining CSS files asynchronously when the browser is free. That helps eliminate render-blocking styles and speeds up the first render. But elements that are hidden at first or only appear after user interaction may not be detected automatically.

Typical safelist candidates include a sticky header, dropdown menu, popup, modal window, tabs, slider, gallery, mobile menu, and page builder blocks that appear only after a click or scroll. In FlyingPress, you need to add CSS selectors or clear selector fragments, not file names. The documentation directly points out that style.css or theme.css will not solve the problem, while .header-sticky, .popup-overlay, or .wp-block-gallery will.

Quick check before safelisting

If a menu or popup loses its styling after you enable Remove Unused CSS, do not safelist the entire theme CSS file. Inspect the broken element in the browser, identify its class, and add the most specific selector possible. Then purge and preload the cache, test the page in incognito mode and on a mobile viewport. The goal of a safelist is to preserve the required dynamic styling, not to restore all the extra CSS.

Delay All JavaScript without blindly going all-in

The FlyingPress documentation describes three script delay strategies. Defer loading uses the standard browser behavior: scripts load in the background and execute after HTML parsing. Load when idle starts scripts when the browser is idle after the important content is handled. Load after interaction waits for user action such as scrolling, clicking, or another interaction.

On a simple content site, aggressive delay may work without obvious side effects. On a WooCommerce site, a page builder site, a site with a complex mobile menu, cookie notice, forms, sliders, or chats, it can easily break the first screen. A practical workflow is to start with the less aggressive strategy, verify every interactive element, and then selectively delay third-party scripts that clearly are not needed before interaction.

FlyingPress lets you exclude scripts using partial keywords. It checks the entire <script> tag: src, id, and inline content. Wildcards are not needed and are not supported. For Contact Form 7, you can use fragments such as contact-form-7; for a theme, an ID or part of the path; for an inline script, a function or variable name. Chrome DevTools Coverage is useful here: it helps you spot unused CSS/JS, but the actual decision still has to be verified manually across pages that use different templates.

Minification and testing order

CSS and JavaScript minification is usually less risky than aggressive delay, but on older themes and nonstandard scripts it can still cause issues. Enable it after the base cache and before Delay All JavaScript if you want to isolate the source of a problem. If you turn everything on at once, you will not know what actually broke the menu: minification, defer, delay, unused CSS, or an external plugin.

After each settings group, test more than just the homepage. Open a blog post, category archive, form page, product page, cart, account area, search page, and mobile menu. Performance should be optimized for the site as a whole, not just for a pretty homepage report.

Images, fonts, and media: how not to make LCP worse

A large portion of the visual weight on a WordPress site often comes from images, fonts, videos, iframes, and avatars. FlyingPress addresses several tasks at once: lazy loading below the fold, automatic detection of above-the-fold media, preloading of important images, format optimization, local Google Fonts hosting, and lightweight YouTube previews.

Lazy load and the above-the-fold area

The lazy load documentation explains the principle clearly: media below the fold should be marked with loading="lazy", while media above the fold should load immediately with loading="eager". FlyingPress can also preload key above-the-fold images to help Largest Contentful Paint. That is useful for hero images, large product cards, and video posters that are visible right away.

If PageSpeed Insights reports that the LCP image loads too late, first check whether it was included in lazy loading. If it was, add a more precise keyword exclusion: the file name, part of the URL, the image class, or an alt-text fragment. Do not use an overly broad term such as image or hero if it appears in many places. The broader the exclusion, the more media will start loading immediately, and the smaller your performance gain will be.

Built-in image optimization

Built-in image optimization became a major standalone feature in FlyingPress 5.x. The official docs describe the process this way: originals are sent to FlyingPress Image Optimizer, optimized versions are returned based on your settings, saved in the uploads folder, and URLs in the content are rewritten to point to the optimized files. JPG/JPEG and PNG are supported; you can choose WebP, AVIF, or keep the original format, along with lossy or lossless compression.

For most sites, the safest workflow is to create a backup first, choose the format and compression type, optimize a small batch or test only new uploads, confirm the images still look correct, and only then run bulk processing. The documentation specifically highlights restoring originals and deleting originals. Deleting originals is permanent, so it should not be done until you are confident in both your backups and the visual result.

Fonts and external media

Self-hosting Google Fonts, preloading fonts, and prioritizing system fonts can reduce external requests and lower the risk of text shifts. But once font settings are enabled, always verify the typography: headings, buttons, forms, menus, Cyrillic support, bold weights, and the mobile layout. If the site uses a custom font only in the logo or in a few isolated blocks, do not draw conclusions from a single page too early.

For YouTube, FlyingPress can generate lightweight previews so the heavy video player code does not load immediately. That is helpful for blogs, reviews, tutorials, and landing pages with multiple embeds. But if a video sits above the fold and is the main content of the page, make sure deferred loading is not making the user journey worse.

Cloudflare, FlyingCDN, and external cache

When a site serves visitors from different regions, local WordPress caching alone may not be enough. FlyingPress offers Cloudflare integration for full-page caching at the edge. According to the documentation, regular Cloudflare caches static files by default, while the FlyingPress integration lets Cloudflare cache HTML pages, reduce origin server load, and automatically purge Cloudflare cache when content changes.

The important detail here is rule synchronization. Pages excluded from cache in FlyingPress are also excluded in Cloudflare; ignored query strings and bypass cookies need to stay aligned as well; and separate mobile cache in FlyingPress enables Cache by Device Type in Cloudflare. That matters because two unsynchronized cache layers can serve different versions of the same page.

How to verify edge cache

Use DevTools or a dedicated TTFB test for validation. The first request after a purge will often be MISS; the next one should become HIT if the page is cacheable. On the Cloudflare side, check cf-cache-status; on the WordPress side, inspect X-Flying-Press-Cache. If one layer shows HIT and the other shows MISS, do not jump to conclusions: determine which layer is actually serving the current response.

The FlyingPress documentation advises disabling Cloudflare APO before enabling the integration in order to avoid conflicts. That does not mean APO is inherently bad. It means the same HTML cache should not be controlled by two separate systems that know nothing about each other's rules.

When a CDN will not solve the problem

A CDN will not fix heavy JavaScript, broken images, slow SQL queries in the admin area, a poorly built theme, or a third-party widget that blocks the main thread. It improves delivery and can reduce TTFB for visitors far from the origin server, but LCP, INP, and CLS still depend on the page structure itself. That is why external cache should be enabled after the basic FlyingPress setup is already working, not instead of it.

FlyingPress mode map: what to enable immediately and what to enable only after testing

To avoid treating the FlyingPress interface as one long list of toggles, it helps to divide settings into three groups: foundational, conditionally safe, and settings that require manual verification. This does not replace the documentation, but it does help separate different levels of risk. Page cache and preload usually come first because they create the foundation. CSS/JS optimization, lazy render, media exclusions, and Cloudflare page cache should come only after base caching is confirmed through headers.

Foundational settings

The foundational group includes page caching, cache preloading, automatic purging of related pages, and cache status verification. On a standard public site without personalization, these features create a clear mechanism: WordPress builds the page once, FlyingPress stores the result, and the next visitor gets ready-made HTML. If something goes wrong at this stage, the search area is still fairly small: write permissions, site accessibility, the REST API, exclusions, or a conflict with another caching layer.

Basic minification can also fit in this group if the site uses a modern theme and does not rely on old custom scripts. Even then, manual validation is still necessary. Minification changes files, not business logic, but older JavaScript sometimes depends on formatting, order, or obscure global variables. If the site is older, enable minification as a separate step.

Conditionally safe settings

The conditionally safe group includes lazy loading for below-the-fold media, self-hosted Google Fonts, preload for important fonts, and image optimization with originals preserved. These settings usually do not break the interface as dramatically as aggressive JavaScript delay, but they can affect LCP, visual quality, and text shifting. That is why they should be tested across different types of content: a post with a large image, a product card, a gallery, a video page, a form page, and the homepage.

If you enable the built-in image optimization, do not judge it only by the percentage of saved bytes. Inspect real images: faces, logos, text-based illustrations, products, UI screenshots, and dark photos. Lossy compression often looks acceptable on ordinary photos, but it can damage fine text and high-contrast edges. That matters much more on a product catalog or tutorial screenshot site than on a blog with decorative illustrations.

Settings that require a manual exclusion map

The most sensitive settings are Remove Unused CSS, Delay All JavaScript, separate mobile cache, cache for logged-in users, bypass cookies, query parameter cache variations, and full-page Cloudflare caching. They are useful, but they depend entirely on how the site is built. For example, separate mobile cache is not needed for every responsive site; it makes more sense when the mobile version really serves different HTML or different interface elements. Cache for logged-in roles can help on projects with repeatable account dashboards, but it is risky when the content is personal.

For each of these features, ask the same question: what input changes, how will FlyingPress process that input, what HTML or asset will the visitor receive, how will we verify the outcome, and what symptom will reveal a mistake? If you cannot answer that, the feature should stay off until it is tested. Optimization should be explainable: input - rule - result - validation - rollback.

This approach is especially useful on sites that support sales or client work. When an owner asks why the most aggressive script delay strategy is not enabled, you have a clear answer: because you first need to confirm that the above-the-fold experience and key user actions do not depend on those scripts. That is engineering logic, not caution for its own sake.

Practical scenario: speeding up a store without breaking the cart

Consider a realistic WooCommerce setup: a store with a homepage, catalog, product pages, cart, checkout, account area, a mini-cart in the header, and several marketing scripts. The goal is to speed up public pages and product views without caching personal states.

Goal and preparation

The goal is to achieve stable caching for the homepage, category pages, posts, and product pages, reduce CSS/JS and image weight, and preserve a correct cart and checkout flow. Before you begin, create a backup, disable any overlapping page cache, confirm that the site is publicly accessible, and prepare a list of pages for manual testing: /shop/, a product page, a category page, /cart/, /checkout/, /my-account/, a search page, and a page with a form.

Configuration steps

1. Enable the base cache and preload, then verify X-Flying-Press-Cache on the homepage and on a product page.
2. Confirm that Cart, Checkout, and My Account are not being served like ordinary cached pages. The documentation says FlyingPress excludes them automatically for WooCommerce, but manual verification is still necessary.
3. Enable Remove Unused CSS, purge the cache, and test the menu, catalog filters, popup, sticky header, and product gallery.
4. Enable Delay All JavaScript with a moderate strategy, then test add-to-cart, the mini-cart, variation selection, coupons, and checkout.
5. Configure lazy loading and image optimization. If the homepage or product LCP image is being deferred by mistake, add an exclusion.
6. If the cart counter does not update, check whether the theme refreshes it via AJAX. If not, add the woocommerce_items_in_cart cookie to Bypass Cache for Cookies, understanding that this will reduce the cache hit ratio for visitors who have items in their cart.

How to validate the result

After configuration, test two user paths. The first is a new visitor with no cookies: homepage, category page, product page, and add-to-cart flow. The second is a visitor with an item already in the cart: quantity updates, browsing the catalog, mini-cart behavior, and checkout. If public pages return HIT while personal actions still work correctly, the setup is moving in the right direction.

For metrics, do not rely on a single PageSpeed Insights run. Google Web Vitals distinguishes between lab data and field data; FlyingPress Vitals, if enabled, collects LCP, INP, CLS, and TTFB from real visitors through a small asynchronous script and displays the data in a separate tab. On low-traffic sites, the numbers can fluctuate, so meaningful conclusions are better drawn after enough data has accumulated.

An important nuance for filters, currencies, and personalization

If the store changes content based on query parameters, cookies, currency, or language, do not add exclusions blindly. First determine what actually changes the HTML: the URL, a cookie, AJAX, local storage, or server-side logic. Then use the matching FlyingPress mechanism: exclude pages, separate cache for query parameters, bypass cookies, or a theme-level fix. Otherwise you may either cache the wrong version or disable caching where it would have been safe.

Validating results: not just PageSpeed

After configuring FlyingPress, the results should be checked on three levels: technical caching, visual integrity, and user-facing performance metrics. A single strong lab score does not prove the site is better. It only shows that one specific test on one specific page has fewer issues. For a production site, stability across different templates and the absence of regressions matter more.

Technical level

• The main HTML request for a public page shows X-Flying-Press-Cache: HIT after preloading.
• With Cloudflare integration enabled, a repeated external request shows the expected cf-cache-status.
• The page source or loaded assets contain signs of FlyingPress optimization when those features are enabled.
• Cache files appear in wp-content/cache/flying-press/ if you have filesystem access.
• After updating a post or product, related pages are purged and then preloaded again.

Visual and functional level

Check the above-the-fold area, mobile menu, sticky header, forms, search, filters, gallery, popup, lazy-loaded sections, comments, video, map, checkout, and account area. Do this both in incognito mode and under a logged-in user if the site has roles. If something breaks, do not disable all of FlyingPress. Roll back the last settings group and isolate the problem: CSS, JavaScript, lazy loading, cache exclusion, or external cache.

Metrics and expectations

FlyingPress Vitals is useful because it shows real visitor data, not just lab simulation. The documentation references LCP, INP, CLS, and TTFB, along with device and date filters, plus page-level and country-level breakdowns. That helps you see where the problem actually lives: on all pages, only on mobile devices, in a specific country, on one product page, or after a theme update.

A solid validation process is a combination of: cache HIT status, a stable interface, improved problem resources in DevTools, no console errors, correct dynamic page behavior, and gradual improvement in field metrics. If only one report improves while users complain about the cart or menu, the optimization work is not finished.

Safe improvements and small technical techniques

FlyingPress includes documented filters for developers. Use them only when the regular interface settings are not enough. Every example below is reversible: it can be removed from Code Snippets, a child theme, or a small custom plugin. Do not put them into WordPress core, FlyingPress files, or the parent theme.

Exclude the homepage from cache only when there is a specific reason

In most cases, the homepage should absolutely be cached. But if it contains server-side personalization, a temporary A/B block, or geo-dependent content, you can use the documented filter. The page exclusion documentation shows an example using flying_press_is_cacheable. Before using it, make sure standard URL exclusions do not already solve the problem.

add_filter('flying_press_is_cacheable', function ($is_cacheable) {
  // Do not cache only the homepage; leave all other FlyingPress rules unchanged.
  if (is_front_page() || is_home()) {
    return false;
  }

  return $is_cacheable;
});

Validation: purge the cache, open the homepage in incognito mode, and inspect the X-Flying-Press-Cache header. Then open a normal post or category page and make sure they still transition to HIT. Rollback: disable the snippet and purge the cache again.

Do not break the return value

The documentation for conditional cache control emphasizes this point: if your condition does not apply, return the original $is_cacheable. Do not return true "just in case." FlyingPress already accounts for user status, cookies, query parameters, and other conditions. If you forcibly return true, you may allow caching in situations where the plugin intentionally meant to bypass it.

When it is better to avoid code

For CSS selectors, lazy load exclusions, bypass cookies, and page exclusions, the FlyingPress interface is usually enough. Code is only needed for conditions that cannot be expressed with standard keyword matching. If the task is "exclude any URL containing checkout," use the settings. If the task is "do not cache the homepage only when a server-side campaign flag is active," then a filter may be justified.

Common FlyingPress issues and troubleshooting

Optimization problems are rarely random. Usually there is a symptom, a settings group, and a test that quickly narrows down the cause. Below are situations confirmed by FlyingPress documentation or typical of this class of plugin.

Error: "Unable to communicate via REST API"

Symptom: settings do not save, cache purging or preloading will not start, and the interface shows a REST API availability error. Possible causes: a security plugin, WAF, hosting firewall, server overload, PHP error, or restricted public access to /wp-json/.

Start by opening https://your-site.com/wp-json/ in a browser. If that endpoint is unavailable, FlyingPress will not be able to perform part of its operations. Then check your protection settings, firewall rules, PHP error log, and /wp-content/debug.log if WordPress debug is enabled. The fix is to allow the REST API, remove the block for the required endpoints, reduce preload load, or resolve the PHP error. Rollback means temporarily disabling the last security or performance setting that was enabled before the error appeared.

Preloading does not start or gets stuck

Symptom: the preload queue does not move, pages stay at MISS, and the interface appears stuck. Causes: the site is not public, is behind HTTP authentication, blocks FlyingPress Cloud Optimizer requests, the REST API is unavailable, or the server does not meet requirements.

The documentation states that preload servers may come from different regions, and a fixed IP allowlist is not provided. A more reliable approach is to allow a User-Agent containing the keyword FlyingPress. Also check Tools - FlyingPress Queue - Test REST API if that tool is available in your version of the interface. If the server is weak, increase the preload delay and avoid running bulk purges during peak traffic.

The menu, slider, or form broke after optimization

Symptom: the menu does not open, the slider does not move, the form does not submit, the popup loses its styling, or the mobile header looks wrong. Causes: critical JavaScript was delayed, dynamic CSS was not included in used CSS, lazy render deferred an important block, or another plugin is minifying the same assets at the same time.

What to check: disable the last enabled settings group, purge the cache, and test again. If Remove Unused CSS is responsible, add specific selectors to Include CSS Selectors. If Delay All JavaScript is responsible, add a partial script keyword to the exclusions or choose a less aggressive strategy. If the problem appears only in the mobile menu, check the classes for the mobile element specifically, not the desktop menu.

WooCommerce cart counter does not update

Symptom: a product is added, but the mini-cart or header counter still shows the old value. Cause: the theme may not refresh the cart count via AJAX, while the visitor is still receiving a cached page. The FlyingPress documentation suggests adding the woocommerce_items_in_cart cookie to Bypass Cache for Cookies.

The fix works, but it lowers the cache hit ratio for visitors who already have items in the cart. That is why the better long-term solution is to ask the theme developer to implement AJAX-based cart updates. Rollback: remove the cookie from the bypass list, purge the cache, and verify whether the previous cache behavior returns.

Images were optimized, but quality or LCP got worse

Symptom: some images look worse, the LCP image loads too late, the hero image was included in lazy loading, or the optimization queue is taking too long. Causes: overly aggressive compression, the wrong format for a specific graphic, no exclusion for the above-the-fold area, or an oversized batch running in the background.

Check more than the overall file size. Review actual visual quality on retina and mobile displays. If the problem is lazy loading, add a specific exclusion for the LCP media. If the problem is the format or compression type, restore the originals using the built-in function while they still exist, adjust the settings, and repeat the test on a smaller batch. Do not delete originals until you have validated the result and confirmed your backups.

Cloudflare shows MISS or serves stale HTML

Symptom: the WordPress cache was purged, but an external visitor still sees the old page, or cf-cache-status stays at MISS where you expected HIT. Causes: the DNS record is not proxied, Cloudflare APO is still enabled, FlyingPress and Cloudflare rules are not synchronized, the page is excluded, the visitor is logged in, or a bypass cookie is present.

Check it layer by layer: first FlyingPress HIT/MISS, then Cloudflare HIT/MISS. Make sure the DNS record is enabled through the orange cloud, APO is not conflicting with the integration, and the page did not end up in the exclusion list. After a purge, the first request may be MISS - that is normal. What matters is the repeated request and correct purging after content changes.

When FlyingPress is the right choice

FlyingPress is a strong choice if you want one capable WordPress optimization hub: cache, preloading, CSS/JS, images, fonts, media, Cloudflare workflows, and real Core Web Vitals data. It is especially useful when the site owner wants more than file compression and is aiming for a controlled process: enable a feature, verify the result, add an exclusion, and keep the public-facing site stable.

Before a production rollout, verify the requirements, remove overlapping optimizations, enable settings in groups, and document your changes. For a store or membership site, pay special attention to cookies, query parameters, dynamic pages, and checkout. For a complex design, check hidden elements, menus, sliders, popups, and forms after enabling Remove Unused CSS and Delay All JavaScript.

If you now understand which pages should be cached, which ones should bypass cache, how to verify HIT/MISS, where to look for broken CSS/JS, and how to roll back a questionable setting, you are ready to test it on your own site. Near the download section, there is a link to get the WordPress version and evaluate the plugin in a controlled environment.

The main thing is not to turn optimization into a race for a single score. WordPress acceleration matters when visitors can see the right content faster, open the menu, add a product to the cart, submit a form, and avoid visual jumping. FlyingPress gives you a strong toolkit for that, but the quality of the outcome still depends on careful configuration and validation on a real site.