26

If website load time is a concern, which is generally better to use when referencing a JavaScript or CSS file? Would using a CDN be better or would that just add more HTTP requests?

5 Answers 5

19

The CDN should be used for all static files (.css/.js/images).

Sometimes however javascript or css files can have dynamic aspect to them such as that it would include a unique user string or something of that sort. In this situation the CDN server would have to contact the origin server on every request which would defeat the purpose.

If your CSS and Javascript is static for all users then using a CDN is the right way to go. This would not cause any extra HTTP requests because it would only load the css and js files from the CDN instead of your own webserver (unless you are using inline code). So instead of a users browser loading these requests from your server they would be loaded via the CDN, there is no additional requests you are just changing where to send these requests (again as long as you are currently not using inline code).

Other benefits from using a CDN would be that the CDN server would most likely be located closer to your end users then your origin which will benefit loading times. The CDN servers are also likely setup to serve static content much faster then your origin server by specifically catering the web server for static content.

2
  • 3
    If the CDN is not nearer and doesn't use edns-client-subnet it's not going to improve performance at all. This is not an "other benefit", being nearer the client, possibly providing some DOS protection/content optimization (though you don't mention these) are the only benefits.
    – symcbean
    Commented Apr 6, 2016 at 22:39
  • 3
    The main benefit using a CDN is the fact that most likely the user already visited a website that used the same CDN and the browser already cached it, so when the user arrives to your website the browser won't send any request.
    – Offir
    Commented Dec 1, 2019 at 10:10
5

Using a CDN vs traditional web hosting for delivering your static files such as CSS, JS, and images is commonly preferred. This is because once your files are cached on the CDN's edge servers, your site visitors will be delivered static content from the closest point of presence (PoP) instead of the origin server.

In the majority of cases, this shortens the distance between the client and the server and thus helps improve loading times without adding any additional HTTP requests. This also helps in other areas such as increasing redundancy, taking a load off the origin, etc.

4

Use a CDN if you need a CDN. If your user is global and spread over a large area, or you have a lot of such content that you don't want to store on your own server, that is when a CDN is useful. Globally, it can speed up access to your content if the server is closer to the user. If you have many GB or Terabytes of static data and a heavy load for access to that content, a CDN can help with that.

However, small, local sites or lightly loaded sites rarely need such things and a CDN can only add one more complication to your set up, operation and workflow, such as caching problems.

Too often I see people use a CDN cause they read they should be using one and no other reason.

2
  • Thanks for pointing out it's not always required and indeed adds unnecessary complications. In my case I'm using a laravel based cms with a backend assets combiner and caches minifed files setting up an S3 cdn, gulp and vc on few js files was a waste of time. I'd rather focus on DB caching and proper code for speed Commented Nov 26, 2017 at 4:14
  • @Rob, upvoted. As my father once told me, "Always use the right tool for the job." Doing something quick-and-dirty, sure use a CDN. Doing production code, concur with Rob, because it follows the KISS principle. Commented Sep 27, 2020 at 12:33
4

Hosting on a CDN has many disadvantages:

  1. Privacy. Everytime you go to a site that hosts scripts/stylesheets/fonts on a CDN, the CDN knows about you visiting the site.
  2. Offline time. In the last weeks cloudflare etc had some hours, where their loading time was very slow or even offline for some minutes. In the best case your site looks ugly, when that happens, in the worst its completely unuseable in a time, where your competitors have problems, too, and you could get customers of them if your site was online and theirs not.
  3. Security. The CDN can be compromised (it happened before). In the best case your server spreads malware then, in the worst your data is now public or gone.

Compared to that the advantages are insignificant:

  1. Less data to load: we talk about some 100kb of scripts per site. 1 image in low quality does account for more than that. If you dont have a website that is on its limits with like 5.000.000 visits per minute, it will not make a difference. And if, you probably should set up a better server environment with load balancer and more webservers, because using CDNs will not solve your problems.
  2. Faster loading times, because CDN servers are closer to the client: in times, where the latency from EU to US is about 100ms for nearly all connections, the css gets loaded in 50ms or 100ms.

Theres like zero reason for using a CDN on a production environment.

1

Using a CDN can be both a burden and a benefit to a website, all depending on how it has been implemented.

Positive Points

  1. Static content stored closer to the end user (faster loading times)
  2. Additional sub-domains (cdn1.example.com, cdn2.example.com, etc), this assists with the inherent limit in browsers where they limit file downloads to two simultaneous files from the same fully qualified domain name at any one time. In other words using this example you would access HTML from www.example.com and all the while be downloading 2 files from cdn1.example.com, 2 files from cdn2.example.com, and 2 files from cdn3.example.com with all three CDN domains accessing the one CDN service and source.
7
  • Can you give a reference from where the "2 simultaneous files per domain" come? It is certainly per browser. Also with the advent of HTTP/2, Domain sharding became a moot issue. Commented Jul 2, 2019 at 15:49
  • @PatrickMevzek the limit of 2 comes from the HTTP/1.1 RFC (w3.org/Protocols/rfc2616/rfc2616-sec8.html). IE7 was the last major browser to enforce this (which was already virtually unused in 2016 when the original answer was written). Note that even as of Aug 2021, it's still only 67% of all websites that support HTTP/2 (httparchive.org/reports/state-of-the-web#h2).
    – Peter
    Commented Aug 11, 2021 at 8:57
  • @Peter Can you highlight precisely which sentence says that? Sharding (per different domain) is indeed a known workaround, but limits were different per browser (I think I have read most often 4 or 5 simultaneous connections per domain for Firefox for example) Commented Aug 11, 2021 at 14:32
  • @PatrickMevzek: "A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy." w3.org/Protocols/rfc2616/….
    – Peter
    Commented Sep 22, 2021 at 14:27
  • @Peter Please double check the definition of "SHOULD NOT" (it is different from "MUST NOT") and RFC2616 is now obsolete and superseeded by RFC7230 to RFC7235 and none of them have this sentence anymore... Commented Sep 22, 2021 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.