Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.<\/p>”}_ * and all of the introductions to each cookie type. is it the stray \ in the closing
tag? - Performance – this is not version related, I was encountering it with the previous version too. I am NOT a developer so I only know a bit caching but was working with my hosts support people on Friday. With the plugin activated, I am getting Lighthouse scores 6 – 8 lower than with it deactivated. The plugin appears to hinder my sites caching. I use my hosts edge caching and CDN (“ Stackcache”). Visibly the pages load near instantly without your plugin and take between 2 – 3 seconds with it activated. * [https://prnt.sc/GUBMII3vWrW0](https://prnt.sc/GUBMII3vWrW0) – shows the dev tools for my home page with your plugin on. The cache control says “ no-cache, must-revalidate, max-age =0, no-store, private”. The X-Cdn-Cache- Status says “MISS”. * [https://prnt.sc/6sj5OvL2mouL](https://prnt.sc/6sj5OvL2mouL) – The cache control says public, s-maxage=216000. The X-Cdn-Cache-Status says “HIT”. * Thanks, * James - This topic was modified 2 weeks, 6 days ago by [James](https://wordpress.org/support/users/james-feaver/). * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fperformance-impact-11%2F%3Foutput_format%3Dmd&locale=en_US) to see the link]_ Viewing 9 replies - 1 through 9 (of 9 total) * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [2 weeks, 6 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18918744) * Hi James, * Thanks for the very detailed bug report — both points are real and I have already shipped a fix for the first one. Quick recap. * **Bug 1, the JSON leak in the Cookie Policy.** * You are right that the rendered policy is showing the raw JSON for category names, category descriptions, cookie descriptions and durations. The root cause was inside the new Cookie Policy generator: the function that builds the cookie inventory was reading the four i18n columns straight from the database with a JOIN’d SELECT and printing them through esc_html() without first decoding the {“en”:”…”} JSON envelope that those columns use on multilingual installs. Everywhere else in the plugin the i18n decode happens automatically because the code goes through the model getters, but that one path took a shortcut. * The fix landed in 1.16.1, which I just pushed. The renderer now calls a small helper that picks the active language, falls back to en, then to the first non- empty entry, mirroring exactly the behaviour of the standalone [faz_cookie_table] shortcode you may already be familiar with. Description and category-description fields now also go through wp_kses_post() so the inline paragraph tags they may contain survive instead of being escaped to text. I also audited every other place in the plugin that touches those tables (controllers, REST API, WP-CLI export, settings import/export, all shortcodes) to make sure no similar leak was hiding elsewhere — none found. * Once 1.16.1 propagates through wp.org, just update and the policy page should render cleanly in your active language. If you happen to have the policy page cached on the front-end, a hard reload or a cache purge will pick up the new HTML. * Bug 2, the home page being marked as MISS. * I take that one seriously too but I want to make sure I understand what is happening on your specific setup before pushing changes that could hurt anyone else. The plugin sends a no-cache response when geo-routing is active for the current request, because the banner choice depends on the visitor’s country and a cached page would freeze that decision for everyone. That trade-off has been in place since 1.14.0 and is intentional in geo-aware scenarios. * What I’d like to check with you, if you don’t mind: - Are you using the geo-routing feature (Settings → Geo-routing), or do you have a single banner serving every visitor? - Which CDN or caching layer is in front of the site? (Cloudflare, BunnyCDN, hosting-level cache, a page cache plugin…) - Are you seeing MISS only on the home page or on every page? * If you have a single banner and no per-country routing, there is room to skip the no-cache header entirely — and that’s exactly what I’d like to do for sites in your configuration. Knowing the answers above will let me ship that as a follow- up patch without risking the compliance posture of sites that do rely on geo- routing. * Thanks again for taking the time to test and report. * Fabio * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18918956) * Hi Fabio, * Thanks for the detailed response. I’ll come back to you on the first issue now and do some more investigation around the second before replying. * The cookie policy looks good now but I am only getting the banner and cookie icon on the policy page. If I go in to incognito window with any other page as the first one I visit, they are not shown. * Thanks, * James * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18918998) * I’m now seeing it on all pages. I think the delay from purging the cache to seeing changes for some reason took over an hour – sorry for frightening you! * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919023) * Hi James, * Saw your follow-up about the banner showing across all pages now once the cache cleared — glad that one turned out to be a CDN propagation lag and not a real bug. No need to apologise: the fact that it took over an hour for your Stackcache to roll over is actually a useful data point for the second issue too (more on that below). * In the meantime I didn’t want to leave you waiting, so while you do your own investigation I went and looked at the live site from the outside to make sure my mental model of what is happening matches what your server is doing in practice. Here is what I found, kept short and concrete. * First, the good news: the cookie policy literal-JSON bug is gone. The /cookie- policy/ page rendered through 1.16.1 no longer contains the {“en”:”…”} fragments you spotted on the previous release. The fix landed exactly where I expected. The cookie inventory layout is still the flat definition-list from 1.16.0/1.16.1 on your install, but that is improving in 1.16.2 (which is already on wordpress. org and propagating): the inventory becomes a collapsible accordion with a real table per category instead of the long flat list, and the footer disclaimer becomes admin-configurable (toggle plus optional custom text) instead of being hardcoded. So when your install picks up 1.16.2, that policy page will tighten up considerably without any action on your side beyond an update. * Now the cache miss. I confirmed it is happening on every page I tested, not just the home: the home, /cookie-policy/ and /shop/ all return identical headers. The relevant ones are: * cache-control: no-store, no-cache, must-revalidate, max-age=0 x-litespeed-cache- control: no-cachex-stackcache-cacheable: nopex-cdn-cache-status: MISS * So Stackcache is correctly honouring what the origin is telling it; the origin is the one deciding the page is uncacheable. That decision comes from a single function inside the plugin (send_geo_cache_headers), which fires Cache-Control no-store the moment it decides the rendered output is country-dependent. There are four conditions that can flip that switch, in this order of likelihood: 1. IAB TCF v2.3 is enabled in Settings. I can rule this one out — your home page does not contain the _fazTcfConfig object, which means TCF is off on your install. 2. Geo-routing is on with the default behaviour set to “do not show banner outside target regions” (Settings, Geo-routing, fallback). When that is the setting, the cached HTML of an EU visitor would silently show no banner to an outside- EU visitor (or vice versa), so the plugin marks the output uncacheable. 3. Multi-banner geo-routing is configured (more than one banner, with at least one carrying a target-countries list). Here the plugin needs to serve a different banner per country, so once again it cannot let the CDN freeze one version of the page. 4. A custom filter, faz_use_country_language_fallback, is turned on by the theme or another plugin. Very unlikely on a standard install. * For your stack the no-cache header is being driven by one of (2) or (3). Both are legitimate uses of the geo logic, but in your case (a UK ecommerce site targeting mostly UK and EU buyers) you may have set them up only as a safety net rather than because you genuinely want a different banner per country. If that is the case there is a clean fix to push on my side and I’d like to ship it as 1.16.3 within a few days. Two practical paths: * Path A — the minimal one. If you are running a single banner (no per-country variants) and you simply turned on geo-routing to gate the banner for EU/UK only, I add a settings flag so the plugin emits Vary: X-Country-Code plus a permissive Cache-Control header instead of the blanket no-store. Stackcache (and LiteSpeed) can then cache one HTML per country code — typically two or three variants in your case — which keeps the page near-instant for the dominant traffic segment while preserving the regulatory accuracy. Net effect: HIT for the vast majority of visitors instead of MISS for everyone. * Path B — the heavier one. If you are running multiple banners with target_countries, same idea but the Vary header logic needs to enumerate the country codes that actually have distinct banners, otherwise the CDN ends up caching 250 micro-variants of the same page. This is the same fix but a touch more careful. * To pick the right path I need a few details from you when you’ve finished your own investigation — no rush, this is patch-release work, not emergency. Roughly: - In Settings, Geo-routing: is “Geo-routing” itself enabled, and if yes what is “default behaviour” set to (show banner, hide banner, fallback to most- protective)? - In Cookie Banner, do you have one banner or more than one? If more than one, do any of them have a target-countries list configured? - Are you fine with the page being cached per-country (so EU visitors share one cached variant, UK another, US another) rather than not cached at all? In most ecommerce stacks the answer is yes — it preserves performance while keeping the per-jurisdiction banner accurate. - And one extra now that I’ve seen Stackcache react to a purge with that hour- long propagation lag: do you know whether Stackcache currently keys its cache by country (via CF-IPCountry or an equivalent header), or strictly by URL? Their support people will know — it decides whether the Vary trick can work as-is or whether they need to add a small cache key rule on their end alongside the plugin change. * If the answer to question 2 is “one banner, no target_countries”, the change becomes a one-liner on my side: I can probably ship it in a follow-up patch within a couple of days. I won’t push it speculatively because making the page cacheable for sites that DO rely on per-country banners would silently break their compliance posture, which is the worse failure mode. * A side note while I am here: the home page contains a “countryCode”:”GB” string a few times — that is WooCommerce’s own checkout state (“default country is GB”), not the plugin. Unrelated. The plugin’s own geo state isn’t exposed in the public HTML, which is the correct security posture. * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919367) * Hi Fabio, * Thank you SO much for the very detailed response and looking so deeply into this, it is much appreciated. * Policy – I’ve had site visitors every time I looked so have only now updated to the very latest version on my live site. The accordions look good on PC or phone. I’ll need to do a little bit of CSS to get the column widths consistent for the PC, but it is trivial. * Cache Miss – You are right, I have a UK ecommerce site but my customers these days are 100% UK. Brexit killed off sending trees to the EU, so I stopped sending anything outside of the UK. I have one banner and don’t care where any site visitors are that get that one version. If it is legal for the UK, then and EU or rest of the world person can see it / dismiss it. * I had wrongly set things for your point 2, Geo-routing. I didn’t read the small- print and have now left all options unchecked to make the banner match every visitor. So yes, I a running a single-banner (no per-country variants) and turned on the geo-routing in error. Having a single cached variant would be fine – not even per country. * I don’t know where the “faz_use_country_language_fallback” is coming from. I’ll have a dig. * I got in touch my host’s support about StackCache and they say, “This is key’d by URL”. * I think this is the one-liner situation? I’d be happy to try a pre-release version out for you. I know I’ve jumped about a bit in my response but hopefully have given you all you need. Please come back if I have missed something you need. * Thanks again. * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919622) * Hi Fabio, * I’ve dug a bit deeper into looking if “faz_use_country_language_fallback” is used. I downloaded all plugins and themes and used Windows Grep to look for it. As you guessed, it is not used outside of your plugin. * Thanks. * Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/) * (@fabiodalez) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919666) * I re-fetched the headers from your home, /cookie-policy/ and /shop/ a few minutes ago and they now read: * cache-control: public, s-maxage=216000 x-stackcache-cacheable: yesx-cdn-cache- status: MISS * Thanks for the grep on faz_use_country_language_fallback — that confirms what I expected. The filter ships with a default of false and only ever flips if a developer explicitly opts in from a theme or plugin, which neither of yours does. * One thing I’m taking away from this for 1.16.3: an admin warning that fires when Geo-routing is enabled while you have a single banner with no target_countries— i.e. the exact configuration that costs you the CDN cache for zero functional gain. One-click “disable Geo-routing” inline. Your report is what made that warning idea! Thank tou * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919694) * Hi Fabio, * Thanks for rechecking. Definitely getting speed improvements on lots of pages:-). I do still get some pages where I repeatedly get: * ```wp-block-code cache-control: no-cache, must-revalidate, max-age=0, no-store, privatex-stackcache-cacheable: yesx-cdn-cache-status: MISS ``` * A few examples: - [https://www.englishtruffles.co.uk/truffles-about/truffle-cooking-gallery/](https://www.englishtruffles.co.uk/truffles-about/truffle-cooking-gallery/) - [https://www.englishtruffles.co.uk/truffles-about/history-of-english-truffles/](https://www.englishtruffles.co.uk/truffles-about/history-of-english-truffles/) - [https://www.englishtruffles.co.uk/truffle-hunting-shop/](https://www.englishtruffles.co.uk/truffle-hunting-shop/) * Thanks. * Thread Starter [James](https://wordpress.org/support/users/james-feaver/) * (@james-feaver) * [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919698) * Typical, having written the reply, you check again (Firefox this time) and all is good, go back to Edge and all good! * Thank you again so very much. I’ll mark this as closed. Viewing 9 replies - 1 through 9 (of 9 total) You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fperformance-impact-11%2F%3Foutput_format%3Dmd&locale=en_US) to reply to this topic. *  * [FAZ Cookie Manager](https://wordpress.org/plugins/faz-cookie-manager/) * [Frequently Asked Questions](https://wordpress.org/plugins/faz-cookie-manager/#faq) * [Support Threads](https://wordpress.org/support/plugin/faz-cookie-manager/) * [Active Topics](https://wordpress.org/support/plugin/faz-cookie-manager/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/faz-cookie-manager/unresolved/) * [Reviews](https://wordpress.org/support/plugin/faz-cookie-manager/reviews/) ## Tags * [cookie policy](https://wordpress.org/support/topic-tag/cookie-policy/) * 10 replies * 2 participants * Last reply from: [James](https://wordpress.org/support/users/james-feaver/) * Last activity: [2 weeks, 5 days ago](https://wordpress.org/support/topic/performance-impact-11/#post-18919698) * Status: resolved