Cache broken after enabling geolocation with page cache in WooCommerce

  • Resolved tomowow

    (@tomowow)


    1 year, 9 months ago

    Hi,

    One of our websites has always been very fast with your plugin, where we have page caching enabled via Redis.

    To make sure currencies show correct on our clients website, we enabled the WooCommerce function “Geolocation with page cache support” some weeks ago. This adds a unique id in the link for every country, so we have a different page cache per country (more info: https://developer.woocommerce.com/2015/07/02/making-geolocation-static-cache-friendly-in-2-4/). This obviously will make the site a bit slower, but now the site is 10 times slower. It feels like the page cache is not working at al.

    We read somewhere we could test if page cache is working by looking at the status column of the page in the network tab. 304 should indicate, that the page is loaded from page cache. But we get a 200 status.

    Could you help us out what’s the problem here?

    Ps: we disabled the Geo feature on our staging, for you to compare: https://owow.dev/gofluo/

    • This topic was modified 1 year, 9 months ago by tomowow.

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter tomowow

    (@tomowow)

    Pss: when we enable the debug log for page cache, we see that the cache key is empty. When we disable Geolocate with page caching, the cache key is back.

    Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @tomowow

    Thank you for reaching out and I am happy to assist you with this.

    By default, any queries added to the URL preven that page from being cached. If you check the source and the debug on the live website you can see the following line:

    Page Caching using redis (Requested URI contains query)

    Requested URI contains query means that the URI contains a query and therefore will not be cached. If you do want to cache URIs with query strings, you can enable the option Cache?URIs with query string variables in Peformance>Page Cache – General section.

    This will ensure that the query strings are cached.

    As for the 304 response, this header also needs to be enabled in Performance>Bowser Cache under the XML&HTML section.

    I hope this helps!

    Thanks!

    Thread Starter tomowow

    (@tomowow)

    Thanks a million Marko, that seemed to be the issue. I missed that one!

    Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @tomowow

    You are most welcome!

    We would really appreciate it if you could take a minute and post a review here. This will help us to continue offering a top-notch product to users.
    Thanks!

    Thread Starter tomowow

    (@tomowow)

    Hi Marko,

    While the fix from last week is still working like a charm page speed wise, we are encountering issues with down time since we enabled the option “Cache URIs with query string variables”.

    UptimeRobot detected 8 down times last week, at first we thought this should be incorrect after seeing successful requests in the access log.

    However, yesterday we saw that the site was indeed down when UptimeRobot alarmed us. Well, the site was not down in fact but couldn’t be reached because of too many redirects. In the access log below you can see that the site is sometimes switching between country ID’s infinitely.

    We did some testing and see if you open the site with for example a USA query parameter from the Netherlands, this is being cached and if we open the page without query parameter from NL the redirect is does not change from USA to NL. Which can be harmful while some users will share the link, that includes the parameter.

    But, more importantly we suspect this will also sometimes lead to a infinite redirect loop. which is of course very harmful.

    Should we make sure redirects are not being cached, or is there something we can do in the plugin to fix this?

    XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=d3dcf429c679 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=796834e7a283 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=d3dcf429c679 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=796834e7a283 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=d3dcf429c679 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=796834e7a283 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
XX.XXX.143.126 - - [23/Feb/2023:16:06:07 +0000] "GET /?v=d3dcf429c679 HTTP/2.0" 307 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
    • This reply was modified 1 year, 9 months ago by tomowow.
    Thread Starter tomowow

    (@tomowow)

    Hi Marko,

    Do you have time to look at the problem above, or should we post a new ticket? We are currently having 2 downtimes every day average, so we need to fix this fast.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    Do you have time to look at the problem above, or should we post a new ticket?

    There are no “tickets” here, just support topics from users getting help from volunteers.

    Don’t post another topic on this, it will get archived when found.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Cache broken after enabling geolocation with page cache in WooCommerce’ is closed to new replies.