23

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?

18

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
  • 2
    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
    Apr 6 '16 at 22:39
  • 2
    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
    Dec 1 '19 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

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.

3

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 Nov 26 '17 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. Sep 27 '20 at 12:33
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. Jul 2 '19 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
    Aug 11 '21 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) Aug 11 '21 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
    Sep 22 '21 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... Sep 22 '21 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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