It's not a question of trust. You're trying to protect yourself, and that's fine, but the method you're using to protect yourself is wrong. If you want to stick with this method, then by all means, continue to feel safe. But be aware that server security isn't based on outdated client-side methods. For us, safety comes first.
LiteCache Rush: WordPress Performance by Prevention
- Thread starter LiteCache
- Start date
Ok so are you saying Sonicwall and Ubiquiti, Aruba and Cisco are also outdated, we just tried with those on remote VPN locations same errors, not the same ip at all. Anyway, I do know everything, but after 30+ years I know some things, some dated and some not so much. Reached out to a few others and they had the same issues.
All using different IP's, so CF is being over active, why not just a goofy captcha? Are we really working this hard before we even start, even if I'm using an outdated browser on this system, not a single other provider has blocked us, for whatever that is worth.
All using different IP's, so CF is being over active, why not just a goofy captcha? Are we really working this hard before we even start, even if I'm using an outdated browser on this system, not a single other provider has blocked us, for whatever that is worth.
Last edited:
So tell me this please and thank you, since we can't access your site, how does your LiteCache work differently than LSe, it's still built on OLS or something else? Everyone will learn, assuming it's still using some form of LScache > LiteCache - The most powerful page cache for enterprise CMS, based on LiteSpeed LScache. 
Last edited:
After many times of trying many VPN's we are in. I now fully understand what you are selling now, looks like a well thought-out OLS cache warmer+ allot more. I created one using Redis and Relay for Nginx, but still found the admin to be slower than I would like and after all that now trying OLS again in a test case ...
@neikoloves
I've created a special FAQ for you so you can get an idea of what LiteCache Rush is and what it's good for. If you have any further questions, please be patient for a few more days until Rush is available.
What is Rush?
Rush is a plugin-loading controller for WordPress. It does not modify WordPress core, change any WP functions, or replace parts of the system. Rush simply decides which plugins should load for a given request — and prevents the rest from running.
WordPress loads every active plugin on every request, even when most of them are not needed. Rush intercepts the bootstrap before WordPress runs and provides a minimal, demand-based plugin set. The WordPress core remains untouched — Rush is not a fork, override or patch. Themes, builders and WP internals behave exactly as they were designed. Rush improves performance by reducing unnecessary plugin execution, not by altering WordPress itself.
Will Rush improve my PageSpeed score?
No. Rush improves server performance, not browser cosmetics. PageSpeed measures visual behavior, not backend workload.
"Rush repairs the house (WP), PageSpeed evaluates the color of the mailbox."
PageSpeed evaluates what happens after the HTML is already delivered. Rush eliminates unnecessary PHP/MySQL work before the page is generated. Both operate in different worlds of the request lifecycle. A high score doesn’t mean a fast server — and vice versa. Use Rush for real performance, not for green numbers.
Is Rush a WordPress plugin?
No. A plugin loads too late; Rush must act before WordPress wakes up. That’s why it runs as a controlled MU-bootstrap.
WordPress plugins load only after WP is fully initialized. At that point, the damage (full bootstrap) is already done. Rush controls the environment pre-WP to prevent unnecessary loading. This is architectural, not decorative. If Rush were a plugin, it would defeat its own purpose.
Can Rush speed up Plugin X, Y or Z?
No. Rush speeds up WordPress itself by preventing plugins from running unnecessarily. Plugins become "lighter" simply because they run less often.
Rush doesn’t optimize plugin code. It removes unnecessary plugin executions from the request flow. Less work = faster server, regardless of plugin quality. Your site stays functional, but with a fraction of the load. This is structural performance, not per-plugin tuning.
Do I have to tune or optimize anything in Rush?
No. Rush is not an optimizer; it’s a workload controller. It removes what you don’t need instead of tweaking what you do need.
Optimizers adjust things that still get executed. Rush’s core idea is eliminating unnecessary execution entirely. The fastest code is the code that never runs. Configurations are optional helpers, not mandatory tools. The default behavior already delivers the main benefit.
Does Rush work with my page-cache plugin (LiteSpeed, WP Rocket, …)?
Yes. Rush and page-cache plugins complement each other perfectly. Rush makes the server faster before the cache even steps in.
Page-cache plugins operate after WordPress generates the first response. Rush operates before WordPress starts generating anything. This eliminates CPU pressure and makes cache hits cheaper. There is no conflict — only synergy. Caching + workload control = stable high performance.
Will Rush affect my theme or page builder?
No. Themes and builders run normally but under less server load. Rush doesn’t modify frontend output.
Themes and builders execute only when needed. Rush ensures backend load is minimized before they run. Frontend design remains untouched. Performance improves because unnecessary backend work disappears. Your UX stays identical — the server effort does not.
Do I have to update Rush settings when I install new plugins?
Yes. If you want the new plugin to run inside an existing Rush rule. New plugins appear in the GUI instantly, but they are not added to existing configurations automatically.
Rush freezes each rule based on the plugins that were active at the moment of configuration. Installing a new plugin does not retroactively change existing rules. The plugin will only run where you explicitly include it. This avoids unexpected behavior and keeps Rush predictable. If a new plugin should apply to existing routes, you must update those rules manually.
Can Rush break URLs or block parts of my site?
No. Rush only blocks unnecessary execution paths, not legitimate pages. All essential WordPress routes remain untouched.
Rush understands WordPress' core routes (login, admin, REST, etc.). Unknown or irrelevant runtime paths are controlled, not removed. Fallback logic prevents accidental blocking. You always retain full functionality. Only wasteful bootstrapping is filtered out.
Does Rush work with WooCommerce?
Yes. Rush keeps WooCommerce active where required and inactive elsewhere. This reduces overhead on non-commerce pages.
WooCommerce loads a lot of code globally. Rush restricts Woo’s bootstrap to real Woo contexts. Cart, checkout, account pages stay fully functional. Blog pages, static pages, and marketing pages stay lightweight. This is a structural WooCommerce win, not a hack.
What happens if I disable Rush?
Nothing breaks. WordPress returns to its normal state instantly. Rush changes no data; it only controls the bootstrap.
Rush does not override WP core behavior. It adds no persistent code injections or rewrites. Disabling it restores plain WordPress execution. Your site will simply run with the old load again. Functionality remains intact; performance reverts.
Does Rush replace an optimization plugin?
No. Rush is not an optimizer — it is a workload gatekeeper. Optimization plugins tweak assets; Rush prevents unnecessary PHP execution.
Optimizers work inside WordPress after it has already booted. Rush works before WordPress boots and stops wasted processing entirely. Both can coexist because they operate on different layers. Rush fixes the root cause (workload), not the symptoms (asset weight). Use optimization tools for frontend polish; use Rush for backend efficiency.
What is the difference between URL Mode and Bucket Mode?
URL Mode
Rush creates rules based on individual URLs. Every URL can have its own plugin set, and Rush applies the configuration only to that exact URL. This mode gives maximum precision, ideal for sites where only a few specific pages require plugin control.
Bucket Mode
Rush groups many URLs into logical categories ("buckets") — such as posts, pages, archives, products, search results, etc. Each bucket has one shared plugin configuration, which applies automatically to all URLs that belong to that category. This reduces maintenance dramatically and scales better for content-heavy or frequently updated sites.
URL Mode = rule per URL → maximum precision, most control.
Bucket Mode = rule per content category → minimum effort, automatic coverage.
URL Mode is ideal for selective optimization. Bucket Mode is ideal for large sites with repeating structures. Both use the same Rush engine; the difference is the management strategy.
And this is the result:
I've created a special FAQ for you so you can get an idea of what LiteCache Rush is and what it's good for. If you have any further questions, please be patient for a few more days until Rush is available.
What is Rush?
Rush is a plugin-loading controller for WordPress. It does not modify WordPress core, change any WP functions, or replace parts of the system. Rush simply decides which plugins should load for a given request — and prevents the rest from running.
WordPress loads every active plugin on every request, even when most of them are not needed. Rush intercepts the bootstrap before WordPress runs and provides a minimal, demand-based plugin set. The WordPress core remains untouched — Rush is not a fork, override or patch. Themes, builders and WP internals behave exactly as they were designed. Rush improves performance by reducing unnecessary plugin execution, not by altering WordPress itself.
Will Rush improve my PageSpeed score?
No. Rush improves server performance, not browser cosmetics. PageSpeed measures visual behavior, not backend workload.
"Rush repairs the house (WP), PageSpeed evaluates the color of the mailbox."
PageSpeed evaluates what happens after the HTML is already delivered. Rush eliminates unnecessary PHP/MySQL work before the page is generated. Both operate in different worlds of the request lifecycle. A high score doesn’t mean a fast server — and vice versa. Use Rush for real performance, not for green numbers.
Is Rush a WordPress plugin?
No. A plugin loads too late; Rush must act before WordPress wakes up. That’s why it runs as a controlled MU-bootstrap.
WordPress plugins load only after WP is fully initialized. At that point, the damage (full bootstrap) is already done. Rush controls the environment pre-WP to prevent unnecessary loading. This is architectural, not decorative. If Rush were a plugin, it would defeat its own purpose.
Can Rush speed up Plugin X, Y or Z?
No. Rush speeds up WordPress itself by preventing plugins from running unnecessarily. Plugins become "lighter" simply because they run less often.
Rush doesn’t optimize plugin code. It removes unnecessary plugin executions from the request flow. Less work = faster server, regardless of plugin quality. Your site stays functional, but with a fraction of the load. This is structural performance, not per-plugin tuning.
Do I have to tune or optimize anything in Rush?
No. Rush is not an optimizer; it’s a workload controller. It removes what you don’t need instead of tweaking what you do need.
Optimizers adjust things that still get executed. Rush’s core idea is eliminating unnecessary execution entirely. The fastest code is the code that never runs. Configurations are optional helpers, not mandatory tools. The default behavior already delivers the main benefit.
Does Rush work with my page-cache plugin (LiteSpeed, WP Rocket, …)?
Yes. Rush and page-cache plugins complement each other perfectly. Rush makes the server faster before the cache even steps in.
Page-cache plugins operate after WordPress generates the first response. Rush operates before WordPress starts generating anything. This eliminates CPU pressure and makes cache hits cheaper. There is no conflict — only synergy. Caching + workload control = stable high performance.
Will Rush affect my theme or page builder?
No. Themes and builders run normally but under less server load. Rush doesn’t modify frontend output.
Themes and builders execute only when needed. Rush ensures backend load is minimized before they run. Frontend design remains untouched. Performance improves because unnecessary backend work disappears. Your UX stays identical — the server effort does not.
Do I have to update Rush settings when I install new plugins?
Yes. If you want the new plugin to run inside an existing Rush rule. New plugins appear in the GUI instantly, but they are not added to existing configurations automatically.
Rush freezes each rule based on the plugins that were active at the moment of configuration. Installing a new plugin does not retroactively change existing rules. The plugin will only run where you explicitly include it. This avoids unexpected behavior and keeps Rush predictable. If a new plugin should apply to existing routes, you must update those rules manually.
Can Rush break URLs or block parts of my site?
No. Rush only blocks unnecessary execution paths, not legitimate pages. All essential WordPress routes remain untouched.
Rush understands WordPress' core routes (login, admin, REST, etc.). Unknown or irrelevant runtime paths are controlled, not removed. Fallback logic prevents accidental blocking. You always retain full functionality. Only wasteful bootstrapping is filtered out.
Does Rush work with WooCommerce?
Yes. Rush keeps WooCommerce active where required and inactive elsewhere. This reduces overhead on non-commerce pages.
WooCommerce loads a lot of code globally. Rush restricts Woo’s bootstrap to real Woo contexts. Cart, checkout, account pages stay fully functional. Blog pages, static pages, and marketing pages stay lightweight. This is a structural WooCommerce win, not a hack.
What happens if I disable Rush?
Nothing breaks. WordPress returns to its normal state instantly. Rush changes no data; it only controls the bootstrap.
Rush does not override WP core behavior. It adds no persistent code injections or rewrites. Disabling it restores plain WordPress execution. Your site will simply run with the old load again. Functionality remains intact; performance reverts.
Does Rush replace an optimization plugin?
No. Rush is not an optimizer — it is a workload gatekeeper. Optimization plugins tweak assets; Rush prevents unnecessary PHP execution.
Optimizers work inside WordPress after it has already booted. Rush works before WordPress boots and stops wasted processing entirely. Both can coexist because they operate on different layers. Rush fixes the root cause (workload), not the symptoms (asset weight). Use optimization tools for frontend polish; use Rush for backend efficiency.
What is the difference between URL Mode and Bucket Mode?
URL Mode
Rush creates rules based on individual URLs. Every URL can have its own plugin set, and Rush applies the configuration only to that exact URL. This mode gives maximum precision, ideal for sites where only a few specific pages require plugin control.
Bucket Mode
Rush groups many URLs into logical categories ("buckets") — such as posts, pages, archives, products, search results, etc. Each bucket has one shared plugin configuration, which applies automatically to all URLs that belong to that category. This reduces maintenance dramatically and scales better for content-heavy or frequently updated sites.
URL Mode = rule per URL → maximum precision, most control.
Bucket Mode = rule per content category → minimum effort, automatic coverage.
URL Mode is ideal for selective optimization. Bucket Mode is ideal for large sites with repeating structures. Both use the same Rush engine; the difference is the management strategy.
And this is the result:
Last edited:
I'm excited to learn more, PM sent, just to be clear, maybe my ways are sometimes old ways, but the sad truth is it's still a standard by many security softwares out of the box and yes I do at times use old systems, because they just work. So I hope you did not take offense, I was honestly trying to help, as you never know who may have tried to browse the site and could not and thus just give up 95% of the time.
Last edited: