shift8

Hello,

Lets put the bandwidth not displaying issue aside for a moment while we look at site speed issues.

I did a few quick tests to see why the site is loading slow and it looks like a significant amount of time the browser is spending “waiting” for the main web server to respond.

You can see the results of the Pingdom speed test here : https://tools.pingdom.com/#5c9727dd91400000

In total, from a North American endpoint, the for full site load (which includes rendering and executing all code on the page) it took about 45 seconds (!) to complete this. You can see a screenshot of the key takeaway that illustrates the waiting time just to render the main site url (this excludes our CDN from the problem as you can see in the hostname) : https://imgur.com/a/zCVwWgf

Furthermore I did a network latency test from our Canadian endpoint to your site (your domain appears to resolve to a StackCP IP) :

# tcptraceroute www.montessoripartnership.com 443
traceroute to www.montessoripartnership.com (185.151.30.162), 30 hops max, 60 byte packets
 1  144.217.72.252 (144.217.72.252)  0.680 ms  0.779 ms  0.907 ms
 2  10.34.66.10 (10.34.66.10)  0.442 ms  0.597 ms 10.34.66.38 (10.34.66.38)  0.757 ms
 3  10.74.8.152 (10.74.8.152)  0.140 ms 10.74.8.156 (10.74.8.156)  0.167 ms 10.74.8.118 (10.74.8.118)  0.134 ms
 4  10.95.81.8 (10.95.81.8)  3.069 ms 10.95.81.10 (10.95.81.10)  1.868 ms  2.090 ms
 5  be100-1323.nwk-5-a9.nj.us (192.99.146.139)  7.816 ms  7.833 ms be100-1319.nwk-1-a9.nj.us (198.27.73.205)  8.128 ms
 6  be100-1007.ash-5-a9.va.us (198.27.73.219)  13.394 ms  13.612 ms be100-2.nwk-5-a9.nj.us (178.32.135.219)  8.283 ms
 7  be100-1007.ash-5-a9.va.us (198.27.73.219)  13.317 ms ash-eqx-01gw.voxility.net (206.126.236.169)  359.147 ms ash-5-a9.va.us (178.32.135.47)  13.540 ms
 8  * ash-eqx-01gw.voxility.net (206.126.236.169)  388.946 ms  367.564 ms
 9  * * ash-eqx-01gw.voxility.net (5.254.81.129)  383.129 ms
10  185-151-30-162.ptr4.stackcp.net (185.151.30.162) <syn,ack>  386.013 ms ash-eqx-01c.voxility.net (37.221.173.74)  565.343 ms 185-151-30-162.ptr4.stackcp.net (185.151.30.162) <syn,ack>  378.929 ms

Look at what happens right after hop #7, the latency shoots up from 13ms to 367ms. Something is going on either with your Web host or with StackCP (if both are the same thing, not sure) that is causing this problem.

It might be worth while to provide this data to your web host and see what they say. It could be an issue with the host or even a routing / network issue. I dont have any visibility so these are all guesses. Last resort you could always change web hosts, there is no shortage of options out there!

Thanks and I hope this is helpful. I’ll look into the bandwidth reporting issue separately but I will close this issue for now. Feel free to update still if you have any further questions.

Thanks!

Sam,

Thank you for using our service first of all!

I took a look and it is indeed strange that bandwidth isn’t being reported correctly. One possible reason for this is that you are using two CDNs right now (StackCDN and our CDN).

I’m sorry to hear that you are not seeing a visible speed improvement. Its not a standard practice to layer up CDNs like this because it might cause problems with headers, CORS and other unforeseen issues to be honest.

I will still try to investigate further but it would be helpful if you could go to the support section of our plugin settings in WordPress and copy all that debug info and paste here so I could take a look?

Thanks!

Hello – I’ll close this task for now.

If the icons are being loaded via lazy loading, that has been known to be an issue with the way the CDN rewrites. But it wont break the icons it just wont load them from the CDN. Try disabling lazy loading and see if that fixes it.

Please email us directly if you still want support.

Thanks!

Hello!

You reached out to us directly and we resolved this question over email. I will paste the response here for others to see.

Yes Cloudflare should work with Shift8 CDN. Here’s how :

[1] Request for site -> [2] Shift8CDN -> [3] CloudFlare CDN -> [4] your webserver

For requets for your site (#1) , it will the majority of the time hit #2. When the cache is stale and our CDN fetches a new copy, it will hit cloudflare (#3).

Using #2 and #3 in the description above means even less requests are actually hitting #4 (your web server). It should offer an improvement but you could experiment with our CDN settings in the plugin settings to set whether media, JS/CSS files are to be routed through our CDN.

You can use tools.pingdom.com to test speed before and after every change to see for yourself as well.

Thanks!

I’m closing this issue as its more of a feature change at this point. I will continue to investigate this and roll it out any necessary improvements in a future update.

Hey there!

You emailed us directly and we resolved it for you.

The issue is if you enter a URL for the CDN dashboard but that url has a 301/302 redirect to correct it (i.e. adding a www or an extra slash). The CDN cannot handle this redirect right now so it can cause it to not work.

We fixed this by re-entering the site in the dashboard to be the true destination URL (as you would see when first loading in your browser).

We will work towards having better checks in place to catch this mistake in the future, but for this issue it is at least resolved.

Thank you for your interest!

I’ll continue looking into this – I appreciate your understanding. You are correct in your assessment, it would be much more efficient to keep the asset longer.