Anyone use Cloudflare APO or Quic or both for OLS WP Woocommerce site?

[swapot]

Hi, new here and new to OpenLiteSpeed. So far, so good.

I recently moved from shared hosting to OLS stack on Vultr HF server (4GB mem/2vCPUs/128GBspace/3TBband) with Runcloud to help me stay out of trouble. I'm not a developer, but I know how to follow directions.

I have a WP Woocommerce site with about 900 products, and each of them has between 170-250 variations (each variation has it's own image). Images are optimized, sized 1600px, and webp format, but as you may imagine, this puts a lot on the site/database to open those product pages.
I have got Redis Object Cache running, and installed the LSCache plugin. Haven't fine-tuned it yet, but I am considering following these recommendations: https://onlinemediamasters.com/litespeed-cache-settings/

Does anyone have experience with using Quic.Could for CDN, dynamic caching, image and file optimization on a OLS ecommerce site? Wondering how it compares to Cloudflare CDN (free) with APO (for dynamic caching aspects). I read that Cloudflare APO and LSCache may not be compatible?
The same website mentioned above says the best of both worlds is to use Coudflare (free) for DNS and edge caching (with Super Page Cache plugin) and Quic.cloud for dynamic caching and other optimizations.

I also have WP-Rocket that was being used before moving to new server and OLS, but it seems that LS Cache covers everything that Rocket does?

Wondering who has been down this road and what their experiences are. Thanks!

 

[LiteCache]

The most important question is, do you have more international visitors on your site than from your own country?

 

[swapot]

No. There are some important international countries for the growth of the business, but the primary target is the US. The server is in Atlanta since the largest population of the US is in the South.

 

[LiteCache]

No. There are some important international countries for the growth of the business, but the primary target is the US. The server is in Atlanta since the largest population of the US is in the South.

In this case a CDN doesn't make much sense, meaning you have no advantage of a CDN and the CDN is slower as without CDN.

 

[swapot]

In this case a CDN doesn't make much sense, meaning you have no advantage of a CDN and the CDN is slower as without CDN.

Hey LiteCache, thanks for asking and your reply. I can appreciate your perspective that I the site may not benefit from a CDN (or even be slower), however, both Cloudflare and Quic.cloud, which are integrated into LSCache, have many features in addition the their CDN for speeding up a website.

My post is not really asking IF the site would benefit from a CDN, but if anyone on this forum is using OLS to host a WP Woocommerce e-commerce site and has experimented with either of these setups (LSCache + Coudflare or LSCache + Quic.cloud or all three being used together).

 

[LiteCache]

My post is not really asking IF the site would benefit from a CDN, but if anyone on this forum is using OLS to host a WP Woocommerce e-commerce site and has experimented with either of these setups (LSCache + Coudflare or LSCache + Quic.cloud or all three being used together).

In short, use optimization features of the LScache plugin, but forget whatever CDN. You don't a CDN to benefit from optimizations. Also CloudFlare optimizations conflict with LScache plugin.

 

[LiteCache]

Hey LiteCache, thanks for asking and your reply. I can appreciate your perspective that I the site may not benefit from a CDN (or even be slower), however, both Cloudflare and Quic.cloud, which are integrated into LSCache, have many features in addition the their CDN for speeding up a website.

My post is not really asking IF the site would benefit from a CDN, but if anyone on this forum is using OLS to host a WP Woocommerce e-commerce site and has experimented with either of these setups (LSCache + Coudflare or LSCache + Quic.cloud or all three being used together).

Thank you for allowing me to help you selflessly, even though the answer is not what you expected.

 

[swapot]

Thank you for allowing me to help you selflessly, even though the answer is not what you expected.

Well, thank you for helping selflessly. I do understand that LSCache and Cloudflare have some overlapping features. I'm not completely convinced that having no CDN will be the best option. For example, if we start getting more customers from the West coast, would the website load faster from CDN cached pages/assets closer to them than from my server in Atlanta? (I understand that someone would have had to have already visited from the CDN edge location for them to be cached there and may not stay cached if they don't continue to be vistited.)

