Warning All Users – Browser Cache No Longer Works!

  • Resolved Ray

    (@burnimage)


    2 years, 12 months ago

    Litepseed Cache now no longer serves the expires headers that *YOU* set in Browser Cache settings. After extensive tickets with my host it appears that Litespeed Cache have decided that *ALL* pages are news pages. So NONE of your static pages, taxonomies or posts now display the expires headers that *YOU* instructed the plugin to do so. (One month to one year etc).

    THERE ARE SIMPLY NONE DELIVERED NOW – WHATSOEVER !!!!!!!!!!

    You will all be getting warnings in every page test accordingly.

    According to my host, tickets with the Litespeed team confirm that this change is DELIBERATE !!!!!!!

    Currently, this plugin is UNUSABLE.

    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
    • This topic was modified 2 years, 12 months ago by Ray.
Viewing 15 replies - 1 through 15 (of 23 total)
1 2
  • Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    A temporary workaround is to add this to your .htaccess file:

    <IfModule mod_expires.c>
FileETag MTime Size
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
ExpiresActive On
ExpiresByType text/html "access 1 year"
</IfModule>
    • This reply was modified 2 years, 12 months ago by Ray.
    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    Please understand , the LSCWP never put Expire header on HTML page , but only to static resources

    and when you do this , you will risk that page being cached by browser and no longer receives update from your edit

    like you edit a page and update its content, but browser may continuously serve the cached version from its local cache , instead of fetching from server again.

    the cache system in WordPress is all the server-side cache , by that saying , you can always control , update or flush the cache on your side.

    imagine you have a Woocomerce site , you have a product that sells for 10 dollars , and then today you raise it to 15 dollars , but for a repeated visitor , he or she may still see the product is priced at 10 dollars due to browser cache , and at that point , you will have problem with the customer and I am sure that’s something you don’t want to

    and once page is cached by browser , you will have hard time to get it freshed to new content unless you tell users to clean up browser cache or force refresh.

    • This reply was modified 2 years, 12 months ago by qtwrk.
    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    This used to work fine. Google themselves state that you should deliver an expires policy of a minimum of one month and preferably one year:

    https://developer.chrome.com/docs/lighthouse/performance/uses-long-cache-ttl/

    This used to work fine. Basically you are confirming that Google is wrong and you guys are right.

    So, every user of your plugin is now being mugged. We all *think* the plugin is honouring our browser cache settings in the plugin.

    But you’ve decided to *completely ignore this*

    Therefore, the browser cache settings in the plugin are now *USELESS* as you ignore them.

    You have lost the plot……

    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    well, if you read the page you provided , as my mark in screenshot , you will see it referred to static resources

    and further more , if you scroll the page to bottom , where it gives link to wordpress document here: https://wordpress.org/documentation/article/optimization/#browser-caching

    where , again as my mark in screenshot , it is meant for static resources

    as simple explanation , the page generated by PHP , is typically considered as Dynamic resources , and where the files like javascript , CSS , or images , that don’t usually change , or not changing frequently , are considered as Static resources

    the plugin’s browser cache will add Expire header to these static resources , but not to dynamic resources

    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    Yep, static resources might be, but in my case, every post, page and taxonomy on my entire website •*S A STATIC RESOURCE*. But you guys have have decided otherwise.

    So, once again, you have rendered the browser caching section of your plugin *UNUSABLE* as you now *COMPLETELY IGNORE USER CHOICES*

    This means that for every user of your plugin there is now *NO EXPIRES INFORMATION EVER*

    • This reply was modified 2 years, 12 months ago by Ray.
    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    In other words, you guys have decided that every fixed page, post or taxonomy is, in your opinion, now a “dynamic resource” and WILL NOT HAVE A CACHE EXPIRES HEADER.

    How the heck did you guys suddenly decide that *EVERY* page for *EVERY USER* is now a dynamic resource?

    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    if you check the browser option tooltip , it clearly indicates this option is meant for static resources only

    and I can assure you , our plugin has never ever set Expire header on dynamic pages whatsoever , you can check our source code in Github for its history commit or just directly download previous versions here

    and if you wish , you could continue to use the htaccess workaround you posted , but please remember , when or if one day you hit a weird issue like your change doesn’t reflect in page in browser , new comment doesn’t show up …etc that kind of outdated content and cache doesn’t get purge kind of issue , that is related to this.

    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    Pages, taxonomies and posts *ARE STATIC RESOURCES* unless we tell the plugin otherwise!

    Like I said, the plugin now considers *EVERY PAGE TO BE DYNAMIC*

    Thus, the browser cache part of the plugin is now BEYOND USELESS

    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    no , we don’t decide what is static or what is dynamic, it is “industrial standard” as people classify PHP generated page as dynamic , and files like JS/CSS/IMG as static.

    You may think your pages to be static, but not others, as I have explained to you, we follow the industrial standard, if you have your own special standard, then I would suggest using your workaround for your need.

    certainly, it’s not big trouble for us to add this, it’s just like few lines of code , but please understand, many people will mis-understand and mis-use it, and believe me , as support staff here for years, I have witnessed too many people misuse the browser cache header to their pages and end up issues like page not getting new content.

    Then they came here and blamed our plugin that broke their site, until I explained to them how and why it happens due to the browser cache on dynamic pages.

    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    The problem is that the plugin has now decided that *EVERY* page is dynamic. So it now *NEVER* delivers the correct expires headers.

    When did your users give you permission for *YOU GUYS* to decide that every post on WordPress is now *DYNAMIC* ???????????????????

    • This reply was modified 2 years, 12 months ago by Ray.
    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    Let’s follow the logic. So the browser cache settings on the plugin are pointless and should not be there in the first place. Why? because the plugin only applies them to static resources. But the plugin has decided that things like homepages etc are dynamic.

    What a load of nonsense!!!!!!!!!!

    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    you probably have misunderstood the page cache and browser cache in wordpress.

    the page cache ,is applied to all wordpress generated page , that is what called page cache , or server-side cache in wordpress , so when page is cached , it doesn’t invoke PHP to generate page again , thus to save time and resources, and most importantly , once page content is changed , the server-side page cache can be flushed in time and be able to deliver new content to visitor.

    the browser cache is meant to be static resources , where files like JS , CSS , IMG can be cached by browser , so on a repeated visitor , his or her browser only need to check or fetch the main page from server again , but all these static resources will be directly loaded by browser , that is the properly usage for browser cache

    this is also explained in the document you provided from google

    it is dynamic request as it is generated by PHP , that is simple and clear , and the reason for no apply browser cache over wordpress page , is because it will prevent users to see new content after site owner has updated his or her site.

    and if you check the wordpess official site like wordpres.org or wordpress.com , or even just this very topic you and I are communicating , they are either not having expire header at all , or set to a backward time to effectively force the browser to fetch from server again , otherwise if your browser cached this page, you will not even see my replies

    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    I have misunderstood nothing. Fixed content should be cached, for a minimum of one month and preferably one year.

    Dynamic content should not be cached.

    We are all clear on that.

    The problem is that the plugin has decided that *ALL* content is dynamic, not fixed. Therefore it *NEVER* delivers the cache expiry policy selected by the user in the plugin under any circumstances !!!!!!!!

    Therefore, the browser cache section of the plugin is useless, as it does not honour user selects!

    • This reply was modified 2 years, 12 months ago by Ray.
    Plugin Support qtwrk

    (@qtwrk)

    2 years, 12 months ago

    yes , that’s correct , as I have explained the reason for we do not apply browser cache header over WordPress pages

    I apologize for the inconvenience you may have experienced with this approach and I am sorry if you are upset or mad with it

    but as sorry as it is , that is how thing is , and since you have your own workaround already , then please use that.

    Thread Starter Ray

    (@burnimage)

    2 years, 12 months ago

    There is no point to the browser caching section of your plugin and you are misleading EVERY user of your plugin. Millions of homepages, posts and the like are being delivered with ZERO expires policy. Despite users thinking otherwise.

    This used to be a great plugin. But this issue is so massive and I find it beyond comprehension that you guys think otherwise!

    OMG and wow!!!!!!

Viewing 15 replies - 1 through 15 (of 23 total)
1 2

The topic ‘Warning All Users – Browser Cache No Longer Works!’ is closed to new replies.