Help with long wait times...and not sure if Cloudflare or host is delivering content


#1

Greetings all,

I’m using Cloudways hosting with a DO New York server to run a WooCommerce store. We advertise to both Europe and the US. I have done the basics such as minifying / compiling the CSS / Javascript / HTML on the store first, and linked up to Cloudflare. Below are my settings which i think are relevant.

Speed: Auto minify=CSS off (breaks site), Javascript on, HTML on / Rocket Loader = Automatic
Crypto: SSL=Strict / Always use Https = On / Automatic HTTPS Rewrites = On
Caching: Caching Level = Standard / Browser Cache Expiration = 4hrs
Page rules:

On my hosting side, I’m using Cloudways’ new caching plugin Breeze which seems to be working slightly better than W3TC.

I ran test on Pingdom / Webpagetest / GTMetrix on 3G throttle and I noticed the huge discrepancies in the load speeds, which I thought a CDN like Cloudflare is suppose to minimise. For example in the screenshot below, the highlighted image is taking 2s+ TTFB response, and if I’m interpreting correctly it’s served from Cloudflare.

Image-20170823-2108-002

GTMetrix Test location London on 3G throttle: 3+ seconds wait time

Rest of results here from Singapore / France / UK / San Francisco, all on 3G throttle.
https://www.webpagetest.org/result/170823_1E_d9ecbdae99018a42d41c2380466271aa/
https://www.webpagetest.org/result/170823_R6_93edb15cc6df5d4f30e3ab303db2f4c2/
https://www.webpagetest.org/result/170823_W2_9a72a5d0679c5ab30923162a19062a92/
https://www.webpagetest.org/result/170823_0S_0db236abd4f8f0bd180543ea02d0bb3e/
https://www.webpagetest.org/result/170823_KS_c4325ec2dfb869fde5119704ddc143d3/


https://gtmetrix.com/reports/www.cratemill.com/qj2Hp5uG

One big bummer is San Francisco. On the same continent, but takes 18s to load with 1.6s ttfb. On New York where the server is based, the results are good of course. But quite a letdown to see everywhere else suffering from long load times.

https://www.webpagetest.org/result/170823_B3_271b1d408962253bb7cac223aa9c00ba/

Why is the performance so bad? What am I missing?


#2

Well a couple of things.

  1. Your page rules are ordered backwards (assuming you ever wanted rules 2 & 3 to fire). Only 1 rule will apply to a given url and the way you have it set up the first rule would apply to any requests that are contained in the second and 3rd rules.

  2. Your rules are for the root domain, but you redirect all requests to www so none of those rules apply to any of the requests which are being made (add * or www. before to match the pattern depending on your needs).

So all of the requests require at least one trip to origin for the shop page currently because cache everything isn’t applying. Beyond that… there’s ~= 2.6MB of data being returned on that page and the tests were performed over 3g. That’s a fair bit of data for a mobile device to pull down for a single page.

Check the page rules at a minimum to see if that helps at all (assuming the intent was to cache to html itself with your page rules).


#3

Thanks!

I’ve reversed the page rules, and added the wildcard. It should look like cratemill.com/ correct?

Also, I made the changes 2 hours ago and checked webpagetest, the results still look similar. The waiting times seems just as long in Pingdom, nothing like the awesome ping shown in the following thread:

My pingdom stats from San Jose, Dellas, Stockholm



Is there something else I need to check, or do I have to wait longer for the changes to propagate?


#4

Changes propagate pretty quickly typically. Only other major caching related thing I see is that the html pages themselves aren’t cached and we have to go back to origin for those because there’s an explicit no-store; no-cache;must-revalidate being set on those pages.

I think that would generally account for the perf difference you’re seeing between POPs as NYC POP which is closest has the best load time for the html page from origin and the perf generally gets worse as the distance increases.

Looking at network utilization on the tests, the image downloads seem to pretty much max out the allocated bandwidth (or come close to it) for a large portion of the main images load and then more appear to be called via ajax later in the page load process. So potentially there is some opportunity for optimization there in the code along with image size.


#5

Thanks for your help! I’ll check with my hosting if the server is using those no-cache settings.


#6

Hi again,

I tried disabling CF to compare, and this is what I got. The results from Webpagetest.org shows some differences after disabling CF, but no consistent pattern.

For pingdom however, it was faster across the board after disabling CF.

Recap: results before disabling Cloudflare
https://www.webpagetest.org/result/170823_1E_d9ecbdae99018a42d41c2380466271aa/
https://www.webpagetest.org/result/170823_KS_c4325ec2dfb869fde5119704ddc143d3/
https://www.webpagetest.org/result/170823_0S_0db236abd4f8f0bd180543ea02d0bb3e/
https://www.webpagetest.org/result/170823_R6_93edb15cc6df5d4f30e3ab303db2f4c2/
https://www.webpagetest.org/result/170823_W2_9a72a5d0679c5ab30923162a19062a92/
https://www.webpagetest.org/result/170823_B3_271b1d408962253bb7cac223aa9c00ba/



Disabling Cloudflare
Screenshot of Cloudflare admin

Results after disabling Cloudflare
https://www.webpagetest.org/result/170826_4G_ca59c6de36b4f3bc8ad697087741ceff/
https://www.webpagetest.org/result/170826_BS_530a1b5626570af970958eb60a9725eb/
https://www.webpagetest.org/result/170826_VJ_09929b2b0aaafb790b8f1913da1fd190/
https://www.webpagetest.org/result/170826_CP_8d5d681801d43de7b91dcca96375bd91/
https://www.webpagetest.org/result/170826_97_6d83d93a13e6b161fb5af1cb83fa30a0/
https://www.webpagetest.org/result/170826_3V_c5c126a994d6b3a464a1187b0914d622/



There’s a “cf-cache-status: MISS” before I disabled CF.
Image-20170826-1218-001

Regarding that no-store; no-cache;must-revalidate, those disappeared after disabling CF.

BEFORE

AFTER

The pingdom score kind of suggest that CF is simply re-routing the request back to my host server right? Any ideas where to check / fix next?

UPDATE:
Cloudways responded saying since the no-store; no-cache;must-revalidate issue disappeared after disabling Cloudflare, the issue is on Cloudflare.

My understanding from your support page is that cache headers are issued by the origin server to CDNs, and set by origin server admin. Please advise.