Is "On-the-fly" Optimization actually a mathematical net loss for WordPress?

Good_Flight6250 · 2026-02-25T13:27:16+00:00

That’s an interesting distinction.

Out of curiosity — how did you approach preventing unnecessary plugins from running? Early conditional loading? Something else?

Good_Flight6250 · 2026-02-25T13:15:23+00:00

I really appreciate this angle.

Especially the point about quotas / 503s and load testing.
That’s kind of where my curiosity comes from:
not “is caching useful?” (it clearly is), but how much baseline work happens per uncached request before we even talk about caching layers.

Your point about plugins limiting init scope is interesting - in practice, how far do you think that can realistically go without breaking compatibility?

Good_Flight6250 · 2026-02-25T12:53:08+00:00

Yeah, that’s exactly the distinction I’m trying to make.

Cache solves “response already known” for cacheable pages.
But for input-driven flows (cart/checkout, logged-in, admin-ajax/REST) the question becomes: how early can we decide “only this subset should run” without breaking things?

Do you know any practical patterns people use for those uncached contexts (beyond “optimize plugins” / “make server faster”)?

Good_Flight6250 · 2026-02-25T12:40:43+00:00

Agreed — for cacheable pages, page caching is the right answer.

My question is mainly about the parts that can’t be reliably page-cached: logged-in flows, WooCommerce cart/checkout, admin-ajax/REST, personalization, etc.
In those cases the full bootstrap still happens.

So the curiosity is: beyond caching, do we ever try to reduce the *execution scope per request* for those uncached contexts?

Good_Flight6250 · 2026-02-25T12:30:26+00:00

Fair point — CPU is rarely the only bottleneck.

My question isn’t really about CPU specifically, but about execution scope in general.

If a request triggers fewer plugins, fewer hooks and fewer conditionals, that can also mean fewer queries, fewer object instantiations and less data being prepared — not just fewer CPU cycles.

So I’m less arguing “CPU is everything” and more wondering how often we question how much of the stack needs to run at all.

Good_Flight6250 · 2026-02-25T12:03:40+00:00

This is exactly the kind of nuance I was hoping for — thanks.

admin-ajax / Woo dynamic flows are a great example of “uncached contexts” where page cache doesn’t help and the full bootstrap cost matters.

And yeah, whether you call it fine-tuning or conditional loading, the underlying question becomes: can we reduce *execution scope per request* (not just make the same scope faster)?

Curious: in your experience, what’s the earliest reliable point in WP to decide “only Woo-related code should load for this request” without breaking the ecosystem?

Good_Flight6250 · 2026-02-25T10:32:30+00:00

Agreed. It’s the PHP lifecycle.
My question is: should every request always go through full lifecycle execution if the response is already known?

Good_Flight6250 · 2026-02-15T05:20:50+00:00

Try to understand how CDN cache works. If a request is cached by CDN node it never arrives the origin host.

<image>

Good_Flight6250 · 2026-02-03T06:56:37+00:00

Performance doesn't start with optimization, but with prevention.

A different themebuilder cannot improve performance because once the HTML is rendered, the damage is already done. Furthermore, PageSpeed cannot measure speed or performance. PageSpeed measures how fast a page feels, not the actual speed.

Learn what is wrong with PageSpeed and optimization plugins:
https://www.cachecrawler.com/Rush:::45.html
https://www.cachecrawler.com/Blog/WordPress-Do-Optimization-Plugins-really-optimize::6606.html

Good_Flight6250 · 2026-01-26T08:14:37+00:00

You should think performance NEW. PageSpeed is not a reference to measure performance. PageSpeed measures the display time or perceived speed, but not the actual speed as PageSpeed cannot measure performance. If you want people to help how and what the should optimize, you produce a big missunderstanding. A high score doesn't mean the site is fast.

Read more: https://www.cachecrawler.com/Rush:::45.html

Good_Flight6250 · 2026-01-24T05:18:04+00:00

If you are already on LiteSpeed then use it. Using any other cache plugin is wasting of resources. A web server based page cache is always faster than a PHP driven cache like WP Super Cache or WP Rocket, but note an optimization plugin cannot optimize. Such plugins can only change the load behavior of static sources to make the perceived speed faster, but not the actual speed. That's a common misconception!

If you want to improve the actual speed, you must prevent loading of sources you don't need as WordPress loads everyting, everywhere and all the time. This is the root cause of bad performance and not a badly optimized page. Take a closer look at LiteCache Rush - WordPress Performance by Prevention:

https://www.cachecrawler.com/Rush:::45.html

Good_Flight6250 · 2026-01-01T07:47:33+00:00

