WebPagetest Forums

Full Version: TFB: Long idling times for all assets, especially the static ones on a CDN
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi, I am trying to figure out the rather slow time to first byte on the website of a friend of mine, where each asset is idling up to several seconds and I have not really a clue what could cause the idling for especially the static assets. The page is on a shared hoster. It is a WordPress Multisite. All assets (CSS, JS, images, fonts) are hosted on Cloudfront. The trace for the homepage regularly loaded is the following:


He exchanged the dynamically loading page for testing purposed with a static html page:


The idling is insignificantly shorter and still too long anyways. What might be the reasons for those delays? Cuz basically I've thought those intervals should be way shorter cuz especially the static assets are just directly accessed with no server work necessary. :/ I am bit of ideas. The only thing that might be changed could be the hoster for the WordPress site, but that wouldn't have any effect on the accessed files on the CDN. Aside that no idea. Any suggestions anyone? Best regards Ralf
The first visit of a resource through a CDN is usually slower as it needs to be pulled from the origin server to the CDN (Cloudfront in this instance). If you test the site twice the second test should load the assets from the CDN much faster as it can be downloaded directly from the CDN. You may need to test and tweak the expiry headers on the origin server and Cloudfront to ensure CF isn't pulling the original file unnecessarily from the origin server. i.e if the resource expires on CF after 4 hrs it will pull the original file again on the next visit .

I'd recommend switching hosts as it's taking a long time (1.4s) just to download a 52kb image:

The origin server is the real bottleneck here. It does not have keep-alive enabled which will double the latency, as the CDN will need to reconnect to the server to download each resource. This plus the long SSL handshake and the fact the CDN will be downloading in parallel over HTTP/2 where as the origin server likely won't be, will further compound the load time. So look for a host that has keep-alive enabled and HTTP/2 and it should load a lot faster.
ahhhh thanks a lot! I haven't used CDNs at all so far so i haven't had the regular transfer of assets between server and CDN on my radar. But that makes totally sense. Thanks a lot for raising the awareness on my side. Wink And i've forwarded your suggestion to my friend as well. He is already testing a new hoster for the origin server at the moment. And results look promising in comparison to before as you suggested. Smile
Reference URL's