4 ms·

Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. I have put anycast SSL termination in front of sites before that ha

by jabart 8y ago

Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. I have put anycast SSL termination in front of sites before that have also decreased the ssl connection handshake, which barely beats CloudFront or CloudFlare on a decent day. If I had the money I could use Akamai which I know my ISP has before it even hits the internet, no way I could make my web server faster than that. It is not a performance de-optimization. If you have 8mb of JS, sure you should break that up, but you have 8mb of JS and that is your first true problem. I aim for about 400kb or less of JS, on a marketing website it may change once a quarter, so I really don't care and they are all first time users anyway. For a web application, I also don't care because if they are mobile they need that in one request, gziped to like 40kb, so the hours it would take to optimize for the single byte changed is still a performance budget of 80ms.

acdha 8y ago
> Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. For you, with warmed caches. The problem is that most users aren't you and so when they follow a link to example.com their client makes that first DNS request for example.com, starts the connection and TLS handshake, etc. and then sees a request for e.g. cdnjs.com and does that same work again for a different hostname. If (in that example) you were hosting your site on CloudFlare you'd have the same work for the first connection but not the second because it'd already have an open connection by the time your HTML told the client it needed your CSS, JS, etc. Here's an example: check out https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8a67d3b1b6473e66d3/1/details/#step1_request1 https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8... and notice how often you see “DNS Lookup” and ”Initial Connection” times which are a significant chunk of the total request time — and ask yourself whether it would be better for the render-blocking resources to have those times be zero. Especially measure how that works on a cellular or flaky WiFi connection, which is closer to what most people experience in the real world. As to the gigantic bundle of JavaScript, do some real browser testing and ask whether it's better to wait for the entire resource to be loaded before any code runs — and to repeat that entire transfer every time one byte changes — or only block on the portions needed to render the page. Yes, having 8MB of JavaScript is too much in aggregate but the solution is to use less and use it more intelligently, not slap it all into a big ball of mud.
- jabart 8y ago
  Those DNS lookup times for Azure are in fact terrible, no DNS query should take 400ms. You can pre-lookup DNS using html header tags, but nothing fixes a slow DNS query like that, that is a failure of the Azure Edge DNS servers. I do real browser testing, and have Real User Monitoring setup to prove the results. Page load times from 600ms to 1.2s reported from the clients browser. I measure and test our app on 3g connection including the high packet loss 4g signal I get at my house. The point of my comment was that HTTP2 is not a fix all issues with performance on a site. The Webpagetest result would not have loaded in 2 seconds if they switched to HTTP2. Its 400 resources is what is slowing it down, not http/1.
  - acdha 8y ago
    Look at the times for Google where they loaded jQuery: because it's using an external CDN, the initial connection time (80ms) is greater than the total transfer time (69ms) on a relatively fast connection. It would be faster to serve it from your own server and then you also don't have to deal with things like SRI to maintain the same level of security.

by jabart 8y ago

acdha 8y ago

> Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. For you, with warmed caches. The problem is that most users aren't you and so when they follow a link to example.com their client makes that first DNS request for example.com, starts the connection and TLS handshake, etc. and then sees a request for e.g. cdnjs.com and does that same work again for a different hostname. If (in that example) you were hosting your site on CloudFlare you'd have the same work for the first connection but not the second because it'd already have an open connection by the time your HTML told the client it needed your CSS, JS, etc. Here's an example: check out https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8a67d3b1b6473e66d3/1/details/#step1_request1 https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8... and notice how often you see “DNS Lookup” and ”Initial Connection” times which are a significant chunk of the total request time — and ask yourself whether it would be better for the render-blocking resources to have those times be zero. Especially measure how that works on a cellular or flaky WiFi connection, which is closer to what most people experience in the real world. As to the gigantic bundle of JavaScript, do some real browser testing and ask whether it's better to wait for the entire resource to be loaded before any code runs — and to repeat that entire transfer every time one byte changes — or only block on the portions needed to render the page. Yes, having 8MB of JavaScript is too much in aggregate but the solution is to use less and use it more intelligently, not slap it all into a big ball of mud.

jabart 8y ago
Those DNS lookup times for Azure are in fact terrible, no DNS query should take 400ms. You can pre-lookup DNS using html header tags, but nothing fixes a slow DNS query like that, that is a failure of the Azure Edge DNS servers. I do real browser testing, and have Real User Monitoring setup to prove the results. Page load times from 600ms to 1.2s reported from the clients browser. I measure and test our app on 3g connection including the high packet loss 4g signal I get at my house. The point of my comment was that HTTP2 is not a fix all issues with performance on a site. The Webpagetest result would not have loaded in 2 seconds if they switched to HTTP2. Its 400 resources is what is slowing it down, not http/1.
- acdha 8y ago
  Look at the times for Google where they loaded jQuery: because it's using an external CDN, the initial connection time (80ms) is greater than the total transfer time (69ms) on a relatively fast connection. It would be faster to serve it from your own server and then you also don't have to deal with things like SRI to maintain the same level of security.