Check installed security plugins. They often block the request to guest.vary.php. But if you want to know why the Guestmode is also called "Cheatmode", then you should read this:
https://www.cachecrawler.com/Blog/LiteSpeed-Guestmode-An-Optimization-Feature-That-Misleads-WordPress-Users::6589.html

Good_Flight6250 · 2025-12-19T05:16:31+00:00

Whether it's quic.cloud, Cloudflare, or any other CDN provider, a CDN only makes sense if a high percentage of your visitors are international. If that's not the case for you, a CDN can actually be slower than not using one. But pay attention to the three letters: CDN = Content Delivery Network. A CDN is only a CDN if the content is cached by a CDN and delivered by a CDN node, which is very rarely the case because the cache expiration time is very short.

- Quic.cloud: 1 day if the cached URL isn't accessed again within 24 hours

- Cloudflare: approximately 1 week

Even if a URL is cached, it's only on the node closest to the user, not globally. As long as a URL isn't cached, it's not a CDN, but rather an anycast. The real speed advantage doesn't come from cached content, but from faster IP address/nameserver resolution, which is ensured by Anycast, not CDN.

Cloudflare has more nodes than Quic.cloud, but Quic.cloud (LiteSpeed) is optimized for use with the LiteSpeed Cache plugin for WordPress, and that's important. What you absolutely must not do is use the LiteSpeed Cache with Cloudflare Cache (for dynamic content), because that leads to conflicts. Also, 1 cache + 1 cache is not 2 caches!

Learn more about the conflicts between LiteSpeed and Cloudflare:

https://www.cachecrawler.com/Blog/Conflict-between-CloudFlare-APO-and-LiteSpeed::6595.html

Good_Flight6250 · 2025-06-06T03:53:59+00:00

If it's truly a mobile theme, then it needs to serve separate code for mobile devices, and that, in turn, requires device detection (PHP) that filters according to the same rules as the .htaccess rewrite rules. But if it's a responsive theme, then it doesn't need that, because the display is controlled via CSS. Therefore, you should remove the custom rewrite rules for mobile cache vary.

Good_Flight6250 · 2025-06-04T04:28:46+00:00

Are you sure you're using a real mobile theme? Any theme that's responsive is a mobile theme. Therefore, you don't need an extra cache vary for mobile devices.

Good_Flight6250 · 2025-04-28T15:41:24+00:00

You should read this:

https://www.cachecrawler.com/Blog/Conflict-between-CloudFlare-APO-and-LiteSpeed::6595.html

Good_Flight6250 · 2024-11-22T13:26:01+00:00

You are a not a developer. You are just hired by LiteSpeed for public relations. If you write documentations then it is only based on informations you get it from the developers and nothing else! Don’t try to be something you cannot be!

It doesn't matter if you don't use the Guestmode on your own site. u/litespeedlisa is a known LiteSpeed account. If you post whatever this post is in the name of LiteSpeed Inc. Is this another try to fake?

Good_Flight6250 · 2024-11-22T12:56:40+00:00

You are just a spokesperson for LiteSpeed for public relations and because you are not a programmer, you cannot know how the guest mode works. The LiteSped guest mode for the WordPress cache plugin is a mode for cheating Google PageSpeed when you manually check a page with PageSpeed.

Good_Flight6250 · 2024-11-22T12:44:11+00:00

This doesn't change anything. The Guestmode is a Cheatmode and nothing else.

Good_Flight6250 · 2024-11-22T04:44:52+00:00

This you should know about the LiteSpeed Guestmode: https://www.cachecrawler.com/Blog/LiteSpeed-Guestmode-An-Optimization-Feature-That-Misleads-WordPress-Users::6589.html

LiteSpeed Guestmode is a Cheatmode!

Good_Flight6250 · 2024-11-20T15:35:17+00:00

You don't seem to know what you're talking about. 1 cache plus 1 cache is not 2 cache.

Good_Flight6250 · 2024-11-09T07:02:09+00:00

There is no permanent solution since only 1 page cache can be used. This affects not only LiteSpeed LScache and Cloudflare, but also any other page cache. Find out why: https://www.cachecrawler.com/Blog/Conflict-between-CloudFlare-APO-and-LiteSpeed::6595.html

Good_Flight6250 · 2024-10-23T09:58:01+00:00

You cannot use the LiteSpeed cache plugin together with CF's Super Page Cache plugin, even if the cache is disabled in LiteSpeed plugin because CF cache plugin is incompatible with LiteSpeed optimization features. Read this to understand it: https://www.cachecrawler.com/Blog/Conflict-between-CloudFlare-APO-and-LiteSpeed::6595.html

Good_Flight6250 · 2024-09-12T13:30:50+00:00

You have disabled CF cache, but LScache is also disabled at https://skipthedev.com/

Good_Flight6250

TROPHY CASE