Home > Programming, Servers & Scripts > Hosting, Servers & Security

Is Render-Blocking JS & CSS Really a Big Deal? (And a DNS question too) (6)


10-18-2016 10:52 PM #1 elskafreya (AMC Alumnus)
Is Render-Blocking JS & CSS Really a Big Deal? (And a DNS question too)

Google Page Insight and a couple of other tools are telling me that some Javascript and my CSS delivery are slowing the page down.

The javascript is mypage/js/button.js

The css is my stylesheet.

I know that some solutions are to take the javascript out of the header, which makes sense to me, but Google also has a suggestion...that as far as I can see, involves rearranging or replacing it in a way that might make the JS itself slower, but the page load faster for everyone who's encountering it for the first time? I can't tell exactly.

I'm also still in the early stages of testing my page speed...getting 300ms some places and up to 2.5 seconds in other places. I'm running tests from different test sites, in as many locations as possible, to get Cloud Front to propagate.

I'm using my Namecheap Dashboard to handle DNS, which I did according to Amazon instructions. Still I don't know if this is slowing me down significantly. Some of the page speed tests seemed to indicate it might be...but I can't tell for sure!


10-18-2016 10:57 PM #2 elskafreya (AMC Alumnus)

Also, the page isn't currently mobile-responsive. I"m about to go through a tutorial on how to do that with Bootstratp. NOt sure if that will make things better or worse? It sounds like the JS issues are going to be biggest on phones.

I'm not specifically targeting mobile devices, but I am running POF traffic and have no idea how much there is mobile. So far it's not something I have tracked.


10-19-2016 04:27 AM #3 erikgyepes (Moderator)

How big is the slowdown for that JS?

Remember that those testing tools are not always 100% correct, it's just a benchmark.

If you are getting 300ms that's pretty good, anything below 500ms you should consider great!

If you get more from other locations, perhaps those locations are geographically more far from your server location?


10-19-2016 03:57 PM #4 elskafreya (AMC Alumnus)

You know, as far as I can tell, it's not slowing down the actual download speed much. My biggest thing seems to be "first packet", but I don't know if the JS affects that.

Thanks for those benchmark numbers btw. I'm often getting 300-500ms in the US, but sometimes as much as 2+ seconds. And often about 1.25 seconds.

I might be still "warming up" my CDN (Cloudfront).

Maybe will just try putting JS in the footer and compressing my images.


10-20-2016 05:41 AM #5 erikgyepes (Moderator)

The warming-up stuff is quite interesting, just did a search on it and here is what I've found:

If you use Cloudfront as a cache onto your own servers, you'll have noticed that the first request for a resource can be very slow, whilst Cloudfront fetches your content and stores it in S3 or whatever it is that it does.

So, when you push out new assets, you want to prime the caches by requesting each new asset. It's not enough to just do a simple HTTP request, though, because each cloudfront host is handled by multiple different IP addresses. Moreover, the IP addresses you get back depend where in the world you make the DNS requests from.

So, we first make requests for each of our cloudfront hosts from as many public DNS servers around the world as we can find. Once that's done, we request every cloudfront URL from every cloudfront IP that we've found. Hey presto, toasty-warm caches.
There is a script for it written in Ruby, but it's like 6 years old stuff: https://github.com/chrismay/warmfront

But wouldn't it be enough to just run some cheap traffic from your geo to it and the warm-up will be done? The more traffic you will run the better it should be isn't it?

Also compressing images is a must, you can use tools like kraken.io, tinypng.com or optimizilla.com.


10-20-2016 06:50 AM #6 zeno (Administrator)

Don't bother with warming up your CDN distribution. The fact is you won't cache to that many end points by doing so, and the first user pulling from a PoP is going to cause caching anyway. So unless you are advertising to a dozen people per day, chances are the CDN nodes are going to working fine very quickly.

As for the first packet - I presume you mean time to first byte (TTFB) or the connect/wait times. Usually this will be most dependent on the user/test server --> your server connectivity i.e. the opening of a connection.

This is strongly dependent on connectivity distance, and user connection (e.g. on mobile there's probably going to be an extra 300-1000 ms just from carrier overhead).

Would be much easier to comment with a screenshot of a loading waterfall.


Home > Programming, Servers & Scripts > Hosting, Servers & Security