• Resolved vonsa

    (@vonsa)


    Hi,

    I’ve been trying to fix this issue for a week now, and SiteGround technical support have still not even acknowledged this issue.

    I’ve just tried disabling Memcache, which led to my sites being totally unaccessible on the front end. This seems to be resolved now and back to the old issue.

    Main issue:
    At the link below you can see some varying loadtimes, the proper loadtimes are all x-proxy-cache: HIT and the slow ones ~5 seconds are all x-proxy-cache MISS:
    https://ibb.co/ScqRxpt

    I’ve already provided more extensive information in the ticket which I opened, unfortunately after back and forth with the support team the response I keep getting is about general optimization etcetera. It’s taking a really long time now and my business is leaving bad impressions all over the place.

    Is this issue related to your caching services or not? I just want to move on.

    You can find my account as organization name: Vonsa

    P.S. for my main site vonsa.nl I’ve disabled SG optimizer all together for now and replaced this with WP fastest cache which is not ideal but so far does not seem to produce the same issue. Still testing.

    • This topic was modified 4 years, 12 months ago by vonsa.
    • This topic was modified 4 years, 12 months ago by vonsa.
Viewing 15 replies - 1 through 15 (of 18 total)
  • We’ve had a similar problem as well. SG Optimizer’s caching engine is unstable in my opinion.

    We do, however, use both Cloudflare and WP Rocket, so we “tweaked” a few things to minimize the X-Proxy-Cache = MISS issue.

    Here’s what we did:

    (1) Turn off then turn on MEMCACHE in your cPanel, then turn off then on in SG Optimizer’s plugin.

    (2) Do not use two caching plugins at the same time. In our case, we installed the plugin, Disable Page Caching, and our X-Proxy-Cache issue improved.

    (3) If using WP Rocket, in Settings, turn off Mobile Cache and User Cache (click here: https://prntscr.com/rckphq).

    (4) When you clear your cache (back-end and front-end) don’t expect to get X-Proxy-Cache = HIT the first time you visit your site. Will happen at the 2nd or 3rd visit.

    In any case, yes, SG Optimizer’s caching engine is still quite unreliable. We’ve opened several tickets on the issue and it’s still not a “slam dunk/case closed” issue.

    Hope this helps.

    Cheers!

    Thread Starter vonsa

    (@vonsa)

    Hi Jetxpert,

    Thanks for your contribution! Really appreciate that.

    SG optimizer is actually the only caching plugin I’m using right now, trying to keep it simple and minimize issues.

    I’ve deleted the cache folder manually now as well and looked for remnants of other cache (could not find any, but I’m not good at searching for this), not sure if it will make any difference.

    Did they progress the issue on your end?
    Now they are sort of basically saying that this is all normal behavior. But in my eyes that would make it non effective, which seems strange to me.

    I’ll keep you up to date about progress/solutions!

    All the best,

    Coen

    @vonsa,

    Thank you!

    Here’s another tip …

    To ensure your X-Proxy-Cache tests are accurate and reliable, use the following URLs or methods:

    (1) https://securityheaders.com
    (2) https://tools.keycdn.com/curl
    (3) https://www.keycdn.com/support/popular-curl-examples

    Note: To use and/or install cURL, follow the instructions given below. If you are using Windows 10 Version 1803 (or later), you already have cURL installed in your laptop/pc. Quite easy!

    https://www.thewindowsclub.com/how-to-install-curl-on-windows-10

    Last, when you perform your tests, make sure you always clear your local cache (CTRL + F5). Once you clear your local cache, you may notice a change in your X-Proxy-Cache results.

    Cheers!

    Thread Starter vonsa

    (@vonsa)

    @jetxpert

    Thanks once more for your contribution ??

    What has concluded from my Siteground ticket, which I’m not sure if true, since they seem to have a hard time pinpointing what my ticket is about (so take it with a grain of salt):

    – Their dynamic cache is flushed alot, less than once each hour in my case. Possibly even way shorter if you think about bots (do these stimulate cache creation?) which are visiting the site.

    – Their static cache can make your website slower depending on your installation / installation of plugins etc. They advice to use another caching solution in this case.

    – As they store dynamic cache in their RAM, this type of caching is significantly faster than other types of caching. Which I must say results in very much improved results, going from ~3.5 seconds to ~1.3 seconds.

    This behavior however does not seem useful in many situations. Let’s say you only have a few site visitors each day, in this case SG optimizer cache will only be slowing the site down for them (in my case). As my site will load in about ~4 seconds instead of the dynamically cached ~1.3 seconds.

    I’m really unsure if this is all true, and in this case:
    Why SiteGround does not provide an option to automatically generate cache after flushing. Even having more traffic will at least probably still mean you have ~12 visitors each day that do not benefit from dynamic caching, increasing bounce rate alot for these users. It will require more server resources but the benefit could be very well worth it, especially during peak hours.

    Possibly an experienced dev which is not part of the SiteGround team, will look into it for me later and possibly I’ll be able to provide any other information that could be relevant.

    Could you confirm all this Stanimir Stoyanov?

    All the best,

    Coen

    • This reply was modified 4 years, 12 months ago by vonsa.
    • This reply was modified 4 years, 12 months ago by Yui.
    Plugin Author Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    @jetxpert what do you mean by the SG Optimizer caching engine is unstable? It works perfectly fine and the way it is supposed to work. The problem is that people use too many optimization plugins together and some plugins / themes pass on headers they should not be passing anyways that cause lower hit to miss ratio.

    @vonsa first, I would advice you to disable Memcache. Since you are not certain you actually need it I would disable it just to eliminate another variable that might be a potential issue. It handles dynamic hits only, so it should be out of the equasion anyway.

    Let me quote your other questions so I don’t miss something:

    – Their dynamic cache is flushed alot, less than once each hour in my case. Possibly even way shorter if you think about bots (do these stimulate cache creation?) which are visiting the site.

    The dynamic caching is flushed when there is a change on your website – post published / deleted, comment approved, plugin installed, core updated, etc. etc. We monitor all hooks to make sure that cache is flushed properly. Plus, we do not invalidate all the cache all the time but we do it in a smart way depending on the event.

    This said, you need to look into your site and figure out what is causing this behaviour – do you have many comments for example? Or is there a plugin that causes such behaviour. Maybe you’re spammed somehow. I can’t tell more without knowing your site URL / ticket ID, something so I can actually troubelshoot this.

    – Their static cache can make your website slower depending on your installation / installation of plugins etc. They advice to use another caching solution in this case.

    This is not true. The static cache has nothing to do with your plugins / themes. It works on a server level and caches static resources until their last modify parameter chandes. I don’t know exactly what my colleagues told you or if it is out of context or something else but this is just not the cae.

    – As they store dynamic cache in their RAM, this type of caching is significantly faster than other types of caching. Which I must say results in very much improved results, going from ~3.5 seconds to ~1.3 seconds.

    Yes, pretty much ??

    I’m really unsure if this is all true, and in this case:
    Why SiteGround does not provide an option to automatically generate cache after flushing. Even having more traffic will at least probably still mean you have ~12 visitors each day that do not benefit from dynamic caching, increasing bounce rate alot for these users. It will require more server resources but the benefit could be very well worth it, especially during peak hours.

    Simply put because in order to pre-generate the cache we need to hit it. This will add bogus info to your stats and will increase the load on the server. Your math is not right because the cache is life span is updated upon hit. This means that if you have a popular piece of content and you don’t make any changes to your site it might be cached indefinitelly ??

    Thread Starter vonsa

    (@vonsa)

    Hi Hristo,

    Thank you alot for your response, finally someone who is responding to the subject. And thank you for being precise and responding extensively.

    The dynamic caching is flushed when there is a change on your website – post published / deleted, comment approved, plugin installed, core updated, etc. etc. We monitor all hooks to make sure that cache is flushed properly. Plus, we do not invalidate all the cache all the time but we do it in a smart way depending on the event.

    This said, you need to look into your site and figure out what is causing this behaviour – do you have many comments for example? Or is there a plugin that causes such behaviour. Maybe you’re spammed somehow. I can’t tell more without knowing your site URL / ticket ID, something so I can actually troubelshoot this.

    I guess it could be a plugin that is triggering one of your hooks which is causing a lot of flushing. Otherwise I honestly don’t know, because it’s happening on sites that are completely without posts/comments/page/plugin/theme/css/js changes and does not have any woocommerce/products functionality.

    So strange that talking with SiteGround tech support for over a week, still has them saying it’s all normal behavior and I should do speed optimization. I don’t think they even provide correct information and don’t ask about the situation this is happening in. I’ve sent them screenshots showing hourly gtmetrix charts, all tests indicating that cache is not being loaded. However they do a test and get cache hit result and totally ignore the subject..

    This is not true. The static cache has nothing to do with your plugins / themes. It works on a server level and caches static resources until their last modify parameter chandes. I don’t know exactly what my colleagues told you or if it is out of context or something else but this is just not the cae.

    This is my question and a quoted response from one of the senior technical support staff, take in consideration that this ticket has been going on for a week now, and my patience is running out a little bit in that ticket:

    – Why is your caching making my site slower than not using caching at all? Should static cache (which should be flushed every 3 hours according to a post on your website) not shorten loading times?

    Without any cache:
    https://gtmetrix.com/reports/vonsa.nl/ZW9kYjaW
    https://tools.pingdom.com/#5c2d55c7a1800000

    With cache:
    https://gtmetrix.com/reports/vonsa.nl/x1pNWjUW

    “SG Optimizer is a software built and dedicated to our hosting environment and its purpose is to ease the optimization of client’s WordPress sites. As a piece of software, it has its pros and cons, but it manages to speed up the performance of the majority of websites which has it activated. Unfortunately, there are plugins/themes which are not fully compatible with SG Optimizer and sometimes this could affect the speed negatively. We strive to provide as much reports as possible to the developers of the plugin and many bugs and issues are fixed in future updates. Still, if you believe your sites are slower when SG Optimizer is enabled, you should disable it and replace with another caching plugin.”

    So what should static cache be doing in terms of performance boost? As it does not seem to do anything for my installation, even showing increased loading times during tests and showing the x-cache miss.

    Simply put because in order to pre-generate the cache we need to hit it. This will add bogus info to your stats and will increase the load on the server. Your math is not right because the cache is life span is updated upon hit. This means that if you have a popular piece of content and you don’t make any changes to your site it might be cached indefinitelly ??

    Sorry for my incorrect math, this is only due to my experience with trying to relate GTmetrix / pingdom testresults to what SiteGround tech support is saying.
    pre-generating cache should not be necessary if cache is indeed stored for longer periods of time, as you indicate.

    Additional info:
    Ticket ID: 3485799
    URL 1: vonsa.nl
    URL 2: lezzjeansfashion.nl

    I will test tonight if there is a plugin stimulating the cache purge. You have my permission to do some investigation in cpanel, the wordpress installation etc..
    Both domains are using different plugins, and lezzjeansfashion should be the most basic and without any other caching/optimalisation activated for that webshop.

    All the best,

    Coen

    • This reply was modified 4 years, 12 months ago by vonsa.
    Thread Starter vonsa

    (@vonsa)

    Things really seem to be getting out of hand:
    https://gtmetrix.com/reports/lezzjeansfashion.nl/Hw50BI8j

    There is a 12.5 second wait here on the initial https request.

    Response Version – HTTP/2.0

    cache-control no-store, no-cache, must-revalidate
    content-encoding gzip
    content-length 35041
    content-security-policy upgrade-insecure-requests
    content-type text/html; charset=UTF-8
    date Tue, 10 Mar 2020 11:00:46 GMT
    expires Thu, 19 Nov 1981 08:52:00 GMT
    host-header 624d5be7be38418a3e2a818cc8b7029b
    link <https://lezzjeansfashion.nl/wp-json/&gt;; rel=”https://api.w.org/&#8221; <https://lezzjeansfashion.nl/&gt;; rel=shortlink
    pragma no-cache
    server nginx
    set-cookie PHPSESSID=b074e2e30d1970df3615ef63d2c449ee; path=/
    set-cookie wpSGCacheBypass=0; expires=Tue, 10-Mar-2020 10:00:45 GMT; Max-Age=0; path=/
    status 200
    vary Accept-Encoding
    x-cache-enabled True
    x-proxy-cache MISS

    Request Version – HTTP/2.0

    :authority lezzjeansfashion.nl
    :method GET
    :path /
    :scheme https
    accept text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
    accept-encoding gzip, deflate, br
    accept-language en-US,en;q=0.9
    upgrade-insecure-requests 1
    user-agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

    Thread Starter vonsa

    (@vonsa)

    I’ve possibly found the issue, will update later.

    Plugin Author Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    Let me know what you’ve found!

    Thread Starter vonsa

    (@vonsa)

    The issue is only happening when SiteGround’s Gzip function is active, any ideas?

    Plugin Author Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    Probably some other plugin interferes with the lines added to the .htaccess file.

    hi Hristo,

    I am getting pretty much the same x-cache miss issue and also use both WP-Rocket and SG Optimizer.

    I did notice that both add the same lines to the htaccess file automatically, and will add it back if you try to remove it from it.

    How can I prevent that? What is the best way to keep both plugins working together? To install the WP-Rocket disable caching plugin?

    Also my SG Optimizer dynamic caching isn’t currently working properly, which is most likely due to a compatibility issue between both…Many thanks for your kind support!

    Best regards

    Plugin Author Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    I would completely remove WP Rocket and use only the SG Optimizer.

    I am only using the SG Optimizer plugin. I was noticing that the dynamic cache is flushing without any updates, comments, plugin changes etc. I found a note here:

    https://www.siteground.co.uk/kb/siteground-dynamic-caching-configuration/

    which says that the dynamic cache is flushed every 12 hours. I asked SIteground technical support about this today and they confirmed that the cache is flushed every 3 hours.

    This really makes this plugin unusable for a website with few daily visitors as all they are doing is priming the cache which will disappear pretty quick anyway.

    I currently have an open ticket as my dynamic cache is not generally lasting more than 10 mins. I will let you know what they come back with.

    @kvnhnf,

    Have you solved your issue? If not, let me know and I’ll guide you on how to use both SG Optimizer and WP Rocket together with no MISS issues. We use both plugins and our website performs great. Using SG Optimizer alone created a lot of issues for us and/or never gave us the performance benefits that SiteGround claims. We have the data to prove it.

    @confusedneedhelp,

    Looking forward to your update.

    Cheers!

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Sites often indicate x-proxy-cache miss and loads extremely slow’ is closed to new replies.