Concrete5 with CloudFlare Cache
Permalink
Hi Everyone,
Ever since we replaced our old HTML site for our new Concrete5 site, we have lost revenues (ads & eccomerce sales) apparently due to Google penalizing us for a slower website. We have attempted to optimize our website according to Google and Lighthouse recommendations. However the largest performance gains were not seen until we switched to CloudFlare and maximized caching. We found we were only able to significantly affect our Google rankings when we maximized caching CloudFlare.
With CloudFlare full cache enabled, it is very difficult and cumbersome to edit our site. Only a few weeks ago we had to decreased CloudFlare caching settings for several days, just enough to see the resultant edits. We also kept concrete5 caching off as well. As a result our revenues (ads & eccomerce sales) dropped dramatically. Google AdSense once again warned us that our site was too slow. We have since readjusted CloudFlare caching back to maximum settings.
In effort to circumvent this problem our web host set up an alias site on a different domain (bypass.tempdomain.com), in hopes of bypassing CloudFlare cache when editing site. We added the temporary domain as an Alternative canonical URL in Concrete5 settings. Now we can browse the website using that Alternative canonical URL.
However, when we login to backend (bypass.tempdomain.com/login), we are redirected back to our original domain. We set our chronic URL to include the alias domain, but something is still transporting us back to our original domain. We suspect there is another setting in Concrete5 that is causing this redirect since it only happens when we login to edit the alias site.
Would be grateful if someone can point to the right direction.
HtAccess file also attached herewith.
Thanks in Advance!
Ever since we replaced our old HTML site for our new Concrete5 site, we have lost revenues (ads & eccomerce sales) apparently due to Google penalizing us for a slower website. We have attempted to optimize our website according to Google and Lighthouse recommendations. However the largest performance gains were not seen until we switched to CloudFlare and maximized caching. We found we were only able to significantly affect our Google rankings when we maximized caching CloudFlare.
With CloudFlare full cache enabled, it is very difficult and cumbersome to edit our site. Only a few weeks ago we had to decreased CloudFlare caching settings for several days, just enough to see the resultant edits. We also kept concrete5 caching off as well. As a result our revenues (ads & eccomerce sales) dropped dramatically. Google AdSense once again warned us that our site was too slow. We have since readjusted CloudFlare caching back to maximum settings.
In effort to circumvent this problem our web host set up an alias site on a different domain (bypass.tempdomain.com), in hopes of bypassing CloudFlare cache when editing site. We added the temporary domain as an Alternative canonical URL in Concrete5 settings. Now we can browse the website using that Alternative canonical URL.
However, when we login to backend (bypass.tempdomain.com/login), we are redirected back to our original domain. We set our chronic URL to include the alias domain, but something is still transporting us back to our original domain. We suspect there is another setting in Concrete5 that is causing this redirect since it only happens when we login to edit the alias site.
Would be grateful if someone can point to the right direction.
HtAccess file also attached herewith.
Thanks in Advance!
You'd also use this free add-on to see if you have bottlenecks in your PHP code: https://www.concrete5.org/marketplace/addons/speed-analyzer/...
I don't know much on the topic of online ads but isn't the fact that Chrome is now actively blocking ads also a factor in revenue drops?
You might also want to have a look at this free package:
http://www.concrete5.org/marketplace/addons/use-cdn...
There is also this one from the core team which serves a different purpose but might helphttps://github.com/concrete5/cloudflare_proxy...
And finally this tutorial addresses specifically the editing issue but it is for CloudFront and given how it's done I am not sure it is even possible with CloudFlare but you might want to give it a lookhttps://documentation.concrete5.org/tutorials/how-setup-concrete5-be...
http://www.concrete5.org/marketplace/addons/use-cdn...
There is also this one from the core team which serves a different purpose but might helphttps://github.com/concrete5/cloudflare_proxy...
And finally this tutorial addresses specifically the editing issue but it is for CloudFront and given how it's done I am not sure it is even possible with CloudFlare but you might want to give it a lookhttps://documentation.concrete5.org/tutorials/how-setup-concrete5-be...
Thanks for the suggestions.
Although it is true that ad revenues have been declining since the growing popularity of ad blockers. the loss of revenues I am speaking about occur whenever we turn down caching in CloudGlare. Adsense actually displays a red icon showing content speed is too slow. We finally discovered the only way for this to disappear and increase our ad revenues was to set Cloudflare Caching to its maximal settings. When we decreased it again for several days to correct several bad links, our ad revenues plummet and the red icon in Adsense appeared again. When we switched back to maximum caching, our ad revenues returned to normal.
The problems of having CloudFlare set to maximum caching is that (a) suggested pages and products no longer change after page reloads instead they persist as long as the cache is refreshed in the settings , and (b) if we make more than one change to a page, we have to purge the page cache. Having CloudFlare as full throttle forfeits the main reason we chose Concrete5 our CMS, to be a hassle free way to edit content. Now editing a page is a headache with too many steps, particularly if you do not or cannot make all the changes in one session.
We already us Concrete5 CloudFlare Proxy Add-on. I see the other add-on you mentioned uses CDNs other than CloudFlare. I also noticed that someone already asked you last year if the PHP solution designed for Cloudfront which allowed for unadulterated editing on an alias site:https://documentation.concrete5.org/tutorials/how-setup-concrete5-be... You told them as you warned me that it might not work for Cloudflare due to the way it returns the visitor's user agent. So my question is, if we switched from Cloudflare to a service like BunnyCDN (https://bunnycdn.com/) or BelugaCDN (https://www.belugacdn.com/) [apparently the least costly CDNs], would a similar script have a chance of working for the set up we described so we can performed edits without seeing the cached version on our alias site? Would you be willing to help us do this if we hire you again?
Although it is true that ad revenues have been declining since the growing popularity of ad blockers. the loss of revenues I am speaking about occur whenever we turn down caching in CloudGlare. Adsense actually displays a red icon showing content speed is too slow. We finally discovered the only way for this to disappear and increase our ad revenues was to set Cloudflare Caching to its maximal settings. When we decreased it again for several days to correct several bad links, our ad revenues plummet and the red icon in Adsense appeared again. When we switched back to maximum caching, our ad revenues returned to normal.
The problems of having CloudFlare set to maximum caching is that (a) suggested pages and products no longer change after page reloads instead they persist as long as the cache is refreshed in the settings , and (b) if we make more than one change to a page, we have to purge the page cache. Having CloudFlare as full throttle forfeits the main reason we chose Concrete5 our CMS, to be a hassle free way to edit content. Now editing a page is a headache with too many steps, particularly if you do not or cannot make all the changes in one session.
We already us Concrete5 CloudFlare Proxy Add-on. I see the other add-on you mentioned uses CDNs other than CloudFlare. I also noticed that someone already asked you last year if the PHP solution designed for Cloudfront which allowed for unadulterated editing on an alias site:https://documentation.concrete5.org/tutorials/how-setup-concrete5-be... You told them as you warned me that it might not work for Cloudflare due to the way it returns the visitor's user agent. So my question is, if we switched from Cloudflare to a service like BunnyCDN (https://bunnycdn.com/) or BelugaCDN (https://www.belugacdn.com/) [apparently the least costly CDNs], would a similar script have a chance of working for the set up we described so we can performed edits without seeing the cached version on our alias site? Would you be willing to help us do this if we hire you again?
As for using other CDNs you would have to ask them what user agent they use. If they use a custom user agent that can be used to reliably identify them then yes, that would work.
I have to ask you what may sound like an obvious question though: when you disable CloudFlare, do you enable C5 caching back?
I have to ask you what may sound like an obvious question though: when you disable CloudFlare, do you enable C5 caching back?
Sorry for the delay. It took a while to get an answer. Our web developer chose to keep Concrete5 caching off during this time so our team would not have to continually clear the cache after every edit. However Cloudflare cache was still in effect, being reduced from maximum to a moderate level of caching. Apparently the text was not cached. This reduction in caching seemingly resulted in a slower site evident by an Adsense alert (red icon by content speed) with a concomitant decrease in advertisement revenues. Revenues returned to normal only after we changed Cloudflare caching back to maximum values. We still have several speed issues with need to remedy as reveled by GTMetrics and LightHouse.
As you suggested, I asked BunnyCDN what user agent they used and explained what we were trying to accomplish. They replied:
At the moment, we use the user agent of the client that caused us to have to go back to your origin. However, we have a number of ways to identify if it is one of our PoPs connecting to you for content. These methods are listed here:https://support.bunnycdn.com/hc/en-us/articles/115003578911-How-to-d... I would suggest you listen for the CDN-ServerID HTTP header, and then use that to check if it us connecting to you.
Do you think we can use one of the methods listed in that link to reliably identify BunnyCDN, ultimately allowing us easily edit an alias of our site on another domain without being effected by BunnyCDN caching, using a similar technique as you referenced here:
https://documentation.concrete5.org/tutorials/how-setup-concrete5-be...
As you suggested, I asked BunnyCDN what user agent they used and explained what we were trying to accomplish. They replied:
At the moment, we use the user agent of the client that caused us to have to go back to your origin. However, we have a number of ways to identify if it is one of our PoPs connecting to you for content. These methods are listed here:https://support.bunnycdn.com/hc/en-us/articles/115003578911-How-to-d... I would suggest you listen for the CDN-ServerID HTTP header, and then use that to check if it us connecting to you.
Do you think we can use one of the methods listed in that link to reliably identify BunnyCDN, ultimately allowing us easily edit an alias of our site on another domain without being effected by BunnyCDN caching, using a similar technique as you referenced here:
https://documentation.concrete5.org/tutorials/how-setup-concrete5-be...
If you can identify them through a specific header than yes you can re-use that solution with small modifications
As an FYI, it seems CloudFlare also uses custom headers. Read this page:https://support.cloudflare.com/hc/en-us/articles/200170986-How-does-...
All headers starting with CF are custom headers. Their presence would help identify CloudFlare.
Make sure you use headers that are always sent back as some of them depend on the situation.
All headers starting with CF are custom headers. Their presence would help identify CloudFlare.
Make sure you use headers that are always sent back as some of them depend on the situation.
You might very well just look at how your box is set up and get some more performance there.
Can you provide a analysis from webpagetest.org ?