Since every time a web browser requests a page, we are almost certain that there are .css and .js files to be sent as well. Why do we wait for the browser to parse the DOM and discover those files before issuing a request for the CSS and JS files? The server has the HTML files and knows all the links to other resources. Why doesn't the server say "Hei, you want foo.html? here you go, but you would need also foo.js and foo.css"? Has this been considered? What are the drawbacks of this solution?

It is not the browser, it a server implementation. Let's say IIS or Apache, pre-scans the html and discovers all the CSS and JS include in each specific html page.

  • 2
    HTTP/2 solves this problem. Look it up. – RibaldEddie Aug 4 '16 at 19:20
  • 2
    If the server were to send things just because they're linked in the page without your browser requesting them, that would be push technology. Pages have links to all kinds of files. Browsers request .css and .js because they need them to render the page but, for example, when you download an html page with wget it doesn't request .css or .js from the browser. – Tulains Córdova Aug 4 '16 at 19:50
  • 1
    @mben: Actually, when the browser requests those files is an implementation detail. – Robert Harvey Aug 4 '16 at 19:51
  • 1
    @MBen I just ran wget -q -U Mozilla -O apple.html http://www.apple.com and it only downloaded the index.html file of the Apple website (which I named apple.html). No .css, .js or jpg etc. – Tulains Córdova Aug 4 '16 at 19:56
  • 2
    @MBen: are you suggesting that the server should send all referenced documents without the client explicitly requesting them? So, what if I search something on Google, and I get 30000 results. Should the server send me all 30000 referenced sites? If not, why not? How does the server decide which references to send and which not? – Jörg W Mittag Aug 4 '16 at 20:07

Your question seems to assume that all of these resources are coming from the same source. But that's not how the World Wide Web works.

The browser's prevailing (and correct) assumption is that resources can come from anywhere, and in fact they often do. This is why we can stitch together web pages from many different resources, and have them appear as if they are a single document.

Javascript files are often served up from CDN's. Sourcing them from a CDN has certain technical advantages, like high performance and availability. Browser caching takes care of any remaining problems.

  • Yes I thought about CDNs, but thought this could be good for local resources – MBen Aug 4 '16 at 19:48
  • 1
    The prevailing assumption still applies. Resources can come from anywhere. You can have relative URLs like ..\somefile.js indicating a local resource, but the browser still has to parse the page to discover that information. – Robert Harvey Aug 4 '16 at 19:49


By sending them separately, a web browser can just cache the CSS and Javascript files, and reuse them when another page calls for the same file, skipping additional requests. If they're merged into the HTML file by the server, then the browser just sees a new unique file each time, and thus has to download the same CSS and Javascript content each time.

CSS and JS might not be wanted at all

As Tulains Córdova pointed out in the comments, there are programs that can be and are used to download HTML files, but which will not request any linked CSS or Javascript files (and cannot, since they can't parse HTML).

Additionally, some browsers won't request the Javascript files when Javascript is disabled.

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.