I can see you appear to be in the caching business, so I am weighing that with your response (which I appreciate you taking the time to do).

Ultimately, I will do some speed and load testing. I'm still adding some content, so I'm not quite there yet.

 

[Cold-Egg]

Regarding the QUIC Cloud CDN service, it covers certain US cities, so it may slightly improve speed in your case.
You can check the node status here: https://status.quic.cloud/

Once everything is set up, you can perform some speed tests to see if the CDN helps. If it does, you can keep it; if not, you can easily revert the changes.
For speed checks, try tools like: https://www.uptrends.com/tools/cdn-performance-check

Feel free to share the test results here so that other users can benefit from them.

 

[LiteCache]

Regarding the QUIC Cloud CDN service, it covers certain US cities, so it may slightly improve speed in your case.

Regardless of whether it is quic.cloud or any other CDN, improved speed requires that the content of a URL be cached in a CDN node, which is rarely the case. If the content is not cached, which is the typical case, then a CDN creates an additional layer, which slows down the network time. With QC, the problem is made even more difficult by the fact that QC purges the cache after 24 hours if a URL is not accessed again within this period. This severely limits the supposed advantages of quic.cloud as a CDN.

 

[LiteCache]

I'm not completely convinced that having no CDN will be the best option. For example, if we start getting more customers from the West coast, would the website load faster from CDN cached pages/assets closer to them than from my server in Atlanta?

You have already answered this question yourself. In order for a CDN to be faster than without a CDN, the content of a URL must already be cached. Normally, this is rarely the case, which means that an additional layer is created by the CDN, which makes a CDN slower than without a CDN. After all, the abbreviation CDN stands for "Content Delivery" Network. If a CDN node has not yet cached the content of a URL, then a CDN only functions as an Anycast service. Anycast can improve the time required to resolve the IP address and name server addresses, but not generally. It depends on whether the browser, the nearest router, the respective CDN node already has information about the IP address and the name server of the requested host. Nameservers and IP addresses are well known to the respective Internet access providers for requests within a country. Therefore, there are rarely advantages or differences when using a CDN within a country. The advantages of a CDN only apply to cross-border requests and only if the content of a URL is cached. If this is not the case, the only improvement is a faster resolution of the IP address.

In your specific case, this means that you cannot benefit from a CDN. To actually benefit from it, you would have to be able to warm up the cache at every relevant CDN node. Currently, only I can do that!

 

[swapot]

Cold-Egg and LiteCache;

Thank you both for your replies. Also, these two articles have helped me understand this more:

https://www.quic.cloud/?faq=can-i-u...-lscache-for-wordpress-plugin-with-quic-cloud

https://acnam.com/untold-truths-of-cloudflare-cdn/

Thanks.

 

[LiteCache]

@swapot

The article from https://acnam.com/untold-truths-of-cloudflare-cdn/ is very good and also confirms my tests with CloudFlare. Even if you now understand more thanks to these two articles, it does not make using a CDN any easier, as the seemingly uncontrollable routing makes a CDN a gamble. This means that a CDN is not always the better choice and cannot always be faster.

If you want to get even deeper into the subject of CDN, then read this too Article:

https://www.cachecrawler.com/Blog/W...oud-or-CloudFlare-CDN-Nodes-Part-I::6594.html
https://www.cachecrawler.com/Blog/How-to-Warmup-the-Cache-of-CloudFlare-CDN-Part-II::6600.html
https://www.cachecrawler.com/Blog/D...d-really-speed-up-the-loading-time::6597.html
https://www.cachecrawler.com/Blog/Conflict-between-CloudFlare-APO-and-LiteSpeed::6595.html
https://www.cachecrawler.com/Blog/CDNs-Kill-LiteSpeed-Speed-Feature::6599.html

 

[swapot]

I would like to check those out. However, it appears that Cloudflare thinks I'm a threat.

 

[LiteCache]

You are using an outdated Firefox version.

 

[swapot]

You are using an outdated Firefox version.

Yes, my current workflow/software requires a Mac running nothing newer than Mojave 10.14.6. So, Firefox and Chome are up-to-date for that OS.
Your site did open in my outdated Safari though, so thanks, I will read those.

