GUIDE 01
Start here
A controlled setup beats switching everything on at once.
1. Install and activate
Download the FlyWP Cache ZIP from your Account. In WordPress, open Plugins → Add New Plugin → Upload Plugin, select the ZIP, install and activate it. FlyWP Cache 1.0.0 requires WordPress 6.2 or later and PHP 8.1 or later. An administrator account is needed to change its settings.
2. Check the environment
Open FlyWP Cache → Dashboard and review the health checks. Page caching needs a writable wp-content/cache/flycache/ directory, the FlyWP Cache advanced-cache.php drop-in and WP_CACHE enabled. If another plugin owns the drop-in, resolve that conflict before enabling FlyWP Cache page caching. Image generation also depends on the image formats supported by your server.
3. Establish a baseline
Back up the site and record how a few representative pages behave before changing settings. Include the homepage, a content page, search, a product page and the complete purchase flow. Use an anonymous browser session for cache testing.
4. Enable features in stages
Start with Page Caching, save, then visit the same public page twice. Add CSS, JavaScript and media optimizations one group at a time. Purge cached pages after changes and retest desktop, mobile and interactive components. Add cache preloading after normal caching works.
What is enabled by default?
Page caching, CSS delivery optimization, JS minification/defer/delay, lazy loading, font optimization, preloading, Cloudflare and Script Manager start disabled. AVIF/WebP generation and source-image optimization have enabled defaults. Check the Media tab before uploading images. Existing installations retain their saved configuration.
Back to contents ↑GUIDE 02
License & updates
Activate a site, manage your installations and stay on the current release.
Activate a license
Copy your key from Account → Licenses. In WordPress, open FlyWP Cache → License, enter the key and activate this website. The license screen displays status, plan, website allowance, active websites and validity. Keep the key private.
Move or change a license
Deactivate the current website before switching keys or moving its activation to another website. Use Refresh status after changing the license in your account. A temporary license-server error preserves the last known license state; license checks do not disable the existing page cache.
Install updates
With a valid active site license, use the normal WordPress Plugins or Updates screen. Back up before updating and check important pages afterwards. If an update download fails, refresh the license status and retry. Persistent HTTP errors need the exact error message and environment details; do not post a license-bearing download URL publicly.
One license for updates and CSS
The activated FlyWP Cache license authorizes updates and Remove Unused CSS for this website. No separate SaaS API key is required. The CSS service checks FluentCart on every generation request and result poll. Missing, expired, revoked or inactive site licenses are rejected. After renewal or reactivation, use License → Refresh status. This requires FlyWP Cache SaaS 1.1.0 and store-side FlyWP Cache Commerce 1.0.2.
Back to contents ↑GUIDE 03
Page caching
Serve reusable HTML for public pages.
Enable Page Caching
Settings → Cache writes eligible pages as static HTML. The early advanced-cache.php drop-in can serve a warm page before most WordPress code runs. The first request may generate the page; subsequent eligible requests can reuse it. FlyWP Cache is a page cache, not a replacement for a persistent object-cache service.
Mobile Cache and lifespan
Mobile Cache creates separate mobile and desktop cache variants. Use it when the server produces different HTML for mobile visitors; a responsive CSS layout alone does not necessarily need it. Cache Lifespan is measured in hours and defaults to 10. A value of 0 disables time-based expiry, so content freshness depends on purging.
Requests that should stay dynamic
Caching is intended for successful public GET requests returning HTML. Admin, login, REST, feeds and password-protected contexts are excluded. Logged-in, post-password, commenter and WooCommerce cart/session cookies also prevent normal page-cache reuse. Verify personalized pages with their actual cookies and URLs.
Exclude one page
In the WordPress post/page editor, open FlyWP Cache Options and select Exclude from Page Cache. Saving purges that page. For broader rules, use Advanced → Never Cache. Excluding a page from the page cache does not by itself disable every CSS, JS or media optimization.
Back to contents ↑GUIDE 04
Clearing & rebuilding cache
Know which layer is still holding the older version.
Automatic invalidation
When page caching is enabled, public content changes trigger purging. Hooks cover posts, pages, products, variations, WooCommerce stock changes and comments/reviews. Relevant homepage, blog/shop and taxonomy URLs are included. Menu, theme, Customizer and permalink changes trigger a full purge.
Changes beyond the current page
Use Advanced → Always Purge (URLs) for additional pages that depend on changed content. For example, a custom landing page with product information may need invalidation when the product changes. Add one URL per line.
After a redesign
Clear generated Used CSS when the stylesheet or layout changes, then allow it to regenerate. Clear the page cache and any connected server/CDN cache as needed. A browser cache can still show old assets after the WordPress cache has been cleared.
Warm pages again
With cache preloading enabled, a full clear can start a new warming queue. Purged URLs can also be scheduled for rewarming. Processing depends on scheduled jobs and successful requests back to the site; a purge is not proof that warming has already finished.
Back to contents ↑GUIDE 05
CSS optimization
Cut stylesheet weight and control how your CSS is delivered.
Minify CSS
Settings → CSS → Minify CSS removes unnecessary whitespace and comments from eligible stylesheets. Use Minify Exclusions for files that must remain untouched. Save and clear the page cache after changing exclusions, then inspect the rendered result.
Choose one delivery method
Optimize CSS Delivery offers Remove Unused CSS or Load CSS Asynchronously. These are alternative methods. RUCSS generates used styles for a URL; async loading changes when complete stylesheets load and allows custom Fallback Critical CSS for the initial viewport.
Remove Unused CSS setup
Activate a valid FlyWP Cache license under FlyWP Cache → License, enable CSS delivery optimization and select Remove Unused CSS. The client sends the page URL, safelist and desktop/tablet/mobile viewport context to the service. The service must be able to access the page. Password protection, bot challenges or blocked requests can prevent processing.
Generation and fallback
Eligible anonymous page visits queue missing results. While a result is pending or failed, FlyWP Cache keeps the original HTML/CSS. Completed used CSS is inserted inline and original eligible stylesheets are removed. Missing generated files trigger regeneration. Standard logged-in browsing is not a reliable test of RUCSS output.
Dynamic states and the safelist
Open dropdowns, accordions, popups, tabs, forms and mobile navigation when testing. If a style is used only after interaction, add its selector to CSS Safelist, one per line, then regenerate Used CSS. A good initial appearance alone does not establish that all states are covered.
Async Transport is a separate setting
Async Transport (Cloudflare-safe) dispatches CSS-generation jobs and polls for their results instead of holding one long service request open. It is useful behind proxies with request timeouts. It is different from the Load CSS Asynchronously delivery method.
Using asynchronous stylesheets
Select Load CSS Asynchronously and supply critical CSS for above-the-fold content where needed. FlyWP Cache retains a noscript fallback. Check for a flash of unstyled content and layout shifts on a slow connection. If the initial view breaks, adjust the critical CSS or turn this method off while investigating.
Back to contents ↑GUIDE 06
JavaScript optimization
Treat minification, defer and delay as three separate decisions.
Minification
Minify JavaScript reduces eligible JS files. Its exclusions are separate from defer and delay exclusions. Test the browser console and functional behavior after enabling it; an error-free page load is only the start of the check.
Defer JavaScript
Defer lets eligible external scripts execute after document parsing. Already asynchronous or deferred scripts are treated separately. The optional Defer Inline JS & jQuery setting is more aggressive and can affect dependency order. Start with basic defer before testing inline handling.
Delay JavaScript Execution
Delay postpones eligible scripts until user interaction. Check navigation, sliders, consent, analytics, forms, search, carts and payment widgets. Anything that must initialize immediately needs an appropriate exclusion; improved lab scores are not useful if a key interaction stops working.
Safe Mode and Click Replay
Delay JS Safe Mode applies delay only for logged-in administrators, allowing initial tests without changing ordinary visitor behavior. This is not a full anonymous-cache test. Click Replay replays the initial interaction after scripts load to address first-tap problems; verify it with your own mobile controls.
Fix an affected script
Use the relevant Minify, Defer or Delay Exclusions field. Add identifiable script URL fragments or matching script text, then save, purge and retest. Quick Exclusions provide presets for selected common libraries/plugins. Keep dependent scripts together when diagnosing ordering problems.
Availability note
The Visual Script Picker shown in the JavaScript settings is marked Coming soon in 1.6.3. Do not confuse that placeholder with the working frontend Script Manager described below.
Back to contents ↑GUIDE 08
Image optimization
Generate modern variants and stay in control of source-image processing.
Server support
AVIF/WebP generation uses supported local image libraries. FlyWP Cache checks GD and Imagick format capabilities; enabling a toggle cannot add a missing server encoder. SVG files are not converted. Check a small sample upload before processing a large library.
Quality defaults
AVIF quality defaults to 60, WebP to 82 and JPEG to 84. PNG compression defaults to level 9; progressive JPEG and GIF optimization are enabled in the default configuration. Lower lossy quality can reduce file size but may affect detail. Compare product images, gradients and small text visually.
Source files and backups
Source JPEG/PNG/GIF optimization is separate from serving a modern variant and can change original files. Keep an independent backup before bulk operations. In the current generator, disabling both AVIF and WebP also skips that generation pipeline; do not assume source optimization will continue independently in that state.
Existing media library
Generate Missing AVIF/WebP fills gaps; Regenerate All reprocesses existing images. Delete Generated Files removes variants, while Cleanup Orphaned Files targets unneeded generated files. These actions are different from page-cache clearing. Run a sample first and allow sufficient server resources.
Delivery and LCP
Eligible images are wrapped with picture sources for available formats while retaining a fallback image. LCP Image Optimization can prioritize leading images; its default count is 2 when enabled. WooCommerce Product LCP targets the main product image. Avoid assigning high priority to many noncritical images.
Async generation and large uploads
Async Image Generation schedules processing through WP-Cron so uploads can finish before variants are ready. Until processing completes, modern files may not yet be available. Big Image Threshold defaults to 2560 pixels and controls the size at which WordPress scales large uploads.
Back to contents ↑GUIDE 09
Fonts
Control font hosting, preload and display behaviour.
Self-Host Google Fonts
FlyWP Cache detects supported Google Fonts stylesheet links, downloads their CSS/font resources and serves cached local versions when downloads succeed. The server needs outbound access and writable cache storage. Inspect frontend requests after enabling it; unsupported loading patterns may still contact external hosts.
Smart Auto-Preload
Automatic preload inspects supported font stylesheets and identifies font resources, including Latin subsets. It operates independently of self-hosting. Confirm it targets the fonts used in the first viewport, especially on multilingual sites.
Manual preload and display swap
Preload Fonts accepts font-file URLs, one per line. Add only files needed early; excessive preload competes with images and other critical requests. Display Swap keeps text visible during font loading. Test for visual shifts when the fallback and final font metrics differ.
Back to contents ↑GUIDE 10
Cache preload & Instant Pages
Server warming and browser prefetching solve two different problems.
Cache Preload
Settings → Preload → Preload Cache crawls sitemap URLs to warm pages. Detection includes common sitemap_index.xml, sitemap.xml and wp-sitemap.xml locations, including nested sitemap indexes. Add unwanted URLs to Exclude URLs from Preload, one per line.
Queue requirements
Warming runs in scheduled batches and uses a queue lock. A blocked loopback request, inaccessible sitemap or cron that never runs can stall progress. If WP-Cron is disabled, your host must provide a working replacement scheduler. Review queue/health information before repeatedly restarting jobs.
Instant Pages strategies
Instant Pages (FlyInstant) prefetches links in a visitor’s browser. Hover waits briefly before prefetching; Mousedown starts on click/touch; Viewport combines visible-link prefetch with hover. Hover is the default strategy, with a 65 ms delay and a configured concurrency limit of 3.
Bound the extra requests
Stop on Server Error defaults to enabled. Ignore Keywords can prevent prefetching of login/logout, cart actions and other dynamic URLs. Review these rules for your own shop and account routes. Prefetch adds traffic; check host load before choosing the most aggressive strategy.
Back to contents ↑GUIDE 11
Script Manager
Remove assets from the pages that do not need them.
Open the manager
Enable Script Manager in its settings tab. While logged in with the required administrator access, visit the frontend page and use the admin-bar entry or append ?flycache_scripts to its URL. For an existing query string, use &flycache_scripts.
Start with a narrow rule
Identify the script or stylesheet and disable it on the current page first. Available conditions include everywhere, current pages, post types, archives, login state, device type and URL regular expressions. Enable exceptions keep an asset on matching pages even when a broader disable rule applies.
Example: a form asset
If a form is used only on your contact page, first confirm which assets belong to it. Test a disable rule on an unrelated page, then consider a broader rule with a contact-page exception. Include any popup or footer forms in that decision.
Testing Mode and dependencies
Testing Mode applies asset-disabling rules only for administrators. Display Dependencies helps reveal relationships between scripts. After testing, turn Testing Mode off deliberately, clear caches and verify an anonymous session. Browser usage hints cannot prove an asset is unnecessary in every interaction.
MU Mode
MU Mode installs a must-use helper that can prevent selected plugins from loading at PHP level. This is broader than removing a CSS/JS file: queries, hooks and rendering logic can disappear. Use it only for carefully tested page-specific cases and confirm the helper installation status after saving settings.
Expert, export and reset controls
Expert Mode exposes protected assets such as jQuery, admin-bar and FlyWP Cache scripts. Keep it off unless you understand the dependency. Script Manager has its own JSON export/import with merge or replace options. Reset Everything removes its rules and exceptions; export them first.
Back to contents ↑GUIDE 12
Advanced cache rules
Make cache behaviour match how your content actually works.
URLs, cookies and user agents
Never Cache (URLs) supports one rule per line, including URL/path matches, wildcard patterns and regular expressions. Never Cache (Cookies) matches cookie names and supports wildcards. Never Cache (User Agents) matches specified user-agent strings. Test every rule with an actual request.
Useful URL exclusions
Exclude personalized account, checkout, receipt, membership and session-dependent routes. For example, /account/* and /checkout/* are wildcard-style rules; adapt them to your actual paths and test the base URLs too. Avoid a bare slash-delimited path being mistaken for a regular expression.
Ignored query strings
Ignore Query Strings serves the normal cached version without creating a separate variant for that key. Built-in examples include marketing keys such as utm_* and fbclid, and also ref. Do not ignore a parameter that changes content, permissions, pricing or required server-side tracking.
Cache Query Strings
This list allows selected parameters to produce separate cache variants. Unrecognized parameters normally prevent caching. Keep the allowlist small to avoid generating excessive variants and verify the early drop-in behavior after saving.
Affiliate and personalized flows
A referral parameter may need PHP to run to set a tracking cookie. Because ref is ignored by default, verify real anonymous referral attribution with every cache layer active. Do not assume the affiliate integration works solely because a referral URL opens successfully.
Back to contents ↑GUIDE 13
Cloudflare, NGINX & deployments
Keep FlyWP Cache in step with the infrastructure around WordPress.
Cloudflare purge integration
Enable Cloudflare Integration and enter an API token and the correct Zone ID. The token needs permission to purge cache for that zone. FlyWP Cache synchronizes full and URL purges, including relevant Used CSS events. Check the dashboard’s credential status and verify a real purge.
What Cloudflare setup does not imply
Configuring purge credentials does not create a complete edge-caching policy or configure DNS for you. Keep personalized routes and session cookies excluded in your CDN rules as well. After a change, inspect both the origin response and the response visitors receive through Cloudflare.
NGINX FastCGI
Purge FastCGI Cache clears an already configured server cache. The default discovery path is /etc/nginx/cache/{domain}; Custom Cache Path overrides it. The directory must exist and be accessible to the process. This integration does not install or configure NGINX caching.
FlyGit deployments
Advanced → Auto-Purge after Deployments integrates with FlyGit 2.1+. It reacts to deployments by attempting an OPcache reset, purging page/connected caches and rewarming through the preload queue. Verify the deployment hook and warming on your environment before relying on it.
Back to contents ↑GUIDE 14
Database maintenance
Choose exactly what may be removed — and nothing beyond it.
Cleanup categories
Database settings cover revisions, auto drafts, trashed posts, spam comments, trashed comments, expired transients and table optimization. Run Cleanup Now uses the selected categories. Normal drafts are not the same as auto drafts.
Deletion is permanent
Revision cleanup removes stored revisions; 1.6.3 does not implement a keep-last-N revision policy. Trashed posts/comments and selected other records are permanently removed. Create a restorable database backup and review the counts before running a cleanup.
Schedules and tables
Automatic Cleanup offers Disabled, Daily, Weekly and Monthly. It relies on scheduled execution. Expired-transient cleanup targets expired database entries, not every active transient. Table optimization targets eligible non-InnoDB tables with reclaimable space; it is not a universal database speed-up.
Back to contents ↑GUIDE 15
Bloat & Heartbeat
Disable only the features your site genuinely does not use.
WordPress feature switches
The Bloat tab can disable emojis, Gutenberg block CSS, oEmbed, frontend Dashicons, jQuery Migrate, XML-RPC, RSS and self-pingbacks. Leave block CSS enabled if any frontend blocks need it. Test older scripts before removing jQuery Migrate; review external integrations before disabling XML-RPC or feeds.
WooCommerce assets
Optional controls remove cart fragments or WooCommerce assets on non-shop pages. Check mini carts, cart counters, embedded products and shop widgets outside normal shop routes before using them. A page’s route alone does not tell you whether it uses commerce features.
Heartbeat controls
Backend, Post Editor and Frontend each support Allow, Disable or Reduce when Heartbeat Control is enabled. Reduce uses the configured interval, clamped to 15–300 seconds, with a default of 60. Keep editor behavior conservative and test autosave, post locking and any plugin relying on Heartbeat.
Back to contents ↑GUIDE 17
Troubleshooting
Isolate the failing layer before you change more settings.
I do not see a cache hit
Use a logged-out browser without cart/session cookies. Check Page Caching, WP_CACHE, the writable cache directory and FlyWP Cache drop-in status. Visit the URL twice and inspect its response. Unknown query parameters or exclusion rules may bypass the cache. A CDN can hide the origin’s current behavior.
The design is broken or styles are missing
Temporarily disable CSS delivery optimization, purge and compare. If that fixes it, check RUCSS job status, dynamic-state selectors and the safelist. Regenerate Used CSS after correcting rules. For async CSS, review Fallback Critical CSS. Compare mobile navigation, hover states and dialogs as well as the first screen.
Buttons need two clicks or scripts fail
Test with JS Delay off, then Defer and Minify separately. Check the browser console and exclude the responsible script plus its dependencies from the relevant optimization. Test Click Replay for first-tap issues. Also check Script Manager rules that may remove the asset altogether.
CSS generation, preload or images are stuck
Check the dashboard health status, scheduled jobs, server loopbacks and outgoing HTTP access. Confirm the active product license for RUCSS, the sitemap for warming, or GD/Imagick support for images. Use Async Transport for generation timeouts behind a proxy. Repeated retries do not fix blocked access or a missing encoder.
The cache keeps showing old content
Clear the correct FlyWP Cache cache, then verify connected Cloudflare/FastCGI purges and browser caching. Refresh Used CSS after style changes. Ensure custom pages that depend on changed content are listed under Always Purge when automatic relationships do not cover them.
Quick optimization comparison
Append ?flycache-nocache to a URL, or &flycache-nocache if it already has a query string, to bypass FlyWP Cache’s normal cache/HTML optimization path. This is a diagnostic aid; independent image hooks, Script Manager rules or an upstream CDN may still influence the result.
Prepare a useful support report
Provide FlyWP Cache/WordPress/PHP versions, the affected page, exact reproduction steps, whether it occurs logged out, relevant settings and a screenshot or console error. State which single change makes the problem disappear. Remove license keys, tokens and private purchase/download links.
Back to contents ↑GUIDE 18
Your verification checklist
Check real use, not just a performance score.
Functional pass
Test navigation, accordions, sliders, search, forms, consent choices, login/logout and downloads. On stores, include product variations, cart updates, coupons, shipping, payment and order confirmation. Repeat in a fresh anonymous session after caches are warm.
Visual and device pass
Compare desktop and mobile, hover/focus states, open overlays and below-the-fold images. Check that hero images and fonts load promptly and that the layout stays stable. Test a slow connection as well as a fast one.
Measure consistently
Compare the same pages and conditions before and after a setting change. Separate cold-cache and warm-cache results. Review loading speed, layout stability and interaction responsiveness together with server load. FlyWP Cache cannot guarantee a particular score or sales increase.
Keep a known-good configuration
When the result is stable, export your settings and record important exclusions. Change one group at a time for future tuning so you can explain and reverse a regression.
Back to contents ↑