Since I now see that I will be better off for the time present with no CDN, I have to make a decision which raises some technical questions for me. Maybe this is better in a new thread, but I'll start here.

I currently have Cloudflare enabled with DNS proxied. My server had a load from hits on my wp-admin and xmlrpc.php page so I set up Cloudflare Zero Trust with 2FA for the wp admin and a custom WAF rule to block the xmlrpc.php page (and other rules to block known bots and unwanted crawlers.) I know there are other ways to do this, but I like that it was easy to set up in Cloudfare, that it's not another plugin, that it's free, and the fact that the security stops some attacks before they even get to my server.

I think I could create a rule with a wildcard to tell cloudflare to bypass caching the entire site (and I could still use DNS and security).

Would that still leave Cloudflare as an extra route that all my traffic would have to go though, slowing it down?

Of course, I can test this. But changing DNS providers isn't always an instant thing.

 

[LiteCache]

I think I could create a rule with a wildcard to tell cloudflare to bypass caching the entire site (and I could still use DNS and security).

There is no need to create a rule to bypass caching if you don't enable caching. Using CF Cache + LiteSpeed Cache and LiteSpeed Optimizations at the same time is an absolute no-go! Don't use CF caching and LScache at the same time, because it causes much conflicts! But you can still use CF Cache for static sources.

Would that still leave Cloudflare as an extra route that all my traffic would have to go though, slowing it down?

Answer: Yes and no, and it depends on which CF services you use. An additional layer only arises if you use caching and the content of a URL is not cached. In most cases, this is the norm. Especially since the cache TTL is very short with CF, but higher as at quic.cloud.

DNS only (no proxy):
If you only use the DNS service, CF functions transparently. Transparent means that a request via CF is only forwarded to the origin host and the IP address of the origin host is transmitted to the client. With each subsequent request, the client/browser no longer needs the DNS resolver, so the benefits of CF only apply to the first request.

Within a country, the IP addresses of the name servers are largely known, so there are no advantages to using CF. The benefits only apply to requests from another country.

Proxy:
If you use the proxy service, CF behaves in a non-transparent manner. The IP address of the origin host is not transmitted to the client/browser and every request is answered by CF, which is essential for the CF WAF. The CF proxy offers you a high level of security with the WAF, but this security is not free and inevitably leads to latency.

 

[swapot]

There is no need to create a rule to bypass caching if you don't enable caching. Using CF Cache + LiteSpeed Cache and LiteSpeed Optimizations at the same time is an absolute no-go! Don't use CF caching and LScache at the same time, because it causes much conflicts! But you can still use CF Cache for static sources.



Answer: Yes and no, and it depends on which CF services you use. An additional layer only arises if you use caching and the content of a URL is not cached. In most cases, this is the norm. Especially since the cache TTL is very short with CF, but higher as at quic.cloud.

DNS only (no proxy):
If you only use the DNS service, CF functions transparently. Transparent means that a request via CF is only forwarded to the origin host and the IP address of the origin host is transmitted to the client. With each subsequent request, the client/browser no longer needs the DNS resolver, so the benefits of CF only apply to the first request.

Within a country, the IP addresses of the name servers are largely known, so there are no advantages to using CF. The benefits only apply to requests from another country.

Proxy:
If you use the proxy service, CF behaves in a non-transparent manner. The IP address of the origin host is not transmitted to the client/browser and every request is answered by CF, which is essential for the CF WAF. The CF proxy offers you a high level of security with the WAF, but this security is not free and inevitably leads to latency.

@LiteCache Thank you for this explanation, and for taking the time to answer my other questions on this thread. I've got a much better grasp on CDN now!

 

[LiteCache]

@swapot

I'm glad that you've learned something from this discussion and you can now hopefully evaluate for yourself whether a CDN is beneficial to you.

But there are still tons of insights to be gained to delve deeper into the subject of CDN: "Big Deal or Big Fake?" If you need further information, contact me via PM, as I cannot make my many years of experience freely available.

 

[swapot]